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.
-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.
>>>>
>>>>
>>>
>>
>
--
Vivek Pandey
Web Services Standards and Technologies
Sun Microsystems Inc.