Paul Sandoz wrote:
> It is for consistency with the EncoderFactory in addition to the
> following: for some transports strings may not be used to represent the
> content type (e.g. i am proposing this for the SOAP/TCP transport which
> will use integers instead). In this respect the checking what Decoder to
> use can be performed by the transport pipe using integers instead of the
> facade using strings.
The transport abstraction is meant to be orthogonal to the
encoder/decoder abstraction, and for those transports I don't want the
transport to start treating the content type as an enumeration of finite
values (instead I want them to treat the content type as a string, and
data as an opaque byte stream.)
So I really think the current Encoder/Decoder plus facade is a
reasonable approach. If I'm writing a transport, I shouldn't be bothered
by choosing the right encoder. It's not a transport's job to do so.
But this doesn't prevent someone else from creating a
transport/encoder/decoder hybrid --- which can be almost thought of as a
communication channel to send/receive infoset, not byte stream.
Such hybrid channel won't even have to use Encoder at all. On the server
side, it can just create Packet directly out of nowhere, and pass it to
WSEndpoint.PipeHead.process() and JAX-WS will merrily take care of it.
On the client side your transport pipe doesn't even have to use an encoder.
So this flexibility would allow SOAP/TCP transport to work with multiple
encoders, if you choose to do so.
> In general the facade approach may work well for some transports (and
> features of) but for other transports there needs to be more flexibility
> such that the pipe can make choose the Encoder and to have choice on how
> to choose a Decoder.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com