dev@jax-ws.java.net

Re: Propagation of properties from RequestContext context to Packet

From: Kohsuke Kawaguchi <Kohsuke.Kawaguchi_at_Sun.COM>
Date: Thu, 06 Apr 2006 11:07:37 -0700

(Bundling up replies to multiple e-mails)

Paul Sandoz wrote:
> I agree.
>
> It would be better if pipes can get access to properties directly
> associated with the production of an outbound message that are constant
> with respect to the outbound message (represented as a Packet) as it
> flows through the pipeline.
>
> Is the request context instance guaranteed to be the same for the
> lifetime of the pipe line? If so could the client pipes can obtain the
> com.sun.xml.ws.client.RequestContent from a method on the WSBinding
> interface or the BindingID abstract class?

I think what I have in my mind is not to store values in RequestContent
--- that would require each pipe to check for the values, and check
often, because pipes don't know when they change.

Instead, I think it would be good if the user invocation of
RequestContext.put(SOMETHING,value); eventually invokes
SomePipe.setSomething(value); We do early hand-shaking among pipes and
stub to make this possible.

In this way, values are injected into your pipe when they changed, so by
the time you see a message, you have all you need prepared and
pre-computed around (as opposed to check Packet.invocationProperties or
etc.)

We need something similar for injecting HTTP related properties into
WebServiceContext on the server side, so this shoots down two birds.


> I wish i could pop over to Santa Clara and have a white board session on
> this with you :-)

Yes. In fact, I think I'm going to ask people that we really need to
have you come over here, if just for a week. If nothing else, it would
be really really great if you can come here a week before for JavaOne,
or a week after JavaOne, so that we can have concentrated time talking
about all the issues.


> I think the conneg property would be directly associated with the HTTP
> transport pipe, and my plan was to manage the conneg state on this pipe.

Does FI interact with HTTP? Is that because you use Accept (or some
other HTTP) header? Does that mean FI can be only used with HTTP?
Decoder takes a Packet, which contains transport-specific information in
it. Can you get to Accept header from it?

I think it would be nice to keep the transport and the encoder separate.


> If the encoder facade is used how can the transport inform the facade to
> encode using the FI encoder?

For the above reason I really don't want the transport to choose which
encoding it uses.

> Having something on Packet is the most direct solution because Encoder
> takes an instance of Packet.

I'm fine with this, too. I was just wondering if we can make it a part
of otherProperties or invocationProperties, as opposed to a strongly
typed field. In general, we try to reduce the number of typed fields in
Packet that are from sub-components that don't directly belong to the
JAX-WS RI (FI is somewhere in the middle between the JAX-WS RI core and
satellite projects, so this is bit difficult to say.)

I really need to allocate some time for this to sketch out a coherent
proposal in words --- I think I have it in my brain, but it just needs
to be dumped out. Unfortunately, right now I have other high-priority
JAXB things, so I'll come back to this soon. Very soon. Really. But
sorry, not now.

> Instead, the state could be assosiated with
> the BindingID or the WSBinding, that way the facade could get access to
> the conneg state. We could have a method:
>
> WSBinding.isFastInfosetEncodingEnabled
>
> The transport pipe would have to set this flag to inform the facade that
> if it (the facade) supports FI then it should use the FI encoding. Then
> the transport has to then check if indeed the facade did actually encode
> in FI by checking the returned content type.
>
> If all this functionality was kept in one place it would be easier to
> implement, understand and maintain. A good example of the current
> complexity is the way SOAP action is currently supported, it is spread
> out and the contract for it is not that obvious, so it is easy to
> introduce subtle interop bugs if a change is made in just one area
> without realizing what the dependency is in other areas.
>
>
> So ideally IMHO it would be better for the transport pipe to be a
> transport+binding pipe. Such pipes would be responsible for directly
> using the encoders/decoders from that specified by the BindingID
> instance and the pipes can use facades as helpers. This does mean more
> work for a transport pipe, but the advantage is everything is more
> self-contained. Encoders/Decoders would operate directly on Message and
> Encoder can return a set of parameters that may be part of the meta-data
> to be transmitted by a transport (e.g. the boundary parameter and value
> for a XOP encoded message) since the encoding of such data on transports
> could be different (for example, the SOAP/TCP transport will encode of
> MIME type and parameters and values separately).



-- 
Kohsuke Kawaguchi
Sun Microsystems                   kohsuke.kawaguchi_at_sun.com