Professional Java.JDK.5.Edition (Wrox)

Chapter 12

4.Deploy your application-specific MBeans. Point a Web browser at http://localhost:8082. This brings up the agent view of the htmlAdaptor that was just registered with the MBean server in the Agent class (see Figure 12-12).

List of registered MBeans by domain:

Adaptor

name=html.port=8082

JMImplementation

type=MBeanServerDelegate

processing

name=order-processor-01

Figure 12-12

As you can see from Figure 12-12, the html adaptor shows two MBeans registered with the MBeanServer. The htmlAdaptor is getting this information from the MBean Server’s query capability.

5.Let’s add the message processing MBean to the MBeanServer. The first step is to select the admin button in the top-right corner of the agent view as pictured in Figure 12-12. This will bring up the Agent Administration screen pictured in Figure 12-13.

List of MBeans attributes:

Figure 12-13

6.Specify the domain field; this can be anything you would like. The one used here is processing. Then enter a unique key in the format key=value1,key=value..n. Then specify the fully qualified name of the messageProcessor class and select send request. Once that is done, you should see the Create Successful message below the registration form. Now, select Back to Agent View in the upper-right corner and you should see what’s shown in Figure 12-14. The MBeans register should include the name=order-processor-01 in domain processing.

576

Distributed Processing with JMS and JMX

OrderRouter

Figure 12-14

The htmlAdaptor took the values posted by the form submission and used them to register processor MBean with the MBean Server. That is how to create an MBean using the HtmlAdaptor, but you can do the same programmatically as shown here:

MessageProcessor processor= new MessageProcessor();

processorName= new ObjectName(“processing:name=order-processor-01”); server.registerMBean(processor, processorName);

7.Go back to the agent page and select the name=order-processing-01 link. This will bring up the MBean view for the order processing MBean. This page renders as HTML the attributes and methods specified in the MessageProcessorMBean interface.

8.In the attributes section, specify the names of the source and destination queues as well as the name of the class implementing the processing interface. Once this is done, select Apply (see Figure 12-15).

OrderSplitter

Figure 12-15

577

Chapter 12

This is the equivalent of executing the following operations against the MBeanServer:

processorName= new ObjectName(“wrox.processing:name=order-processor”); server.setAttribute(processorName, new Attribute(“Source”, “source-queue”)); server.setAttribute(processorName, new Attribute(“Destination”, “destination-

queue”));

server.setAttribute(processorName, new Attribute(“Processor”, “wrox.processing.order.OrderProcessor”));

9.Configure and start each message component.

10.Finally, go back to the MBean view of the MessageProcessor and invoke the start message. You should see the Start Successful message at the start of the screen. This will invoke the start method of the message processor MBean.

Start to finish, that is how to create and deploy a message processing component. The next section will show how to use some of the advanced deployment options available through JMX to deploy MBeans dynamically from a configuration file.

Advanced Deployment

So far, the example has shown how to deploy MBeans directly to the MBean Server as well as indirectly using an htmlAdaptor MBean. This provides a great deal of flexibility to deploy and configure MBeans at run time. This section will demonstration how to deploy MBeans automatically using the M-Let Service.

M-Let is an abbreviation for managed applet. It is an agent service that works with the MBean server to allow remote deployment of MBeans. The logical view of how this works is pictured in Figure 12-16.

There are two benefits to using the M-Let service:

The M-Let service supports Remote deployment. In a distributed processing architecture; one server can prove the MBean configuration for all the other servers in the processing architecture. At startup, all the severs would look to the M-Let server for their configuration settings.

578

Distributed Processing with JMS and JMX

The agent does not need to be restarted to add classes to the JVM classpath providing true hot deployment. This allows a production environment to maintain continuity of operations, which in turn prevents service interruptions and downtime for maintenance and software upgrades.

There are three steps to using the M-Let service: Deploy the M-Let service to the JMX Agent, configure the M-Let deployment descriptor, and add the descriptor URL to the M-Let service.

Deploy the M-Let Service

Working with the same Agent class for creating the earlier examples, all that needs to be done is to deploy the M-Let services as a standard MBean:

package wrox.processing.jmx;

import javax.management.loading.MLet; public class Agent {

public static void main(String[] args) {

MBeanServer server= MBeanServerFactory.createMBeanServer(); try {

// htmlAdaptor omitted for brevity

MLet mlet= new MLet();

mletName= new ObjectName(“Services:type=MLet”); server.registerMBean(mlet, mletName);

}

Once this is complete, it is possible to configure and manage this MBean via the HTML adaptor just like the other MBeans in this chapter. Point a Web browser at http://localhost:8082/ to inspect the method and properties exposed by the M-Let service.

Configure the Deployment Descriptor

The M-Let deployment descriptor is a text file that contains the definitions of MBeans to be deployed as well as the required supporting Java classes needed to run the application. An M-Let deployment description is shown following this paragraph. The file is called wrox.mlet and it is located in a Web server directory so it can be viewed by selecting http://localhost/mbeans/wrox.mlet. Only the CODE, NAME, and ARCHIVE parameters are required:

<MLET

The code attribute is the fully qualified class name of the MBean:

CODE=”wrox.processing.jmx.MessageProcessor”

The name attribute is equivalent to the string in the ObjectName constructor uniquely identifying the MBean:

NAME = MLetDeployed:name=processor-03

579

Chapter 12

The archive attribute specifies the jar file that contains the class name from the code attribute as well as any other support classes needed to run the application. The archive attribute can also be a commaseparated list of jar files:

ARCHIVE=”wrox.jar”

The code base attribute is a file path to the jar file. In this example, absolute path is used, but the path can also be relative to the directory where the JVM was started:

CODEBASE=”file:c:\mlet”>

It is also possible to specify constructor parameters for nonzero parameter constructors. You can only specify primitive types using this method:

<arglist>

<arg type=”java.lang.String value=”source-queue /> <arg type=”java.lang.String value=”destination-queue /> </arglist>

</MLET>

The M-Let file can have several <MLET> tag declarations. In most cases, it is recommended that you use one M-Let config file for each type of server being deployed.

The M-Let descriptor file is part of the standard JMX specification. But there are a few complaints about some of its limitations.

The first is, “Why is it not an XML file?” The descriptor is in an XML-like text file, but it is not XML. This makes it a bit harder to validate and parse.

The second is that there is no built-in way of supporting deployment dependencies. If MBean A needs to deploy before MBean B, there is no way of expressing that in the M-Let descriptor file.

Some JMX vendors have provided extensions to the M-Let service in order to make up for these limitations. One of the JMX implementations available under open source license, JBoss, has a nonstandard approach to address both of these limitations.

The JBoss Group (www.jboss.org) has a custom MBean descriptor file. The Jboss JMX Agent assumes that all files using the <serviceName>-service.xml naming convention contain Mbeans. Each Mbean description can have a <depends> tag.

This tells the server to make sure the MBean described in the depends tag is deployed prior to this one.

JBoss also recognizes custom MBean lifecycle methods, calling create() and then start() on each MBean as the server loads, followed by stop() and destroy() as the server is shut down.

580

Distributed Processing with JMS and JMX

Add the M-Let Configuration File to the M-Let Service

The M-Let file describes the MBeans that need to be deployed. All that is left to do is to point the M-Let service to the M-Let descriptor file. This can be done through the HttpAdaptor by adding the URL http://localhost/mbeans/wrox.mlet, to the M-Let service. The easiest way to do this is through the htmlAdaptor. This is pictured in Figure 12-17.

The steps to load the M-Let descriptor file are as follows:

1.Load the httpAdaptor by pointing the Web browser to http://localhost:8082.

2.Select the Services:type=MLet from the list of MBeans.

3.Enter in the URL of the M-Let descriptor file.

Web Server

Agent Server 1 /mbeans mlet

processing.mlet

processing.jar

Agent Server 2

mlet

Agent Server ..n

mlet

Figure 12-17

Click the Submit button. Once you see the Success message, return to the Agent view and the MBeans described by the wrox.mlet file will be visible and the jar file containing the depend classes deployed remotely through the Web browser. MBeans deployed through the M-Let service can be managed as any other MBean.

Summar y

In this chapter, you have learned about building scalable and manageable distributed processing systems through JMS and JMX. The first section illustrated using some of the concepts of asynchronous message systems to scale processing ability. Following that, you built a series of basic messaging components. These components handled the message responsibility of processing, routing, and splitting and aggregating. Then, the example showed how to link theses basic components to implement a business process. The final section discussed how to deploy and manage these components remotely in a distributed computing environment.

There are other JMS design patterns to handle integration scenarios, and third-party tools built on top of JMS for workflow management problems. JMX has applications in managing network devices and includes methods and classes for event notification and component relationships not covered in this chapter.

581

Chapter 13

JCA Design and Architecture

The Java Cryptography Architecture (JCA) forms the core of the security API. It was designed with two important principles in mind. First, the JCA is implementation-independent and interoperable. Implementation independence is achieved through the use of cryptographic service providers (or, more simply, providers). A provider implements a cryptographic service such as generating random numbers or creating digital signatures. Interoperability ensures that different providers will still work with each other. For example, different providers implementing routines using the same algorithm should work such that a message encrypted by one provider can be decrypted by another provider. The second principle is that of algorithm independence and extensibility. Algorithm independence is achieved through the specification of engine classes that provide a specific cryptographic service, such as a key generator or a message digest service. Algorithm extensibility ensures that these engine classes can be updated with new algorithms easily.

The JDK comes with a default implementation of the cryptographic service providers. This provider package is named SUN and has the providers listed below:

Implementation of DSA (Digital Signature Algorithm)

Implementation of MD5 and SHA-1 message digest algorithms

Key pair generator to generate public and private key pairs for the DSA algorithm

DSA algorithm parameter generator

DSA algorithm parameter manager

DSA key factory that supports converting public keys to and from private keys

SHA1PRNG pseudo-random number generator

X.509 Certificate path builder and validator for PKIX

A certificate store using the PKIX LDAP V2 Schema

Certificate factory for X.509 certificates and Certificate Revocation Lists (CRLs)

A keystore

All of these providers will be discussed in more detail in this chapter. All examples in this chapter will use the default implementation of providers in the SUN package. Consult the third-party documentation if you are using another provider package.

Engine Classes

An engine class provides the interface to a specific cryptographic service. This interface dictates how programmers use a particular service. There can be a number of different implementations for a particular engine class, such as Signature implementations that use SHA-1 or MD5 algorithms. Each engine class has a corresponding Service Provider Interface (SPI), which is an abstract class that is encapsulated by the engine class. The SPI class must be subclassed in order to create a concrete implementation. Each engine class also has a factory class that is used to create a specific instance of the engine class (and its enclosed SPI class) using the getInstance factory method.

The Java SDK defines 12 engine classes. Three of which (the certificate path classes and the certificate store) were introduced in the 1.4 version of the Java 2 SDK. These engine classes and their descriptions are shown in the following table.

584

The naming convention of SPI classes is the text Spi appended to the engine class name. For example, the SPI for the SecureRandom engine class is SecureRandomSpi. Each engine class has a getInstance method that is used to request a particular algorithm and also a particular provider if needed.

Installing a different provider package is done by either placing the JAR file in your classpath or deploying the JAR file as an extension in your JRE. The provider must then be placed in the list of approved providers in the java.security file. This file is found in the lib/security directory of your JDK or JRE installation. The property in this file takes the following form:

security.provider.n=masterClassName

The n is replaced with a number, such as 1 or 2. Using numbers provides a way to rank providers, and this list of providers is searched top down when no specific provider is specified in a call to one of the engine classes’ getInstance methods. The masterClassName is replaced with the fully qualified class name of the master class for the provider package. This file contains the following lines for specifying providers in the JRE that comes with the current Java 5.0 SDK:

security.provider.1=sun.security.provider.Sun

security.provider.2=sun.security.rsa.SunRsaSign

security.provider.3=com.sun.net.ssl.internal.ssl.Provider

security.provider.4=com.sun.crypto.provider.SunJCE

security.provider.5=sun.security.jgss.SunProvider

security.provider.6=com.sun.security.sasl.Provider

Next, let’s take a closer look at using each of the engine classes. Examples utilize the default implementations provided by the SUN package.

585