|Home • Patterns • Ramblings • Articles • Talks • Download • Links • Books • Contact|
SOA's and Drunk Driving
January 17, 2005
|DDD - Diagram Driven Design|
|What Does It Mean to Use Messaging?|
|A Chapter a Day...|
|Clouds and Integration Patterns at JavaOne|
|My First Google Wave Robot|
|Into the Clouds on New Acid|
|Design Patterns: More than meets the eye|
|Reflecting on Enterprise Integration Patterns|
|Google Gears Live From Japan|
|Double-Dipping: OOPSLA and Colorado Software Summit|
|Enterprise Mashup Summit|
|Facebook Developer Garage|
|Mashups Tools Market|
|Mashups == EAI 2.0?|
If you have a Web browser and are interested in Web services you probably have not escaped the discussion around SOA, REST, Web services etc. I am going to let the REST argument rest for for the time being (pun intended), but want to share a few thoughts on Service-oriented architectures. By now most people agree that a service-oriented architecture is not a specific technology, but rather a design philosophy or architectural style. Web services technologies make implementing this architectural style convenient but are by no means the only technology choice. For example, one can build fine SOAs using CORBA, even though the nagging question might be "why would you?" (Steve V., please forgive me!).
So what is an architectural style? Roy Fielding defined it in his oft cited thesis as follows:
"An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style."
Essentially, an architectural style describes what elements we can work with (for example, filters in a Pipes-and-Filters architectural style or objects, interfaces and classes in an object-oriented architectural style. The style also defines the rules and constraints on how the elements can be composed. For example, in a Pipes-and-Filters style, filters have input and output ports that can be connected to pipes whose purpose it is to transport messages from one filter's output port to another filter's input port. One constraint is prescribes that you are not allowed to connect one filter directly to another filter.
There are more formal definitions of architectural styles, which enable the formal expression of the constraints in architectural design languages (ADLs). I touched on them briefly in a prior posting, so I won't repeat them here.
So what are the design elements and constraints that make up a service-oriented architecture? The elements of an SOA are services, self-contained modules that are universally accessible and advertise their interface contracts via some form of registry. Hao He has defined the following architectural constraints for SOAs:
These principles are some of the main ingredients into making SOA's loosely coupled. Interfaces hide implementation details and services communicate by exchanging documents rather than by invoking methods directly on another service.
We often underline the advantages of loosely coupled, service-oriented architectures by comparing them to the prior architectural style, namely distributed component (DC) architectures. This is only natural. It is hard to define the optimum architectural style for a given category of applications. Instead, it is much easier to learn from the shortcomings of the last attempt and to correct them based on incremental evolution. In the case of distributed component architectures, the shortcomings we set out to fix include the following:
Note that some of these problems are inherent in the architectural style (e.g., tight coupling) while others are merely byproducts of popular implementations of the style (e.g., vendor lock-in). For practical applications, though, both kinds of problems are relevant factors in the adoption of Service-oriented architectures.
We can easily see how service-oriented architectures based on the Web-services standards and specs resolve these issues. They are (somewhat) vendor neutral, have a simplified, loosely coupled interaction model, and are based on an asynchronous document-passing model that allows for communication over partially connected networks.
So it seems that SOAs solve all our problems. Well, at least the ones we had with the distributed component architectures. But there remain two nagging thoughts. First, if SOAs are largely driven by the desire to cure problems in the prior style how can we be sure that SOAs are in fact the best approach or are they maybe a sub-optimization of the problem? And, more importantly, what other problems do they introduce?
Collective learning and vendor adoption cycles in our seemingly fast-moving field are often surprisingly slow. Object-oriented development took about a decade from early adoption (SmallTalk, early C++) to the preferred mainstream style of development. Given the long cycle times and the reactive nature of defining a new style via the weaknesses of the old style, we start to wonder whether we are really converging on a good style or whether we are swaying back and forth like a drunk driver who is swaying back and forth across the street trying to avoid hitting the curb. Every time the curb comes near the driver yanks the steering wheel in the opposite direction, causing the car to sway in the other direction until it is about to hit the other curb.
So are Web services and SOAs over-compensating the perceived issues with distributed component architectures? Are we heading for the curb on the opposite side? Sometimes I feel like that's what's going on. For example, distributed component architectures are too tightly coupled and brittle. A few levels of indirection can help resolve that but I think UDDI was aiming hard for the other curb by trying to make service discovery so generic that it became difficult to use. Likewise, we discovered that the object-oriented interaction model of instantiation and method invocation is too complex and chatty for network-based communication. So we fixed that with the document-oriented model. But is passing a document to a totally stateless service really sufficient for many real-life scenarios? What if I need a reply back? What if I don't have all required information available to assemble a single document? How about more complex conversations, transactions etc? Many of the WS-* specifications like WS-Addressing etc are trying to address these shortcomings. But then if I look at the dozens of WS-* specifications, where is the simplicity that we were aiming for?
It will be interesting to see where the Web service evolution balances out or whether we'll hit another curb. It will also be interesting to see what the next best thing will be. One can't blame the business users for asking "How can you be sure you got it right this time? First you tell me terminals and mainframe hosts are all the rage, then it is client-server, then 3-tier, then distributed components and now SOAs. What's next?" I kind of have to agree with the end users but at the same time I have no idea what will be next. But we can be assured that once SOAs reach wide adoption all marketing departments are itching to define the next major trend...
MORE RAMBLINGS SUBSCRIBE TO GREGOR'S RAMBLINGS
Gregor is a software architect with Google. He is a frequent speaker on asynchronous messaging and service-oriented architectures and co-authored Enterprise Integration Patterns (Addison-Wesley). His mission is to make integration and distributed system development easier by harvesting common patterns and best practices from many different technologies.
|© 2010 • All rights reserved.|