dev@jax-ws.java.net

Re: Decoders and the DecoderFacade class

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 16 Feb 2006 11:47:45 +0100

Kohsuke Kawaguchi wrote:
> Paul Sandoz wrote:
>
>> Rather than a facade should we be using a DecoderFactory that returns
>> a Decoder for a given content type? There can be DecoderFactory
>> instance per pipe (and it could cache Decoder instances appropriately).
>
>
> I think they are really the same thing. If you design a DecoderFactory
> in a way that reuses Decoders, it will be probably implementing Decoder
> interface by itself.
>

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