关于C#中调用java JMS操作！

Question

看起来目前还没有办法，好多的JMS厂商并没有提供这个功能。以后吧...这是在微软英文新闻组中的一个讨论：我贴过来，你参考一下：
问：
－－－－－－－－－－－－－－－－－－－－－－－－－－－
Hi People,Has any body connected to MOM components via JMS using a .NET
application/service?
I have a requirement to subscribe to a message queue in the JAVA world and
wanted to know if there are any libraries exposed in the Microsoft world.
I saw an open source com library called ActiveJMS and will be testing that.
Are you aware of any similair components?Thanks for you views
Regards,
Rajesh－－－－－－－－－－－－－－－－－－－－－－－－－－－
答：
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
Has any body connected to MOM components via JMS using a .NET
>application/service?
>I have a requirement to subscribe to a message queue in the JAVA world and
>wanted to know if there are any libraries exposed in the Microsoft world.
...JMS is (AFAIK) a standard set of Java interfaces for accessing a
queue manger (ie JMS is to queues as JDBC is to databases). As
such, it isn't JMS you're probably wanting to access from .Net,
but rather the underlying queue manager itself.Off the top of my head, the following would all be "mainstream"
ways of interacting with a queue manager from .Net:* If the queue manager happens to be MSMQ, look at the
System.Messaging namespace in the .Net framework.* If you want read/write an IBM MQSeries queue *but* keep all
your .Net code using (only) Microsoft's stuff, you could look at
using MSMQ (via System.Messaging) then Host Integration Services
(HIS) to translate MSMQ to/from MQSeries. [aside: This adds
moving parts - ie you have TWO different queues and queue
managers to deal with, but everything is an off-the-shelf
technology.]* Again if it's MQSeries you're needing to talk to, IBM offers a
COM interface for it, which you could (probably - I've not tried
it myself) use to access MQSeries from your .Net code using COM
Interop.* You could use a "bridging" product (JNBridge is mentioned
regularly in this and other newsgroups) to directly call the JMS
driver implementation for the queue (ie the Java code running
within a Java VM) from your .Net code.Really the bottom line questions seem to be:1. Which actual queue manager do you need to work with (ie the
specific product, platform it's running on, etc)?
2. What is that vendor's .Net strategy (ie do they now ship .Net
drivers - or are they planning to)?
3. How many "othervendor" translators and shims are you happy to
integrate into your solution between your .Net code and the
queue manager (the need for these, and which ones they might be,
depends on the answers to 1 and 2 above).ted.h.
-- 
Ted Harper (Sydney, Australia)
Email: [email protected]
Voice: [phone]
－－－－－－－－－－－－－－－－－－－－－－－－－－－－