7246Re: [soapbuilders] rpc/literal and wrapped doc-lit
- Mar 1, 2002Speaking for myself (not for IONA for this message. I don't think IONA
has an official position on this yet), I have to agree 100%. I REALLY
like rpc/literal as a transport for RPC style messaging. It really is
the best of all worlds in my opinion. Think about it:
1) The operation name is always part of the soap message. Also, since
this is literal (no hrefs), the only element in the body is the RPC
wrapper element. This makes it very easy to dispatch on no matter what
style parser you use (streaming, sax, dom, etc...) Deterimining the
operation to call on the server side is trivial. Also, things like
"echoVoid" can be done easily.
2) The parameter descriptions are "literal", thus bound by the schema
descriptions, not the abiguous and sometimes confusing section 5
3) Since each parameter is placed in the message in the WSDL
individually, you can do SOAP w/ attachments with RPC/literal. You
cannot do so with the wrapped doc/literal as there is only 1 part in the
message, the wrapper element. I don't know how DIME handles this so I
cannot comment on it, but the MIME extension for WSDL only really allow
attachments of message parts. If you only have 1 part that is the
wrapper part, no-attachements are possible.
4) Since the rpc wrapper element is namespace qualified, the individual
part elements don't need to be. Since elements directly in the soap:body
must be ns qualified, with doc/lit you have to qualify them even if their
schema has them unqualified.
Anyway, I really like rpc/literal. XMLBus does currently support it
(both client and server) and I would like to see it more widely used.
J. Daniel Kulp
END 2 ANYWHERE
P: 781-902-8727 C: 617-513-4582 F:781-902-8001
On Friday 01 March 2002 01:01, wes_moulder wrote:
> So, on the plane trip back home, I started wondering about two great
> mysteries that came up at the soapbuilders conference. As the title
> suggests, this is about rpc/literal and wrapped doc-lit. Since we've
> got an unknown style/use combination, why are we overloading doc/lit
> to support the idea of a method call with the wrapped/bare semantics?
> My understanding of rpc is that it's supposed to declare that the
> message in the body is in fact a method call. Since this is what
> wrapped does as well, why not merge the ideas there, and declare that
> our interpretation of rpc/literal is indeed wrapped doc/lit?
> Is there any technical reason that this should not be done? (I should
> probably go read the spec to see, but I just got home, and I'm
> exhausted. I'll do it in the morning if there are no replies.)
> Going forward into SOAP 1.2, is it possible to suggest to the SOAP
> working group that this should be the mapping of that combination (if
> they don't just do away with the literal vs encoding semantics)? The
> whole idea here is to eliminate the "parameters" hack to figuring out
> which version of doc/lit you're using.
- << Previous post in topic Next post in topic >>