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.
