Vivek Pandey wrote:
> Current Encoder works only based on binding and not runtime and I guess
> runtime will need to choose different encoders such as FI.
>
Exactly.
> For decoders it works primarily on the received content type. Not sure
> do we really need DecoderFactory.getDecoder() and have DecoderFactory
> extends Decoder. Not sure why DecoderFactory extends from Decoder when
> it has getDecoder() method on it.
>
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.
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.
> Other things to consider is how do the pipes get these factories, I see
> that WSBinding.createEncoder/Decoder methods that return Encoder/Decoder
> not sure if this is the best place to create the factories.
>
I am not that familiar with this area but it does seems like the right
place since a binding does define transports.
Paul.
> -vivek.
>
> Paul Sandoz wrote:
>
>> Yes, it is similar.
>>
>> But it currently does not work well for an Encoder. It is not possible
>> to tell the EncoderFacade that it should encode using FI because it is
>> a run time decision based on a previous response.
>>
>> We could have a method on Encoder like:
>>
>> setPreferedEncoding(String contentType)
>>
>> but it does not make sense for most encoders. A factory like:
>>
>> interface EncoderFactory {
>> Encoder getEncoder(String contentType);
>> }
>>
>> where the pipe can obtain the necessary encoders based on binding and
>> runtime information seems a better fit.
>>
>> Then for completeness we could have:
>>
>> interface DecoderFactory extends Decoder {
>> Decoder getDecoder(String contentType);
>> }
>>
>> class DecodeFacade implements DecoderFactory {
>> DecoderFactory(Decoder[] decoders, String[] contentTypes);
>> }
>>
>> class XMLAndFIDecoderFacade implements DecoderFactory {
>> XMLAndFIDecodeFacade() {
>> decoders[0] = ... // XML stream decoder
>> decoders[1] = ... // FI stream decoder
>> contentTypes[0] = ... // XML content type
>> contentTypes[1] = ... // FI content type
>> suprt(decoders, contentTypes);
>> }
>> }
>>
>>
>> Incidently allowing encoder/decoder choice based on facades/factories
>> means we can permanently enable/disable FI for some clients/endpoints
>> at the level of the binding (something which was not so obvious/easy
>> to do previously).
>>
>> Paul.
>>
>>> I agree that DecoderFacade could be implemented in a bit more generic
>>> way, not just for MTOM vs SOAP.
>>>
>>>> This also means it is possible to clearly separate XML decoding and
>>>> FI decoding instances. Even though the StAX API is used for the most
>>>> part i think this is useful for initiation and may potentially be
>>>> useful for future optimization (e.g. SOAP header blocks could be
>>>> processed in a different manner to create the stream buffer).
>>>
>>>
>>>
>>> Yes, and it's good for modularity, too.
>>>
>>>
>>
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109