J4ONet Component Viewpoint Analysis

The component viewpoint is where we break down the problem into objects. We look at the roles, responsibilities, and attributes that the system must satisfy. Here these concerns are translated into a object oriented design.

The roles for the J4ONet system are pretty simple: peers, or client-servers. Each agent needs to be able to ask other agents about their MBeans and status. At this point, there is no security model. I am keeping with the assumptions of the JMX RI from Sun, which also has no security model.

Patterns:

Chain of Responsibility:



Forces

• Complexity: The system might employ multiple strategies to handle a problem, but you don't want to have a single do it all object.

• Extensibility: New strategies might be added to the system after initial development. Need a straight forward way to add these to the system.

• Coupling: As strategies are changed, removed, or added; you want to isolate the system from these changes.



The Chain of Responsibility pattern has several components. A Client makes a request to a Handler. This Handler does not actually handle the request, but instead delegates the responsibility for handling the request to one or more Concrete Handlers. These Concrete Handlers might delegate their responsibilities, and so on, and so on. This main Handler manages these sub-handlers. It contains strategies to determine which Concrete Handlers should handle the Client's requests. It acts as a single point to add Concrete Handlers. The Concrete Handlers agree by contract to an interface, so no link up the chain knows how the links down the chain work. This reduces coupling.

Singleton:



Forces

• Complexity: Need a way that the entire system is accessing a single state, i.e. configuration.
  
  The singleton pattern ensures a class has only one instance and provide a global point of access to it. This is the essence of registration systems like JNDI. The entire system sees a single directory that contains references to single objects that entire system shares.



J4ONet:



JsRegistryManager:

This acts as the first link in the Chain of Responsibility. It handles requests to discover MBeans and Agents. It aggregates Concrete Handlers that do the actual resolving of the JMX services. It should accept resolving requests and return their locations via a token.



MBeanResolver:

This is the contract by which the JsRegistryManager agrees to work with the RegistryManager's sub-handlers. It contains the core interface and common logic for children handlers.



JsRegistry:

This is a singleton to cache the location of discovered services. As services are discovered by the JsRegistryManager, they are cached in this object.



JsRegistryResolver:

This sub-handler looks for services in the local JsRegistry cache.



MBeanServerResolver:

This sub-handler looks for services in the local agent.



BroadcastRequestResolver:

This sub-handler looks for services in the LAN. It sends off a UDP ping that will be answered by a working J4ONet. If the J4ONet finds a matching service in its local agent, it will respond with a UDP packet that the BroadcastRequestResolver will translate into a found service.



J4ONet:

This is another singleton. It contains the configuration information for the local agent. It contains a socket that listens for BroadcastRequestResolver requests. When the JsRegistryManager responds to a resolving requests, it will use this object find out about the local agent.



BroadcastHandler:

This is a thread that is spawned in the J4ONet to handle the BroadcastRequestResolver request UDP packets. It will use the JsRegistryManager to handle resolution.



The diagram shows the JsRegistryManager aggregating multiple components. This does not mean that the JsRegistry holds hard references to these objects. All of these objects will be MBeans registered with the local agent. The JsRegistryManager will use the local agent to reference these objects.