Current Encoder works only based on binding and not runtime and I guess
runtime will need to choose different encoders such as FI.
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.
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.
-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.