dev@jax-ws.java.net

Re: SOAP Action and other heretical ideas <was> [Fwd: CVS update [rearch-2005]: /jax-ws-sources/jaxws-ri/rt/src/com/sun/xml/ws/api/pipe/, /jax-ws-sources/jaxws-ri/rt/src/com/sun/xml/ws/sandbox/impl/, /jax-ws-sources/jaxws-ri/rt/src/com/sun/xml/ws/transport/http/client/]

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 23 Feb 2006 19:03:16 +0100

Kohsuke Kawaguchi wrote:
> 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 just enumerated all three encoders.


>> 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.
>

To support FI conneg there currently has to be some loose connection
between the transport pipe and the encoding at runtime. It just seems an
unecessary indirect level of abstraction when this can easily be managed
locally by the client HTTP transport pipe.


>> 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 guess i am looking at things from a different orthogonal perspective!
because i view the transport pipe as a transport plus transport binding
and encoders/decoders separate from that, which do not have any binding
logic and are not aware of what they have to do with certain information
(e.g. like SOAP Action).

So it is up to the transport pipe to use the encoders/decoders in the
best most efficient way it knows how.


> 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.
>

It would be useful for the transport pipe to know what the binding
supports in terms of content types and what implementations are
recommended by the pipeline constructor (e.g. if there are no JAX-WS
handlers then the SOAP 1.1/1.2 encoding could use an encoder optimized
for JAXB which uses the OutputStream).


>>
>> 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.
>

OK. I will come up with a mock client HTTP transport pipe.

Paul.

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109