Mark
follows on from my previous post. He suggests that clients should determine what they want to do with the returned document “based on the type of the document”. Mark gives this as a reason for not having to define, as part of the contract, the information that is going to be returned. However, doesn’t the consumer now need to understand the specification of the type that governs the returned document’s structure? Isn’t this similar? In fact, I think it’s worst because the service may return information to a consumer that the consumer did not understand. Hence, we allowed an interaction to take place for nothing.

In contrast, WSDL tells you in advance what it is expected (it could be a number of alternatives) so you can decide whether you want to interact with the described service or look for something different. I argue that Mark’s general approach could also be captured by WSDL, where the structure of the information exchanged is described through xsd:any.

I agree with Mark that the end of my post didn’t make much sense (the long sentence about SOAP). I am sorry about that. Didn’t manage to capture in writing what I had in my mind. SOAP is a general solution for transferring information, just an “envelope” as Jim likes to describe it. And SOAP over HTTP is the preferred binding for interoperability purposes, so it makes sense to move information between services using SOAP messages.

And while we are in this mode of interaction with Mark, which I enjoy btw, I will try to answer his next question.

Using WSDL it is indeed possible to describe a message exchange pattern where any XML document could be accepted by a service for processing (see my comment about xsd:any above). One of SOA’s principles, as described by Don Box, suggests that services will only interact with one another only when they have determined, based on policy assertions and metadata about the document structure of the information, that they can meaningfully exchange information. Effectively, services can advertise metadata about what kind of information they consider acceptable so, for example, an order for a car should not be sent for processing to a service that expects an invoice. The same can be done with policies (e.g., a service requires messages to be signed using an X.509 certificates).

Two things to note here: 1) A service may indeed decide to accept any information if that’s what it wants to do (e.g., the equivalent of POST), and 2) in most cases, it may be possible to send any document to a service endpoint. However, at the endpoint it can be determined, based on the advertised schema and policy (the contract), whether the received document should be further processed and eventually delivered to the service logic. I think that’s a great strength for Web Services.

I hope that the above thoughts are not too random (it’s almost 3.00am now… brain has already gone to bed 🙂