dev@jax-ws.java.net

Re: Propagation of properties from RequestContext context to Packet

From: Kohsuke Kawaguchi <Kohsuke.Kawaguchi_at_Sun.COM>
Date: Tue, 04 Apr 2006 10:58:42 -0700

Paul Sandoz wrote:
> Hi,
>
> I am implementing support for FI content negotiation and would like to
> know what is the best way is to propagate the conneg property on the
> request context to the packet.

I think this is touching a deep issue, of how to allow applications to
configure pipes through a proxy. This is really a very generic problem
that will happen to any non-trivial pipe.

For example, HTTP transport might want to allow users to set a proxy
authentication information, security might want to let people change the
keystore (I'm just making this one up), and so on.

These configurations aren't really a "packet" property. There really is
no need for those values to be passed around between pipes. It only
needs to be delivered to a particular pipe that it's intended to.
Besides, attaching them to Packet is not good for performance, because:

   - Stub has to always copy values from request context to Packet
   - Pipes have to check for them all the time

It seems to me that a better approach is to somehow allow pipes to
expose properties to RequestContext directly, in such a way that the act
of setting it would immediately call the corresponding method on the
corresponding pipe (as opposed to values set to Packet, to be picked up
by a pipe)

A downside is that it interacts with asynchronous invocations (changing
a property while asynchronous invocation is in progress may affect that
invocation, while ideally it shouldn't.) I know that the spec-defined
properties must observe this carefully, but I think we can do this for
many proprietary properties, such as FI content negotiation.

-- 
Kohsuke Kawaguchi
Sun Microsystems                   kohsuke.kawaguchi_at_sun.com