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.
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
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.
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.