Wonder what this meansIn his most recent article, RDF Roundup, Edd Dumbill refers to WS-I via the unlikely tag "WS-mess". I suppose he could be suggesting that WS-I recognizes and is attempting to address the "mess" which in the context of his article is the plethora of WS-* specifications.
If you look at all the WS-* specifications being published the first thing you're likely to say (as your eyes glaze over) is "wow there sure are a LOT of them". The thing which puts things into persective is understanding that when you go to produce a Web Service you only use the specifications required to do the job, and in most cases that'll be a very small subset of the WS-* family. That's actually why there are so many of them, rather than write one massive specification those developing the Web Services specification set decided to produce many small ones, and to make it possible for developers to use combinations of them to tackle different tasks. So although there are Web Services specifications out there which apply to building Web Services Remote Portlets you only need to use a spec. like that when you're trying to build a ... remote portlet. Think of it as having a number of different tools in your tool box and picking out those suitable for the task at hand, if you're not cutting wood you leave the saw where it is, and if you're cutting metal you use the metal saw rather than destroying your cross cut saw (wince ... ok ok so I'm more the Tim the tool man type).
I think one of the mistakes most people make is trying to fit all the WS-* specifications into one coherent document so they can say "there we go, they all fit together that way". I know I've tried to do it and I've never been satisfied with the results. Based on my pondering I suggest that's a meaningless exercise. I think it's more constructive to try to enumerate the Usage Scenarios which describe the roles into which Web Services will step and the ways they will interact. Once you've done that it becomes possible to articulate the characteristics they'll need and to define profiles (a profile is a specification which identifies a set of relevant WS-* specifications and gives guidance on how to employ them to produce a Web service) which identify the specifications in the WS-* family which will help us give Web Services those characteristics in a common way so integrating them into applications will be practical. The WS-I produced a set of Usage Scenarios which cover using their Basic Profile, take a look at chapter 3 to see what I mean. I think the important concept is that if you start by deciding that the service you are writing will be a consumer within a one-way usage scenario, then you'll be able to pick out the profile you want to use, and that gives very explicit guidance concerning how to implement your service. Of course for most developers all this probably won't be necessary since your IDE will know how to do all the gorpy code generation for you once you've given it the same basic information we've just touched upon (i.e. this is a consumer in a one-way and we need to use one profile, the basic profile for instance). I'm watching the eclipse project for to see this code becoming available via an open-source project.
There's still a heck of a lot of work to be done to make Web Services live up to their promise. We need to do a good job of writing the WS-* specifications together, that work is taking place all over and although it's chaotic there's progress being made. We need to develop the Usage Scenarios which define how Web Services will be employed, that work has started in WS-I and since I think it's important I urge you to get involved if you've something to contribute. We also need to develop the profiles which we'll use to define the external characteristics of our Web Services, that work has started and will continue as the WS-* family of specification grows and matures.
Now it's possible that Edd didn't mean what I've said. It's just possible (ghasp) that Edd was suggesting that WS-I could be improved. Dispite the recent round of glowing articles and analyst reports I recognize that WS-I, like any organization, can always be improved (notice the extreme use of understatement). If Edd has suggestions I'd love to hear them. I think what WS-I is attepting to accomplish is very important, and if Edd or any of you reading this post have suggestions let's discuss them!¶ 9:38 PM
