As my consulting partner
Thad Scheer and I prepare to give a keynote at this week's SAIC SOA Industry Day, we've been working hard on a succinct definition of Service-Oriented Architecture. It has to go beyond the simple definition of a "bunch of related web services" since SOA is quite a bit more than that. However, because SOA is a complex and rich architectural concept, oversimplifying it can do real harm too.
In the end, we've decided to keep the definition simple but focus beyond the obvious. To be effective, SOAs should probably be described as being foremost about abstraction, with services exchanging messages in the language of the domain. And once you have a basic service landscape with a common (or at least similar) vocabulary, the good stuff can happen: SOAs then become environments of ubiquitous and autonomous services that dynamically interoperate to achieve common goals. This is also known as orchestration and is usually the most compelling aspect of intentional SOA architectures.
By designing services to speak a common language, and then by wiring them together in a loosely coupled fashion (i.e. BPEL, BizTalk, etc) to provide integrated functionality, SOAs can create an extremely strong yet highly pliable architectural fabric. This fabric can propel an organization forward to achieve the technical and business goals they desire like very few other architectural approaches.
Figure 1: Checking the Contract and Invoking the Service with Loose-Coupling
What does this have to do with service description and the ongoing SDL comparison? Building large, federated SOAs is still quite difficult, especially when you have to incorporate services outside your firewall. Part of this is because of the ongoing standards story, or fragmentation thereof. While
SOAP and
WSDL still have an airtight lock on the web services standards story, other approaches have evolved.
REST services, the Semantic Web (RDF & OWL), and others have inevitably been creeping in from the sidelines and any decent SOA will have to determine how to embrace them.
An overarching SDL that could describe 90% of the types of services in common use would really help. So would one that makes it easy to consume a service, is straightforward to use, and promotes service-orientation. The details I've spoken about in my previous posts so I won't belabor those points, but I do very much like the service-orientation precepts I came across this weekend at serviceorientation.org.
A Tour of a Loosely-Coupled Web Service C# Client Using WSDL 1.1
I was hoping it was going to be fairly easy to build a client for our canonical Order SOAP service. As I blogged about previously, the client should dynamically check its service contract (here) for existence, location, binding, operations, and schema. Once the contract has been examined to ensure that it hasn't changed unacceptably, the client can use simple XMLHTTP to construct the XML SOAP envelope and place an order with the SOAP service via HTTP. In the client posted here, I even pull the current location of the service from the WSDL service description in case it changes, thus making the client even more resilient and dynamically compliant with the service contract (though certainly, it brings up security issues).
Since we never leave XML, the client is wonderfully straightforward and can handle pretty much any format that XML Schemas can hand out. Like we've discussed before, this is one of the common problems with code generated from service descriptions; it often can't be mapped to the local language though the XML/programming language mapping issue will continue to be a hot topic in the community. The second part is the kicker, since we check the contract only for the bits of the service we use, the client's relationship to the service is highly loosely coupled. The way I constructed the client, you can add operations, change the order schema, move the service, and as long as you haven't changed a part that I care about, it all works.
Loose-coupling is one of the most important concepts of SOA. Since you are wiring together many or even most of your organization's (and others) services together, making the dependencies between them brittle in any way can be disasterous. Finding a technique to make the connections between SOA services reliable yet supple can be an important success factor, and my experiences with this approach so far have been very positive.
The crux of the contract checking process is to use easy-to-understand XPath queries on the service description on a periodic basis. How often is up to the user, but since it's quite fast, I don't see why it can't happen very often as long as thousands of operations a minute aren't the norm. If they are, you can scale back the frequency of contract checking depending on the level of reliability required.
The source for the Loosely Coupled C# WSDL Order Client is here. It's still a bit crude, and we'll clean up things as we go. You'll need to use tlbimp to build an interop DLL for MSXML2 and build the client with the command-line C# compiler, like so: csc oc /r:msxml2. For the faint of heart, the C# Order Client executable is here. You can place orders and check on them in one single command-line operation. The source code has details in the comments for how the contract checking is done in XPath for WSDL 1.1. To see the orders from the server side, I have a dynamically updated web page of the currently placed orders. Note: Comments and criticisms are welcome, the more scrutiny the better.
Now that it's done, I was actually quite surprised how straightforward contract checking WSDL was. With a well-documented pattern I think the average programmer could do it without much trouble. That wasn't what I was expecting necessarily and I'll be very curious to see how the other SDLs check out in this regard. One issue of course is that the service and schema being used are fairly simple. We might have to do a sanity check against a more complex service but that will have to wait until the comparison is done.
Next: The same client in Java and Ruby and then we pick another SDL.
Technorati: Enterprise Architecture, Computers and Internet, Programming, Web Services