On 03/08/2010 09:32 PM, Cliff Jansen (Interop Systems Inc) wrote:
Hi Gordon,
I'd suggest we don't focus exclusively on 'QMF' here
I agree completely on your comments regarding generic functionality
and interoperability in the WCF C++ client, and that the need for this
is completely independent of QMFv2.
Though the need is independent, this work would (I believe) go some way
to making QMFv2 usable in .Net also. That was really the point I was making.
My point is merely in regards to Carl's original discussion regarding
various approaches to implementing QMF in .NET and the relative pros
and cons. The arguments apply equally to the Java-derived dotnet
client. Stated another way, (and while looking through a WCF tinted
lens) there are three approaches:
- as before, provide a QMF API in .NET and ignore WCF altogether
(that is, from the application's point of view; the QMF modules
could still use WCF under the hood for sending and receiving the
AMQP messages)
This sounds like the wrong approach to me.
- provide a specialized QMFv2 WCF channel layer, with custom binding
and encoder, so that low level QMF functions are exposed. The WCF
programming model would be used by the application to access
generic QMF functions that don't change between agents.
ProcessQmfSubscribeResponse(<some args>){
// agent just sent an update,
// do something in context of a rigid IQmfv2 contract
}
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. The patterns QMFv2 uses are going
to be commonly used in other messaging scenarios.
- provide more specialized WCF channel layers or behaviors so that
Agent-specific contracts can be created:
factory = new Channelfactory<IPrinterAgentService>(qmfBinding,
printerAgentUri);
printerProxy = factory.CreateChannel();
n = printerProxy.GetJobCount();
>
And, of course, these approaches aren't mutually exclusive. Without
doing a full design and identifying all the pitfalls, my gut
recommendation would be to do approach #2 and a limited amount of #3
for simple agents. This would satisfy power programmers (who might
want to write code that isn't tied to a particular agent anyway) and
leave good bone structure for additional WCF goodies down the road.
That said, custom WCF channel stacks and encoders are non-standard WCF
topics and can be challenging even for many experienced .NET
programmers. I merely wished to reduce the terror quotient by
pointing out that some serious outages in the WCF C++ client that
would affect such work are being addressed as quickly as possible.
Cliff
-----Original Message-----
From: Gordon Sim [mailto:[email protected]]
Sent: Monday, March 08, 2010 4:11 AM
To: [email protected]
Subject: Re: QMF and .NET
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).
--Gordon.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
