Hi,
If people are reasonably comfortable with the interfaces i have proposed
i would be happy to make the code changes and write appropriate Java docs.
Paul.
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.
>
> 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