dev@jax-ws.java.net

DispatchDelegate changes

From: Kohsuke Kawaguchi <kohsuke.kawaguchi_at_sun.com>
Date: Fri, 16 Dec 2005 17:24:38 -0800

(Not sure if Kathy is subscribed to dev_at_jax-ws.dev.java.net, if not,
please do so...)

I looked at changes you made to DispatchDelegate and a few other
classes, and I wasn't sure if you are on the right track.

First, about DispatchPipes. You don't need a list of Pipes. A pipe form
a list by themselves, so you only need to have a reference to a Pipe,
which is the entry point to the whole pipeline. So I don't see any point
of "DispatchPipes".

Now, DispatchDelegate. We shouldn't be extending from DelegateBase,
which is one of the legacy stuff we are trying to get away with. You
shouldn't be using neither MessageStruct nor messageInfo. The point of
the rearchitecture is for us to go straight from SOAPMessage to Message
(which means wrapping into SAAJMessage) without going through those
intermediate abstractions. Instead, directly implement
Dispatch<SOAPMessage>.

Also, MessageImplFactory is not necessary. In fat, it's harmful. We
shall never get into the situation at anywhere in the runtime where we
have an 'Object' that might be either X, Y, or Z. Don't use/introduce
those it-does-right-stuff-by-sniffing-types-mostly utility methods.

In your class that implements Dispatch<SOAPMessage>, you know that your
input is SOAPMessage, and you'll be calling new SAAJMessage(...); directly.

Furthermore, do not assemble a new pipeline for each message. This
architecture is designed so that your Dispatch<SOAPMessage>
implementation will reuse a pipeline for processing multiple messages,
the Dispatch implementation should not get into the business of how to
construct a pipeline, either. Just take that as a constructor parameter.

Finally, I noticed that you added "Map<String,Object> context" to
HttpTransportPipe, but I'm not very familiar with what it represents.
Can you clarify? Given that there are so many contexts that have
different lifespan, I think it's good to use a stronger type to avoid
ambiguity. See MessageProperties for how something like that can be done.


-- 
Kohsuke Kawaguchi
Sun Microsystems                   kohsuke.kawaguchi_at_sun.com