There are many optional methods to send and confirm the receiving message, which enables developers to deliver messages flexibly.
By Peter Varhol
Messaging in the enterprise is increasingly recognized as an important tool for creating an enterprise application. It is not too obvious for creating an application itself, but it may not be too obvious, but for the application and integration of cross-commercial processes. Said, its importance is very big. Message transfer allows us to establish an asynchronous communication channel between applications that cannot work synchronously or between application components. What is the benefit of establishing these types of channels? Enterprises can get more information without having to create a new underlying architecture and custom new enterprise applications.
For beginners, they will have questions about the news itself: What is news, what? The message is completely defined by the needs of the business process, rather than being defined by an arithmetic unit. A message can be any discontinuous message segment. It can contain a file, or other formatted file, a text request or response, or an instruction to perform a specific action.
Java Messaging Service (JMS) does not change the message content. It just ensures a way of data transmission. This feature makes JMS very flexible in use and response to different uses (see Figure 1).
figure 1.
Ensure the delivery of messages
Java 2 Platform, Enterprise Edition (J2EE) 1.2 provides synchronous messaging, which means that the message provider and the recipient must agree on the content and delivery time of the message. Starting from J2EE 1.3, Java integrates asynchronous messaging in its enterprise application solution. This mechanism of JMS includes a bottom API to access the enterprise message delivery system. JMS supports message queues and more modern publishing - Subscribe-subscribe messaging methods.
Users in the enterprise are unlikely to deliver messages by using JMS directly. Alternatively, integrated software vendors use JMS in a large architecture, including applications, servers, and message providers that provide more comprehensive and higher levels. Enterprises will use JMS in these architectures that provide advanced development tools and application management support.
Companies (IBM, BEA, Sun, and Oracle) developed and promoting Application Server are also concentrated on the use of JMS messaging techniques because JMS may need to be applied as effective communication mechanisms between different applications. Some functions of the program server. In particular, Message transfer using Enterprise Java Beans (EJBS) makes an application server a major part in this structure. As the message passes the viable solution for communication between applications, JMS will become an important consideration for application server vendors.
In fact, messaging will be used more to connect existing applications and databases instead of connecting new components. Message delivery, or more clear message delivery architecture, a connection between the previously legacy, Data Warehouse, the destination, the transaction system, and even new distributed applications, but it is typical After the application is deployed, it is not a planned section of the enterprise application and data policy (see the comparison of toolbar "JMS and Web Services").
The comparison of JMS and Web Services is as we may know, Web Services ... More below is how companies use message service: In most companies, we developed and deployed applications to solve specific business process issues. Over time, users find that these applications will provide more business information if more data can be obtained. If these applications are written in J2EE, JMS is a natural choice for maintaining application integrity while providing a technical solution to business issues. Even if one or two applications are written on the platform left, if the company is planning a long-term Java policy, then JMS still meaningful. The supplier uses JMS as a technology, and the message delivery has been a few years. Products such as IBM MQSeries and Microsoft MSMQ are messaging providers based on transaction-based distributed applications. However, in most cases, the transmission mechanism is determined by the company developers. These messaging providers are largely designed for another era. In this era, a transaction client or terminal must transmit and receive data from a large legacy system or data warehouse.
The architecture under JMS is somewhat different. The JMS message provider component is implemented inside the application server. Do you have a certain conceptual meaning because many applications that use messages are running in that environment.
However, when the application included in the message is legacy application, the application server means that some JMS functions cannot be used. On the contrary, it means that the proprietary features in many JMS solutions means that you are bound to that solution, and there is no cross-platform portability.
BEA supports JMS through its iconic WebLogic application servers. WebLogic JMS implements several JMS features, including an optional JMS tool for defining a message user server management pool. Currently, JMS under WebLogic is not a cluster service, that is, it does not support load balancing or Failover.
Since JMS is not a cluster service, all clients must be configured to use the same instance of JMS on a particular member of a cluster. The user must configure one of the servers as the JMS provider. This configuration means that the attribute file should define all clients to access the JMS Connection Factory, and the connection pool you want to use by JMS. In summary, put the message provider and the user on the same server can enhance the reliability of the application because if the server is broken, all messages will be lost, and everyone must start from the beginning.
IBM's WebSphere Series also implements a JMS tool through its WebSphere MQ product (after the JMS message delivery support is added, rename it from MQSeries product line). In 2002, the company added support for Java, including publishing - subscription messages, and improving performance and scalability.
Some suppliers, such as Spiritsoft, have progressed further, it will use JMS to build a more wide application integrated architecture mechanism, and enterprise developers can use it to connect different kinds of enterprise systems. These architectures do not need to include application servers, but as alternatives, it can provide a stand-alone manner to connect to the Java and local applications in the company with Java. Spiritsoft's SpiritWave architecture claims to connect all legacy intermediate partial interior systems that use JMS in a variety of legacy applications.
Several suppliers are integrating JMS into a more comprehensive message transfer underlying architecture. For example, Ashnasoft's ASHNAMQ includes support for JMS 1.1, which can be used in real time web, wireless, Microsoft .NET, and Java clients. ASHNAMQ's management tools can dynamically create connectivity and sessions, which have multiple messages, recipients, and browsers to send, receive, and view messages. Similarly, Sonic Software's SonicMQ can be accessed from JMS, C, C , COM, and HTTP clients and support messaging with application servers, other messaging systems, FTP, and email. Sonic's Dynamic Routing Architecture and cluster technology can be SonicMQ deployment for advanced scalability.
In fact, all applications server vendors that implement JMS provide at least a message transmission and processing. In many cases, the supplier expands the standards in the field confirmation or application cluster. From part to some extent, the proprietary extension of the supply product represents JMS standards is not mature. There are still many Messages that JMS do not take into account, or confirm these aspects, but have not been implemented.
An important aspect of JMS is that you can control any messages and which message you can send, because it is not all the creation of all messages. In some cases, whether the message arrives at the destination is not particularly important. For example, if a message includes a weather forecast sent to someone, since this person is not within his or her wireless device reception, the message is not considered important.
On the other hand, sometimes it is absolutely important to receive and deal with a message. In business activities, it is necessary to determine if they receive and process a order, credit confirmation or inventory order. In some cases, in health care, national defense or space exploration, if there is a failure, it will cause catastrophic consequences.
figure 2.
Point-to-point messaging
JMS can complete various tasks. Of course, we need to trade. To confirm that the message is received, allowing copy messages or implementing a custom confirmation tool requires more complex code and higher processing capabilities. However, developers have become accustomed to doing this weighted, this type of functionality can make JMS for many different applications.
JMS provides two ways to messages: Point-To-Point and Publish-subscribe. Each method can be used in a variety of different situations. Point-to-point messages have a recipient for each message. The recipient can be different, but only one recipient is used to use the message. This method can be used for unique transactions, such as online purchase (see Figure 2).
image 3.
subscriber
On the other hand, Publish-subscribe believes that messaging is for multiple subscribers. This method allows multiple users to subscribe to a special message and receive that message, regardless of the number of other subscribers. When the message is sent, it is not automatically processed; as an alternative, you can think that it is subscribed by the subscriber (see
image 3).
These methods are implemented in the different mechanisms in the Javax.jms package. In both cases, the starting point is the Destination interface. Destination represents a message delivery channel, which is a mechanism for connecting message sources and recipients. For the Point-to-Point message, the interface queue extends Destination. As you expect, Queue is arranged in order, and one is used in order. Queue also needs to specify the recipient of the message, and a message has only one recipient.
For the Publish-Subscribe message, the interface Topic extends Destination. Topic allows multiple subscribers to receive messages. Receiver must subscribe, that is, take some actions to ensure they on the recipients of these messages.
From the concept, Destination is not a transfer mechanism. It is a list of sequentials, just like the meaning of Queue this name. For Queue interface, it is like a queue data structure that allows the recipient to use messages in order. Topic is also like a queue data structure, which is different from all subscribers receive messages, it will be removed from the list. Message providers, usually a type of application, create a message and use the Destination interface to place them waiting to be sent. The user, ie the message recipient, reads the message, and removes the message from the list in the case of the Queue Interface. Conceptually, this process is simple, just passes data from an application to another application. However, the details are not as simple.
Planning anyone who uses JMS for applications to consider messaging, message reception confirmation, component failure, and fault recovery methods. JMS provides a variety of optional methods that require us to trade. The AUTO mode is the simplest form that confirms the received receipt, which can be automatically confirmed. The use of Auto mode provides a one-time transmission guarantee for the message. Listing 1 is an example of using AutoAcknowledgement to receive JMS messages.
In contrast, in Dupicates Okay mode, although the message can still be automatically confirmed, it is not guaranteed in the confirmation response time. When the processing capability and bandwidth can be confirmed, the message is confirmed. This method is useful when confirmed is necessary, but further news is not dependent on it. Listing 2 illustrates an implementation example of using the Duplicates Okay method.
The third method is Client mode, in this mode, no automatic confirmation. Alternatively, the recipient is responsible for providing a confirmation to the sender. This approach can be adjusted to confirm, so it is most satisfied with the needs of the application. Weighing point is that if you confirm, confirmation must be implemented within the receiving application, not the tool provided by JMS. The cost is a complicated code, and the manual implementation also needs resources.
Other types of confirmation provided by JMS vendors are largely variants of these options. Other methods are not part of JMS, so it is advantageous to use them. They can give you a choice option for your application needs, but is based on standardization and portability.
From the application's position, there are several optional methods for message delivery mechanisms. It is important to have multiple optional methods because the application may not only make sure to ensure the receipt of the message, but also ensure the processing message. If the application or its hardware fails before the message is processed, another mechanism may need another mechanism to resend the message.
A trading session allows an application to receive messages by creating a local transaction. In this manner, the received application controls the transmission of the message through its function (such as submitting transactions in an appropriate time, or rollback transaction when a problem occurs).
You can also use the message-driven beans to control the processing of messages, use the Container or NonContainer method. The Container method allows the Bean Container to monitor whether the transaction is successful. Using this method, Bean specifies the Container in the deployment descriptor, and Container determines whether to submit transactions or rollback transactions based on its confirmation of the application.
As a choice, Bean can also monitor whether the transaction is successful in the case of Container does not participate. In this case, monitoring must be manually implemented. We describe the message sending process and whether the transaction is submitted or rollback. This manual approach provides higher degree of flexibility again with code complexity.
Is JMS suitable for your company? The first aspect you should consider when using JMS, whether your application accepts a message-based communication. If you have already used a queue structure, you can use JMS. If not, then ask yourself, if you have a separate application to benefit from the transaction. You may have not used messaging, but you can use it as a longer goal to simplify business processes or improve data streams. Once you have determined your application or process, you can use JMS messaging, then you need to make sure you have a underlying architecture to support it. The underlying architecture includes hardware for network and application servers, and support for application servers. At the same time, it is also important to determine your demand for performance, messaging, confirmation, and failure, and to ensure that the hardware and software you choose support these needs.
JMS can be used for various applications for any enterprise. By carefully designed and implemented messaging, transaction-based processes can be expanded and improved. JMS provides Java-based messaging, which supports these goals, and uses Java technology and existing planned Java applications. Their integration allows the JMS architecture to provide actual value to the application integration project.
About the Author:
Peter Varhol is a technical communication of Compuware Corporation. His contact information is
Peterv@mv.mv.com.
