Hi all,
 
Maybe I should briefly explain my *immediate* need before I go on.   In a few words I am interested in having implicit Service Context stuff done first.  I do not have the need yet to set the headers through my methods signature.   Also, since my server is not implemented in Axis I am first concerned by the client aspect of it.
 
My understanding goes like this:
 
Header belongs to the service.  To achieve this I was simply considering adding a ServiceContext dataMember to the Service class (which would possibly hold a hash).  Each service's soap:header stored in the ServiceContext would be accessible by its name defined in the soap:header node. i.e.:
 
  <operation name="login">
    <soap:header name="authInfo" message="tns:AuthInfo" use="encoded">
    [...]
  </operation>
  <operation name="doSomething">
    <soap:header name="passport" message="tns:PassInfo" use="encoded">
    [...]
  </operation>
Here is a scenario that uses authentication as an example.
 
  MyServiceLocator service = new MyServiceLocator();
  MyServicePortType binding = service.getMyServicePort();
  service.setHeader("authInfo", new AuthInfo("foo", "bar"));
 
  binding.login();
  binding.doSomething("someData");
 
When calling login(), the AuthInfo header is serialized to the server which allows the server to authenticate the user.  In this case when sending the response back the server sends back the user's passport information.  This passport information is then "implicitly" used by doSomething().
 
In my mind, it is the call.invoke() method that is responsible for maintaining the Service's headers.
 
By dynamically generating the ServiceContext class (as Charles proposed) we endup with an easier to use ServiceContext class (since each data member are typed appropriately).  My proposition still allow for strong type approach by ensuring that the provided object matches the type of the message defined in the soap:header entry.
 
Areas of changes:
 
  WSDL2Java needs to add the appropriate addHeader in each stubs:
    call.addHeader( call.getService().getHeader("headerName") );
 
  ServiceContext class needs to be created (simply holds a Hashtable... for now...)
  Call.invoke() needs to do the header roundtrip thing.
  Service.java needs a ServiceContext data member.
 
Well, that is about it for now.  
 
Sylvain.
 
-----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.

Reply via email to