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).

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.

You could implement the low level first, and add more and more bits of
upper level icing over time.

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

Cliff

-----Original Message-----
From: Carl Trieloff [mailto:cctriel...@redhat.com] 
Sent: Wednesday, March 03, 2010 1:49 PM
To: dev@qpid.apache.org
Subject: QMF and .NET


Options and thoughts on direction for QMF in C#. We have one
impl on the native C# client for QMF v1. Question is to port this
to the C++ C# wrapped impl or / and do ?

First of QMF can be used in two ways, one for modelling object
interactions, second doing management.

In the Windows world, the most natural binding for QMF would be
to have a powershell mapping.

For the object mapping it is less clear. Here we could port the work
done on the native C# WCF client which provides a service layer inside
WCF. Pros - it works, simple. Cons, duplicates QMF logic in C# and does
not map directly to the WCF WS stack.

We could wrapped QMFv2 API in C#. Pros, no code duplication. Cons, as
above ignores the WCF WS stack.

Finally we could write a mapping from WSDL to QMF. This would mean all the
WCF WS stuff would work with a QMF payload. Pros - fits into WCF service
architecture, Cons - we qould be able to map QMF to WSDL, but would not
be able to or it would be a large piece of work to map all of WSDL schema to
QMF. (Not sure it is worth the effort.)

Love to get thoughts, ideas and perspectives.
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

Reply via email to