I've been taking a closer look at the various ways to describe web services over the last few days. Since
my last post on the subject, several folks have also been kind enough to forward some additional methods including WADL, RDF Forms, and OWL. While I've been taking a look at the details of these approaches and what advantages they bring to the table, I've also been struggling with what they actually do for us.
Service description languages (SDLs) of the machine readable variety typically describe how to prepare XML documents (often sets of interrelated XML documents) that describe the service in enough detail that a user can robustly interact with it. Most of the SDLs that I've been looking at fall into this category and include WSDL, WSDL 2, NSDL, SSDL, RSDL, WRDL, RSWS, WADL, Resedel, SMEX-D, RDF, RDF Forms, OWL, WSML, and so on. These SDLs describe the service in minute detail including the specifics of operations, parameters, document schemas, exceptions, URIs, and protocol.
The sum total of this information generally constitutes the service contract, though some of these languages only consider a portion of the service description to be the contract. The contract though is the central pillar of service description. Hence, a service is defined by the promises it makes to the client through its contract. Namely that the service will do X if Y is supplied to the service in the correct format and in the right location.
Service Description Languages: WSDL, WSDL 2, NSDL, SSDL, RSDL, WRDL, RSWS, WADL, Resedel, SMEX-D, RDF, RDF-Forms, OWL, WSML
This is all fascinating of course, but what value do SDLs really provide to service providers and consumers? Usually, it's one of three things. If an SDL is machine readable and has closure (meaning it provides full self-description), it facilitates automatic code generation of client stubs in the local programming model and makes the service look like a local resource. This is convenient because it can make interacting with the service much easier though at the risk of breaking service-orientation, IMHO.
An SDL can also support automated checking to verify that you are complying with the service contract. This can be important for at least two reasons: 1) Understanding if the service has changed its contract since you last checked and 2) wiring together services in a service-oriented architecture, especially using configure-time orchestration aka BizTalk or WebSphere Studio.
Lastly, an SDL provides a means to build abstract models of services using visualization and model checking tools. The usefulness of this latter item is of course entirely dependent on the application and consumer, but can certainly be high value to some.
None of this answers the question of whether the cost of implementing service descriptions in these languages is higher than the benefit. This value proposition is still unconfirmed for many folks, particularly since WSDL, the most univerally accepted SDL currently, can't properly describe many of the web services in wide use today (HTTP/XML and REST, for example). Some of the newer SDLs like SMEX-D and RSWS reflect a better understanding of today's needs including simplicity, straightforwardness, and inclusion (support for SOAP, REST, HTTP/XML, etc), but they are relatively unknown. And others, like SSDL, are extremely complex and focused on a particular web service model and are unlikely to see widespread use. Like Bill de hÓra says, it's partially about the classic complexity/simplicity trade-off.
In any case, I think we have the majority of SDLs listed here, but please submit more if you have them (with links please!). In the next few days, I hope to post some detailed comparisons of the various SDLs to see what their specific advantages are. Because the real issue is about a balance between adoption and usefulness. Until there are one or two major standards that always do the job, are accepted, and widely used, the fragmentation of SDLs just won't help folks use web services other than as manual references.
Perhaps what we need is a USDL, a Universal Service Description Language that somehow subsumes these or enables them in a straightforward way. I realize the world does not need Yet Another Service Description Language, but I have some interesting ideas.
More to come...
Technorati: Enterprise Architecture, Computers and Internet, Programming, Web Services