Welcome to MSDN Blogs Sign in | Join | Help

Welcome to The Metaverse

Navigating the service-oriented, identity aware metaverse

News

  • Disclaimer:
    The content of this blog are my own personal opinions and do not necessarily represent Microsoft's position, commitments or strategy. In addition, my thoughts and opinions often change, and as a weblog is intended to provide a semi-permanent point in time snapshot you should not consider out of date posts to reflect my current thoughts and opinions.




    Add to Technorati Favorites
Does SOA introduce new/original architectural concepts?

James McGovern asked in a recent post: "Would love to see you explain why SOA isn't an architectural style? Do so in your next blog entry at your own risk". I thought I would take a stab at clarifying what I meant when I opined that: "Service Orientation does not prescribe a particular architectural style".

Anyone who has been involved in software or systems architecture during (at least) the last 30 years will be well aware of the many guiding principles that we (at least try to) follow when we design computer systems. Many of these principles are based upon bitter experience. Some are based upon common sense. The Patterns Movement popularized by the Gang of Four, Martin Fowler, etc, has gathered together commonly-found architecturally-sound patterns that can be readily applied to real systems.

During all these shifts from Today's buzz-term is  "Service Oriented Architecture" and we're told that this is the silver bullet that we've all been waiting for. We're told that it's fresh, it's new and that it requires us to completely rethink how we've been designing software thus far.

I disagree.

To me, and many others with whom I have enjoyed discussing this subject with, Service Orientation is the minimal set of guidelines that help us design and architect systems whilst avoiding much of the ambiguity that currently complicates our world and which will help redefine the assumptions we make when designing a system to help us adopt a more pragmatic view of the world and to design systems that are more flexible, agile, resilient and usable than systems we might have architected in the past.

Sound architectural principles are sound architectural principles for a given bounded scenario. Many of these principles are applicable and appropriate to a to a given bounded scenario regardless of the architectural approach or methodology we use - be it object-oriented or service-oriented. The principles of Service Orientation are equally of value when building a distributed system using a traditionally object-oriented technology such as J2EE or COM+ as they are to those building Web Services using JAX-WS or WCF. Let's not confuse architectural principles with particular technologies which may have gained popularity at some point in the past but have since been superseded by more appropriate technological approaches.

Hope this helps clear up my comments before. Let me know if you think I am wrong.

Posted: Monday, November 28, 2005 10:41 AM by RichTurner666

Comments

Shaun Bedingfield said:

I agree with you on SOA. I think that it is not a silver bullet. The long period, which it has taken for the concept to become any form of reality, proves this. How has the world really changed since the terms SOA and web services have changed? (Not from the developers view but the end user)

The prime goal of SOA is to provide services rather than websites. For example, rather than having to send a user to a page to track a package. You can send a service the package number, get the user's information and then present it through your own user interface.

This would allow for stronger integration of multiple websites because a site can use a service rather than send the user to another website. Collaboration has always been a hard problem and SOA just changes the language. It does not make the problem easier. It will always be hard to get multiple companies to work together to provide end user solutions. As we grow the ability to communicate, we run into the problem of orchestration. How do we combine the use of multiple services to provide a useful result? What is the workflow? We may need to intelligently combine the results of ten web services to get the results we want and if we want too much flexibility we run into the problem of chatty interfaces that traditionally do not fare well in a networked environment.

If we limit the problem to the web, communication between companies has traditionally not been a large problem. Most websites provide one service, information. Here, the problem is entirely different. How do we organize the huge amounts of information in a way that helps our users? We provide portals so users can find the right information and forums, blogs, and use groups so users can share ideas. We are still not very good at creating digital librarians that can aggregate the information the user wants so they only need one website instead of hundreds. Knowledge management is a huge problem of which this is only one aspect.

Crossposted to my blog at blogsb.blogspot.com
# November 28, 2005 5:09 PM

RichTurner666 said:

Thanks for posting your thoughts Shaun. What you describe here are indeed the benefits of adopting a Service Oriented mindset. I have written frequently here on this blog (and on a few others too) about how changing our fundamental assumptions and approaching the design of systems as sceptics rather than optimists will generally result in much more successful implementations.

You're absolutely right also that the "web" in "web services" means little other than SOAP/HTTP. In the services world, this is not even an implementation detail - it's an infrastructure detail.

Services are a way of encapuslating behaviour and information in a way that is immesurably more flexible and reusable than pure "objects" ever gave us. Service Orientation is the evolutionarily-influenced approach we need to take to successfully design tomorrow's systems.

A Service Oriented Architecture is something a system owner designs in order to fulfil a given set of requirements in a way that doesn't just adapt to change in the future ... it embraces change and is made the better for it.
# November 28, 2005 9:04 PM

Anil K Sharma said:

I agree with Rich.

The guiding principles for service orientation are not new.

In past, Architects had designed systems with XML interfaces, so that other systems could interoperate easily.

Building business functionality with maximum re-use was alway a key principle that has driven architects. We have seen SOA adoption by customer using legacy technology. The level of adoption was dependent effort required to create such interoperable end-pts of functionalites.

What we have seen is that the enabling technologies for service orientation become more & more mature with the concept of SOAP or XML web services. The adoption & investment to create services is now trivial.

- Anil K Sharma

# November 29, 2005 2:09 PM

Roland Trevino said:

The problem with silver bullets is that they only exists in lore. No one really makes silver bullets when lead is available and so much cheaper. SOA has great attention because it theoretically provides that silver bullet. But again, silver bullets only exists in stories and the value add of SOA is theoretical. The value add only surfaces within an enterprise when the entire enterprise is able to convert to pure SOA. That means converting legacy SNA, old monolithic clinet/server, DCE, CORBA, EAI, (the last integration architecture that promised the same thing) and whatever else distributes within the enterprise not falling the umbrella of SOA (not likely to happen). The proponents herald, "Loose Coupling! Flexibility!, Adaptability!, etc.! etc.!" But this only occurs within the SOA container. Right now this is restricted to basicaly the J2EE and .NET containers. Remember there is a big big enterprise out there with much more then the J2EE and .NET containers. Yes, Yes, Yes, I know all we have to do is wrap all the legacy and other distributed stuff in a loosely coupled interface of an SOA enterprise and Wahlah! we've got an SOA styled enterprise. But so far in industrial strength enterprises this has not happened because no matter how much we don't like it, management hates it when we tell them we're going to fix something that is in thier view, not broken. If it finally does happen, SOA will be obsolete and the next great integration architecture (if it's even called integration then) will be bannered.
# November 29, 2005 4:47 PM

RichTurner666 said:

LOL! :) I like your analogy Roland ... I hope you'll forgive my extending it a little: I can't help wondering if "SOA" as a technology isn't something more bovine, rather smelly and malleable into bullet shaped items spray painted with silver.

You're also absolutely right that platforms and technologies which readily enable adoption of Service Oriented principles and practices are most prevalent in the most recently updated platforms - .NET and Java.

Having said that, some of the most successful SOA projects I have seen over the last 3-4 years have been existing established systems which were carefully constructed using proprietary technologies and which are extremely agile, flexible and sophisticated ... and interoperable through simple message exchanges (CSV anyone?) via standard transports.
# November 29, 2005 6:03 PM

Charlie Bess said:

I agree that the concepts are not new, it's just that it is being discussed at a different level. We used to talk about reusable components and sharing information primarily for a single application or function. Now we are viewing it as more of an enterprise or trans-enterprise service. It may be a subtle change, but the implications on organization governance and the possibilties once it is in place can be quite different.
# December 2, 2005 12:17 PM

Buz Word Man said:

Absolutely, and SOA is not the only new Buzzy Thingy these days that repackages concepts and patterns from the days of yor… you know like in 1995. Back in 95 we were using our own tag based packages for request-response communications using sockets. Who knew!

With the passage of time comes standardization and libraries etc., that reduce development time and bring old technologies to the masses rather than just the educated few. And don’t forget those all important Buzz Words that enable managers to take all the credit hehehehe.
# December 5, 2005 10:59 AM

Martín Cabrera said:

I think the main problem is that we have a lot of buzz-comercial material surrounding SOA and few articles that really covers the main architectural challenges that we have to face with SOA. For example...how can we do to really design a service contract based on messages and not on remote operations?...how can we design a service contract that is really reusable across the enterprise?...aren't we transferring too much complexity to the service client if we design too generic services?

My conclusion is that SOA it is not introducing new architectural concepts...the main point is that we have to work in the kind of issues that i mention to really implement SOA.

Regards.
Martín.
# December 5, 2005 11:21 AM

Rohan Thomas said:

http://msmvps.com/blogs/rohanthomas/archive/2006/01/26/81858.aspx
# January 26, 2006 12:41 AM
Anonymous comments are disabled
Page view tracker