Overview

Traditionally, massively distributed systems such as those enabled by the Service Grid are notoriously difficult to manage. The user has had to manage each node of the distributed system individually. The Service Grid introduces a management System to solve the challenges of managing nodes on the network.
The System centralizes the management of Service Grid components distributed across the network. It consists of a standalone process called the Focal Server. The Focal Server pulls all the management capabilities of the nodes on the network into one location. This gives the operator a one stop shop to see the whole network. Additionally the Focal Server can be systematically accessed via standard methods that enable integration with standard monitoring tools in the market.

New in GigaSpaces 5.2 The Service Grid Management Framework is a new feature in GigaSpaces version 5.2 and onwards.

How it Works

The Focal Server uses Jini Discovery to discover remote JMX MBeanServers on the network. A proxy MBean is registered at the Focal Server for each remote MBean of each discovered MBeanServer. The proxy forwards all MBean attribute and operation requests to the remote MBean via standard JMX Remoting. The remote MBeanServer is also monitored for MBean registration changes. The proxy MBeans are then adjusted to match the remote MBeanServer.
The Focal Server can expose itself via several standard adapters. By default, it runs the RMI Adapter and the MX4J HTTP Adapter. The RMI Adapter enables standard tools such as JConsole and MC4J to connect to the Focal Server. The MX4J HTTP Adapter is a XML over HTTP api enabling end users to develop their own custom solutions using standard apis. The HTTP Adapter also has a limited HTML interface that is compatible with most browsers. The HTML interfaces can lists all registered MBeans, their attributes and operations. In addition, it can even set attributes and invoke MBean operations.

Focal Server Requirements

The Focal Server requires that participating remote MBeanServers be available over the network and be registered with either a Jini Lookup Service or have its URL available manually.
The user code must be instrumented according to JMX standards and registered with the exported MBeanServer. In particular, JMX supports only primitive types (and their wrappers), standard Java collections and JMX specific CompositeData and Tabular-Data. All attributes and operation parameters must use this limited set of types.

Using JMX Standard MBeans

All built-in MBeans are implemented as JMX Standard MBeans. Therefore, all MBeans have matching interfaces with names ending in MBean, for example, <class name>MBean. Moreover, Mbeans that support JMX Notifications should implement the NotificationEmitter interface.

Service Grid

The Service Grid is instrumented using the above guidelines. Both the GSMs and GSCs expose MBean interfaces and are registered on startup by default. In the GSCs, all ServiceBeans and Watches are automatically registered as MBeans too.

Below is a list of MBeans:

• GSMMBean
• GSCMBean
• WatchMBean
• All sub-classes of ServiceBeanAdapter

ServiceBeanAdapter implements NotificationEmitter, making all Service Beans capable of sending JMX Notifications. Sub-classes should add their MBeanNotificationInfo to the protected mbeanNoticationInfoList member. Notifications must then be sent using the NotificationBroadcasterSupport, that is returned by the protected method getNotification-BroadcasterSupport().
ServiceBeanAdapter has automatic transformation of SLAThresholdEvents to a JMX Notification. The GSMMBean extends this, and also transforms ProvisionMonitorEvents to JMX Notifications.

End-User ServiceBeans

The end-user ServiceBeans can extend the standard ServiceBean MBean interface by providing their own MBean interface, for example, MyMBean. The ServiceBean must then extend ServiceBeanAadapter and implement MyMBean. It is the user's responsibility to implement MyMBean interface keeping the instrumentation guidelines in mind.

POJO Support

Like ServiceBeans above, end-user, POJO-style, Service Grid services must implement a MBean interface. The Service Grid dynamically generates a sub-class of the ServiceBeanAdapter, which also implements all the of the POJOs interfaces. As a result, the JMX framework supports POJOs as if they were direct extensions of ServiceBeanAdapter described above.

JMX Enabled Space

Although the Space exposes a tremendous amount of administrative information and operations, it is not currently JMX enabled. The effort to JMX enable the Space largely resembles the instrumentation of POJOs. It is very important to ensure the right JMX MBeanServer, which is facilitated by using the provided JMXUtil, is used. Next should be the task of simply creating JMX Standard MBean interfaces that match the whole or the subset of current Space administrative functionalities.

Spring JMX Support

The JMX support in Spring provides the capability to integrate a Spring application into a JMX infrastructure. Ensuring interoperability with this feature in Spring is on the roadmap, but out of scope for the first release of the Focal point server.

Command Line Interface

The Command Line Interface(CLI) feature is set generally intersect that of the JMX Framework. These include the listing of available services on the network, administrative tasks such as starting and stopping services, and introspection of service properties. However, the CLI is arbitrarily extendable. It's likely that there are current and future CLI functions that is or will be beyond pure management focus of the JMX Framework. Therefore, the two efforts remain independent.

Focal Server Jini Configuration

Using Jini Configuration to configure the Focal Server adds the flexibility to fine tune the Server, and supports the registration of end-user MBeans and Adapters.

Performance Impact

In general JMX is pull-based, meaning whatever the overhead that is needed in order to return the JMX data is only needed when JMX calls for it. This usually results from the operator refreshing the JMX frontend screen or periodically pulled by scripts for automated monitoring.
In comparison to the original Java Class they were converted from, use of CompositeData and TabularData is heavier in terms of memory usage and network bandwidth usage. Return of too much data as a result should be taken into account.