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
