GlassFish Server Open Source Edition 3.1 - AMX One Pager

1. Introduction

1.1. Project/Component Working Name:

AMX ( Application server Management eXtensions )

1.2. Name(s) and e-mail address of Document Author(s)/Supplier:

Prasad Subramanian : prasad.subramanian@sun.com

1.3. Date of This Document:

05/24/2010

2. Project Summary

2.1. Project Description:

This component deals with JMX support for managing and monitoring modules, services and applications in the GlassFish Application Server. This component also includes the support JSR 77.

See below for a longer, more detailed technical description.

2.2. Risks and Assumptions:

Clustering infrastructure is new and hence the AMX support for clustering is dependent on the stability of the infrastructure.

3. Problem Summary

3.1. Problem Area:

JMX provides an interface to manage and monitor components within an application server using third party ( remote ) clients. It provides the ability to create custom management tools for customers. JSR 77 standardizes the manageable objects in a Java EE compliant Application Server. AMX is a GlassFish specific API which provides a simpler JMX based interface to manage and monitor the Application Server specific components.

3.2. Justification:

We need to provide customers who wish to use JMX to manage and monitor the Application Server , a standard supported mechanism of doing so, the basis of which they could design their remote management clients.

4. Technical Description:

4.1. Details:

AMX support is carried on from GlassFish v3.0 and the additional work to be done for this release is as follows :

1. Support for AMX in the clustered setup
2. Extending support for JSR77 in a clustered setup
3. Reduction of the number of JARs for AMX
4. SSL support for JMX connectors.

AMX underwent considerable change in GlassFishv3 , with the use of AMX SPI to make it extensible and provide modules being added , the ability to add AMX Mbeans of their own. The same SPI shall be used to extend the AMX support.

4.1.1. Support for AMX in a cluster

AMX support in a cluster can be broadly defined into two parts

4.1.1.1. Management

Config Beans

An application server instance is managed by the AMX interfaces that map to Config Beans. There are additional config beans that would be introduced to support a cluster profile. These additional config beans added / enhanced would need to have corresponding AMX interfaces.  There are AMX interfaces for the cluster, cluster-ref, GMS elements. The plan is to track the changes to the config beans and update the AMX interfaces.

Reading and Setting config values

AMX can be used to read the values from the configuration ( domain.xml)  or to set a particular value to a config. In a cluster setup ,the user would connect to the DAS or a specific remote instance to read the values. In case of a value being set, the user would have to set the value in the Domain Administration Server ( DAS) and then effect a cluster restart to propogate the set value to all the instances in the cluster, via the synchronization that takes place during a cluster restart.

4.1.1.2 Monitoring

The user would have to connect to the individual instances's JMX port to read the monitoring data ( which would at a per instance level). There is no plan to provide a collated monitoring data at the cluster level via AMX. The monitoring dev tests / QE tests would have to be run at an instance level to check if there is any anomaly.

4.1.2 Extending support for JSR77 in a cluster

As per the JSR 77 specification there are no special requirements that would need to be met for a clustered setup. Hence its expected that the JSR 77 implementation in a single instance should work in remote instances. Broadly this can be classified into

• Creation of JSR77 MBeans for Server J2EEApplication and J2EEModule in remote instances. This would be done lazily as is done in a single instance
• Ability to manipulate applications ( enable/disable) on a remote instance. This would have be done by connecting to a remote instance directly using a JMX client.
• Ability to collect Statistics from remote instances by connecting to these instances directly.

Open Issue : How do we manipulateJ2EEResource objects in a cluster ? Do we manage them per instance or from the DAS and then use synchronization to propagate the changes ?

• MEJB  The MEJB would have to be loaded in each instance of the cluster and then accessed directly.

4.1.3. Reduction of the number of Jar files for AMX

Currently there are multiple jar files that the AMX interfaces and classes are delivered in. However a point to be considered here is that all these are downloaded and loaded into the VM at runtime at the same time. In effect we are not achieving any additional modularity by keeping these classes files in separate jars. Hence an attempt will be made to merge the following 7 jars into a single jar

1. amx-core.jar
2. amx-core-impl.jar
3. amx-config.jar
4. amx-config-impl.jar
5. amx-j2ee.jar
6. amx-j2ee-impl.jar
7. amx-ext-impl.jar

4.1.4. SSL support for JMX connectors

With the introduction of cluster support for GlassFish, we need to provide a secure mechanism for remote JMX clients to connect to instances. Hence JMX connectors would need to support TLS/SSL. This support would be provided for both RMI-JRMP and JMXMP protocols.

Note : SSL support is planned only for connectors acting as Server.

4.2. Bug/RFE Number(s):

All P1, P2 and P3 issues.

4.3. In Scope:

Same as in section 4.1

4.4. Out of Scope:

• Addition of new AMX support in a single instance setup.

4.5. Interfaces:

Interfaces may be commands, files, directory structure, ports,
DTD/Schema, tools, APIs, CLIs, etc.
Note: In lieu of listing the interfaces in the one pager, providing
a link to another specification which defines the interfaces
is acceptable.

4.5.1 Public Interfaces

List new, public interfaces this project exports.

There are no new interfaces that this project plans to export. The same interfaces exported by the AMX in GlassFish v3 will be supported.

4.5.2 Private Interfaces

List private interfaces which are externally observable.

There are no new interfaces that this project plans to export. The same interfaces exported by the AMX in GlassFish v3 will be supported.

4.5.3 Deprecated/Removed Interfaces:

List existing public interfaces which will be deprecated or
removed by this project.

There are no interfaces that are planned to be deprecated.

4.6. Doc Impact:

Additional AMX APIs would have to be documented.

Migration path from AMX in GlassFish v2 to AMX in GlassFish v3 would need to be documented.

Migration path from AMX in GlassFish v2 to REST based management would need to be documented.

4.7. Admin/Config Impact:

No change is expected.

4.8. HA Impact:

None.

4.9. I18N/L10N Impact:

I18N support for error messages from the AMX beans.

4.10. Packaging, Delivery & Upgrade:

4.10.1. Packaging

• The APIs and it implementation would be delivered as a part of the amx-all.jar

4.10.2. Delivery

None.

4.10.3. Upgrade and Migration:

• If upgrading from GlassFish v3, then there is no impact.
• If upgrading from GlassFish v2.x then the AMX APIs are non-compatible. Hence the users would need to change their framework according to the new APIs introduced in GlassFish v3.

4.11. Security Impact:

None.

4.12. Compatibility Impact

• The API has changed significantly from the APIs in GlassFish v2.x and the main point of change are documented here

Since the changes in the API will affect the clients, the upgrade and migration tool should have no impact.

4.13. Dependencies:

4.13.1 Internal Dependencies

• Dependent on the clustering infrastructure.

4.13.2 External Dependencies

• None.

4.14. Testing Impact:

• Existing tests from GlassFish v3 can be used for regression testing.
• New tests using the existing ( or slightly modified) framework would need to be developed for testing the clustering support for AMX and JSR 77.

5. Reference Documents:

• AMX in GlassFish v3 doc
• AMX SPI doc
• Gmbal specification doc
• JSR 77 spec
• Clustering one pager doc

6. Schedule:

6.1. Projected Availability:

Indicate which milestones from the current schedule the project
will be:

• To get more granular updates about the delivery , please refer to milestone schedule here