axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "St-Germain, Sylvain" <Sylvain.StGerm...@cognos.com>
Subject RE: soap:header
Date Fri, 12 Apr 2002 14:50:43 GMT
Charles, 

I realized after the fact that there is no name attribute on the
soap:header.   Looks like we will have to use the combination of the
soap:header message and part attributes to uniquely identify them.

Sylvain.


-----Original Message-----
From: Ng, Charles [mailto:Charles.Ng@cognos.com]
Sent: Friday, April 12, 2002 10:20 AM
To: 'axis-dev@xml.apache.org'
Subject: 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:chris.haddad@cobia.net]
Sent: Thursday, April 11, 2002 4:10 PM
To: axis-dev@xml.apache.org
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:Charles.Ng@cognos.com] 
Sent: Thursday, April 11, 2002 2:34 PM
To: 'axis-dev@xml.apache.org'
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:tomj@macromedia.com]
Sent: Thursday, April 11, 2002 2:16 PM
To: 'axis-dev@xml.apache.org'
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:Sylvain.StGermain@cognos.com]
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.

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.

Mime
View raw message