• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

[JMS] communication between producer-consumer, different vendors

 
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi. The specs for JMS 1.1 say: "JMS does not define a wire protocol for messaging.", so this means different vendors may define totally different approaches, right?
Suppose I have an producer A, and produce messages to destination B, which are different vendors. Will this work? Or can I only send messges produced by one vendor to destinations backed up by the same vendor implementation? Basically, can I send messages from an SSB in Glassfish and process it with a MDB on, say, JBoss? Or can messages produced by Glassfish implementation be processed only by other Glassfish instance?
 
Ranch Hand
Posts: 2187
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Keep in mind that the Java Message Service (JMS) API is only a programming interface. The vendors that create message server products create their own implementations and typically make it compliant with the JMS API.

An example, a C++ application can post a message on a MQ Series Queue X and a Java-based application can be listening for messages on MQ Series Queue X and pick them up.

Applications can send messages using a message server if the vendor has provided an API for the particular programming language.

Applications can receive messages using a message server if the vendor has provided an API for the particular programming language.

The benefit of using the JMS API is that you reduce the syntax-level dependencies between the Java-based application and the message server. If you program with the JMS API, you can easily switch to a different message server. If you programmed with the server's specific API, then you will have more work to do in order to change message servers.

The MQ Series message server has it's own Java-based API and it also has a JMS implementation. It is a best practice to use the JMS API.
[ December 29, 2008: Message edited by: James Clark ]
 
Raf Szczypiorski
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I understand all that (using interfaces and so on), the question I wanted to ask is different, maybe I asked in the wrong way.
What I meant was, that suppose a sender and receiver are two different, but JMS-compliant implementations. They are compatible with each other only on the interfaces level - both use JMS, and one send and the other receives messages. So, the producer will send a, say, TextMessage, and the bytes that traverse the network are in a specific format, specific to this implementation. The receiver, being a different vendor implementation, may use a completely different implementation class for TextMessage, and also there may be many differences on the network level - I mean, the bytes that constitute the TextMessage for the sender may mean nothing but garbage to the receiver. Is this the case? Or is my assumption a fallacy, and different JMS providers can "talk" to each other?
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

What I meant was, that suppose a sender and receiver are two different, but JMS-compliant implementations.



Ok. Application A (sender) and Application B (receiver). They are applications that use the JMS API to exchange messages using one message server. The message server code contains the server-side implementation of messaging. The applications use client API to send/receive messages. There is only one message server. There is only one server implementation. It can have many client API. Applications use the API which is appropriate, e.g. C++, Java, etc.

They are compatible with each other only on the interfaces level - both use JMS, and one send and the other receives messages.



Ok. There is a message server in between them. Let's not forget this critical part.

So, the producer will send a, say, TextMessage, and the bytes that traverse the network are in a specific format, specific to this implementation.



Ok. Application A sends a TextMessage to a queue on the message server. Bytes are bytes. They go on the the wire to the message server. The message server receives the bytes and puts the message on one of its queues (the one that the receiver is watching.)

The receiver, being a different vendor implementation, may use a completely different implementation class for TextMessage, and also there may be many differences on the network level - I mean, the bytes that constitute the TextMessage for the sender may mean nothing but garbage to the receiver.



Application B (the receiver) is not a vendor implementation. It is watching the queue and the message server sends the TextMessage to Application B. It get the message in a format that is understood by Application B.

It is wrong to think of message servers as JMS providers. A message server is compliant with the JMS API, that is all. A message server is either compliant with JMS or not. The message server provides messaging services.


Application A can send messages to the message server, if the vendor provides an API, it can be JMS compliant or not.

Application B can receive messages from the messages server, if it can talk to the message server.

The sender and receiver (Application A and Application B) never communicate or connect directly to exchange messages. There is a message server between them. The actual format of what a TextMessage is is only known to the message server. It translates between its storage format and the programming API, JMS for example.
[ December 29, 2008: Message edited by: James Clark ]
 
Raf Szczypiorski
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi. Your explanation assumes there is one JMS implementation, and A and B both use it. What I was asking about (and failed to be specific enough) is that A is using one JMS server to produce messages, and B is using another (different) server to consume them.
For example: I have a host A, there is a Glassfish server running, having an EJB that produces messages (using Open Message Queue). It sends the messages to a destination which is a remote host (host B). This host B is running JBoss AS 5, and has a MDB that consumes messages send to that destination (JBoss Messaging as JMS implementation).
So, producer A creates text message using Open MQ on host A, and it is somehow marshalled into bytes (Open MQ is the marshaller) to get via network to the configured destination, which is JBoss Messaging on remote host B. The bytes then are attempted to be unmarshalled in to a TextMessage, but this time it is JBoss Messaging that unmarshalls, and it may not know how to re-create a TextMessage object as the bytes that came in are understandable to Open MQ only.

The question is: are JMS implementations able to communicate in this way, or both host A (producer) and host B (consumer) would have to use the same JMS implementation, say both running Glassfish, so that the marshalling and unmarshalling are compatible?

PS A and B don't have to be remote to each other, even if they are the same host, marshalling and unmarshalling would still happen, of course.
 
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Raf Szczypiorski:
The question is: are JMS implementations able to communicate in this way, or both host A (producer) and host B (consumer) would have to use the same JMS implementation, say both running Glassfish, so that the marshalling and unmarshalling are compatible?



I don't think there will be any problem as both servers should understand and able to process those text messages. Of course, there might be problem if they are using two different encoding standards (i.e. one uses UTF8 and the other uses ASCII). But it should be a configuration matter only which is easy to fix. Also it can happen to the two servers with the same implementation as well.

What you are worrying about is like a text file created by Notepad++ cannot be opened/viewed properly using Textpad. And you know it should work OK.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

What I was asking about (and failed to be specific enough) is that A is using one JMS server to produce messages, and B is using another (different) server to consume them.



If Application A (sender) is putting messages on Message Server A, then Application B (receiver) has to get the message from Message Server A.

Code puts message on a queue. Code listens for message on a queue.

You are adding names of software, version numbers and describing a cooky sounding possiblity that is very unrealistic. (See *** below)

If I code a Session EJB and deploy it to Glassfish. And I want to send a message to another Session EJB which is deployed on Websphere. This is fine. What do I need?

I need the client API for Websphere's MQ Series and the name of the message queue which is set up in Websphere. I code the Session EJB in Glassfish to use the JMS API to send a TextMessage to the message queue in Websphere.

I will have a Message-Driven Bean listening for messages that are placed on the Websphere queue and when they come in, I then forward control to the Session EJB deployed in Websphere. No problem. The fact that the message was sent from code deployed in Glassfish means nothing.

*** You seem to be asking if message servers communicate directly with each other. The answer is they don't. If you needed two different message servers to comunicate with each other you would need to write the code for this using each server's client API. Message servers communicate and interact with software applications, not other message servers.

Glassfish has an embedded message server. Any application code that wants to put messages on this server can by connecting with and using the JMS API.

If an application (deployed in JBoss) wanted to post messages in the Glassfish message server, then all it needs is to connect via JMS API. This is possible because the message server embedded in Glassfish is JMS compliant.

If an application (deployed in Glassfish) wanted to post message in an embedded message server in JBoss, then all it needs is to connect via JMS API. This is possible because the message server embedded in JBoss is JMS compliant.


When a message server is connected to properly, it knows how to handle the messages it receives. It does not matter where the messages come from.


When an application is coded to connect and listen to a message queue properly, it does not care about where or who or what places the message on the message queue. A message server will not accept messages that are not in a compliant format. And a message server will not send messages in a non-compliant format. If the message server is JMS compliant, then any JMS message can be produced or consumed by any JMS compliant code.

Messaging is a core technology in distributed computing. It has been around for decades. The Java API for messaging and using a message server is very robust. Understanding the details of messaging is a fancy skill to have. About six or seven months of dedicated study and coding should get you grounded. Good luck!
[ December 29, 2008: Message edited by: James Clark ]
 
Raf Szczypiorski
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


If I code a Session EJB and deploy it to Glassfish. And I want to send a message to another Session EJB which is deployed on Websphere. This is fine. What do I need?

I need the client API for Websphere's MQ Series and the name of the message queue which is set up in Websphere. I code the Session EJB in Glassfish to use the JMS API to send a TextMessage to the message queue in Websphere.


I think this is the answer to my question: if I want to send a message to another server / JMS implementation, I must have the client libs for that implementation (let it be JMS or not, preferably JMS ;-)). I can't connect and send messages to Websphere just having the default JMS implementation on Glassfish.
This solves my doubt, and gives me the answer what to do - jsut use the other's implementation client API, and use it. It's that simple.
Thanks
[ December 30, 2008: Message edited by: Raf Szczypiorski ]
 
Raf Szczypiorski
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I found such thing in JMS specs 1.1, point 3.12:


A provider must be prepared to accept, from a client, a message whose
implementation is not one of its own. A message with a �foreign�
implementation may not be handled as efficiently as a provider �s own
implementation; however, it must be handled.


Does this mean that I can send a message to Websphere with Glassfish, and it will just work?
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Does this mean that I can send a message to Websphere with Glassfish, and it will just work?



Yes, it will work like Moose Magic

You CAN send a message from a client object deployed in Glassfish to a message queue of a message server within Websphere.

From any JRE, you CAN connect to and listen for messages placed on a message queue of a message server within Glassfish or Websphere.

From any JRE, you CAN send a JMS message from a client object a message queue of a JMS message server.

Each message server consists of two parts: (1) server implementation and (2) one or more client API (some API may be JMS compliant and some may not be compliant).

A JMS compliant message server can be connected to by any Java object, anywhere in the world by using the JMS API. This is how wonderful programming to interfaces is. The programmers that created the message server wrote the implementation for their server and made it compliant with the JMS specification.

What does a client object need to post messages to a message server? It need the server's JMS implementation (client API).

What does a client object need to listen to messages of a message server? It needs the server's JMS implementation (client API) and the application server's client runtime libraries.

Let's look at a code example.

The IP address is to an instance of Websphere. The JMS ConnectionFactory is called: SugarBearConnectionFactory. The implementation of the ConnectionFactory is specific to Websphere's message server. The objects we get from the factory are all server-specific JMS implementations (client API).


[ December 31, 2008: Message edited by: James Clark ]
 
Raf Szczypiorski
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your answers and patience
 
F is for finger. Can you stick your finger in your nose? Doesn't that feel nice? Now try this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic