On 03/09/2010 07:54 PM, Cliff Jansen (Interop Systems Inc) wrote:
The encoder is basically a map-message encoder, which would be more
generically applicable. My view would be to try and make all the
custom channel stuff as generic as possible.
Sorry, I should be more specific. When I say "custom binding
and encoder" I am referring to sub-classing
System.ServiceModel.Channels.Binding and
System.ServiceModel.Channels.MessageEncoder
These play an important role in converting abstract WCF Message
objects to and from the wire format. But they don't do encoding
or decoding in the sense you are thinking. They choreograph a
group of other related (and somewhat soapy) objects to do their thing
when the message is "consumed" (possibly way off in the future, or
never).
Ok, I misinterpreted due to my lack of knowledge of WCF. Thanks for the
clarification! I'll try and learn a bit about Binding & MessageEncoder
before I stick my oar in again.
A "map-message encoder", in the sense you are thinking, would be
separately invoked somewhere along the way (by one of those other
dancing objects). Such an encoder was already envisaged separately
from QMF and will be implemented, in any event, as part of the need
for arbitrary applications to conveniently handle Amqp types in general
and interoperate with other AMQP clients.
The patterns QMFv2 uses are going to be commonly used in other
messaging scenarios.
Agreed.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
