This Group now has over 1,300 members. As you may have noticed this means that any given thread is liable to generate a lot of messages from a lot of people. This can lead to confusion, so may I ask you when quoting someone else's written words to make the source clear.
The message below is a good example of how someone (in this case "chaudharyarvind" [= Arvind] whose nickname the system automatically puts in) has managed to make the previous writer anonymous. I must ask those who make a habit of doing this to desist from this confusing practice. Gervas Moderator --- In [email protected], "chaudharyarvind" <[EMAIL PROTECTED]> wrote: > > > JMS supports portability, but not interoperability. > > I totally agree on that. But, interoperability is a far cry in > software industry. For example, even two implementations of J2EE > specification "practically" do not interoperate. > > > The interoperability issue is that multiple JMS implementations > can't share > > the same queue. For example, I can't put a message on a queue > using IBM > > WebSphere MQ and get the message from the queue using Sonic MQ. > Both > > applications must use the same JMS implementation. > > Do you mean the physical queue? If so, I think multiple JMS > implementations have no business to share a common physical queue. > The underlying physical stuff should always be encapsulated > (shielded) from outsiders. If you mean a logical queue, then scope > moves to two applications rather then implementations and in that > case it is possible if they use standard JMS API. > I can't think of any scenario where different JMS implementations > need to share physical queues. > > For B2B interactions, > > that type of symmetric dependancy is extremely undesirable. > > Totally agreed. It's the B2B interactions that need a standard MOM > protocol to get the real benefit of MOM. > The "real" benefit because the B2B interaction can be done in a > client-server dialog without the needing interoperability but, then > you loose much of the benefits of MOM. A server-server dialog is > required for fully leveraging the MOM based B2B interactions. > > The other example can be in the SOA world where it makes quite a > good sense for a service-service interaction using a middleware > protocol. > > Other then these two, I can't think of any other example and I > guess, itâs because of these limited scenarios (though very > important), the AMQP is not getting the attention and importance it > deserves. > > -Arvind. > > > > Anne > > > > On 8/28/06, Gregg Wonderly <gergg@> wrote: > > > > > > Howard Kapustein wrote: > > > > Bad example. > > > > JDBC is asymmetric whereas the JMS discussion is revolving > around > > > > symmetric behavior. > > > > > > > > JDBC lets you talk to _a specific server_. > > > > Furthermore, that server _doesn't talk to you_. > > > > > > > > JMS - queuing - is more of a hub topology; the _interop_ issue > is if - > > > > when - you want multiple JMS-based applications to talk > together. You > > > > need a single implementation across them all, because JMS is > just an > > > > API, not a wire protocol. > > > > > > > > JDBC has the same issue theoretically - if you want all your > apps to > > > > exchange data in a database, they all need use the _same_ > database > > > > server/product. > > > > > > I guess I don't know how everyone is using JMS, perhaps there's > something > > > that > > > you're doing which is injecting limitations on how you can use > it? The JMS > > > API > > > requires the inclusion of the jms.jar to compile software using > it, in the > > > > > > compiler classpath. After that, you just need to include the > vendor > > > specific > > > jars in your classpath to use a particular JMS instance, based > on my > > > experience. > > > > > > I create a connection to the queue, and either become a producer > or > > > consumer on > > > that queue. All of that coding is completely vendor neutral. > What do you > > > do > > > that keeps your software from attaching to a queue from any > particular > > > vendor? > > > > > > Are people wanting to attach one queue to another queue without > an > > > intermediary? > > > I guess I'm not sure what the argument is based on. > > > > > > With JDBC, I do the same thing. I can attach the drivers for a > particular > > > JDBC > > > implementation to my software via classloading, and then use the > database > > > of choice. > > > > > > I have applications that run 24/7 doing this dynamically, client > and > > > server, > > > producer and consumer. > > > > > > Gregg Wonderly > > > > > > > > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
