Vivek Pandey wrote:
>
>
> Paul Sandoz wrote:
>
>> 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.
>
>
> Right, I still dont get why do you want DecoderFactory to exten from
> Decoder. I think you proposed EncoderFactory that doesnt exxtends from
> Encoder.
Yes, because i think the a facade of Decoder that is also a factory
makes sense but does not for Encoder.
So it is still possible for a transport to use a DecoderFactory as a
facade of Decoder as is done today but it is also possible to use it a
more optimal if a different transport so desires. i.e. we do not have to
change any logic in the current HTTP client and server transport for
decoding.
Paul.
>
> -vivek.
>
>>
>> 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