Class Diagram

The diagram shows the class diagram of significant classes in GB. They are categorized into 5 main categories:

3.3.2.1.1 Messaging Layer

GB is built on top of a message-based architecture. All modules in GB such as

BootstrapService, ForkDaemon, Managers, Registry and ServiceAdapters are standalone and communicate with one another by message passing. With this model, separate modules can be deployed as distributed services.

GB has a set of classes dedicated for message passing. Each module has a unique UUID and one or more UniversalLocator(s) (UL). UL provides all the information necessary to identify a module in the network, including transport type, host address, port and path. 4 transport types are supported: UDP, TCP, HTTP and NB. Each UL is responsible for message of one transport type.

TransportSubstrate is responsible for sending and receiving messages to and from a module. It automatically serializes the message content according to the transport type of destination. Once created, it spawns a thread which keeps waiting for incoming messages and notifies the associated MessageProcessor upon message arrival.

Modules which want to receive message should implement the MessageProcessor interface and associates itself with a TransportSubstrate. Important modules which implement this interface include BootstrapService, Registry, SystemHealthChecker, Manager, ServiceAdapter and UserTools.

Communications between SensorManager and SensorServiceAdapters use the Web Service (WS) interface. WS in GB is built on top of this messaging layer.

3.3.2.1.2 Domain Management

Domain management in GB is done by BootstrapService. Each domain has one BootstrapService which constantly communicates with the BootstrapServices of other domains. Each domain hierarchy contains one Root node. Each domain connects with at most one parent node and any number of child nodes. For now the hierarchy is defined using a configuration file (mgmySystem.conf).

To keep the whole hierarchy up and running, each domain periodically sends a heart beat message to its parent domain. It also has to spawn the BootstrapService of all child domains if any of them is not sending heart beat for some time.

Domain 2 Bootstrap Service Domain 1 Bootstrap Service Root Domain Bootstrap Service

Heart beat Heart beat

Domain 3 Bootstrap Service Heart beat …... spawn_spawn spawn

Figure 24: Domain Management

3.3.2.1.3 Managers

In GB there are two levels of managers. The lowest level is ResourceManager, which manages resource specific modules. For example, SensorManager is responsible for managing a SensorServiceAdapter through the Web Service interface and performs operation such as sending policies to the adapters.

The upper level is Manager, which manages ResourceManagers and ServiceAdapters. The Registry keeps checking whether there are ServiceAdapters which have been registered but do not have a Manager during the health check sequence. If there is one, the Manager is notified and create a SAMModule in turn creates a ResourceManager for the particular resource in the ServiceAdapter. SensorClientAdapter is an adapter inside SensorManager for communication with the associated SensorServiceAdapter inside the Service Adapter.

Manager SAMModule Registry Sensor Manager Sensor Client Adapter Service Adapter Sensor Service Adapter SAMModule Sensor Manager Sensor Client Adapter Service Adapter Sensor Service Adapter

Resource specific communications Discover new SA

register register

monitor

monitor

Figure 25: Manager and Service Adapters

3.3.2.1.4 Resource Management

These classes are at the resource level, where resource specific tasks are performed. Each sensor is treated as a resource in GB, and each sensor has a corresponding client program (represented by SensorClient) responsible for interfacing the sensor with SCGMMS. Sensor Service Abstraction Layer (SSAL) is the interface for connecting all types of sensor client programs with GB. The class diagram only shows part of SSAL which resides in GB. The whole SSAL involves classes of SXO as well.

Communication between resource managers (i.e. SensorManager) and Resources (i.e., SensorServiceAdapter (SSA)) uses the Web Service (WS) interface for message passing. SSA therefore conforms to the WS “Put”, “Get”, “Delete” and “Create”. “Get” is used for getting SensorPolicy of the sensor and initiates connection with SG. “Delete” is used for disconnecting connection with SG.

3.3.2.1.5 Registry

Each domain has a Registry which maintains the state of the entire domain, such as the Universal Locator of every module, how many Service Adapters have been registered, the status and policy of each sensor, which SA is assigned to which Manager, etc.

RegisteredServiceAdapter is a class which contains information of ServiceAdapter such as UniversalLocator, SensorPolicy and current status. RegisteredService contains information of non-SA modules such as Managers and MessagingNodes.

Registry can work with or without persistent storage. By default all information is stored in memory using hash tables. The user has an option whether to write all information to persistent storage so that it can be retrieved later on even if the domain is restarted. The persistent storage used is compliant to WS-Context specification [3].

Figure 26 shows the overall architecture of the Domains, Registry and WS-Context modules in Grid Builder. To use WS-Context, an AXIS server and a MySQL server should be running in each domain for WS communication and storage. All domain related information in the Registry is stored in WS-Context and shared with other domains through NaradaBrokering’s topic-based publish-subscribe messaging service.

Although the current implementation does not use WS-Context as a centralized database for service discovery, it can be easily enhanced to provide such service since the system is already WS compliant.