Kohsuke Kawaguchi wrote:
> Paul Sandoz wrote:
>
>> 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.
>
>
> The transport abstraction is meant to be orthogonal to the
> encoder/decoder abstraction, and for those transports I don't want the
> transport to start treating the content type as an enumeration of finite
> values (instead I want them to treat the content type as a string, and
> data as an opaque byte stream.)
>
I agree with you have Encoders/Decoders should operate on data as an
opaque byte stream.
The 'enumeration of finite values' would be based from the content type
as a string. It would be a runtime optimization.
> So I really think the current Encoder/Decoder plus facade is a
> reasonable approach. If I'm writing a transport, I shouldn't be bothered
> by choosing the right encoder. It's not a transport's job to do so.
>
We may have different understandings on orthogonal! Transports may
specify mechanisms on how to declare/negotiate encodings, in this
respect the choice on what encoding(s) to use seems like a decision for
the transport to make at runtime.
What makes me uncomfortable is some of the transport logic (e.g. HTTP
content negotiation) is being split between the transport pipe and the
Encoder facade, which seems to create a fragile dependency between the
two. Experience in JWSDP 1.6/2.0 tells me keeping this logic in one
place will make things much easier to maintain (this was one of the most
fragile areas, granted the new arch makes it much less fragile!).
Any such Encoder facade for HTTP (that included FI logic) may be
redundent for say JMS as the decision to use FI has to be achieved by
other means. In general any transport that narrows down the choice of
what is encoded and decoded through initiation or negotiation steps can
make the facades redundent once optimal communication is negotiated.
Possibly a side issue but... I am not sure that a transport pipe can be
assumed to be completely orthogonal from the binding, e.g. SOAP HTTP
binding [1], or SOAP with BEEP [2], from an initial browse it certainly
looks like a BEEP transport pipe would have to know that SOAP is being
used at least for the profile initiation steps.
>
> But this doesn't prevent someone else from creating a
> transport/encoder/decoder hybrid --- which can be almost thought of as a
> communication channel to send/receive infoset, not byte stream.
>
> Such hybrid channel won't even have to use Encoder at all. On the server
> side, it can just create Packet directly out of nowhere, and pass it to
> WSEndpoint.PipeHead.process() and JAX-WS will merrily take care of it.
> On the client side your transport pipe doesn't even have to use an encoder.
>
> So this flexibility would allow SOAP/TCP transport to work with multiple
> encoders, if you choose to do so.
>
That would work, but it would be nice to reuse as much as possible :-)
since the individual encoders/decoders are quite general, it is how they
are facaded by the binding where generality can be lost.
Hmm... i think the source of the problem is in the binding since this is
where the Encoder/Decoder facade is chosen. I think it is useful that a
binding states what encoders/decoders may be used (since this can be a
configuration point e.g. turn of FI, which is not possible in JWSDP
1.6/2.0 on the server side).
If the transport could get the set of encoders/decoders without any
assumption of thier use (static or runtime) then the transport can
choose to use facades (transport specific or general helper facades).
Would that be an acceptable solution?
Paul.
[1]
http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapinhttp
[2]
http://www.faqs.org/rfcs/rfc3288.html
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109