Fri, 10 Jan 2003 11:42:30 -0500
I've actually done some research on this topic... Your right in that the
current .Net implementation is tightly bound to MSMQ.(and I don't think
anyone wants to write that). So your options are:
1) Extend the interface to make it usable to other providers
2) Wait for MS to release the next version of the System.messaging
libraries and then implement it.
I know of numerous people who have bashed the leading MS guys about the
crappy Messaging library. The MS developers ackowledged it was a problem
but haven't publicly stated when or what they would do about it...
So it kinda leaves you in a bind... you could start down implementing and
extending the class(I'm guessing make it as JMS like as possible) and then
back port that work to a new interface if/when MS releases it. Since its
messaging it shouldn't be to hard to backport any work done... it would
probably be no more than an abstraction interface and you would be done...
>I think it is, but the problem is with the semantics.
>System.Messaging is very tied to MSMQ, you can't even opt for another
>provider, like you do in ADO.NET and on J2EE JMS. That's why I started a
>However, I want to extend System.Messaging (in truth, the extensions are
>planned to go within a Mono.Messaging namespace) to allow for pluggable
>queueing services providers, but it may penalize performance, or bypass
>server features: for instance, IBM's now renamed WebSphere MQ, have
>encoding/codepage conversion of messages built-in.
>I do not have a lot of knowledge about how messaging >works (more than
>what I read from my COM+ book), but it looked >relatively simple to
>implement. Up to the point, that we wanted to >implement it for Bonobo
>back in the pre-Mono days.
>It would be very fun to write such a beast in C#, but >my knowledge is
>Rusty, and I have promised myself not to write new code >until I fix the
>known bugs in my current code ;-)
MSN 8 with e-mail virus protection service: 2 months FREE*