Chapter 3. JSR 160 (JMX Remoting) Explained

Table of Contents

What is JSR 160 ?
MX4J's JSR 160 implementation
How to use JSR 160
Creating a JMXConnectorServer
Creating a JMXConnector
Remote Notifications
JSR 160 Security
Requiring user authentication to connect to a JMXConnectorServer
Running under SecurityManager and Subject Delegation
Advanced JSR 160
Intercepting calls between the JSR 160 JMXConnectorServer and the MBeanServer
Standard JSR 160 JMXConnectors and JMXConnectorServers
Overview of RMIConnector and RMIConnectorServer
Connecting to the RMIConnectorServer
ORB properties for JMXConnector and JMXConnectorServer over IIOP
RMI socket factories (over SSL) for the RMIConnectorServer over JRMP
MX4J's JSR 160 JMXConnectors and JMXConnectorServers
The SOAP JSR 160 connector
The HESSIAN and BURLAP JSR 160 connectors
Using HTTP-based connectors over HTTPS
Configuration of the web container
Configuration of the keystore
Code examples
Porting old MX4J remoting code to JSR 160
Porting Examples
MX4J Remote Tools and Utilities
Remote MBean Proxying

What is JSR 160 ?


The Java Management Extension (JMX) API is defined and under maintenance release of the Java Specification Request (JSR) number 3.
JMX defines the API for management of Java applications, and those API are local to the application: remote clients that would like to connect to a JMX-enabled remote application and manage or monitor it using JMX could not do it in a standard way.
The MX4J project, the JMX reference implementation itself, and other JMX implementations provide custom connectors, mostly RMI-based and HTTP-based, but those are not interoperable.

To fill this gap, JSR 160 extends JSR 3 by providing a standard API to connect to remote JMX-enabled applications.
Currently, JSR 160 has defined a mandatory connector based on RMI (that supports both RMI/JRMP and RMI/IIOP), and an optional one based on sockets and Java serialization (JMXMP).

JSR 160 thus provides a standard way to connect to remote JMX-enabled applications using RMI; it is possible to use MX4J JSR 160 implementation on client side, and have a JMX Remote Reference Implementation on server side, or viceversa. This allows the creation of Management Consoles based on Swing, for example, that will be able to interoperate no matter which JMX implementation is used.

MX4J's JSR 160 implementation

MX4J implements JSR 160. This means that MX4J ships the standard JSR 160 API, located in package, and the mandatory providers defined by the specification, namely the rmi and iiop providers, located in package
MX4J does not implement yet the optional jmxmp provider defined by the JSR 160 specification.
MX4J provides other four providers, not specified by the JSR 160 specification. This means that they will work only if MX4J runs at both client and server side. These four providers are the soap, local, hessian and burlap providers.

To sum up, MX4J allows you to specify JMXServiceURLs (see next section) of the following kind:

  • service:jmx:rmi://host
  • service:jmx:iiop://host
  • service:jmx:soap://host
  • service:jmx:local://host
  • service:jmx:hessian://host
  • service:jmx:burlap://host