Document/literal messaging

[Pradeep bhatt]

I read some article on www.theserverside.com that document/literal is becoming more popular. What could be reasons. Thanks.

[Tim West]

Microsoft is behind it. It's the default in all Microsoft products. I'm not even sure if .Net supports RPC/literal...anyone?

IMO, the choice really doesn't matter from a "language theoretic" point of view - the choice that people take is almost always based on the tools they use. Java tools are buggier with doc/lit; .Net won't do RPC/encoded. Usually by the time you account for the limitations of the server and all the clients, you're only left with one (or zero) choices...


-Tim

[Kuldeep Vaishnav]

is there nethin called rpc/literal ?? never heard of..but dont know again i am towards the bottom of the specturum....I think the most appealing feature of doc/lit is its sort of relax grammer..rpc/encoded is stricter in that manner..

[Tim West]

There is no fixed list of valid styles. The SOAP1.1 spec defines three: Document/Literal, RPC/Literal and RPC/Encoded. While Document/encoded is theoretically possible, it is never used. RPC/Encoded is on the way out, as the Basic Profile disallows it.

Microsoft decided these weren't good enough, and added a fourth: Document/Literal Wrapped. This isn't defined anywhere other than Microsoft's Web Service stub generator utilities. It does have some "nice" properties that aren't present in the other encoding schemes, though.

IMO, "relaxed" isn't a good thing here - I have a hunch it's lead to the buggy and often incompatible Web Services implementations out there. When a language meant to be understood by a computer is both relaxed and human readable, humans are liable to misinterpret what is allowed.

Here is a good IBM article about the differences between the encoding schemes. This Microsoft article is shorter and perhaps more biased, but has some nice examples. It also does not discuss RPC/Encoded in detail.


-Tim

[Pradeep bhatt]

Microsoft is behind it. It's the default in all Microsoft products.

Yes it is default in MS product but I was talking about the article written by Debu Panda from Oracle. He was explaining how to create J2EE Web Services.

[Tim West]

Well, you didn't provide a link to the article, so I wasn't aware of that.

In any case, the reason behind it becoming more popular is orthogonal to any one particular article that observes it popularity. The fact that someone from Oracle observes it is becoming more popular does not mean, for example, that Oracles supports this gain in popularity. (OK, it could: Microsoft will happily tell you how bad RPC/encoded is, because they support doc/lit).

Anyway, I should also add use of SOAP encoding is prohibited by the Basic Profile, which is being adopted by all vendors (AFAIK, anyway). I *thought* that it also recommended use of document/literal over RPC/literal, but I couldn't find that stated in there just now.


-Tim

[Pradeep bhatt]

Here is the article
http://www.onjava.com/pub/a/onjava/2005/05/25/j2ee-services.html

[Kuldeep Vaishnav]

when i said relaxed grammer i meant looselly forced binding requirements.As far as I know,doc/lit supports user defined objects and not just xml supported data types which is not the case with other combinations of soap transport method/soap encoding.Theoratically speaking that should be the last reason for all these messy webservices floating out there...

[Tim West]

Maybe I've missed something but "loosely enforced binding requirements" didn't help me understand what you meant.

AFAIK, you can represent any business data (i.e., any object structure) with either SOAP encoding or literal (i.e., use of an XML schema). The advantage of literal is that because a schema is used, it's more widely compatible. Schemas are used all over the place (in particular, in non-Web service areas); SOAP encoding is not.

The biggest disadvantage of literal in my mind is that that schemas are really too broad and powerful for representing object graphs. Now, the 'literal' camp say that's cool, as they don't view Web services with an RPC/distributed objects metaphor. However, for us programmers that have to bind objects to XML documents, it *is* a concern. The end result is that because schemas are so powerful, toolkits only support a subset of possible schemas. E.g., they won't support xsd:choice, or won't enforce all facets. But what's supported varies from toolkit to toolkit, so for a schema to be broadly compatible, you have to use a "lowest common denominator" approach.

On the other hand, SOAP encoding is designed specifically for object serialisation (I think). So, it isn't so complex, so toolkits generally supported its entire syntax. Also, it can do nice things like serialise object graphs with circular references - try doing that with XML Schema (without rewriting the graph, I mean).

The IBM article I linked to earlier goes into way more detail on the differences.

Ultimately, I'm not fussed which I have to use, so long as it isn't a buggy, inflexible, poorly documented pain in the ass. Neither so far have made me smile :-\


-Tim

[Pradeep bhatt]

Lot of people say that it in case of document/literal , the SOAP body can be validated against the schema. Can't we do the same with RDP/literal ? Shouldn't each parameter be a type in the schema ?

In rpc/literal the child element of soap:body is the method name . What about in case of document/literal ? How is the mapping between the request and operation done? I am really confused.

[Pradeep bhatt]

I was trying out the .NET WebServices. MS uses document/wrapped style where the SOAP body has the operation name as it's immediate child. I am still confused how the containers map a request to operation in document/literal cases?

[Tim West]

That's described in detail in the IBM article I linked to earlier. If you're interested, I'd suggest reading it - it's much more detailed and informed than anything I could write here.

I *think* the short story is that a RPC/literal message can't be validated just by an XML Schema validator, whereas a doc/lit one can.

The IBM article says that doc/lit is best overall, aside from its lack of standardisation and support outside of Microsoft tools.


-Tim
[ August 08, 2005: Message edited by: Tim West ]

[Pradeep bhatt]

I *think* the short story is that a RPC/literal message can't be validated just by an XML Schema validator, whereas a doc/lit one can.

Yes you are right. I dont understand why it took me so long to understand. Thanks Tim.

[Pradeep bhatt]

The microsoft article says

Each message contains zero or one part. That part points to a schema element declaration that describes the entire contents of the message body.

The IBM document contains this for document/literal

<message name="myMethodRequest">
<part name="x" element="xElement"/>
<part name="y" element="yElement"/>
</message>

I see that the message above has 2 parts x and y. Did the microsoft article mean document/literal wrapped rather than document/literal?

[Tim West]

The IBM article is in error. Well, it was written in 2003, before the final version of the Basic Profile. So, it's perhaps better to say that it doesn't validate against current standards.

In any case, the intention behind doc/lit was to only allow one "part" per "message", but this is made explicit in R2201 and R2210 in the Basic Profile, to quote:

R2201: A document-literal binding in a DESCRIPTION MUST, in each of its soapbind:body element(s), have at most one part listed in the parts attribute, if the parts attribute is specified.

R2210: If a document-literal binding in a DESCRIPTION does not specify the parts attribute on a soapbind:body element, the corresponding abstract wsdl:message MUST define zero or one wsdl arts.

I'm not 100% sure if both, or just one, of the above specify one part per message. The Basic Profile assumes you are *really* familiar with the associated standards (in this case, WSDL in particular), and because of this it can be hard to understand.

I don't know whether the WSDL standard itself mandates one part per message with messages used in doc/lit services, but the BP certainly does.



-Tim
[ August 10, 2005: Message edited by: Tim West ]

[Pradeep bhatt]

I found this article

http://www.codeguru.com/Cpp/I-N/internet/xml/print.php/c9761__1/

I am yet to read this completely.

[Pradeep bhatt]

Hi Tim,

Thanks for all the replies so far. I have one more question - In doc/literal style the SOAP message does not contain the operation name , so how does the Web Services server know which operation to invoke. I think it is not practical to use it. The articles that I have read so far just mentions that doc/literal makes it difficult to identify the operation but it does not say how it identifies ?

[Tim West]

I have to say, I have no idea! I've never thought of delving into it. That sort of thing is usually taken care of by whatever WS toolkit you're using.

I am 99.99% sure doc/lit is practical, though - people are using it successfully now. The article is quite old, I guess any major issues have been cleaned up since then.

As the article notes, doc/lit wrapped is "best of both worlds" - you get method-identification (like in RPC/encoded) and schema-validatability (like in doc/lit).

If you happen to find an article that explains how doc/lit works, I'd be interested to read it.


-Tim

[Pradeep bhatt]

Thanks Tim.

If you happen to find an article that explains how doc/lit works, I'd be interested to read it.

Sure.