You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Cliff Jansen (Interop Systems Inc)" <v-...@microsoft.com> on 2010/02/04 20:54:54 UTC

WCF/C++ client feature work for 0.7

The existing 0.6 version of the WCF/C++ client provides basic WCF
functionality.  Its most significant additional feature is distributed
transaction support for enterprise applications.  The WCF channel
portion relies on the well tested and high performance C++ native
client libraries for most of the logic at the transport and session
layers.  The current status and future wish list are summarized in the
top-level ReadMe.txt file.

The long term goal of the WCF channel is to provide .NET programmers
with a full featured AMQP messaging client.  To maximize adoption, it
uses the same programming model used by the Microsoft WCF channel
implementations for messaging over MSMQ and over WebSphere MQ.  To
maximize functionality, it incorporates or has planned features for
AMQP specific capabilities (such as local transactions which will
require some magic to associate separate WCF channels with a single
AMQP session).

A further goal is to maximize the interoperability of the WCF channel
with other AMQP clients by providing full access to AMQP types in
message headers and the message body.  In 0.6 it is possible to
exchange int and string properties between JMS and WCF clients.  Text
and binary content can also be shared between clients as demonstrated
by the WcfPerftest sample program.  Expanding this to include all JMS
message properties and supporting AMQP map messages is proposed as a
high priority improvement for the WCF channel in the 0.7 timeframe
(consistent with the goals of QPID-2226).

Another serious outage is the lack of SSL support and authentication.
This work was deferred until SSL support was ported to the Windows C++
client.  Steve Huston has just recently completed this work, so adding
the ability to the WCF channel should be very straightforward in 0.7.

Beyond those two goals, there is plenty to choose from in the "Planned
features" section listed in the ReadMe file.

As time allows, I would propose tackling temporary (and reply) queues
as another high priority item that WCF developers will be wanting.  I
would also like to rationalize the CMake and MSBuild build
interactions to make them smoother and to introduce failsafes to
prevent subtle bugs that arise from inconsistent compiler switch
settings.

In summary, for 0.7, I propose to pursue the development and
submission to Qpid of the following improvements to the WCF/C++
client:

  - expanded AMQP type support and client interoperability
  - SSL support and authentication
  - temporary/reply queue support
  - better CMake integration

I welcome any questions or comments.  And especially welcome anyone
who would like to assist with WCF channel enhancements for Qpid.

Cliff

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Re: WCF/C++ client feature work for 0.7

Posted by Gordon Sim <gs...@redhat.com>.
On 02/24/2010 09:00 AM, Cliff Jansen (Interop Systems Inc) wrote:
> The easiest way to think of it is that there are two programming
> models. The "channel model" is at the lower level and has variations
> of send and receive that are analogous to session.messageTransfer()
> and localQueue.get().  WcfPerftest.cs is an example and it should be
> very easy to follow if you are at all familiar with the C++
> perftest.cpp program.
>
> The second programming model, the "service model", is built on top of
> that and has fancy features for handling incoming messages and
> imposing structure on message content to allow contracts between
> clients and servers and discovery of available services.

Ok, that is very helpful already.

[snip]
>> The samples both use "amqp:<exchange_name>?routingkey=<routing_key>"
>> when sending and "amqp:<queue_name>" when receiving messages. How does
>> the binding (in the AMQP sense) happen?
>
> At the moment this has to be done outside WCF using external tools
> like the python qpid-config command or a custom C++ program.  Near
> term feature work will allow creating temporary queues on the fly for
> subscribers to topic exchanges or associating a temporary response
> queue with a WCF channel.  Further out, the plan is to supply
> PowerShell commands to do more sophisticated management, which can in
> turn be called from GUI management consoles or invoked from within
> applications.

It would be good to see if we could use the address syntax the c++ and 
python clients now use (indeed I believe the JMS client can be 
configured with the same syntax also now).

[snip]
> I hope this helps.

It certainly does, thank you very much Cliff!

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


RE: WCF/C++ client feature work for 0.7

Posted by "Cliff Jansen (Interop Systems Inc)" <v-...@microsoft.com>.
Hi Gordon,

> (I need to get a better grasp of the WCF model, any good links you can
> suggest?)

Any intro will do, but be warned that the bells and whistles above
messaging will get highlighted and seemingly simple terms like
"client", "binding", and "message" will have specific meaning within
WCF.

The easiest way to think of it is that there are two programming
models. The "channel model" is at the lower level and has variations
of send and receive that are analogous to session.messageTransfer()
and localQueue.get().  WcfPerftest.cs is an example and it should be
very easy to follow if you are at all familiar with the C++
perftest.cpp program.

The second programming model, the "service model", is built on top of
that and has fancy features for handling incoming messages and
imposing structure on message content to allow contracts between
clients and servers and discovery of available services.

But aside from providing the necessary glue between the service and
channel models, the Qpid WCF client is essentially all about the lower
level channel model and building an underlying "WCF transport channel"
over AMQP.

Another way to think of it is that WCF proxys and dispatchers sit
above a transport channel stack that is analogous to an SVRV.3 stream,
made up of channels/modules in a pipeline.  Closest to the wire is the
transport channel.  Further up the stack can be another channel that
maintains session state.  In this context, a WCF "binding" is the
description of the channel stack and its knob and dial settings.

People with a messaging background often find that the WCF "Message"
class has a couple of features that are unexpected: (a) its content
can be read or written at most once (corresponding to the time the
content is extracted or placed on the wire), (b) its content is
notionally an abstract XML infoset.  Regardless of whether you are
expecting the content to be elaborate SOAP or raw binary, you must go
through an XML based reader or writer to access the body.

> The samples both use "amqp:<exchange_name>?routingkey=<routing_key>"
> when sending and "amqp:<queue_name>" when receiving messages. How does
> the binding (in the AMQP sense) happen?

At the moment this has to be done outside WCF using external tools
like the python qpid-config command or a custom C++ program.  Near
term feature work will allow creating temporary queues on the fly for
subscribers to topic exchanges or associating a temporary response
queue with a WCF channel.  Further out, the plan is to supply
PowerShell commands to do more sophisticated management, which can in
turn be called from GUI management consoles or invoked from within
applications.

> How would I specify accept/acquire modes? 

There is no way at the moment, but the way to specify it would be as a
binding property (similar to setting the prefetch limit on incoming
messages).  .NET Framework 4.0, which will be out soon, has a new
feature called ReceiveContext which allows the application to specify
acceptance of a particular message.  Until then, a WCF message must be
processed in the scope of a transaction to defer its
acceptance/rejection (in this case at the time the transaction status
is determined).

> How would I get access to the message properties for sent and/or received messages?

The extensibility point in the WCF Message class is the "Properties"
field which allows adding an arbitrary object (in our case an
AmqpProperty).

    AmqpProperties amqpProperties = new AmqpProperties();
    // sample AMQP property:
    amqpProperties.Durable = true;
    // arbitrary application property: Dictionary<String, AmqpType>
    amqpProperties.PropertyMap.Add("appkey1", new AmqpInt(1234));
    myWcfMessage.Properties.Add("AmqpProperties", amqpProperties);

I hope this helps.

Cliff

-----Original Message-----
From: Gordon Sim [mailto:gsim@redhat.com] 
Sent: Monday, February 15, 2010 11:29 AM
To: dev@qpid.apache.org
Subject: Re: WCF/C++ client feature work for 0.7

On 02/10/2010 07:41 AM, Cliff Jansen (Interop Systems Inc) wrote:
> Hi Gordon,
>
>> I'd be keen to hear more of your thoughts an opinions on the new API
>> for the c++ client.
>
> I will try to take another look at it shortly.
>
>> It would be worth seeing if we can get better alignment between the
>> examples for all languages.
>
> Agreed.  I will do my best to make the upcoming interop examples
> resemble the main C++ and Java examples in structure as much as WCF
> allows.

I didn't mean to imply that was a task just for you! We should work 
together to make sure that the various components look more like part of 
a coherent suite.

(I need to get a better grasp of the WCF model, any good links you can 
suggest?)

>> Documentation of some form would be really great [...]
>
> Absolutely.  This is a known major outage and is just as high a priority
> for us as the functional feature work.
>
>> I notice for example you use uris that look similar to the JMS
>> "binding urls". Is the same syntax supported? There are some usability
>> issues with that format (in my opinion), especially when using more
>> complex patterns.
>
> I believe there are very few similarities.  The WCF model specifies
> the connection properties to servers (i.e. brokers) in a separate
> Binding which can be arbitrarily complex and already has established
> conventions for specifying many network related properties either
> programmatically or within XML config files.  The actual uris in the
> WCF client specify the minimum to identify a queue or exchange +
> routing key pair.

Could you describe that briefly? Does it assume that the queues and/or 
exchanges are set up using other tools or can you have them created as 
part of creating a producer or consumer?

The samples both use "amqp:<exchange_name>?routingkey=<routing_key>" 
when sending and "amqp:<queue_name>" when receiving messages. How does 
the binding (in the AMQP sense) happen?

How would I specify accept/acquire modes? How would I get access to the 
message properties for sent and/or received messages?

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org



---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Re: WCF/C++ client feature work for 0.7

Posted by Gordon Sim <gs...@redhat.com>.
On 02/10/2010 07:41 AM, Cliff Jansen (Interop Systems Inc) wrote:
> Hi Gordon,
>
>> I'd be keen to hear more of your thoughts an opinions on the new API
>> for the c++ client.
>
> I will try to take another look at it shortly.
>
>> It would be worth seeing if we can get better alignment between the
>> examples for all languages.
>
> Agreed.  I will do my best to make the upcoming interop examples
> resemble the main C++ and Java examples in structure as much as WCF
> allows.

I didn't mean to imply that was a task just for you! We should work 
together to make sure that the various components look more like part of 
a coherent suite.

(I need to get a better grasp of the WCF model, any good links you can 
suggest?)

>> Documentation of some form would be really great [...]
>
> Absolutely.  This is a known major outage and is just as high a priority
> for us as the functional feature work.
>
>> I notice for example you use uris that look similar to the JMS
>> "binding urls". Is the same syntax supported? There are some usability
>> issues with that format (in my opinion), especially when using more
>> complex patterns.
>
> I believe there are very few similarities.  The WCF model specifies
> the connection properties to servers (i.e. brokers) in a separate
> Binding which can be arbitrarily complex and already has established
> conventions for specifying many network related properties either
> programmatically or within XML config files.  The actual uris in the
> WCF client specify the minimum to identify a queue or exchange +
> routing key pair.

Could you describe that briefly? Does it assume that the queues and/or 
exchanges are set up using other tools or can you have them created as 
part of creating a producer or consumer?

The samples both use "amqp:<exchange_name>?routingkey=<routing_key>" 
when sending and "amqp:<queue_name>" when receiving messages. How does 
the binding (in the AMQP sense) happen?

How would I specify accept/acquire modes? How would I get access to the 
message properties for sent and/or received messages?

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


RE: WCF/C++ client feature work for 0.7

Posted by "Cliff Jansen (Interop Systems Inc)" <v-...@microsoft.com>.
Hi Gordon,

> I'd be keen to hear more of your thoughts an opinions on the new API
> for the c++ client.

I will try to take another look at it shortly.

> It would be worth seeing if we can get better alignment between the
> examples for all languages.

Agreed.  I will do my best to make the upcoming interop examples
resemble the main C++ and Java examples in structure as much as WCF
allows.

> Documentation of some form would be really great [...]

Absolutely.  This is a known major outage and is just as high a priority
for us as the functional feature work.

> I notice for example you use uris that look similar to the JMS
> "binding urls". Is the same syntax supported? There are some usability
> issues with that format (in my opinion), especially when using more
> complex patterns.

I believe there are very few similarities.  The WCF model specifies
the connection properties to servers (i.e. brokers) in a separate
Binding which can be arbitrarily complex and already has established
conventions for specifying many network related properties either
programmatically or within XML config files.  The actual uris in the
WCF client specify the minimum to identify a queue or exchange +
routing key pair.  A similar mechanism, with slight variation, will
probably be proposed for use with AMQP 1.0.

Cliff

-----Original Message-----
From: Gordon Sim [mailto:gsim@redhat.com] 
Sent: Friday, February 05, 2010 4:19 AM
To: dev@qpid.apache.org
Subject: Re: WCF/C++ client feature work for 0.7

Thanks for the info, Cliff! You've done some great work on this.

On 02/04/2010 07:54 PM, Cliff Jansen (Interop Systems Inc) wrote:
> The existing 0.6 version of the WCF/C++ client provides basic WCF
> functionality.  Its most significant additional feature is distributed
> transaction support for enterprise applications.  The WCF channel
> portion relies on the well tested and high performance C++ native
> client libraries for most of the logic at the transport and session
> layers.  The current status and future wish list are summarized in the
> top-level ReadMe.txt file.

I'd be keen to hear more of your thoughts an opinions on the new API for 
the c++ client. Though the existing 0-10 specific API will remain, I 
anticipate improvements and added features via the new API (producer 
flow control for example, and it already has built in reconnection and 
replay logic).

> The long term goal of the WCF channel is to provide .NET programmers
> with a full featured AMQP messaging client.  To maximize adoption, it
> uses the same programming model used by the Microsoft WCF channel
> implementations for messaging over MSMQ and over WebSphere MQ.  To
> maximize functionality, it incorporates or has planned features for
> AMQP specific capabilities (such as local transactions which will
> require some magic to associate separate WCF channels with a single
> AMQP session).
>
> A further goal is to maximize the interoperability of the WCF channel
> with other AMQP clients by providing full access to AMQP types in
> message headers and the message body.  In 0.6 it is possible to
> exchange int and string properties between JMS and WCF clients.  Text
> and binary content can also be shared between clients as demonstrated
> by the WcfPerftest sample program.  Expanding this to include all JMS
> message properties and supporting AMQP map messages is proposed as a
> high priority improvement for the WCF channel in the 0.7 timeframe
> (consistent with the goals of QPID-2226).

It would be worth seeing if we can get better alignment between the 
examples for all languages. That's a great way to demonstrate the basic 
interoperability and is especially helpful when for clients with quite 
different programming models.

Documentation of some form would be really great (even if its links 
elsewhere) on that front also. The samples are really quite different to 
those for the other clients. I don't have previous experience of WCF, 
and it may be more obvious to those that do. Even there though some 
description of the mapping of WCF to AMQP would be important.

I notice for example you use uris that look similar to the JMS "binding 
urls". Is the same syntax supported? There are some usability issues 
with that format (in my opinion), especially when using more complex 
patterns.





---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org



---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Re: WCF/C++ client feature work for 0.7

Posted by Gordon Sim <gs...@redhat.com>.
Thanks for the info, Cliff! You've done some great work on this.

On 02/04/2010 07:54 PM, Cliff Jansen (Interop Systems Inc) wrote:
> The existing 0.6 version of the WCF/C++ client provides basic WCF
> functionality.  Its most significant additional feature is distributed
> transaction support for enterprise applications.  The WCF channel
> portion relies on the well tested and high performance C++ native
> client libraries for most of the logic at the transport and session
> layers.  The current status and future wish list are summarized in the
> top-level ReadMe.txt file.

I'd be keen to hear more of your thoughts an opinions on the new API for 
the c++ client. Though the existing 0-10 specific API will remain, I 
anticipate improvements and added features via the new API (producer 
flow control for example, and it already has built in reconnection and 
replay logic).

> The long term goal of the WCF channel is to provide .NET programmers
> with a full featured AMQP messaging client.  To maximize adoption, it
> uses the same programming model used by the Microsoft WCF channel
> implementations for messaging over MSMQ and over WebSphere MQ.  To
> maximize functionality, it incorporates or has planned features for
> AMQP specific capabilities (such as local transactions which will
> require some magic to associate separate WCF channels with a single
> AMQP session).
>
> A further goal is to maximize the interoperability of the WCF channel
> with other AMQP clients by providing full access to AMQP types in
> message headers and the message body.  In 0.6 it is possible to
> exchange int and string properties between JMS and WCF clients.  Text
> and binary content can also be shared between clients as demonstrated
> by the WcfPerftest sample program.  Expanding this to include all JMS
> message properties and supporting AMQP map messages is proposed as a
> high priority improvement for the WCF channel in the 0.7 timeframe
> (consistent with the goals of QPID-2226).

It would be worth seeing if we can get better alignment between the 
examples for all languages. That's a great way to demonstrate the basic 
interoperability and is especially helpful when for clients with quite 
different programming models.

Documentation of some form would be really great (even if its links 
elsewhere) on that front also. The samples are really quite different to 
those for the other clients. I don't have previous experience of WCF, 
and it may be more obvious to those that do. Even there though some 
description of the mapping of WCF to AMQP would be important.

I notice for example you use uris that look similar to the JMS "binding 
urls". Is the same syntax supported? There are some usability issues 
with that format (in my opinion), especially when using more complex 
patterns.





---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org