Vivek Pandey wrote:
>> Hi Vivek,
>>
>> I wonder if there is a better way to handle SOAP action more cleanly
>> rather than exposing SOAP 1.1 HTTP transport binding semantics to the
>> Encoder
>
> Other option that I suggested on other/similar email thread to return
> ITerable<String> containing the HTTP headers by the Encoder. Since the
> original idea of encode() to return was ContentType, just to handle SOAP
> 1.1 SOAPAction this was introduced. The transports that dont care about
> soap 1.1 wouldnt even call ContentType.getSOAPaction().
I think the general solution is not as good because it is pushing even
more general transport stuff into the encoding layer.
>
>> and SOAP 1.2 HTTP transport binding semantics to the implementations?
>>
> Currently MtomEncoder is well tied to SOAP. I will make it generic
> enough so that other protocols can reuse it.
>
Ah, so it should be a XOP encoder :-)
>> The same encoders may be used with other transports (JMS, SOAP/TCP,
>> BEEP, SMTP, XMPP) and new encoders may be used with the same transport
>> (FI). Some encoders may not encode SOAP messages.
>>
> Can they not avoid calling ContentType.getSOAPAction(). The same issue
> exists with MEssage.getHeaderList(), Headers are SOAP concepts too. I am
> not saying this is something we should practice in general but there is
> not any other cleaner way I could think of.
>
Right, it is not easy, plus it is important to get things up and running.
>> It is tricky though, especially when having to support MTOM!
>>
>>
> why?
>
Mostly because of the layering, a transport binding uses MTOM but the
encoding is XOP.
>> 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.
>>
>> 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.
>>
> Not sure if I folllowed you here. Content-Type is somthing that encoders
> can reliably determine. Same way it helps decoders tell soap version.
>
The problem is transport semantics are pushed to each Encoder and the
Encoder facade becomes part of the transport binding. So things are now
split between the transport pipe and the Encoder facade and the
transport pipe does not have much flexibility since it is stuck with the
facade obtained from the binding.
>> At the moment i still think things are too restrictive for pluggable
>> transports, sorry :-(
>>
>> 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.
>>
>> 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.
>>
> At least SOAP encoders/decoders work on the transport level header such
> as Content-Type - for example to let charset to determine encoding to
> decode the SOAP envelope..
>
For HTTP that can be extracted from Content-Type by the transport pipe
and passed as an individual parameter to the decoder.
Note that what i said above does not rule out the use of a helper class
that acts as a decoding facade. The point is that a transport has the
choice to use it or not.
>> I will try and write a clearer proposal on this.
>>
> Ok It will help to see in terms of class/interfaces etc.
>
OK.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109