JLCA 3.0 - Java Messaging Service (JMS)
Messaging is a system of asynchronous request conducted as event-driven communication layer that allows applications to exchange information in the form of messages. The Messages are transmitted using a Message Oriented Middleware (MOM), an intermediary between the clients exchanging information. JMS is an API to access messaging systems that can be used with many different MOM vendors. It also provides a JMS compliant service. JMS is mainly converted to .NET framework through System.Messaging API. Converted applications only support a unique MOM: Microsoft Message Queuing (MSMQ). MSMQ must be installed separately and MSMQ v3.0 should be used for applications using Multiple-Destination Messaging.
Principally, JLCA 3.0 helps to convert the following JMS features: Queues/Topics, Message Producers, Message Consumers (Listeners), Messages (Headers, Properties and Bodies) and Exceptions. JMS Features like Connection Factories, Connections and Sessions are not converted since they are not needed in .NET.
Table 21 and Table 22 show the most relevant details about JMS conversion. In a summarized manner, they enunciate the JMS features preserved in converted applications. On the other hand, they suggest the issues that the user should take care while converting applications using JMS.
Coverage Details
Class / Interface in Package javax.jms |
Functionality |
JLCA 3.0 Coverage |
Description |
BytesMessage StreamMessage |
BytesMessage is used to send a message containing a stream of uninterpreted bytes. StreamMessage is used to send a stream of primitive types in Java. |
Converted |
Converted to System.Messaging.Message. The message contents are written /read to/from the property BodyStream using System.IO classes such as BinaryWriter and BinaryReader. |
Connection ConnectionFactory QueueConnection QueueConnectionFactory TopicConnection TopicConnectionFactory |
Interfaces supporting the connection facility. |
Not Converted |
System.Messaging.Message.MessageQueue takes care of the connection implicitly. |
ConnectionConsumer ServerSession ServerSessionPool |
Interfaces supporting pool facility to process messages on the server. |
Not Converted |
In .NET Framework, MSMQ does not support a pool-like facility. |
ConnectionMetaData |
ConnectionMetaData provides information describing the Connection object. |
Not Converted |
.NET Framework has only metadata about queuing. (System.Messaging.Message.SenderVersion). |
DeliveryMode |
DeliveryMode describes the delivery mode supported by JMS– PERSISTENT or NON-PERSISTENT |
Converted |
Its field's values are converted to boolean values as they are used by System.Messaging.Message.Recoverable. |
Destination Queue |
Destination object encapsulates a provider-specific address. Queue object encapsulates a provider-specific queue name. |
Converted |
In .NET Framework a queue reference is simply a string path. So, they are converted to System.String. |
ExceptionListener |
JMS provider informs the Connection object's registered ExceptionListener about connection problems. |
Not Converted |
In .NET Framework, registered clients are not notified about connection problems. |
IllegalStateException |
This exception is thrown when a method is invoked at an illegal or inappropriate time or if the provider is not in an appropriate state for the requested operation. |
Converted |
Converted to System.InvalidOperationException as it has a similar behavior. |
InvalidClientIDException |
This exception is thrown when a client attempts to set a connection's client ID to a value that is rejected by a provider. |
Not Converted |
In .NET Framework, a connection’s client ID could never be invalid as the equivalent property is read-only. |
InvalidDestinationException JMSException JMSSecurityException |
These exceptions are thrown when provider considers destination or name/password as invalid. |
Converted |
System.Messaging.MessageQueueException is used to notify .NET Framework’s equivalent faults. |
InvalidSelectorException |
This exception is thrown when a JMS client attempts to give a provider a message selector with invalid syntax. |
Not Converted |
In .NET Framework, approach for message selectors is not supported. |
MessageConsumer MessageProducer |
MessageConsumer is used to receive messages from a destination. MessageProducer is used to send messages to a destination. |
Converted |
System.Messaging.MessageQueue provides a similar approach in .NET Framework Messaging. |
MessageEOFException |
This exception is thrown when an unexpected end of stream has been reached when a StreamMessage or BytesMessage is being read |
Converted |
Converted to System.IO.EndOfStreamException. |
MessageListener |
MessageListener is used to receive asynchronously delivered messages. |
Converted |
In the onMessage method some lines of code are added to support the asynchronous message delivery in .NET Framework. |
MessageFormatException MessageNotReadableEx MessageNotWritableEx |
These exceptions are thrown when JMS Client attempts to read write-only message or to write to read-only message or to use a datatype not supported by provider. |
Not Converted |
.NET Framework’s equivalent for StreamMessage will never throw a similar exception. So a workaround could require adding near places where these exceptions are caught - the specific code to check the message availability and integrity. |
MapMessage Message ObjectMessage TextMessage |
Message is root interface of all messages. MapMessage is used to send a set of name-value pairs. ObjectMessage is used to send a message that contains a serializable object. TextMessage is used to send message containing java.lang.String. |
Converted |
Converted to System.Messaging.Message because the property Body could contain different kinds of messages. To convert MapMessage, it wraps a SortedList. To convert ObjectMessage, it wraps the respective object. To convert TextMessage, it wraps a System.String. Message custom properties (application-defined) are not supported in .NET Framework. |
QueueBrowser QueueReceiver QueueSender |
QueueBrowser is used to look at messages on a queue without removing them. QueueReceiver is used to receive messages that have been delivered to a queue. QueueSender is used to send messages to a queue. |
Converted |
System.Messaging.MessageQueue provides a similar approach in .NET Framework Messaging. |
QueueRequestor TopicRequestor |
These helper classes simplifies making of service requests. |
Not Converted |
No equivalent functionality is found in .NET Framework. It can be implemented by the user. |
QueueSession Session TopicSession |
In Java, sessions are used to create different kinds of message objects, message producers and consumers, and to manage transactions. |
Not Converted |
In .NET Framework, this functionality is implemented using classes Message, MessageQueue and MessageQueueTransaction. |
ResourceAllocationException TransactionInProgressException TransactionRolledBackException |
Exceptions |
Converted |
These exceptions are converted to a more general exception (System.Exception). |
TemporaryTopic |
TemporaryTopic object is a unique Topic object created for the duration of a TopicConnection. |
Not Converted |
In .NET Framework, the approach for a publish/subscribe system does not support the creation of temporary topics. |
TemporaryQueue |
TemporaryQueue object is a unique Queue object created for the duration of a QueueConnection. |
Converted |
It is converted to System.String to represent a temporary queue created by a Support Class. In .NET Framework, there are no temporary queues; so the converted code creates a physical one. It is expensive and it must be deleted explicitly. |
Topic |
Topic object encapsulates a provider-specific topic name. |
Not Converted |
In .NET Framework, the term "topic" is different. The multiple destination messaging is represented using different types of string formats. |
TopicPublisher TopicSubscriber |
TopicPublisher is used to publish messages on a topic. TopicSubscriber is used to receive messages that have been published to a topic. |
Converted |
System.Messaging.MessageQueue provides a similar approach in .NET Framework Messaging. |
XAConnection XAConnectionFactory XAQueueConnection XAQueueSession XASession XATopicConnection XATopicSession |
These are interfaces to provide XA interoperability. |
Not Converted |
For a class to be able to use XA interoperability in .NET Framework, it should inherit from System.EnterpriseServices.ServicedComponent. |
Table 21: JMS Conversion Coverage – Package javax.jms
Issues
Issue |
Description |
Connections And Connection Factories |
.NET Framework Messaging uses a different mechanism to access and reference queues. MSMQ has neither "administered objects" nor factories. Connections are opened automatically while sending and receiving. So, the user should review the converted code to possibly ignore all the code used to create a connection (through JNDI). In .NET Framework, they are not needed. |
Custom Messages |
Classes implementing the interface Message to define user-customized messages are converted to classes derived from System.Messaging.Message. Conversion of some Message‘s member is not supported. Conversion of custom messages requires some changes depending on the nature of the user defined message. The user should review the converted code carefully in order to assure its functionality is equivalent in .NET Framework. The user must localize the not converted and unnecessary issues in .NET Framework model. |
Custom Properties |
Functionality related to attaching custom properties to messages is not converted. The user should adapt this behavior to the target application. A workaround could require the use of a Hashtable to add/ retrieve custom properties and serialize/deserialize it to/from the property Message.Extension. |
Destinations (Queues and Topics) |
In .NET Framework, the one-to-many messaging handles topics as multiple queues. Queues/Topics are converted to Strings as their reference is a special formatted string. |
General Issues And MSMQ |
JMS is converted to .NET Framework Messaging and MSMQ as the back-end messaging provider. MSMQ is the only MOM supported in .NET Framework. Converted applications require install MSMQ as a separate package over Microsoft Windows 2000 or XP (depends of the MSMQ version). The user could config the queues using the Microsoft Management Console at ControlPanel->AdministrativeTools-> ComputerManagement->ServicesAndApplications-> MessageQueuing or using the methods System.Messaging.MessageQueue.Create. |
JMS Interop |
Converted JMS applications can not use JMS-compliant MOMs because .NET Framework Messaging is a wrapper for accessing MSMQ technology. A workaround could require using a bridge that translates message formats. |
Message Acknowledgement |
MSMQ does not handle acknowledgment as JMS-compliant MOMs, in the sense that it does not re-send messages when a MOM does not receive an acknowledgment. In .NET Framework, the user has to implement the code to receive process acknowledgment and re-send messages. Acknowledgement requesting could require the use of properties Message.AdministrationQueue and AcknowledgeType. |
Message Concurrency |
Message concurrency behavior though JMS classes ConnectionConsumer and ServerSessionPool is not converted. To support concurrency, the user could write a multithreaded server application having a client running for message processing. |
Message Listeners |
Classes implementing the interface MessageListener are converted for asynchronous message delivery. Since, there is no equivalent in .NET Framework; some code is automatically added in the converted message listener to support asynchronous operations. Finally, an event delegate is attached to the event System.Messaging.MessageQueue.ReceiveCompleted. |
Message Selectors |
The user should review the target code and adapt the Message Selectors functionality to .NET Framework Messaging model. A workaround could require the use of method MessageQueue.Peek to look at messages without removing them from the queue. |
Publish/Subscribe Model And Multiple-Destination Messaging |
Applications using Publish/Subscribe are converted to use Multiple-Destination Messaging. MSMQ supports durability by default (as Durable Subscribers in JMS). To enable Multiple-Destination Messaging, the user must install MSMQ v3.0 (only available for Win XP). Also, the user needs to change the path referencing the queues which can be done through three different mechanisms (IP Multicasting, Format Names and using Active Directory). The user should decide which mechanism of Multiple-Destination Messaging to use. |
Security |
Conversion of applications using the standard JMS security (to authenticate clients against the messaging server) requires user intervention as authentication works differently in .NET Framework and MSMQ. To authenticate a messaging application, the user could use the following classes of System.Messaging namespace: Trustee, MessageQueuePermission and MessageQueueAccessControlEntry. |
Sessions |
In .NET Framework, sessions are managed automatically by the class System.Messaging.MessageQueue. So, the user should review the converted code to possibly ignore the unnecessary code related to session management. |
Temporary Queues |
Temporary Queues are converted as non-temporary as the target code creates a physical queue that is not deleted automatically. Creation of temporary queues is converted through a Support Class. So, the user should remove them explicitly when necessary. Queues are only removed by calling the method delete. The application could require the design and implementation of a better approach for temporary queues. In .NET Framework, use of physical queues indiscriminately produces overhead. |
Table 22: JMS Conversion Issues
Comments
Anonymous
June 13, 2006
JLCA 3.0 — это такое средство для конверсии кода Java в код C#, причём таким обрAnonymous
June 18, 2006
The comment has been removedAnonymous
April 24, 2008
Yes you provided a tremendous information on jms.... really it is very good.But please provide some sample projects on jms so that the readers can easily understood the concept.Anonymous
June 08, 2009
PingBack from http://cellulitecreamsite.info/story.php?id=4308