> Is it on your list of things to do to add map message support for the > WCF client?
Yes. It is next in line right after SSL support. Cliff -----Original Message----- From: Carl Trieloff [mailto:cctriel...@redhat.com] Sent: Monday, March 08, 2010 7:27 AM To: dev@qpid.apache.org Subject: Re: QMF and .NET On 03/08/2010 07:11 AM, Gordon Sim wrote: > On 03/05/2010 08:56 AM, Cliff Jansen (Interop Systems Inc) wrote: >> Hi Carl, >> >> I've taken a look at QMFv2 and hope I understand it well enough to >> give useful feedback. >> >> On the whole, I think your characterization of the options is correct. >> >> However, I would suggest you should not think of WCF merely as a SOAPy >> WSDL provider, but more as a layered architecture. WCF could provide >> a developer with direct access to low level QMF primitives that work >> with QMF objects and AMQP data types, or to higher level (possibly >> agent specific) RPC calls (e.g. "n = HPPrinter.getJobCount();"), >> according to taste. >> >> The former would work best with a custom QMF encoder/decoder whose job >> is mainly to translate between WCF XML infosets and AMQP messages >> (probably with the help of custom QMF object serializers). > > QMFv2 uses map messages. As you note below support for such messages > would also enhance general interoperability between the various > clients independent of QMFv2. > >> The latter would probably require the same plus an added glue layer >> to match requests and responses, plus tools to convert QMF schema to >> WSDL. > > Again, this sort of thing (e.g. generic correlation, response queues > etc) seems like something that is relevant more generally. > >> You could implement the low level first, and add more and more bits of >> upper level icing over time. > > QMFv2 is designed to be much simpler to use 'directly', by which I > mean that constructing, sending, anticipating, receiving and > interpreting the messages is easier and will match common patterns > relevant to many messaging use cases. > > I'd suggest we don't focus exclusively on 'QMF' here, but instead work > on adding flexibility and capabilities that make the sorts of generic > patterns and encodings that QMFv2 makes use of to the WCF client where > they can also be used more widely. > >> When evaluating the relative cost/benefits you should note the >> following in addition to the points you have already raised: >> >> - WCF is currently the top contender within the .NET community for >> client/server or peer to peer communication >> >> - AMQP type support, needed by QMFv2, is already planned within the >> WCF/C++ client for interoperability reasons (and AMQP 1.0 >> management) and should not need re-porting >> >> - basic features of the WCF/C++ client are still in development and >> the capability to provide temporary queue or ad-hoc bindings >> isn't expected until some time later in 0.7 > > I'd be keen to join in any discussions on ways to make the different > clients (c++, python, jms, wcf etc) work well in a system together. > We've been doing some work there already (common encoding for map > messages in python, c++ and jms, a common addressing syntax etc). > > Cliff, Is it on your list of things to do to add map message support for the WCF client? It seems that is one of the fundemetals on the route to QMF support bit also key for inter-client interop across the type system. Carl. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
