As I get everything in place to conduct the
web service description language survey, I'm trying to get the contract and message exchange pattern (MEP) for the test service down right. Capturing a fairly typical web service situation will be important to ensure we're exploring a genuine usage scenario and learning as much as possible from a practical experience.
Besides the contract and MEP, the client side programming model will also make things exciting, and it should probably be proxy-less (see below for a discussion). I also really like Dave Orchard's 80/20 guideline that he's been using in developing WDL, and it's a metric I'll be keeping in mind to see if it helps us deal with SDLs. And in the interest of supporting those folks who might be following along with their own client development, here is my approach on how to deal with the service and the service contract/description.
I've talked numerous times on what I think service-orientation is, but its essence is enabling ubiquitous access to a service while eliding non-essential technical details. In practice, this means using open standards-based communication and data representation methods, such as HTTP and XML, while eschewing a focus on a particular location, transport, or programming language. That's not to say that the technical details aren't important. They are. It's just that they're not important to the basic function the service provides to its clients.
Figure 1: The (DRAFT) SOAP/REST order service structure for SDL comparison
For this survey we're trying to get a handle on how and why web service description languages actually help clients consume web services. In the wild (i.e. non-homogenous environments) you will very likely have clients using your service from platforms, languages, and tools you never imagined. It therefore seems obvious that a good web services description language will foster interoperability in the presence of entirely unanticipated client environments. This is the ubiquity part of service-orientation. And I'll go out on a limb and say if an SDL doesn't make it almost effortless to understand how to interact with a service, it's not a good SDL.
Over the next few years, as alternative platforms and new languages such as Ruby emerge and become popular, it's a bad idea to assume there will be good tool support for a given web service description language (even WSDL). This means that often there will be no code generation of client-side stubs. I think this means the rule here is for SDLs to encourage being programmer informative in favor of being tool informative. During the survey, we will be keeping a close eye on SDLs to see if they emphasize one or the other.
This brings us to the subject of loose-coupling. The beauty of XML-based services is that they allow the structure of a message to be amended and modified without throwing out your entire understanding of the message, or greatly impacting your ability to use the new structure. This means you can add items to a XML service message without fundamentally breaking it, or a client (as long as you haven't changed the particular pieces they depend on.)
So this is the second reason code-generation can be bad, at least if it adds any brittleness to this model. The rule here is if the service makes changes to the message you don't care about, it should require no changes to the client. Obviously, the client must be written properly in order to support this, but the service and its SDL should encourage this as well
One thing that it would help though, is for everyone to agree that loose-coupling means changes to a service shouldn't break your client code as long as the change is not a direct dependency. But it also would help greatly to tell when (and exactly how) a service contract has changed, so at least you have the option of verification. This gives us a third rule for the survey: While contract changes should NOT break the client for indirect dependencies, contract changes should be visible, and straightforward, first class citizens. It will be interesting to see how contract changes will affect things for the various SDLs we'll be taking a look at.
The Order Service (click here)
Right now, we have two operations online and working: placeOrder and getOrderStatus. Both use the exact same order schema. One takes an order and persists it behind the service boundary, waits 5 seconds, and then updates the delivery date to today's date. The second returns the full order construct, and if you've waited more than 5 seconds, you'll get the delivery date. Obviously, we're using request-response on both of these, though we can change it if we think that's not sufficient. Both the SOAP order service and its WSDL contract can be found here. We'll start building the C#, Java, and Ruby clients soon using the WSDL 1.1 defined for this service. Then we'll proceed through the list of SDLs and describe the service again and generate new versions of the clients for each SDL as needed.
And, once we finalize the SOAP order web service at http://hinchcliffe.org/order.asmx, we'll then build out the REST version of the order web service. I'm still figuring out how to try to consume each SDL since I'll have too much knowledge of how to do it after the first client is built. At least, we'll see if the client can detect service contract changes, and report them, but ideally we'll be able to use part of the contract information to do schema validation and other interesting things.
BTW, part of my inspiration for all this is David Ing's wonderfully irreverent post on The Four Horsemen of the SOA, please check it out as it's a great sanity check on where we're going with service-orientation. Hopefully, as we go along with the survey, we'll throw the harsh, practical light of reality on service-description approaches and see if we're heading in the right direction. And as always, suggestions are very welcome.
Finally, thanks much to Tim Bray for his kind posts that have been keeping visitor traffic coming on this subject!
Technorati: Enterprise Architecture, Computers and Internet, Programming, Web Services