Hi Charles, Sylvain, et.al.,
about naming of headers. I don't believe that headers shall
be associated to operations. As Sylvain mentioned some e-mails
before headers are specific to a service, not to a specific
operation of a service. Therefore IMHO headers should be
transmitted for each operation of a service. The association
to a service could be done either using the actor attribute i.e.
the service may register an actor that handles the header or
implicitly because the service is known.
About handling of headers there are some options to consider:
- setting the headers from the client. Shall be done service
specific as Sylvain and Charles proposed. I would also
support the proposal to use a service context to define
headers and not using method signatures. Using a
context would also support to define actor and mustUnderstand
attributes. This way is somewhat similar Microsoft .NET
does it: the client sets a Header process attribute, i.e.
an object that gets called just before the request is sent
and this object may then insert the header in the Envelope.
- processing headers in resposnes from the server. Two things here:
if the server returns headers
shall they overwrite stored headers e.g. if they have the
same element identifier of the immidiate child element
of the SOAP Header
or
are received headers always stored in a spearate context and
the client is responsible to handle them properly
Personally I would like to have them stored in a separate context
an have the client deal with them, IMHO it's a more flexible
approach.
I didn't look at header processing on the server side. Just some
thoughts here:
- Need some way to define and register actors. Global and service
specific actor registration necessary?
- Doing an implicit or explict service context (refer to JAX-RPC,
chapter 11). I would see the implicit model as more appropriate.
- which part deserializes/serializes headers and stores them in
the context (MessageContext?) and calls the header processing
module (that are registered using WSDD?)
Werner
> -----Ursprüngliche Nachricht-----
> Von: Ng, Charles [mailto:[EMAIL PROTECTED]]
> Gesendet: Freitag, 12. April 2002 16:20
> An: '[EMAIL PROTECTED]'
> Betreff: RE: soap:header
>
>
> Hi Chris.
>
> As Sylvain has mentioned already, we're pretty much focused
> on the client
> side of things. I haven't had much time to look at the server side
> implementation. With that said, it does make sense to expose the
> ServiceContext in the <ServiceName>Impl class. The
> ServiceContext object
> would be a stand-alone class with the Stub (or Service as Sylvain has
> proposed) and the Impl class each having a reference to an
> instance. Each
> class should have a get/setServiceContext methods for the underlying
> implementation to populate the appropriate properties.
>
> As for headers that are not typed or not defined in the SOAP
> binding, we
> would just skip over them in the deserialization code. We
> probably need to
> expose a way for the client to get a SOAPHeaderElement as you
> have proposed.
>
> Sylvain's proposal is semantically the same. Rather than
> having an explicit
> list of objects, he has a Hashmap. I do prefer having an
> explicit list just
> so users don't have to 'guess' which headers are serializable
> and which are
> not.
>
> Another problem that has not been resolved is the naming of
> the headers.
> The soap:header declarations in the SOAP binding section do
> not have names.
> How do we associate headers to operations? How do we treat
> headers that are
> shared between operations?
>
> Charles
>
> -----Original Message-----
> From: Chris Haddad [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 11, 2002 4:10 PM
> To: [EMAIL PROTECTED]
> Subject: RE: soap:header
>
>
> Charles -
>
> Deserializing soap:Headers into native java objects where WSDL type
> definitions are supplied would be excellent.
>
> I would like to keep the code that references (gets) and sets soap
> header values in the application logic. It is my
> understanding that app
> logic should be placed in the <ServiceName>Impl class. Is this an
> accurate premise?
>
> In the proposed design approach, how would the <ServiceName>Impl class
> methods gain access to the Stub.ServiceContext object? I
> think I missed
> how the service methods in <ServiceName>Impl find the Stub object....
> Are you thinking about adding ServiceContext to the MessageContext
> object or making a static getServiceContext() method?
>
> Another question, how would the engine work if soap:header values are
> received in the request message, but the definition was not
> in the WSDL?
> Would the envelope parser not throw a fault (because no
> deserializer was
> defined), but continue to parse the header into
> MessageContext.Message.SOAPEnvelope.SOAPHeaderElement.SOAPElement
> objects?
>
> Thanks,
>
> /Chris
>
>
> -----Original Message-----
> From: Ng, Charles [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 11, 2002 2:34 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: soap:header
>
> Hi.
>
> I work with Sylvain so I have put some thought into this...
>
> I was thinking of adding a 'ServiceContext' to the stub. This
> ServiceContext will have properties that matches the header objects
> defined in the WSDL.
>
> For example, if we have objects A, B, C in the header, we create the
> class
>
> class <ServiceName>ServiceContext {
> private A myA;
> private B myB;
> private C myC;
>
> // and getters/setters
> }
>
> I prefer this to get/setProperty since this explicitly defines which
> headers are available. It would be the stub's responsibility
> to update
> the ServiceContext and roundtrip values sent back from the server.
> -----Original Message-----
> From: Tom Jordahl [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 11, 2002 2:16 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: soap:header
> Glen and I have talked a little bit about this, but is was just talk.
> :-) Glad to hear that you are going to tackle this.
>
> One of the big design questions I have is how to pass header values in
> to the stubs.
>
> Do we add them in to the function signatures: myadd(String header1,
> String header2, int arg1, int arg2)? Do we set them some
> other way? via
> the Stub setProperty()? Do we create custom APIs in the Stub?
> Something else?
>
> Sylvain, what is your current thinking?
>
> --
> Tom Jordahl
>
> -----Original Message-----
> From: St-Germain, Sylvain [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 11, 2002 12:53 PM
> To: Axis Dev (E-mail)
> Subject: soap:header
> Has anybody started some work on this? I am looking into it now, if
> anyone as some ideas/guidelines/design ideas please send them to the
> list.
>
> Thanks.
> --
> Sylvain
>
> This message may contain privileged and/or confidential
> information. If
> you have received this e-mail in error or are not the intended
> recipient, you may not use, copy, disseminate or distribute it; do not
> open any attachments, delete it immediately from your system
> and notify
> the sender promptly by e-mail that you have done so. Thank you.
>
>
> This message may contain privileged and/or confidential
> information. If you
> have received this e-mail in error or are not the intended
> recipient, you
> may not use, copy, disseminate or distribute it; do not open any
> attachments, delete it immediately from your system and
> notify the sender
> promptly by e-mail that you have done so. Thank you.
>
