axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "DZIEMBOWSKI,KINGA (HP-NewJersey,ex2)" <>
Subject RE: wrapped style
Date Wed, 30 Apr 2003 15:36:34 GMT
Tom, Glen, Wes,

thanks for the important info. It looks to me that the real interoperability
will be a challenge anyway.
Few points to the discussion:
On the best of my understanding of document style exchange, the wire level
message is modeled after the schema definition for the element defined in
message tag. What goes to wire is the document defined in the schema. Then
the name of the element is what determine what is on the wire.
For example the below part of wsdl is modeled after soapinterop example. In
this example the operation name != element name. Operation name is
"echoString" the element name is "echoStringParam" and what will go to the
wire is "echoStringParam". If we take this example the operation name ==
element name requirement looks important to me. I will prefer to have
"echoString" on the wire.
The other important piece is how do we build the response. Once again the
wire level response need to match the schema definition for the exchanged
document. In rpc, the tags names for the response did not matters. In
document exchange - the tags for the response need to match the schema
definition. Then building response we really need to go to the wsdl,
included/imported xsds if needed, and then build correct response.

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="WSDLInteropTestDocLitService" 
        <schema targetNamespace=""
            <element name="echoStringParam" type="xsd:string"/>
            <element name="echoStringReturn" type="xsd:string"/>
    <message name="echoString">
        <part element="xsd1:echoStringParam" name="a"/>
    <message name="echoStringResponse">
        <part element="xsd1:echoStringReturn" name="result"/>
    <portType name="WSDLInteropTestDocLitPortType">
        <operation name="echoString">
            <input message="tns:echoString" name="echoString"/>
            <output message="tns:echoStringResponse"
    <binding name="WSDLInteropTestDocLitPortBinding" 
        <soap:binding style="document"
        <operation name="echoString">
            <soap:operation soapAction=""
            <input name="echoString">
            <output name="echoStringResponse">
    <service name="...">
        <port binding="..." 
            <soap:address location="..."/>
This is what goes to wire:
<S:Envelope	xmlns:S=""
	<a:echoStringParam>some text</a:echoStringParam>

> -----Original Message-----
> From: Tom Jordahl []
> Sent: Wednesday, April 30, 2003 10:54 AM
> To: ''
> Subject: RE: wrapped style
> Since Glen and I made up the rules, we have been telling 
> everyone that this is the way it should work. :-) We thought 
> Microsoft was using these rules too, but it turns out that 
> they were keying off of the single part name "parameters", 
> which isn't nearly as good as these rules.
> Find the rules encoded in 
>, line 1500:
>         // Hack alert - Try to sense "wrapped" document literal mode
>         // if we haven't been told not to.
>         // Criteria:
>         //  - If there is a single element part,
>         //  - That part is an element
>         //  - That element has the same name as the operation
>         //  - That element has no attributes (check done below)
> I believe I explained these rules to someone from Microsoft, 
> and the thought they were pretty good, and they were going to 
> tell the .NET guys to use them too.  :-)  That could have 
> been a dream on my part though.
> --
> Tom Jordahl
> Macromedia Server Development
> -----Original Message-----
> From: Glen Daniels [] 
> Sent: Wednesday, April 30, 2003 9:45 AM
> To: ''
> Subject: RE: wrapped style
> Hi Wes!
> > Different people choose different things to key in on.  TME 
> > keyed in on
> > the fact that the element attribute always pointed to an anonymous
> > complex type, whereas it seems axis keyed in on the fact that the
> > operations name is the same as the element name for the input 
> > part.  In
> > reality, it's the 4 blind men and an elephant.  They all 
> describe what
> > Microsoft does, but interoperating with derived versions of this
> > requires choosing the same pieces.  (Though I may crib that 
> 3rd option
> > too.)
> To some extent you are of course correct, but I personally 
> think that the name matching is pretty important, as is the 
> other thing we check for - no attributes on the complexType.  
> If the name didn't match, you'd be calling a method called 
> "foo" with arguments that fill in sub-elements of an element 
> "<bar>", which I think would be a little strange (though it 
> would still work).  If there can be attributes on the 
> "wrapper" element, you definitely don't want to follow the 
> wrapped pattern because how would you set them?
> We should probably also be confirming that the output message 
> has only a single part (a wrapper element containing the 
> "output parameters").
> Oh, and speaking of output parameters, I think we also check 
> for matching sub-elements between the input and output 
> messages and make them into INOUT params.  Some people like 
> this (I do), some people don't.
> > The response follows a similar pattern, with the exception 
> of the name
> > being the same, obviously.  Following that pattern, though, 
> > the response
> > name should probably be the operation name + "Response".  Obviously,
> > given the history of "wrapped", only Microsoft knows the definitive
> > answer, and everyone else has their best guess.
> There's a longer conversation here about the way XML messages 
> are mapped to objects and APIs in general, but that should be 
> had over drinks somewhere (why aren't there techy bars which 
> have both great drinks and whiteboards?).
> --Glen

View raw message