We are keeping talking about manageability of an application. Why is it so important? Because at any stage of the application lifecycle, you need a way to probe the some key aspects of the application's internal status and take appropriate actions to change the application's behaviors as a consequence. Without it, you just guess the application's runtime status and never able to steer it per your needs.
But hold on, it's easy to talk about manageability. And it's really a great idea in the air until you want put it in a concrete base in your application. It's so cumbersome, tedious and error prone to make an implementation. There are couples of option you could choose to inject the manageability in your application:
- Your own proprietary mechanism.
- Standard SNMP
- JMX
Forget about option 1, smart as you, don't want invent any wheel. Well, SNMP (Simple Network Management Protocol) sounds good: standardized, bunch of tools and applications and really structured, until you dig in the details of all the ugly OID (Obejct Identification) definitions, binary format, pure data driven approach. And difficulties of debugging. Plus extra cost for those usable commercial SNMP tools and editors.
Fortunately, we are in campus of Java, which is so far the only language and platform that put the serious crucial enterprise aspects intrinsically in the body, especially manageability in an offer as JMX. For the people working for .Net, either they just don't know what is the manageability, or struggling with various proprietary approaches or annoying SNMP stuffs.
Best of the best in Java application manageability is that we have the generous platform MBean Server as a gift from SUN in new version of JVM, which save your efforts looking for a MBean server; we have the JConsole as tool to directly craft your JMX management GUI frontend; and the offer from Spring's JMX supports. Combine them together, you can make any Java application JMX enabled in minutes.
Here is a simple example called MockServer. It's just a simple socket server for any mock testing purpose. With JMX, you can get the information and stop it in runtime.
Following is the partial code snippets, which is definitely the beautiful POJO. No any special MBean or MXBean stuffs in it, see!
/** private ServerSocket listeningSocket = null; public MockServer(String name, boolean isSSL, int port, int sotimeout){ public String getName(){ public int getPort(){ public boolean isSSL(){ public int getSotimeout(){ public boolean isStopped(){ public void stop(){ protected void createListeningSocket() throws IOException { public void run(){ protected void fork(Socket worker){ public long getConnCounts(){ protected class Worker implements Runnable { protected Worker(Socket socket){ public void run() { //Write back the response to socket output stream. //Subclasses to override it. return buf;//echo it. } |
/** public void setServers(Set<MockServer> servers){ protected void init(){ public Set<MockServer> getServers(){ public void stop(){ |
Then we need an application entry point and integrate with Spring. |
public class MockServer { |
the context file for Sring defining the beans. |
<?xml version="1.0" encoding="UTF-8"?> <bean id="mockServerService" class="MockServerService"> |
Until now, nothing to do with JMX. You can run it as a normal Spring application. You can use JConsole to connect with it locally, if you run the application in this command line:
java -cp . -D-Dcom.sun.management.jmxremote MockServer
This is the snapshot of JConsole MBeans tab. Besides the default threads, memory etc. JVM MXBeans, you can't do anything else to this application.
Now, let's just simply tweak the context file, then see what happens. Add this extra block just at the end of the context file.
...
<bean id="mockServerService" class="MockServerService">
<property name="servers">
<set>
<ref local="mockProcessor0"/>
<ref local="mockProcessor1"/>
<ref local="mockProcessor2"/>
</set>
</property>
</bean>
<bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
<property name="beans">
<map>
<entry key="bean:name=MockProcessor0" value-ref="mockProcessor0"/>
<entry key="bean:name=MockProcessor1" value-ref="mockProcessor1"/>
<entry key="bean:name=MockProcessor2" value-ref="mockProcessor2"/>
<entry key="bean:name=MockServerService" value-ref="mockServerService"/>
</map>
</property>
</bean>
...
Here it is! The new JConsole MBeans tab populated with your beans. Now you can see the name of each bean and stop it just by invoking the corresponding stop() method of that bean. Done! You can manage your Spring application now!
In a nutshell, following this pattern, you can tweak any of your applications to be manageable in minutes:
- Define the management interfaces for your Object.
- Spring your application and expose the object as MBean you want control. Nevertheless, Spring is a extremely noninvasive container, don't be afraid. The things need you Springlize is just make a context file for beans, add less than 5 lines of code to create the application context and put the spring.jar in your classpath. Everything is so familiar to you in a POJO world.
- Enable the JVM JMX platform MBean server in command line with -Dcom.sun.management.jmxremote and run it.
- Launch the JConsole and connect to the application then control it in your hands.
1 comment:
Great Blog!!! lot of intreseting stuff
You can also have a look on my blog at:
http://j2ee-now.blogspot.com/
Post a Comment