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 new implementation
Date Mon, 27 May 2002 18:04:09 GMT

Glen,
Has there been any discussion about soap:header support in last week's chat?

Sylvain.


-----Original Message-----
From: Glen Daniels [mailto:gdaniels@macromedia.com]
Sent: Thursday, May 02, 2002 4:28 PM
To: 'axis-dev@xml.apache.org'
Subject: RE: soap:header new implementation



Hi Sylvain!

First off, I'm psyched that you're moving in this direction, because we
clearly need to support headers in some way.    The following is my take on
things, both in terms of where I'd like to be able to go wrt extensions in
general and also how to deal with the particular "fine-grained" approach
you're taking.

Headers have completely arbitrary semantics, and what happens as a result of
a header being sent/received is really completely up to the specification
wherein that header was defined.  In fact, such a specification might well
define *multiple* headers and how they relate to each other, message
exchange patterns, challenge/response rules, etc.... This can get hairy and
you don't really want your clients having to deal with it directly.

What you really want (IMO) for the interesting cases is some well-defined
chunk of code that plugs in and implements the entire specification for the
module, including generating/reading all the appropriate headers.  We
already have Handlers for precisely this purpose, except that they're even a
little too fine-grained.  What's needed, I think, is a "Module" concept
which contains Handlers, rules/code for automatically deploying them (on
either the client or the server side), and some kind of optional API for
getting any interesting values into or out of them.  (This is post-1.0 Axis
we're talking about here, btw)  I can give you some examples later if you're
interested.

Now, that said, there are certainly more simple cases where you just want to
"send the 7 as the ID header" or something like that, this is why we have
the addHeader() API on Call, and this is the kind of thing you're trying to
support with your code.

In looking at the code you submitted, I'm not sure I see a real need for so
much mechanism (i.e. all the Headers/HeaderKey/etc... classes) if we're
going for the "simple" approach.  It feels to me like we either want to:

1) Put the headers in parameters on the generated method signatures (I think
this is what .NET does?  It's also one style recommended in JAX-RPC).  Add
parameters named for the header parts to the list, and Holders for any out
headers:

   public void doSomething(String realArg, String headerArg, IntHolder
outputHeaderArg)

or

2) Just let people add headers by QName via an _addHeader() call on the
Stub.  I'm OK with your "DISCARD"/"PERSIST" options, so perhaps those should
be allowed, but I don't think we need much more than an ArrayList of
HeaderDescriptor objects (where HeaderDescriptor == [SOAPHeaderElement,
DISCARD/PERSIST flag]) in the Stub to make this happen.

Thoughts?

A few more specific comments re: your message inline below.

Thanks,
--Glen

> -----Original Message-----
> From: St-Germain, Sylvain [mailto:Sylvain.StGermain@cognos.com]
> Sent: Thursday, May 02, 2002 10:44 AM
> To: Axis Dev (E-mail)
> Subject: soap:header new implementation
> 
> 
> Read on - design issue at the end.
> 
> I have modified the original soap:header support 
> implementation to allow
> full flexibility around the header management.  The way I 
> have achieve this
> is by allowing the user to specify the header object 
> lifecycle.  The current
> three lifecycles are: 
> 
> HeaderLifeCycle.REPLACE: the response's header object will 
> overwrite the
> request's one

This seems like kind of a bad idea to me, since it implies semantic
knowledge of what the header is supposed to do, and I don't know of a lot of
cases where this style is used (do you?).  If you want to get at a header in
the response message, you should have an API for that, but I don't think
that we want to get into replacing headers like this (what happens if there
are multiple returned headers with the same QName, for instance?).  Leave
that up to the user, or up to the Module if/when we get there.

> HeaderLifeCycle.DISCARD: the request's header object is 
> removed from the
> list after the call.
> HeaderLifeCycle.PERSIST: the request's header stays as is.

These seem like OK options.

> A user then do:
> 	binding.setHeader("CAM", cam, HeaderLifeCycle.REPLACE );
> 	binding.setHeader("hdrSession", hdrs, HeaderLifeCycle.DISCARD );
> 
> To allow the setHeader() and getHeader() method to work off 
> the binding
> (PortType) class I had to add a new extension to the PortType 
> interface
> (currently org.apache.axis.client.HeaderSupport) this is all 
> fine for client
> side since the HeaderSupport interface is implemented by the 
> abstract Stub,
> but doing so, I broke the Impl class since it also implements 
> the PortType.

Why not just stick these methods on Stub, like _getProperty/_setProperty?
In fact it looks like you already did that, so I don't get why this should
change the PortType interface at all....

> This being said we will ultimately want access to those two 
> methods on the
> server-side but in the mean time (since I am not implementing 
> server support
> now) I need a spot to put those two methods.  Any idea?

I don't understand this - these are client-side methods, not server-side
ones....?  On the server, you can get access to the headers via the
SOAPEnvelope.

> Would bringing back the skeleton be the answer to my problem?

Skeletons never disappeared, they're just not the default anymore.
Regardless, I don't think they're the answer. :)

> I am attaching the patch and the new files so you can 
> experiment the problem
> with the Impl class.
> 
> Note: I did not yet rename the Header and Headers classes as 
> was suggested
> when I submitted the first implementation of the feature.
> 
> All feedback much appreciated.
> 
> --
> 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.

Mime
View raw message