axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject RE: soap:header new implementation
Date Thu, 02 May 2002 20:27:59 GMT

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)


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.


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


> -----Original Message-----
> From: St-Germain, Sylvain []
> 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

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

View raw message