Re: QMF and .NET
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:dev-subscr...@qpid.apache.org
RE: QMF and .NET
> 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). 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. Cliff -Original Message- From: Gordon Sim [mailto:g...@redhat.com] Sent: Tuesday, March 09, 2010 5:37 AM To: dev@qpid.apache.org Subject: Re: QMF and .NET 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(){ >// 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(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:g...@redhat.com] > Sent: Monday, March 08, 2010 4:11 AM > To: dev@qpid.apache.org > 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
Re: QMF and .NET
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(){ // 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(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:g...@redhat.com] Sent: Monday, March 08, 2010 4:11 AM To: dev@qpid.apache.org 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
RE: QMF and .NET
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. 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) - 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(){ // agent just sent an update, // do something in context of a rigid IQmfv2 contract } - provide more specialized WCF channel layers or behaviors so that Agent-specific contracts can be created: factory = new Channelfactory(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:g...@redhat.com] Sent: Monday, March 08, 2010 4:11 AM To: dev@qpid.apache.org 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-
RE: QMF and .NET
> 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
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
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:dev-subscr...@qpid.apache.org
RE: QMF and .NET
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