Wednesday, March 19, 2008

RPC over Document/Literal

In my last post, I discussed how document/literal is the recommended style to use when implementing services. One final twist to make the whole thing even more confusing is that there are two different styles of document/literal - wrapped and bare.

The difference between these two parameter styles though is really just an implementation detail at the service producer and consumer. The WSDL and message schema are exactly the same in both cases.

The difference between the two is how the message contract is conceived. With the bare style, the message is a first class citizen in both the service producer and consumer. The message has distinct representation in the code at both ends.

With the wrapped style, the code at both ends takes the form of a method and parameters. The message schema is derived from the method signature. As such, the message does not appear at all in the code.

Since the WSDL remains the same with both options, you could have different parameter styles at each end and the producer and consumer will still work together. You will just have the operation at one end taking the form of an explicit message and a method call with parameters at the other end.

So let's say the service consumer is using the bare parameter style. We might have:

DoSomethingRequest request = new DoSomethingRequest(); = 1234;
request.value = "Hello World!";
proxy.DoSomething( request );

And at the producer using the wrapped parameter style we might have:

void DoSomething( int id, string value )

Just like with RPC/literal, wrapped document/literal defines a convention for packaging the method name and parameter values into the message. The difference is that the method and parameter names are explicitly defined in the service contract.

We take the name of the method we are invoking as the outer XML element, and then create inner XML elements for each parameter.

For example, the request message for the above example would be:

    <value>Hello World!</value>

In my next post, I'll cover why RPC style interactions (that is deriving the message schema from the method signature) are a bad idea.

No comments: