2009/11/30 Rafael Schloming <rafa...@redhat.com>: > What I meant specifically was that you don't seem to have direct control > over creating, sending, receiving, or acknowledging messages. These would > seem to be something the framework does for you based off of a combination > of metadata and application-specific interfaces.
Well, you do have control but it's through what they call behaviours, which as you say are driven by metadata and framework interfaces. So it's certainly less direct, but not unpleasant unless you don't like metadata. > I can see how you might be able to accomplish some of the same sorts of > things as a messaging API in this way, however I'm somewhat skeptical that > the result would be equivalent to a complete messaging API, or that we'd end > up with something that would appeal to our users. I think this is a good point. In my opinion MSFT didn't do a great job of System.Messaging when they first did it (i.e. long before WCF) because it was very tightly coupled to MSMQ so there isn't really a decent non-implementation-specific messaging API in .NET. WCF does I think attempt to address that in a very generic way - but maybe it is too generic to be useful for people who do want a low-level messaging API. > Even if it would work, this approach seems somewhat inside out. Why not have > a dotnet messaging API and build out a WCF transport on top of that rather > than having a private messaging API that is internal to the WCF messaging > implementation which is then reexposed via special service contracts. This is what IBM have done - they have a messaging API that is not unlike JMS and on top of that they have built their WCF channel which is specifically aimed at providing SOAP over MQ. RG --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
