Robert Greig wrote: > Having said that, I did take a look at this question ("could WCF be a > generic messaging API") for other reasons related to my day job a > while ago and concluded that it could be. You would simply have to > define some very simple contracts (e.g. with a single method > "StandardOneWay(Message m) and you would perhaps also need some > AMQP-specific behaviours (a WCF term) to give complete flexibility. > > Cliff, am I right in assuming that is where you were going with the WCF > client?
That is a very valid way to look at it, but not because it is a stated objective of the work I have been doing, but merely because that is how WCF tends to be used in a messaging context (i.e. for MSMQ and WebSphere MQ based transports) if you are using the service model. You can also just use one-way channels to send and receive messages programmatically. WCF isn't the solution to every conceivable messaging problem, but it is a very important framework for .NET developers. It can handle many common messaging scenarios and the code under qpid/wcf tries to provide the AMQP based transport that is expected in these cases. Robert Godfrey wrote: > I'm very supportive of the efforts to make available a WCF client for > Qpid (and more generally, I hope, for AMQP) however I think we need to > look a little more carefully about how we are going to go forward > supporting .net application programmers and - something that tends to > get a little lost - how we enable .net programmers to interoperate > seamlessly with clients using other APIs (for example JMS <-> > .net/WCF).. Unless there is an issue with interoperability in the case of "JMS <-> C++ client", I think that "JMS <-> .net/WCF" interoperability should occur as a matter of course when the AmqpType sub-classes are fleshed out. Cliff -----Original Message----- From: Robert Greig [mailto:robert.j.gr...@gmail.com] Sent: Monday, November 30, 2009 9:44 AM To: dev@qpid.apache.org Subject: Re: 10000 msgs limit per session 2009/11/30 Rafael Schloming <rafa...@redhat.com>: > I'm not sure the stuff Cliff is working on (useful as it is) is actually a > substitute for the old .NET client(s). I took a brief look at the WCF stuff > as I was curious about it, and from what I could glean from the readme and > the examples, it seemed more like an RPC mechanism than a messaging API. It > also looked like the implementation was windows only. RPC...you mean "services" :-) It is certainly true that WCF is geared around building services and clients for those services, with abstractions to allow a great deal of flexibility (e.g. transport). For example, IBM have produced a WCF channel for MQ and it is heavily geared towards SOAP over JMS. Having said that, I did take a look at this question ("could WCF be a generic messaging API") for other reasons related to my day job a while ago and concluded that it could be. You would simply have to define some very simple contracts (e.g. with a single method "StandardOneWay(Message m) and you would perhaps also need some AMQP-specific behaviours (a WCF term) to give complete flexibility. Cliff, am I right in assuming that is where you were going with the WCF client? > I do think that nothing we have under dotnet or wcf currently qualifies as > production ready or supported relative to our other clients, and we should > make this clear somehow, but I don't think it would be correct to deprecate > the old one in favor of the new one unless I'm missing something about the > new one. I think our existing .NET client is very poor and gives potential .NET users a very bad impression of the project. Do we know if anyone is actually using it successfully and is happy with it? RG --------------------------------------------------------------------- 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