Kopretinka

SSDL mixed feelings

I have just seen SSDL (via Jim Webber) and I have mixed feelings.

The good thing I see on SSDL is that they are tightly focused to SOAP messages, which makes sense in those environments, where Web services have little Web in them.

The biggest problem I have with the SSDL proposal is that I don't see the usage model. One of the important use cases for describing services is discovery. For that I'd like a service to point me to its contract, not a contract to enumerate all the services it applies to. I guess it's implied by the packaging that the protocols defined in a contract apply to all the endpoints contained in that contract, but this looks the wrong way around.

Behind WSDL's interface and operation constructs there's the implied promise that the interface (or operation) does something. A protocol in SSDL doesn't give such promise, it just dryly specifies the message constraints. In my view, WSDL can be used for discovery of functionality (an agreed interface, for example) but not so SSDL. During discovery, I'm looking for functionality, not a protocol.

I have to admit that I have met opposition (even in the WSDL working group) to ascribing functionality (semantics) to interfaces or operations, but I still can't see how anybody can interpret the terms interface and operation as just specifying the message schemas and sequencing.

I also have a number of smaller problems with SSDL:

1. The example in SSDL Core spec is not well formed and even ignoring that, it seems to be invalid wrt the rest of the spec (no protocols container, element ssdl that's not defined in the spec etc.)
2. The use of containers like messages, protocols, endpoints doesn't make much sense to me, the root contract seems to be a good enough container, together with the element names like message, protocol or endpoint. The containers are IMHO redundant in the XML model of SSDL.
3. The robust MEPs from WSDL seem to be misunderstood as they define two messages (correct) going in the same direction (incorrect) - the robust MEPs mean to allow one message in one direction and an optional fault in the other direction.

Posted at 1157 on Tue, Feb 15, 2005 in category Work | TrackBack | Comments feed