Web-oriented JMS Application System

--------------------------------------------------------------------------------

Author: Zhu Zhe

Author Profile


Zhu Yu, male, Nanjing, Jiangsu Province, Lecturer, main research direction: Information System and integration technology. You can contact the author via qizhu003@msn.com.

Content summary


Compared with desktop applications, JMS Web-oriented applications have special user requirements: the same message must be consumed by several unknown users, therefore, the message receiver must have a "receive but not confirm" Submission mechanism. This article uses the CWNF campus system as an example, this article discusses the principles and key technologies of message submission for Web-oriented JMS application systems.

Message transmission is a loose coupling method for Distributed communication between software components or applications, compared with various tightly coupled communication technologies (such as CORBA, Java RMI, COM/DCOM, the difference is: ① The message system is a peer-to-peer implementation. Both the sender and receiver of the message are clients in the system and do not have a C/S relationship with each other; ② The work of both parties is asynchronous; ③ Based on the consistent message format, both parties can achieve communication by only one intermediary to store and manage messages, the tightly coupled technology requires that you know the local interface of the remote method. Due to its own characteristics, message transmission technology is widely used in enterprises and enterprises.

Java Message Service (JMS) is a Java Message Service on the J2EE Enterprise platform. Currently, JMS of mainstream J2EE products implements the storage function. The JMS client is created through the jms api, communication between each other through Destination objects; however, JMS messaging systems are mostly used in desktop applications, while Web applications are rarely seen. This article uses the CWNF school affairs system developed by the author as a case study, this article discusses the implementation principles and key technologies of Web-oriented JMS application systems.

1. Implementation principle of Web-oriented JMS Application System
1.1 message transmission principle of the JMS Application System


The JMS application system consists of four parts: ① the JMS Provider is a logical data storage body that provides management tools and control features; ② the JMS client, is a component or application written in Java to send or receive messages. ③ a message is an object that carries information between JMS clients. ④ it is a managed object, it is the JMS object preset by the system administrator for the client, including the destination object and connection factory object. The destination object is the message intermediary between clients. These four parts are associated through JNDI: the Administrator binds the destination object and connection factory object to a jndi api namespace through the management tool, and the JMS client can find these objects in the namespace, and establish a logical connection with these objects through the JMS provider to implement communication between them (figure 1 ). JMS supports two types of message transmission domains: point-to-point, publish/subscribe, and corresponds to two types of Message destination objects: queue and topic.



1.2 message Submission mechanism for Web Applications


Generally, no message is allowed to be lost or duplicated in desktop applications, whether it is a message sender or receiver. the JMS message Submission mechanism is based on this requirement and they guarantee the implementation of this requirement from different aspects: ① control the message confirmation at the receiver. The confirmation ensures that a receiver only consumes one message once. In a non-transactional Session, the message confirmation method depends on the value of the second parameter of the create ××session method. In a transactional Session, message validation is automatically completed by the Bean container, regardless of the Bean management transaction or Bean container management transaction. ② Specify the message submission mode and lifetime for the sender. There are two submission modes: PERSISTENT (stable storage) and NON_PERSISTENT (non-stable storage). Stable storage ensures that messages will not be lost in case of faults; the life cycle determines the lifetime of a message in the storage intermediary. the JMS provider will automatically destroy the expired message. ③ Create a receiver for persistent grading. In the publish/subscribe system, a persistent subscriber can receive messages published by the message sender when the subscriber is disabled.

However, the Web application system has a unique Web user environment requirement in the message receiver: ① several users share a JMS client component, so the message should be submitted to a message receiver without confirmation, beans with the automatic confirmation function of containers cannot meet this requirement. If a session is set to transactional in a component, the container of this component does not have the transaction management capability, this component can be "received without confirmation". In the Web application system, only the Servlet component meets this requirement. ② The message receiver of the JMS client is often closed. To receive messages sent during the closing period, the message receiver must be a topic-based Permanent reviewer, therefore, the Web-oriented JMS application system must adopt the publishing/subscription message transmission domain.

2 CWNF School Affairs System Model


CWNF is a Web-oriented JMS school affairs system used for campus affairs such as publishing notices and soliciting opinions. There are two types of notifications: General notifications and soliciting opinions.

Users in the system are divided into three categories, with different users and different processing models. The basic situation is as follows: ① publish a user, have the permission to notify the topic, and publish a notification to the topic; ② sign the user and check the notification, you can also give feedback on suggestion-seeking notifications. ③ anonymous users can only view the notifications.

2.1 data and data stream model


There are two types of data in the system: Notification and feedback. The data received by the recipient will form an XML Document Object for display in the Web browser. Based on this requirement, the following two problems are investigated: ① data relations between parties in the system, ② form of data of all parties.

There are three main data relationships: ① The Data Relationship between the notification sender and the notification receiver, ② the Data Relationship between the notification sender and the Feedback Receiver, and ③ The Data Relationship between the notification receiver and the feedback receiver. (2) At the sender, data (notification or feedback) is sent in one piece. At the receiver, data (notification or feedback) is received in batches, is a set of data corresponding to the sender. Therefore, it is not necessary for the sender to directly process the data into XML document objects, as long as an element object can be generated to form an XML document object; the Data Relationship between the notification recipient and the feedback recipient is that each solicitation notification has a feedback set.



The data flow model of the system is as follows:
① Notification Sender: form data → XML Element (notification) → topic (storage)
② Notification recipient: subject (storage) → XML Element (notification) → XML document (notification) → XSL display (including forms)
③ Notify the recipient to the Feedback Receiver: XSL display (including forms) → topic (storage)
④ Feedback recipient: subject (storage) → XML Element (feedback) → XML document (feedback) → XSL display (including forms)
⑤ Feedback Sender: form data → XML Element (feedback) → topic (storage)

2.2 Component Model


System Component Model 3: The topic CWNFTopic is a message transmission intermediary. The NoticerServlet component sends a form to the publishing user, receives data from the form, and then generates an XML Element Object, this element object and other data are used as parameters to call the PublisherBean component method and send messages with this element object as the message body to the topic; the ReaderServlet component processes the business of viewing notifications by a signed user and an anonymous user. After obtaining information about the notification that the user will view from the form, then, the receive method is used to receive messages from the topic in a limited time and filter the messages. Then, the filtered message bodies are taken out, it is then processed into an XML Document Object (the root element is the notification set) and finally output. FeedbackerPubServlet is used to feedback the sender's business processing. Its functions are similar to those of NoticerServlet. FeedbackerSubServlet is used to feedback the business processing of the receiver. Its functions are similar to those of ReaderServlet. The PublisherBean component is called by the NoticerServlet and, container Management sends transactions with high reliability.



3 key implementation technologies
3.1 create and output XML documents using JDOM


JDOM is an open-source pure Java-tree API for analyzing, establishing, processing, and serializing XML documents. In the data stream model, both XML elements and XML documents are created by JDOM APIs. At the sender, several name/value pairs are obtained through the forms submitted by the user, the data is processed by the JDOM method to generate an XML Element Object. The Element Object is sent to the topic for storage as the message body. After the receiver and persistent subscriber receive several XML Element objects, create an XML Document Object using the JDOM method. The XML file output to the Web browser also depends on the XMLOutputte object method of JDOM:

XMLOutputter serializer = new XMLOutputter ();
...
PrintWriter out = response. getWriter (); // out is the output stream object of ServletResponse.
Serializer. output (xmldoc, out); // output the XML document to the page through out

 


3.2 XSL defines the XML document display style


XSL is a scalable style single language. XML documents in the notification set and XML documents in the feedback set have relevant XSL documents that determine their page display, for example, the XSL style of the notification set XML document is defined as follows:

<? Xml version = "1.0" encoding = "GBK"?>
<Xsl: stylesheet>
<Xsl: template match = "/">

<HTML>
<BODY>
...
<DIV> <xsl: apply-templates select = ""/> </DIV>
</BODY>
</HTML>

</Xsl: template>
<Xsl: template match = "Notification set">
<Xsl: for-each select = "notice">
...
</Xsl: for-each>
</Xsl: template>
</Xsl: stylesheet>

 


3.3 data transmission between servlets
3.3.1 registration/login


Some user operations can only be performed after registration/login. Therefore, the approved registration/login information must be transferred between Servlet components. The ServletContext object can set and read attributes so that different servlets can communicate with each other and is used in the system for user identity verification by related components.

3.3.2 Association of notification and feedback data


Each comments notification has an associated feedback set, which can be achieved by setting message attributes. All JMS messages (including notification messages) have the system-level JMSMessageID attribute. The value of this attribute is unique and can be used to represent each comments notification, therefore, you can set an application-level Attribute (FeedbackSN in CWNF) for any feedback message to obtain the JMSMessageID attribute value associated with the suggestion notification. In this way, data association between the two is established.

Therefore, the data flow model "③ notifies the receiver to the Feedback Receiver: XSL display (including forms) → topic (storage)" is implemented as follows: After you select a suggestion notification on the page, the JMSMessageID attribute value of the notification will be passed to the FeedbackerSubServlet component, which will use this attribute value to match the FeedbackSN attribute of the feedback message retrieved from the topic to filter out the associated feedback messages.

How can the JMSMessageID attribute value of a request notification be passed to the FeedbackerSubServlet component? Using ServletContex