Ajax
Article TipsAjax and JMX are located on the two opposite sides of the system management stack, respectively. However, Ajax models are now ubiquitous in Rich browser clients. This makes the model become blurred in the architecture domain to enhance the support pattern in the problem parsing pipeline.
This article describes in detail the advantages of an AJAX architecture-it can "broadcast" administrative status to a user base that can use the browser without waiting for the page to be updated.
This architecture is an extension of a common model-can be used to record JMX events and attributes into a server-side log file, and this change further records or "broadcasts" of management information to (AJAX-enabled) user bases.
In this article, we will specifically analyze the AJAX request/response model and the process of drawing management data to the page, as well as the beautiful JMX notification framework-all of which are clearly integrated together through an assembled servlet.
Next, we'll look at the content-security and capacity models that are typically not in standard AJAX discussions.
In this article, we use the BEA WebLogic 8.1 as the release platform for these software, although the architecture and methodology are also applicable to other Java EE application servers.
I. Key needs
The system management stack for enterprise Java and EE applications forms part of the problem-resolution pipeline-where the JAVA/J2EE application interacts with a management to monitor potential problems, such as application server thread starvation, heap overflow, or stale connections to a database.
Management typically includes a JMX mbeans-which application to assemble and use, and other products such as wily Introscope and HP openview-that read these JMX properties can be warned from wily if they exceed a previously configured threshold.
There is a problem with this model-if the system is having problems in the background, the server-side mode for JMX management will not be able to help the browser-side customers because the model is all server-centric. For example, if a new Java EE Web application is to be published or the application is to be closed in minutes-because wily detects a problem, the user in the browser does not know that such an urgent management event has occurred!
By fully allowing users to enter the problem resolution pipeline, a system administrator can manage the end-user experience by broadcasting management information to the user base and, to some extent, controlling the user's behavior.
In order to deliver management information to customers through the HTTP protocol, there is a question of how management can send management information to an HTTP customer if the client user is not openly using GET or post update pages but secretly updating a hidden framework.
Ii. Description of the programme
To implement a simple Ajax script, this article will obtain management information in the form of XML messages from the Mbean server and resolve the problem through a servlet. These management information must be managed and fed back to all participating application servers that can receive AJAX requests.
On the server side:
• A Java EE application server cluster is used to service requests from browser-based users and online transaction processing (OLTP) user bases, such as two or four servers. By using a Third-party Web server, user requests are balanced mounted across the cluster (OLTP cluster).
• A standard Mbean (Userweb) is used to store management information, such as administrative messages with metadata attributes. The Mbean is hosted on the Java EE "admin" server and on the Java server on the OLTP cluster.
• On the Management Server, the system administrator uses the Htmladaptor for JMX to set the warning state, the retry interval (the interval between adjacent xmlhttp-requests), and the warning message-for example, "System down in Minutes.". The administrator then broadcasts the status to the mbeans-on the Management server to reset their state to master management State by the Management Server.
On the client:
• AJAX-enabled clients retrieve states, retry intervals, and messages using a XMLHttpRequest (which calls a servlet to return related Mbean values in the form of an XML message).
• Then the client JavaScript analyzes the XML message, resets the retry interval, and uses the admin message to redraw part of the screen.
• After retry-interval seconds, the customer makes another xmlhttprequest and the customer cycle begins again.
III. Basic Structure
Figure 1 shows a comprehensive solution architecture, where table 1 describes the corresponding basic architectural elements.
Figure 1 Scenario Architecture |
Elements |
Describe |
Standard Mbean (Userweb) |
Properties for warning states and messages, and Getter/setters and a method to broadcast (notify) Mbean status |
Mbean Assistant (Userwebmbeanhelper) |
Packaging the assembled code to facilitate the use of the Userweb MBean |
Mbean Server |
Mbean server in Java-EE container |
Servlet (Admin.java) |
Assembled servlet, formatted XML response based on Userwebmbean content |
Event Listener (Managementlistener.java) |
singleton-it registers itself as a listener for a "alert.broadcast" type of event with the Userweb Mbean on the Management Server |
Client Ajax engine (admin.js) |
JavaScript for managing the Xmlhttprequest-/-repaint cycle |
Client Description (main.jsp) |
The assembled JSP. Ajax launches the page based on the Mbean property |
HTML adapter wrapper (Starthtmladaptor.java) |
Start a htmladaptorserver on listening port +100 to enable HTTP access to Mbeans |
Table 1 Schema elements
(i) JMX notification model
This model contains two components:
· mbean-Activate events for local and remotely registered listeners
• Listener-it registers itself with an mbean to hear events generated by the Mbean
The first one is implemented by the Userweb Mbean, and the second is implemented by Managementlistener.
(ii) JMX MBean for managing user information
The Userweb standard Mbean is a simple class-it contains key properties and methods (table 2).
Elements |
Describe |
Alertenabled |
If alertstatus>-1, True |
Alertmessage |
Information that the user will see on the screen |
Alertready |
If alertstatus>0, True |
CallBack |
The number of milliseconds between each two XMLHttpRequest |
Broadcaststate |
Method-it notifies all registered listeners on the local/remote JVM with an event (Alert.broadcast) (it passes the Mbean status as event data) |
Table 2 Userweb Mbeam Properties and methods
(iii) Event listeners
Singleton The Managementlistener class implements weblogic.management.remotenotificationlistener-it expands Javax.management.NotificationListener and JAVA.RMI.R Emote to allow events on a remote WebLogic JVM to be notified to the remote listener by using RMI technology.
At Application server startup, a listener on each JVM registers itself with the Userweb Mbean on the Management server.
(iv) Mbean assistants
It's a good idea to use an assistant class to package Mbeans. In this way, we can invoke this assistant from the assembled code to invoke the Mbean method.
The Userwebmbeanhelper class is used as a wrapper for the Userweb Mbean. The ancestors of all assistants were applicationmbeanhelper, and it was responsible for:
• Find local and remote Mbean servers
• Call these servers to get/set Mbean properties and invoke the Mbean method
To ensure a match, both Mbean and Mbean assistants implement Interface Userwebmbean.
(v) assembling a servlet
An application can be assembled to use JMX. In AOP terms, the management aspect is woven into the application code. The first JMX assembly point in this article is a httpservlet. This servlet is the target of the AJAX request, and it implements a controller pattern-it can be crafted to handle other AJAX requests with simple request parameters.
From an MVC perspective, the model is a userweb Mbean, and the view is an AJAX-enabled (JSP) page, and the controller is an assembled servlet.
(vi) Client AJAX engine
This is a set of JavaScript functions that:
• Manage XMLHttpRequest and respond to repetitive actions
• Analysis of XML messages returned by XMLHttpRequest
• Repaint the screen with XML message content
Customer description
This is the main.jsp page-it contains the client Ajax engine and the part that can be repaint.
(vii) Sequence
Essentially, the server-side sequence participates in managing the settings of administrative properties and broadcasts these properties to all interested (listening) JVMs. The client sequences, however, participate in retrieving these properties and redraw the HTML page with important management information at the specified interval of time.
(eight) JMX notification (server sequence)
· Userweb Mbeans and Mbean event listeners are created and registered with the appropriate startup class when the application server is started
• The administrator sets the "master" Userweb Mbean attribute (warning message and retry interval), and then broadcasts or notifies the host on the remote Management server of this state
• Remote listener processing notification-by copying master (notification) data to a local userweb Mbean implementation
(ix) XMLHttpRequest query (customer sequence)
• AJAX-enabled clients call a servlet at intervals to query for administrative status
• The servlet reads the local Userweb Mbean properties, inserts them into an XML message, and returns the XML message as an XML response to the browser client (later discusses the alternative message format)
• Then, the AJAX customer analyzes the XML document, extracts messages such as warning and retry intervals, repaint the screen, and then uses this retry interval to set the next XMLHttpRequest delay.
Each of these steps is described in detail below.
[1] [2] [3] Next page