In this period of J2EE Explorer (J2EE Pathfinder), Java Developers and Consultants explained why the message service is critical to the company's architecture, and your solution must overcome what type of obstacle, And in addition to the Java Message Service, JMS, there are alternative solutions. At the end of this article, he analyzes three available solutions (Simple JMS Client, combined with JMS session beans, and message-driven beans), and provides some specific guidelines to measure these options. .
Speaking of the choice of message delivery solutions, you can find solutions suitable for enterprises like with a glove. Your message delivery framework must be able to communicate between a set of applications and enterprise resources. Moreover, this message delivery frame must complete this task quickly and reliably. In addition, face the harassment and emergency situation of the day, it must be seamless.
In order to select the appropriate message to pass the solution according to your needs, you should first have a clear understanding of the current composition structure of your company and the future development trend. In addition, if you can easily understand the obstacles that the message delivery frame must overcome during the completion of the target, the choice of the solution will be helpful. Finally, you have to know how to choose: What is available technologies, as well as the applicability of various technologies for different environments and needs.
In this J2EE explorer, we will explain the above points. The first is an overview of the transfer of enterprise messaging, where we will focus on the role of messaging in your business, and give some challenges in establishing reliable communications. Next, we will quickly understand the angle of the architecture, in a typical enterprise network environment, how J2EE message delivery technology works with a message-oriented middleware. We will then discuss more specific discussions for the Java Message Service, JMS and J2EE messages. We will discuss the basic objectives and functions of three types of J2EE messaging clients, and you can also understand each type of J2EE message delivery client's own advantages and disadvantages. Finally, we will analyze some common messaging scenarios and solutions, which will help you choose the best J2EE message to transfer solutions for your business.
Enterprise Message Transfer 101 Enterprise Messaging Framework is designed to make one or more applications to overcome various obstacles to communicate. Common barriers include: two systems run (synchronous communication) simultaneously, multiple applications get the same message (multiple transmissions) requirements, most systems are heterogeneous, and network failures.
M The architecture of many businesses depends on the message-oriented middleware system (MOM) to provide a message channel for different types of systems. MOM provides a public, reliable way to make them easily created, exchanged, and processed messages without considering the details of the message delivery client. The message is sent to the server destination and domain (DOMAIN) instead of sending to the physical address. The message delivery client only needs to simply declare a particular domain and destination, providing the appropriate security token to obtain permissions accessing the domain, and then communicate with the message delivery server through that destination Interact.
In terms of concept, this is not different from the way of transmitting real emails in real life. The sender of the message is only responsible for using the correct packaging, providing the correct address and attached appropriate postage. The post office (here is an MOM system) to process all the issues related to the security and reliable delivery of the message, not any obstacles in front of them (machine failure, harsh weather, etc.). In an MOM system, the coupling between the client is relatively weak, which allows them to maintain the best quality of services without "online" all day. If it is possible to remove the application, it is always available in the need, and the maintenance and scalability will become easier to manage. You can apply offline, update applications, or as a routine maintenance work refresh, without worrying about the quality of the service.
The Java Message Service MOM server allows for different types of system swap messages, but each MOM vendor has APIs with its unique processing messages. This lack of standardization is unacceptable for Java technology development examples. In order to make full use of the existing MOM infrastructure, the J2EE platform provides JMS.
Java Standards In order to provide a platform-independent and supplier-independent solution, all Java technology can be divided into two parts:
A (or set) Defines the specifications and responsibilities of the technology and tool suppliers that implement the technology. A neutral interface, as a contract between application developers and tool suppliers. No matter what Java technology you use, you first have to write an application component of the interface provided in the technical specification, and then provide a particular supplier to the implementation of these interfaces at runtime. In J2EE, the specifications and APIs of enterprise messaging are JMS.
JMS defines the rules that pass messages in the Java Enterprise System and declare some interfaces that make it easy to apply messages between the application components and messaging systems (usually MOM). The JMS client opens to the destination on the MOM server and then sends and receives messages on that destination. JMS removes the burden on all underlying networks and routing issues in the GUARANTEED DELIVERY, Message Notification, Message Durability and Message Delivery System. JMS and MOM can work well because they all clause the responsibility boundary between messaging clients and servers.
The type of message passed JMS supports two basic messaging mechanisms. The first mechanism is a point-to-point message, in which the message is transmitted by a publisher (sender), by the subscriber (receiver). Another mechanism is publish-subscribe messaging, under this mechanism, the message is transmitted by one or more publishers, received by one or more subscribers. Although these two mechanisms are the actual foundation of JMS, many people still look at this technology in accordance with three messages:
One-to-one message is a point-to-point model. The message is sent by a JMS client (publisher) to a destination on the server, a queue. Another JMS client (subscriber) can access this queue and get this message from the server. Multiple messages can be stored in the queue, but only one message can be obtained each time. One-to-MANY MESSAGING is a publishing-subscription model. Here is a JMS client published a message to a destination on the server, but this time this destination is called a topic. The key difference here is that the messages in one topic include a parameter, which defines the durability of the message (it can wait for the subscriber for more than a server on the server). The message will remain in the topic until all subscribers of this topic take away a copy of the message, or the durability time of the message has expired, regardless of which of the above, the message Will be removed from this topic. Multi-to-MESSAGING, which is also a publishing-subscription model, and has expanded a pair of messaging models. In addition to supporting multiple subscribers, the model also supports a topic with multiple publishers. A good example of multiple messages is E-mail listserve: Multiple pubrs can deliver multiple messages to a topic, and all subscribers will get every message. The structure of JMS messages is quite intuitive. One part is used for routing, addressing, and message identification; there is an optional part, which can pass some of the application-specific parameters; the third part is stored The valid load of the message (text, byte, value map, object, etc.). These three parts are called heads, attributes, and mains, respectively, as shown in Figure 1.
Figure 1. JMS message structure
The type of message delivery model you use depends on your business needs. In a business, there are many messaging strategies that use more than one in a business. In some of the subsequent section, we will study three JMS solutions for the Java platform: Simple JMS client, combined with JMS session beans, and message-driven beans. We will re-review each type, their respective advantages and disadvantages, and their applicable to different enterprises.
Simple JMS Client Although JMS is an enterprise-class technology issued with Java 2 Enterprise Edition, you can easily convert a standard Java client into a support for JMS. Adding Enterprise Message Passages to Java Applets, command line applications, Swing applications, or Java WebStart is very simple. You simply add a small amount of method call to the J2SE application code, then add an interface containing JNDI (part of J2EE) and the JAR file of the implementation class to the classpath (ClassPath). If you have already loaded this JAR file on the client and add it to the classpath of your application, you can use JNDI to access the JMS provider (see the reference below to get the JMS message delivery) More information links).
The advantages and disadvantages of simple JMS clients, simple JMS client methods have many advantages, the most obvious advantage is its simplicity and universality. All J2SE applications can be interacted with a JMS message delivery system. In addition, the new application to use JMS is deployed to make a small amount of configuration on the client, and no configuration is required. The simple JMS client is an extension of almost any Java architecture. From a negative aspect, we will encounter problems such as safety, transaction processing, and scalability. For a simple JMS client, you can only choose to pop up security and transaction processing to a supplier, that is, these issues will be processed in a vendor. If your simple JMS client has to handle the sentive message, you will send a message, then you will encounter a scalability issue. JMS has no more than one built-in mechanism for more than one passed. To support concurrency requests, you need to extend the JMS client to generate multiple threads, or launch multiple JVM instances, allowing these threads or instances to run applications. In addition, it is also necessary to configure the JMS provider to have multiple subscribers on some appropriate destinations. At this time, you (or your development group) will question whether the simple JMS client solution is really simplicity.
Session Bean and JMS combine session beans to use JMS to use a viable business-oriented solution. Session beans are designed to fulfill requests for business services. Enterprise messaging systems must be queried to fulfill such a request, in this point, the enterprise message delivery system can be transparently accessed by a session bean. Using session beans as JMS clients also allow JMS to communicate into a context environment of a large business transaction. For example, a J2EE transaction can be created to get a message from a JMS provider, extract data from the message, and try updating the database. If the update operation fails and the transaction rollback (ROLLBACK), a message is sent to a JMS provider on a separate destination while giving a description of the reason for the failure of the transaction.
Enterprise Javabeans Technology Use the Explorer Connection Factory to access the extra container (Extra-Container). These resources are standard enterprise components, but not the core part of the J2EE container, including data sources, JMS sessions, JavaMail sessions, URL connections, and Java Connector Architecture, JCA) adapters. The resource manager is a component of the J2EE container that manages the entire lifecycle of a particular type of resource, including connection pools, transaction support, and any network protocol required to implement the actual connection.
Enterprise beans have access to a JMS session through three steps: Get a connection factory reference through JNDI, obtain a connection through the factory reference, and then use topics or queue connections in a conventional JMS. Because JMS must have support for the application server that follows J2EE specification, no additional libraries or components are required.
The advantages and disadvantages of JMS session beans combine JMS and session beans, which is a progress in corporate functionality, but in terms of simplicity and flexibility, it is another step. By using a session bean, the application developer can access the entire range of J2EE features provided by the EJB container, including JNDI, declarative transaction semantic, automatic concurrent support, resource management, declarative security, and for such as entity beans, data sources, JavaMail Access to enterprise resources such as JCA adapters. From the position of the message (not the MDB), the session bean and JMS do not have any number of restrictions on the topics and queues you can access by your bean.
As the cost of enhancing the characteristics of the company, you sacrifice the simplicity, the client footprint is no longer as small as before, and there is no asynchronousity. The first two losses have nothing weird. If you have already paid attention to the explore series, you can understand this. Session Bean requires a mature J2EE EJB container that allows your development group (for EJB development) and your entire system architecture (for client occupancy spaces). Asynchronous is one of the main advantages of enterprise messaging technology like JMS, and it doesn't lose this while it is. With JMS, the message delivery client can send a message through the provider, and the message can be offline after sending out, and allow the provider to transmit this message. The client that receives the message can be periodically online and check the new message, or can also set up a listener component to make it a message from the provider to wait for a message from the provider. The session bean is synchronized, so it cannot be supported "Always-on" listener components. Unlike the previous client, the synchronized Java client must call a session bean method. Then open the connection with a message delivery provider by the session bean method to send and receive messages.
The message driver Bean EJB 2.0 specification defines a new enterprise bean to make up for the shortcomings of other four types of enterprise beans (two session beans and two entity beans). This new bean is a message-driven bean (Message-Driven BEAN, MDB), and people expect to use it to provide reusable messaging components to take advantage of existing investments in J2EE application servers, especially existing EJB technology.
MDB can only be called asynchronously by one JMS message. Therefore, it does not have a local and remote interface with other Beans. Instead, MDB implements two special interfaces: an interface between the EJB container (Javax.ejb.MessageDriveNbean), and a messaging interface (javax.jms.MessageListener). As a mature JMS client, the MDB can send a message and can receive a message through an MOM server. As an enterprise bean, MDB is managed by the container and is configured by an EJB deployment descriptor.
The advantages and disadvantages of MDB, MDB allows developers to use existing investments in EJB technology, but can still be integrated into a context environment transmitted by asynchronous messaging. For example, the JMS client can send a message to an MDB (the MDB is always waiting for the message), and the latter can access a session bean or some entity beans. In this way, MDB can be used as an asynchronous package, providing access to business processes, and before these business processes can only be accessed through a synchronized RMI / IIOP.
Message Drive Bean itself is also a powerful message delivery solution. Since MDB is specifically designed to be used as a message, it is still managed by EJB containers, so they provide a huge advantage in scalability. Since the message bean is stateless and is managed by the container, they transmit and receive messages in concurrency (container simply put another bean from the pool). This, plus the scalability inherent in the EJB application server, constitutes an extremely robust, scalable enterprise message delivery solution.
On the other hand, MDB is still a very fresh thing, there is no much test. Thus, not all J2EE vendors support them, even those suppliers that support MDB are only recently achieved. It is foreseeable that MDB's immature means that the supplier has a long way to go in terms of stability and reliability. Moreover, MDB communities also need to experience more tempering to get a set of interested practices using MDB. Throwing the relative immatureness of MDB, it is important to understand it is designed for special purpose (ie consumers as JMS messages). MDB can only be called by JMS messages, and other methods are used. This means that they are ideal for consumers as messages, but they may not be suitable for producers as a message. The message driver bean can of course send a message, but the premise is that it first wants to call it in a request. Moreover, the currently designed MDB can only map to a single destination. They can only listen to the message on that destination. This limitation can be changed in the later version, but you can only define an MDB for each destination you want to listen.
Message Pass Solution Guidelines As mentioned, when choosing an appropriate solution, most of the work is to measure the specific needs of your business, including current needs and foreseeable future needs. If you can remember that a variety of enterprise messaging solutions can be used in conjunction, it will be helpful. In the next section, we will see some common messages to pass scenes and potential JMS solutions for each scene. These contents can provide a general guideline when you choose the appropriate message delivery technology for your business, or when multiple techniques are used.
Accessing multiple topics and queues from a component If your business process specifies that the message destination can only be accessible (in other words, if x <5, access the topic A, if x> 5, access topic B) Then you will not use MDB. However, you can use a simple JMS client or combine the session bean with JMS. In order to make a decision between these two options, you must be in the lightweight characteristics of the simple JMS client (especially suitable for the APPLET, SWING applications, and independent console applications) and the robustness of the J2EE container (including transparent Transactional support, declarative security, and other EJB-type resource management functions.
Asynchronous Access Session Bean and entity beans have two ways to handle this scene. A more obvious way is to use a message to drive bean, but the premise is your supplier supports MDB technology. MDB is designed to consume asynchronous messages and represent the message sender to access corporate functionality. In addition, the application server can maintain multiple instances of an MDB to process concurrent service requests. If you cannot use MDB, you can create a simple JMS client to use this as a listener. When a message can be received, the client can establish a synchronized RMI connection with the application server, and call session beans or entity beans in a conventional manner. However, MDB is a more recommended solution.
In this regard, the simple JMS client is obviously a winner. If more important to you is to provide a lightweight message delivery client, not the scalability and robustness of J2EE client like a session bean, then simple JMS is the correct choice. Whether it is a combination of session beans and JMS, or MDB, both require a J2EE application server, which makes two options that are not suitable for thin clients.
Concurrently sending and receiving messages here This only suitable option is to use a message to drive the bean. The message driver bean is specifically tailored to this scenario. Technically, simple JMS clients can also utilize multi-threaded technologies to provide similar support, but this solution is developed complicated, and the last development there is no good scalability.
Merging messages into the J2EE process You may have been invested in the J2EE architecture, and recognize the need to pass enterprise messaging into these J2EE procedures. In most cases, your best solution is to combine session beans with JMS resource connections. You can use existing session beans to access one or more topics and queues without having to rebuild the entire infrastructure. These session beans will continue to fulfill the discussion of traditional services to business services, and be responsible for the task of messaging. In some cases, it is advantageous to expose your business service to a JMS client, which can also be found in the previous discussion. Conclusion The diversity of technical prospects today and is increasingly, message transmission is an exciting, increasingly popular solution. Java Message Services provides a medium that is independent of the supplier and platform, and multiple systems are tied together by using enterprise messaging. In this article, we browse to enterprise messaging and JMS, and give some guidelines to make it easier for you to choose the solution that best suits your business.
Reference
Participate in the Forum on this article (you can also access the forum by clicking the discussion of the top or bottom of the article). Please refer to the complete J2EE explorer series written by Kyle Gabhar. To get a more professional introduction to J2EE messaging, you can refer to the tutorial "Java Message Service Basic Tutorial" written by Willy Farrell (developerWorks, August 2001). Nicholas Whitehead tells how to solve "independent of suppliers" JMS Solution "(developerWorks, February 2002). Creating a full vendor-neutral message delivery implementation (and gives a complete simple JMS client implementation). "JMS 1.1 simplifies the message delivery through unified domain" (developerWorks, August 2002)) Annap the updated API how to help you write more reusable JMS clients. Daniel Dransin discusses JMS messaging from another perspective in his article USING JMS Technology As A Data Replication Solution (DeveloperWorks, February 2002). From the JMS home page you can learn more about JMS. Brett McLaghlin's EJB Best Practice Series introduces some modes and usages related to business Javabean technology. The "Enterprise Javabean Basic" tutorial has made a comprehensive introduction to EJB technology. Kyle Brown's "Choosing The Right EJB TYPE: Some Design Criteria" (Aug 2002) has a comprehensive comparison of several types of EJBs. J2EEOLYMPUS.COM portal (especially related to EJB) is an excellent knowledge base for J2EE information. Please refer to the developerWorks Java Technical Tutorial page for free Java tutorials from DeveloperWorks. In the developerWorks Java technology area, hundreds of articles on Java programming are found.
