I think that there are some subtle differences in much of what is being
pointed to (which could be the cause of the confusion - IMHO). I'm going
to try and take a pass at trying to explain what the problem is (as we see
it) and why some of these other things aren't quite the same take. Imagine
the following WSDL:
:
<wsdl:message name="input">
<wsdl:part name="parta" type="parttypea"/>
<wsdl:part name="partb" type="parttypeb"/>
<wsdl:part name="partc" type="parttypec"/>
</wsdl:message>
<wsdl:portType name="myPortType">
<wsdl:operation name="operationa">
<wsdl:input message="tns:input" name="input"/>
<wsdl:output message="tns:output" name="output"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="mySoapBinding" type="tns:myPortType">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="operationa">
<soap:operation soapAction="" style="rpc"/>
<wsdl:input>
<soap:body use="literal" namespace="http://foo";
parts="parta partb" />
<soap:header message="operationa" parts="partc"
use="literal"
namespace="http://foo";>
</soap:header>
</wsdl:input>
<wsdl:output>
<soap:body use="literal" namespace="http://foo"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
:
In this case, the portType is already defined w/a list of explicit parts.
This maps directly to the signature (based on JAX-RPC mappings) of the
method request. Note, at this point, the bindings haven't even come into
play. Therefore, the SEI generated (which the stub uses) is fixed w/parts
on the operation. It's only in the bindings that the user decides that
this should be broken out into a portion into the SOAP body, and a portion
into the SOAP header.
I believe that Chapter 11 in JAX-RPC (Service Context) discusses 2 modes
(implicit and explicit). Implicit (isn't an issue). Explicit (modifies
the signature - adding on additional parameters representing the explicit
context stated). I believe the difference between what Glen is quoting is
Explicit style (w/o these parts being rendered on the WSDL portType
interface) - so the signature is modified but not the WSDL portType. I am
making this assessment since the chapters that talk about SEI <-> WSDL
mappings mentions nothing about context. I believe what we (Russell/Rich)
are pointing out is the case where these parts ARE rendered on the WSDL
portType. Adding an addHeader method to the call object works fine in the
case where the aren't represented on the portType. However, it just
doesn't fly when it's part of the portType. I acutally think both options
are needed.
I think we all agree that this mode of operation isn't the best style of
programming. However, there are people doing it and given the current
mappings, we need to deal with it (w/o conflicting directly w/the
specifications). I don't think it's appropriate to start taking exception
cases to the JAX-RPC mappings for WSDL<->Java conversions.
With respect to the comment about following bad specs... having a standard
specification amongst multiple vendors is a good thing (for our customers).
There are certainly parts that aren't necessarily crisp (and are downright
ugly), but standardization takes time. Ok, I'm off my soap box now...
Regards... Greg
Glen Daniels
<gdaniels@macrome To: "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
dia.com> cc:
Subject: RE: [VOTE] Again for
explicitHeaderWork (Glen)
10/09/2002 07:50
AM
Please respond to
axis-dev
Hi Russell.
A quick comment on your mail here before I take off.
WSDL 1.1 says nothing about how to do language bindings. It supports the
ability to say "this header with QName foo:bar is tied to this message part
for this operation" - that's it.
JAX-RPC has a chapter (11) which talks about one way ("explicit context")
it COULD work - it also describes another ("implicit context"). And note
the sentence at the beginning of the chapter : "This chapter describes
non-prescriptive guidelines for the mapping of the service context."
Web Services / SOAP / WSDL are not about language bindings. When you say
"users use it" what you mean is - they expect to be able to set and read
the headers which have been defined in the WSDL. No one is forcing us to
make that happen in any particular way, and I would rather make it happen
in a way which maintains the orthogonality which was designed into SOAP
from the beginning between headers and requests/responses in the body.
In other words - getHeader/addHeader would allow this functionality, with a
little bit more work on the part of the user (they'd need to know the QName
instead of the part name, and to call addHeader instead of adding a param),
but without what I consider to be an inappropriate pollution of the
functional interface of a service. There are also ways we can do it which
make it easier, but still don't change the interface, but
addHeader/getHeader would get us there for now.
Talk to you later this afternoon!
--Glen
> -----Original Message-----
> From: Russell Butek [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 09, 2002 8:31 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [VOTE] Again for explicitHeaderWork (Glen)
>
>
>
>
>
>
> You guys just don't get it. While I agree that explicit
> headers - headers
> that are method parameters - are poor programming practice, WSDL 1.1
> supports it, JAX-RPC defines how it works, and users
> (including interop
> folks if I understand dims correctly, and WS-I) use it. It is not our
> place to enforce good programming style. If we disagree with
> it we should
> go to the spec folks. But we MUST implement explicit
> headers! Otherwise
> we cease to comply with various specs out there.
>
> Russell Butek
> [EMAIL PROTECTED]
>
>
> Tom Jordahl <[EMAIL PROTECTED]> on 10/08/2002 10:50:52 PM
>
> Please respond to [EMAIL PROTECTED]
>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> cc:
> Subject: RE: [VOTE] Again for explicitHeaderWork (Glen)
>
>
>
>
> I am firmly in favor of a single Call object per stub.
> I have always wished for the stub logic to be *much* simpler.
> I think it is a reasonable requirement that stubs can't be shared
> across threads. I know that others might not.
>
> I also like the idea of a setHeader/getHeader API on the Call.
> I would think this would be a much more flexible design then
> adding the headers to the functional signature.
>
> Wouldn't the work be much simpler and more straightforward going this
> direction?
>
> --
> Tom Jordahl
>
>
> -----Original Message-----
> From: Glen Daniels [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 08, 2002 9:36 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [VOTE] Again for explicitHeaderWork (Glen)
>
>
>
> Sorry I wasn't available earlier, there is no network
> connection available
> from the interop - this means I also won't be around on
> Wednesday until
> late in the afternoon.
>
> > This work contains:
> > * Better rpc/literal support in the emitters and
> > runtime...as described
> > in previous notes.
>
> +1!
>
> > * Support to identify parameters and return values as
> > header values.
> > * Support in the serialization/deserialization to
> > read/write values
> > from the headers.
> > * Some minor api additions to the Call object to identify
> > parameters/return values as headers.
>
> -1...
>
> I still pretty strongly think that this is the wrong
> direction to be going
> in. Headers are orthogonal extensions (remember "orthogonal
> extensibility"?), and should be kept separate from the actual
> interface of
> a generated component.
>
> All that is missing for basic support of headers through the stubs is
> stub.addHeader()/clearHeaders() and something like
> stub.getResponseMessage(), all of which would seem to be
> possible if we
> just made the stubs have a 1-1 relationship with Calls. I
> talked to Sam
> about this today at the interop; I haven't looked back through the
> archives, but why aren't stubs associated with a single Call
> object and
> limited to use on a single thread? It would seem making this
> fairly simple
> change would enable a lot of the functionality people want re:
> setting/getting headers via stubs, and wouldn't do it in a way that
> polluted the APIs of the services.
>
> I think this approach also jibes with what Sylvain was trying
> to do a while
> back.
>
> Then later we can talk about different ways of acheiving the
> same sort of
> "syntactic sugar" that sticking the headers on the method
> APIs gives you.
> I have some ideas on this, but I want to take things one step
> at a time.
>
> Thoughts? Apologies in advance for not being around during the day to
> continue this discussion. If you want to check in the RPC/lit stuff,
> please go for it, but my -1 on the header stuff stands.
>
> --Glen
>
>
