Yes. You can write a snooper files to detect the service and restart the node upon node fail and a server instance fail.
Byte Messages contains a Stream of uninterrupted bytes. Byte Message contains an array of primitive bytes in it's payload. Thus it can be used for transfer of data between two applications in their native format which may not be compatible with other Message types. It is also useful where JMS is used purely as a transport between two systems and the message payload is opaque to the JMS client.
Bytes Message stores data in bytes. Thus the message is one contiguous stream of bytes. While the Stream Message maintains a boundary between the different data types stored because it also stores the type information along with the value of the primitive being stored. Bytes Message allows data to be read using any type. Thus even if your payload contains a long value, you can invoke a method to read a short and it will return you something. It will not give you a semantically correct data but the call will succeed in reading the first two bytes of data. This is strictly prohibited in the Stream Message. It maintains the type information of the data being stored and enforces strict conversion rules on the data being read.
When the JMS API was introduced in 1998, its most important purpose was to allow Java applications to access existing messaging-oriented middleware (MOM) systems, such as MQSeries from IBM. Since that time, many vendors have adopted and implemented the JMS API, so that a JMS product can now provide a complete messaging capability for an enterprise.
Since the 1.3 release of the J2EE platform ("the J2EE 1.3 platform"), the JMS API has been an integral part of the platform, and application developers can use messaging with components using J2EE APIs ("J2EE components").
The JMS API in the J2EE platform has the following features.
The JMS API enhances the J2EE platform by simplifying enterprise development, allowing loosely coupled, reliable, asynchronous interactions among J2EE components and legacy systems capable of messaging. A developer can easily add new behavior to a J2EE application with existing business events by adding a new message-driven bean to operate on specific business events. The J2EE platform's EJB container architecture, moreover, enhances the JMS API by providing support for distributed transactions and allowing for the concurrent consumption of messages.
Another J2EE platform technology, the J2EE Connector Architecture, provides tight integration between J2EE applications and existing Enterprise Information (EIS) systems. The JMS API, on the other hand, allows for a very loosely coupled interaction between J2EE applications and existing EIS systems.
At the 1.4 release of the J2EE platform, the JMS provider may be integrated with the application server using the J2EE Connector Architecture. You access the JMS provider through a resource adapter. For more information, see the Enterprise JavaBeans Specification, v2.1, and the J2EE Connector Architecture Specification, v1.5.
Client Mode and Binding Mode are the available modes in JMS.
Binding Mode: Using bindings is a simpler set up. You do not need to specify host name, channel or port as WebSphere MQ JMS classes use the Java Native Interface (JNI) to call directly into the existing queue manager API rather than communicating through a network. Bindings is a shared memory protocol and may offer better performance. Bindings can only be used when the queue manager is on the same node as the JMS client. To use the bindings connection, WebSphere MQ JMS classes must be installed on the WebSphere MQ server. this is the defaultMode in JMS.
Client Mode: Using client gives you more control, but it also means you must specify the values for the client configuration including host name, channel and port and optionally the client channel definition table. The WebSphere MQ client connection is used to connect to the queue manager.