Paul Sandoz wrote:
> Putting my heretical hat on i am becoming more and more convinced that
> the transport pipe cannot be separated from the binding of the protocol
> to the transport e.g. the SOAP 1.1 or SOAP 1.2 transport binding or the
> MTOM transport binding.
Hmm. This change was so that we can free the transport layer from
worrying about the SOAP-ness, at the expense of making encoders/decoders
responsible for them.
And given that SOAP spec requires SOAPAction, the transport is
responsible for sending it.
I'm also curious what the interaction of MTOM in this. I'm not aware of
any complication.
> I think a general problem is that content type is meant to be meta-data
> but it is leaking into the encoding layer (a bit like what prefixes do
> for qnames in content). In this respect i am not sure that
> Encoder/Decoder should actually be using the content type string at all
> for the actual encode/decode process. And this goes to the heart of the
> argument of using facades up front as well which tend to encourage
> transport level binding semantics to be pushed to the encoding/decoding
> layer.
I'm not sure if I understand. I think it's a correct abstraction that
the encoder returns content type, for nobody else knows. And similarly I
think it's a correct abstraction that the decoder is associated with a
certain (or a set of) content types.
> At the moment i still think things are too restrictive for pluggable
> transports, sorry :-(
I'm curious about the specifics. I can see some work that needs to be
done for using one-way transports (like SMTP or JMS), but other than
that I thought it's quite workable.
> Transport pipes can be responsible for instantiating the
> encoder/decoders they require from factories obtained from the pipeline
> constructor (since the constructor is in best position to know what
> implementations to use e.g. SAAJ, stream, JAXB etc). The constructor can
> also use the binding to determine what encoders/decoders are allowed
> (easy way to switch of FI).
>
> The transport pipe is in the best position to determine how to use the
> Encoders/Decoders based on binding and runtime information.
I think of encoder/decoders and transports orthogonal. It is true that
sometimes it's convenient to merge the transport and the en/decoder (for
example if we are to do "AJAX transport" that sends out a responsible as
JSON + script fragment, then we'd want to mix two), but the default mode
of abstraction should be that they are orthogonal.
I think the current abstraction of having TransportFactory accepting
En/decoders as parameters work for both cases. If we want to make
transports and en/decoders agnostic it lets you do so. If a transport
wants to control what en/decoders to be used, it can do so, too, by
simply ignoring the given en/decoders.
>
> Encoders/Decoders can operate on Message and take parameters and return
> parameters (e.g. to support MTOM). Thus Encoder/Decoder is cleanly
> separated from the content type leaking and transports. This does create
> more work for a transport pipe, but all transport binding stuff is kept
> localized and is not spread between the transport pipe and
> Encoder/Decoder. Helper classes can be defined to aid the development of
> a transport pipe.
>
> I will try and write a clearer proposal on this.
OK. I think that would be helpful.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com