.NET Buzz Forum - Message and service contract

Jeff Schneider asked in one of the comments on my last post about "Oracle's new Web services Designer - good idea, but ..." what I mean by message contract. Sorry for not being clear enough on this. Let me give a try here.
Normally everybody only talks about the contract which is the service contract, the one and only, right? In the meantime I tend to see it from another angle. I guess we should start with a possible definition of what exactly is meant by the term contract.

Contracts define the complete interaction between services. In that sense, a contract is the 'business protocol' all involved services rely on. A service designer (human, in this case ;-)) defines all messages and their format, including possible message sequences for reflection in a contract. But a contract also defines protocols, authentication mechanisms and the like. Effectively, contracts allow service interfaces to communicate with each other.

Sounds good so far? Makes sense? Hm ...
With the above definition we are able to further seperate the global term contract into a message contract and a service contract. A message contract would hold all the required information about the message payload itself. In terms of a technology mapping into SOAP 1.x this means that a message contract would be materialized on the wire in the <SOAP:Body> element. Of course, in order to describe this contract we would then use WXS (W3C XML Schema) in order to set up the 'types' (well, these are not the types we are used to from classical OO - for more and deeper information and a superb explanation of that distinction read Steve Maine's MUST READ blog entry on this very topic, including Don's comment). But stop. When saying that a message contract describes how the message itself looks like on the wire we also need to consider describing the message function, not only the message content alone. This can be done by using WSDL.
In contrast, a service contract is a contract that describes what a service is capable of - in terms of "I can do this for you". It is more about describing the infrastructional means needed to communicate with the service which are independent of the message. Again, when mapping into SOAP we will see this information put into the <SOAP:Header>. Originally these requirements were all described in WSDL. E.g., if you leverage a mechanism to authenticate your users with every service call you do, then you put that data and information orthognal to your message into an appropriate section in your service's WSDL that describes the SOAP Headers. Does WSDL really support this? A lot of people think so ...

Isn't there a bit more to this story? By using WSDL you actually cannot express a service's wishes. It is solely a means for describing a syntax. A communication partner cannot know without further knowledge what is meant by the SOAP Header element to use. But doesn't a service not only have to say "I can do this" and express the syntax of the elements that have to carry that information, but also it needs to be able to say "Hey, I really prefer if you would send me this" and even "C'mon - no! I really want you to send this or that!"? Yep. And this is where the whole policy thing comes into play. Policy and the related WS-Policy specs enable a service designer (or even an administrator) to describe policy assertions like capabilities, preferences, and requirements. And it seems like the responsibilities get mixed (WSDL vs. policy) ... Well, here we go.

Now I am in a dilemma ... the whole thing with WSE, e.g., is that the message contract is described via WXS and WSDL, OK. And the service contract is solely described via the appropriate policy descriptions. Now, is there a missing link? Or put another way: is WSDL responsible for describing the whole <SOAP:Envelope> on the wire? I think this was the original idea behind it (the other day). But with the advent of policy this has changed dramatically. This leads very quickly to the never ending story (at least for me) about "runtime" vs. "design time" contracts. What is needed at design time and was not?

Suppose you provide me a WSDL. I take that WSDL and put it into my 'engine'. Perfect. Then I write an application to call your service. Kawoom! Error and exceptions all over. Why? Because there is a security constraint on your service that tells a consumer to digitally sign the messages sent to the service. OK, I did not know that! ... So a viable solution is to send the WSDL and the policy information to me in order to use it. Well ... and here we go again: then I really need both at design time for my service client, don't I?
Maybe the explanation to all of this is just as easy as: hey, don't worry about it. You really only need the appropriate runtime to handle this for you. Hm ... see my side note below.


	Web Artima.com