WebCom Parent WebCom Parent WebCom Parent WebCom Parent WebCom Parent WebCom Parent WebCom Parent Child Child Child Child Child Child Child Child
Figure 5.1: WebCom’s n-tier architecture.
5.2
Architecture
WebCom is composed of a number of replaceable modules connecting to a central scheduler. The core WebCom modules are the Execution Engine Module, the Communications Manager Module, the Load Balancing Module the Fault Tolerance Module, the Naming Manager Module and the
Security Manager Module. These modules make up the core of the WebCom system. Each module
has its own local policies that define the configuration of that module. Non-core modules, called user modules, are also supported. The architecture is “pluggable”, in the sense that a module can be re-implemented to replace the reference implementations of that module. WebCom supports the use of multiple instances of a core module type concurrently. When multiple instances are present, decisions are made jointly. For example, if multiple security manager modules are present, each module makes decisions on requested actions and only when all modules agree will any action take place. Figure 5.2 displays a representation of the core WebCom modules. These modules are examined in more detail below.
WebCom provides a complete messaging infrastructure, allowing modules to communicate be- tween themselves on both the same WVM, and on other WVMs in the network. For example, a load balancing module can ask another load balancing module in a different WVM the extent of the load on its children. The messaging infrastructure is regulated by the security manager.
When a node is firable by the execution engine and is to be scheduled by the WVM, the sched- uler asks the load balancing module and the security manager module to find a child that is both unloaded and is authorised to execute such a node. Whether a child is unloaded and authorised is determined by the load balancer and security manager modules respectively.
Execution Engine Security Manager Module Communications Manager Module Scheduler Network Load Balancer Module Module Fault Tolerance Naming Manager Module
Secure WebCom
Figure 5.2: Secure WebCom Architecture
5.2.1 Execution Engine Module
The execution engine module is used to execute operations sent to the WVM. Execution engine implementations can be written to execute any type of operation. The reference implementation is a Triple Manager that is used to execute condensed graphs. Implementations also exist to execute
CORBA, J2EE, .NET and Grid nodes. If a WVM is operating as a child, the execution engine will
execute the nodes sent to it locally and will return results to its parent. If the WVM is operating as a parent, the execution engine selects nodes for scheduling and maintains the current state of the executing graph.
5.2.2 Communications Manager Module
The communication manager module is used to manage communication between WVMs. Typically this network communication uses the TCP/IP protocol. However other types of communication manager module also exist, such as the Web Services communication manager module [129], that provides a web services interface to WVM. The communication manager module is used to route the traffic between a WVM, its children and parent.
The current prototype of Secure WebCom uses SSL [92] to provide secure and authentic com- munication links. This will be discussed in more detail in Chapter 7. The secure communications manager manages the cryptographic keys and store trusted keys. Implementing a secure commu- nication manager module entails replacing the standard communication manager module with an implementation that uses the SSL protocol.
5.2 Architecture 77
5.2.3 Load Balancing Module
The load balancing module manages the load on the children of a WVM. This allows the parent WVM to choose to schedule nodes to children that are relatively unloaded. The load balancing module makes the scheduling decisions in conjunction with the security manager. The load bal- ancing policies range from simple round-robin schedulers to complex schedulers using history to predict future loads [144].
The load balancer is also used to match nodes to specific WVMs. For example, a node may require data that is only available to a specific WVM. The load balancer policy can contain such details and match nodes to specific WVMs2.
5.2.4 Fault Tolerance Module
The fault tolerance module managers faults that occur within a network of WVMs. This can range from fault avoidance to fault recovery [104]. Work that was scheduled to WVMs that have since failed will be rescheduled to other WVMs by the fault tolerance mechanism.
The default fault tolerance mechanism is sophisticated. If a WVM that is acting as a parent fails, then the only work lost is the work that is taking place on the failing machine. Its children will decide on a new parent between themselves. This new parent will contact their “grandparent”, that is, the WVM that was the parent of the failing machine. The work that the children have executed up to that time will be reintegrated by the new parent and the execution will continue as before.
5.2.5 Naming Manager Module
The naming manager module manages the names of node objects in a condensed graph. When We- bCom modules make decisions they require a fully qualified name for nodes. The naming manager generates, stores and updates the names as the execution progresses. These names hold the execu- tion context of the nodes in a condensed graph application. This execution context can be used by the other modules to make scheduling and security decisions about the nodes.
Chapter 6 describes how nodes in condensed graphs can be properly named. The naming man- ager uses these techniques to manage descriptive names for nodes in the WebCom system. In the current prototype the security manager alone uses these names. However, it is envisioned that the other modules will take advantage of the naming architecture. For example, it is proposed to use the naming system to properly identify WVMs for use by the fault management mechanism.
2The security manager module is also capable of ensuring that nodes are sent to specific WVMs. This will be examined
5.2.6 Security Manager Module
The security manager module enforces the local security policy of WebCom. The security manager module acts as a reference monitor [25], determining whether it is safe to execute security critical actions. These actions could be the scheduling of a node, the sending of a message, a result to be processed or the local execution of a node. The security manager makes decisions based on its local security policy.
The security manager can be implemented in a number of ways, ranging from a simple manager that permits everything, to a sophisticated access control system. An early prototype implemented a trust management based access control system. In this implementation permissions are delegated to principals, representing WVMs, using cryptographic credentials. The trust management security manager uses the credentials provided by child WVMs to decide where to schedule nodes. The implementation of the Trust Management security module is discussed in more detail in Chapter 7.
5.2.7 User Modules
WebCom supports the development a variety of non-core module types. These are referred to as user modules. One example is the information gathering module [123] that gathers machine execution information from WVMs. This is used to map the load on a cluster of WVMs to measure both performance and usage. User modules cannot directly effect the scheduling decision making logic of WebCom. User modules are restricted to gathering information. This information could be used by a core module, and thus effect a scheduling decision.
WebCom provides a complete application programming interface (API). Using this API, third parties can create different implementations of core WebCom modules, or create entirely new mod- ules.