Executive Summary. iii

Transcription

1 Executive Summary Operational and tactical military environments are composed of mobile nodes and dynamic situations resulting in a high degree of uncertainty. Communication links are often based on adhoc networks resulting in intermittent reachability, variable latency, and low bandwidth. As nodes enter and leave the environment, the set of available data sources and services within the Community of Interest change continuously. Information management infrastructures must be designed to operate effectively in such environments in order to support the vision for net-centric operations. Agile computing is an innovative metaphor for distributed computing systems and prescribes a new approach to their design and implementation. Agile computing may be defined as opportunistically discovering, manipulating, and exploiting available computing and communication resources in order to improve capability, performance, efficiency, faulttolerance, and survivability. The term agile is used to highlight the desire to both quickly react to changes in the environment as well as to take advantage of transient resources only available for short periods of time. Agile computing thrives in the presence of highly dynamic environments and resources, where nodes are constantly being added, removed, and moved, resulting in intermittent availability of resources and changes in network reachability, bandwidth, and latency. An agile computing approach is well suited to adapting existing static ground-based infrastructures to operate in dynamic and tactical environments. The proposed effort will focus on four tasks that will facilitate the transition to highly mobile platforms that operate in uncertain conditions. The first task will focus on applying agile computing to service-oriented architectures, with the goal of making it easy to take existing implementations based on service-oriented architectures and porting them to an agile computing environment. The research in this task will address service definition, instantiation, invocation, relocation, and termination in dynamic environments. Service resource utilization, invocation patterns, and network and node resource availability will be used to determine optimal locations for services to be instantiated and invoked. A heuristic coordination algorithm will be developed to perform the service allocation and reallocation on a continuous basis. The second task will address dynamic service discovery. There is substantial past and ongoing work on service discovery in the research community. The proposed research will focus on the unique aspects of service discovery necessary to better support agile computing, which also requires discovery of resources in addition to services. The discovery mechanism will be designed to improve the probability of discovering resources and services that have more capacity and that are more accessible than others, thereby improving the distribution of the load on the system and adapting to changes in resource availability and reachability. For better performance, the resource and service discovery mechanisms will be integrated into the underlying ad-hoc routing algorithms, which will reduce communications overhead. iii

2 The third task will focus on efficient data dissemination via distributed predicate processing. The FlexFeed framework handles hierarchical and bandwidth efficient distribution of streaming data in dynamic networks. The proposed research will extend FlexFeed to handle predicate processing of metadata in a hierarchical manner. The predicates specified by subscribers will be organized into hierarchical trees, with the more generic predicates at the top and the more specific predicates at the bottom. These predicate matching conditions will then be distributed in the network, based on network bandwidth and processing resources available. As data is generated and published, the metadata is propagated through the hierarchies and then forwarded onto the subscribers whose conditions are satisfied. The fourth and final task will address proactive resource manipulation to maintain and restore communications between services and clients as well as between data providers and subscribers. Service invocation and data dissemination will use the Mockets communications library, which can detect connectivity loss and relay that event to the agile computing coordination mechanism. The coordination mechanism can then try to restore connectivity by identifying potentially movable resources (such as a UAV) and repositioning them to provide a communications relay. The components of the system will be developed in a combination of Java and C++ environments and will initially be targeted to PC-based systems running either Windows XP or Linux operating systems. The underlying networking infrastructure will be based wireless communications. Three different demonstrations will be performed as part of this effort at 6, 12, and 18 months into the project. The 6-month demonstration will show the basic capabilities of dynamically defining, instantiating, and invoking services in the agile computing middleware. The 12-month demonstration will show the data dissemination and distributed predicate processing capability. Finally, the 18-month demonstration will show the continuous optimization and proactive manipulation in the context of both service invocation and data dissemination. iv

3 1.0 Technical Approach 1.1 Technical Discussion Introduction Operational and tactical military environments are composed of mobile nodes and dynamic situations resulting in a high degree of uncertainty. Communication links are often based on adhoc networks resulting in intermittent reachability, variable latency, and low bandwidth. As nodes enter and leave the environment, the set of available data sources and services within the Community of Interest change continuously. Information management infrastructures must be designed to operate effectively in such environments in order to support the vision for net-centric operations. Agile computing is an innovative metaphor for distributed computing systems and prescribes a new approach to their design and implementation [1][2]. Agile computing may be defined as opportunistically discovering, manipulating, and exploiting available computing and communication resources in order to improve capability, performance, efficiency, faulttolerance, and survivability. The term agile is used to highlight the desire to both quickly react to changes in the environment as well as to take advantage of transient resources only available for short periods of time. Agile computing thrives in the presence of highly dynamic environments and resources, where nodes are constantly being added, removed, and moved, resulting in intermittent availability of resources and changes in network reachability, bandwidth, and latency. An agile computing approach is well suited to adapting existing static ground-based infrastructures to operate in dynamic and tactical environments. The proposed effort will focus on four tasks that will facilitate the transition to highly mobile platforms that operate in uncertain conditions. The first task will focus on applying agile computing to service-oriented architectures, with the goal of making it easy to take existing implementations based on service-oriented architectures and porting them to an agile computing environment. The research in this task will address service definition, instantiation, invocation, relocation, and termination in dynamic environments. Service resource utilization, invocation patterns, and network and node resource availability will be used to determine optimal location for services to be instantiated and invoked. A heuristic coordination algorithm will be developed to perform the service allocation and reallocation on a continuous basis. The second task will address dynamic service discovery. There is substantial past and ongoing work on service discovery in the research community. The proposed research will focus on the unique aspects of service discovery necessary to better support agile computing, which also requires discovery of resources in addition to services. The discovery mechanism will be designed to improve the probability of discovering resources and services that have more capacity and that are more accessible than others, thereby improving the distribution of the load on the system and adapting to changes in resource availability and reachability. For better 1

4 performance, the resource and service discovery mechanisms will be integrated into the underlying ad-hoc routing algorithms, which will reduce communications overhead. The third task will focus on efficient data dissemination via distributed predicate processing. The FlexFeed framework [3][4] handles hierarchical and bandwidth efficient distribution of streaming data in dynamic networks. The proposed research will extend FlexFeed to handle predicate processing of metadata in a hierarchical manner. The predicates specified by subscribers will be organized into hierarchical trees, with the more generic predicates at the top and the more specific predicates at the bottom. These predicate matching conditions will then be distributed in the network, based on network bandwidth and processing resources available. As data is generated and published, the metadata is propagated through the hierarchies and then forwarded onto the subscribers whose conditions are satisfied. The fourth and final task will address proactive resource manipulation to maintain and restore communications between services and clients as well as between data providers and subscribers. Service invocation and data dissemination will use the Mockets communications library [5][6], which can detect connectivity loss and relay that event to the agile computing coordination mechanism. The coordination mechanism can then try to restore connectivity by identifying potentially movable resources (such as a UAV) and repositioning them to provide a communications relay Overall Architecture Current implementations of the agile computing middleware are based on the NOMADS mobile agent infrastructure [7]. As part of this effort, the implementation will be generalized to support service-oriented architectures. Some of the capabilities underlying mobile agents, including mobile code, mobile computation, and strong mobility, will continue to be used by the runtime environment. However, the user-level components will not be restricted to being agents and communicate with each other using messaging. Figure 1 shows the overall architecture for the envisioned middleware. The four major components of the middleware are the Agile Computing Kernel, the Coordinator, FlexFeed, and Mockets. In addition, the Visualizer and IHMC s KAoS policy and domain services framework [8][9] allow the user to observe and constrain the behavior of the system respectively. The user-contributed components are represented as either clients or services in the figure. Services may either be started up via external means and then register with the middleware, or they may be defined and started up by the middleware on demand. The former case is appropriate for situations where services are bound to particular nodes and represent the access mechanism to the node (for example, a service that wraps a sensor on a platform). The latter case is appropriate for situations where the number of instances of a service can vary over time based on load, resource availability, and network configuration. 2

5 Figure 1: Overall Architecture of the Agile Computing Middleware The following subsections describe the major components of the Agile Computing middleware Agile Computing Kernel (ACK) The Agile Computing Kernel contains a uniform execution environment, a policy manager, a resource manager, a group manager and a local coordinator. Figure 2 shows the main components of the ACK. These components provide the set of capabilities that the running processes rely upon to take advantage of the agile computing framework. They constitute a middleware through which processes communicate and migrate between nodes. The following subsections provide a brief explanation of each of the components. 3

6 Figure 2: The Agile Computing Kernel Uniform Execution Environment The Uniform Execution Environment provides a common abstraction layer for code execution that hides underlying architectural differences such as CPU type and operating system. The execution environment supports the dynamic deployment and activation of services, dynamic migration of services between kernels, secure execution of incoming services, resource redirection, resource accounting, and policy enforcement. The implementation of the Uniform Execution Environment is currently based on either Aroma [10] or the standard Java VM. Aroma is a clean-room implementation of a Java-compatible VM designed to provide architecture independence and support for agile computing requirements. Aroma was designed from the ground up to support capture of execution state of Java threads, provide accounting services for resource usage, and control resource consumption by Java threads. Moreover, the captured execution state is platform independent, which allows migration of computations between Aroma VMs that are running on different hardware platforms. The capabilities of the Aroma VM are critical to ensure secure execution of mobile code. A standard Java VM is an alternative to the Aroma VM and provides higher performance. Under separate funding, we are also adding resource control capabilities to the standard Java VM using the JRaf2 framework [11]. A deployment of the middleware can contain any combination of kernels with Aroma and Java VMs, thereby providing additional flexibility. There are no implicit or explicit requirements to use Java as the language for the implementation of the agile computing infrastructure. However, Java provides many desirable features for a mobile-code based framework. Moreover, the virtual machine architecture of Java provides platform independence. Besides the Java-compatible VM, the execution environment also includes a set of software components that support interaction between the kernel and locally running services. These components are: a) the Security Enforcer, b) the Resource Accounting Mechanism, c) the State Capture Mechanism, and d) the Resource Redirector. 4

7 The Security Enforcer will ensure that running services will have limited access to system resources to avoid denial of service (DOS) attacks. This component will receive settings from the Policy Manager component specifying usage restrictions for each service running in the VM. The restrictions can be established during service deployment, migration, or even at runtime, after the service execution has started. This component also provides authentication and encryption mechanisms for secure data and state transfer. The Resource Accounting Mechanism provides a facility to track resource utilization at the service level inside the VM. The mechanism is used by the Security Enforcer and the Resource Manager components to estimate overall kernel load and resource availability. The resource utilization profile of the service is also made available to the coordination component, which can use the information to decide optimal placement of services within the environment. The Resource Redirector provides the means to transparently move links to local or remote resources when services are migrated between kernels. Consider, for example, a scenario where a service has two network connections open to remote nodes. Due to an imminent power failure the service needs to move to another intermediate node. In this case, the Resource Redirector on each kernel will negotiate a redirection of the resources (the network connections in this case) to transparently move the service with no apparent interruption of the links. For the computation in this example, the migration happens seamlessly and the network connections with the remote hosts are maintained during the migration. The Resource Redirector implementation relies on the Mockets framework to provide migration of communication endpoints [5][6]. The State Capture Mechanism provides the necessary means to capture execution state of one or multiple services running in the execution environment. The execution state can be captured at any point between the execution of two Java bytecodes. The state information can then be persisted or moved to another host to resume execution on the very next bytecode. This capability is only available in conjunction with the Aroma VM and not the standard Java VM. All these components work in concert with policies and the Resource Manager that are also part of the kernel but not directly integrated with the execution environment. The Resource Manager is primarily concerned with higher level interactions with the Coordinator and other kernels, but it does rely on the execution environment components to locally perform and enforce resource utilization policies. Policy Manager Interface The policy manager interface is responsible for communicating with the KAoS policy and domain services framework [8][9]. KAoS manages the specification, conflict resolution, and distribution of policies to the enforcement components (in this case, the agile computing infrastructure). The interface component provides a facility for other components in the kernel to query and determine policies and restrictions that apply to local and remote services and nodes. Resource Manager The Resource manager provides an interface for the Coordinator and remote kernels to query and provide information about local resource utilization. 5

8 Resource availability is one of the metrics considered by the Coordinator when calculating optimum distribution of services. The Resource Manager will act as a bridge between the Accounting Service in the execution environment and the Coordinator. It will monitor local resource utilization in the execution environment and interact with the Coordinator to request migration of local services or to notify it of local resource availability for the Framework. Group Manager The Group Manager is the component responsible for identifying all the nodes that participate in a group. The framework is designed to handle highly dynamic environments, where nodes join and leave the framework at any arbitrary rate. Therefore, a fundamental requirement is to efficiently and accurately identify other available nodes and services. The role of the Group Manager is to coordinate with the Policy Manager to ensure proper advertisement of services and to identify and locate services required by local processes. Although very useful for some types of applications, lookup services fail to provide important features that are necessary for agile computing. Some of these features are offered instead by the notion of service discovery. The Group Manager relies on service discovery mechanisms, which provide a more general notion of service identification and location. In general, discovery protocols rely on the establishment of a global representation or state of the framework, available to each node. Unlike registry lookup, service discovery is an active service that announces the arrival and departure of service providers and capabilities. It doesn t necessarily rely on a centralized registry and it provides means to ensure service availability. Local Coordinator The Local Coordinator works in conjunction with other local coordinators as well as centralized or zone-based coordinators to perform resource allocation, service deployment, service invocation, and service migration decisions. The coordination mechanism is discussed further in section Coordinator The Coordinator in the Agile Computing Framework is an abstract entity that is responsible for allocating and monitoring overall resource utilization in order to ensure that service allocation is in compliance with current optimization criteria (framework goals) and policy constraints. The Coordinator can be implemented as a) a centralized component in the framework, working with global information, b) as a decentralized component relying solely on local information on each node, or c) as a hybrid (or zone-based) component. In the first case, the Local Coordinator component at each kernel acts essentially as an interface to the centralized, global Coordinator that maintains the global state of the network. In the second case, the Local Coordinator at each node is directly responsible for the allocation of its local resources at any given time. This is achieved through direct negotiation with other Local Coordinators. The third approach, which is likely to be the most scalable, is zone-based and 6

9 hierarchical. The network is self-organized into small zones whose combined resources are regulated by a locally elected Coordinator. Zone-level Coordinators are regulated by higher level Coordinators that handle only aggregate information from each zone, allowing for a scalable and efficient model for resource coordination. The coordination algorithms are domain specific and will be developed as part of the proposed research. In general, the algorithm shall take into account the communication patterns (i.e., the communication endpoints and bandwidth utilization), the service invocation patterns, the service resource utilization profiles, and of course the resource availability at nodes. The algorithm will determine the number and placement of service instances and the mapping of service invocations to instances. Details about previously designed coordination algorithms for agile computing are available in [12] [13] FlexFeed FlexFeed [3] provides an application-level interface that is customized for hierarchical data distribution in tactical environments. The goal is to leverage from the multi-hop nature of data distribution paths to distribute processing tasks in the path (in-stream data processing), striking a balance between data processing and data distribution. The component relies on the agile computing framework for resource allocation and it leverages from mobile software agents to efficiently deploy filtering and fusion capabilities in the network. It differs from traditional multicast approaches because of the cyclic nature of node selection for data processing and for routing (the problem is usually solved interactively) and it differs from traditional publish-subscribe models in that data transformation components are deployed on demand (and only while needed), and there is a continuous re-evaluation of topology of the data distribution tree. The FlexFeed framework has been previously described, tested, and demonstrated in the context of tactical environments [13] [4] Mockets Mockets (for mobile sockets ) is a comprehensive communications library for applications. The design and implementation of Mockets was motivated by the needs of tactical military information networks, which are typically wireless and ad-hoc with low bandwidth, intermittent connectivity, and variable latency. Mockets addresses specific challenges including the need to operate on a mobile ad-hoc network (where TCP does not perform optimally), provides a mechanism to detect connection loss, allows applications to monitor network performance, provides flexible buffering, and supports policy-based control over application bandwidth utilization. Mockets provides the following five features: 1. Application-level implementation of the communications library in order to provide flexibility, ease of distribution, and better integration between the application and the communications layer. 7

10 2. A TCP-style reliable, stream-oriented service that is designed to operate on wireless adhoc networks thereby making it easy to port existing applications to the ad-hoc environment. 3. A message-oriented service that provides enhanced capabilities such as message tagging and replacement, different classes of service (reliable/unreliable combined with sequenced/unsequenced), and prioritization. 4. Transparent mobility of communication endpoints from one host to another in order to support migration of live processes with active network connections. 5. Interface to a policy management system in order to allow dynamic, external control over communications resources used by applications Interactions Between Components A number of Application Programming Interfaces (APIs) and protocols define the interactions between the components presented in the architecture. These interactions are described below: Service Definition Service definition for the agile computing middleware is different (but complements) service definition in a service-oriented architecture. For example, Web Services use the Web Service Definition Language (WSDL) [14] to define a service in terms of the set of operations and the input and output messages. This type of service definition supports discovery of services and operations by clients and validating inputs and outputs. Service definition for the middleware specifies other parameters including the code for the service (or the location where the code may be dynamically obtained), the resource utilization profile, and the communications profile. This registration information allows the coordination component to identify nodes with adequate resources to host services and to then dynamically deploy services onto those nodes Service Registration Service registration is the mechanism through which a service that has been activated registers its instance with the middleware. Service registration occurs under two circumstances. A service that was previously defined may have been activated by the middleware (see section ), leading to a new instance being created that subsequently registers with the middleware. Alternatively, specialized nodes such as sensors may have services that register when the node is activated. These services provide the entry points for clients to access the sensors. Service registration usually involves identifying the location at which the service may be reached. This is the equivalent of a port in WSDL that results from associating a binding with a network address. Once a service has been registered, the service may be reached over a network connection Environmental Sensing Environmental sensing involves detecting attributes about a node and connectivity between nodes. The attributes include resource availability (in terms of CPU, memory, power, and disk as appropriate) and physical position in the environment. Connectivity information indicates the reachability of other nodes in the environment from the current node. This information is 8

11 gathered by different providers on the node and made available to the Coordinator. The provider architecture allows different nodes to accommodate different mechanisms to obtain the environmental information. For example, some nodes may use GPS for positioning while others may use dead-reckoning or be stationary. Similarly, connectivity information may be obtained differently based on the underlying networking hardware. Additional node-specific information may also be made available to the Coordinator. For example, a UAV with a specific flight-plan can make the flight-plan information available to the Coordinator, which can use the data to predict the position of the UAV in the future Service Lookup Service lookup is performed by a client in order to find a service to invoke. The result of a service lookup is a set of network endpoints to allow the service to be invoked. Web Services use Universal Description, Discovery, and Integration (UDDI) [15][16] in order to publish and lookup services. The service lookup in agile computing differs from the UDDI approach in two important aspects. In agile computing, service instances may be activated on demand on nodes that are opportunistically discovered. Therefore, a service instance may not be registered until a client invokes the service. This requires a separation between registering a service type versus a service instance. When a client requests the invocation of service, the invocation may only specify the type of the service. The middleware identifies the best instance (or creates a new instance) of the service and forwards the request. Also, UDDI was designed in the context of corporate networking environments and the Internet. The network characteristics of these environments differ significantly from the wireless ad-hoc networks in dynamic and tactical military environments. Some initial work has been done in adapting UDDI-style service lookup to ad-hoc networks [17]. In [18], researchers have shown the benefits of integrating service lookup protocols into reactive routing protocols. The requirements for agile computing are different due to two factors. The middleware needs to discover resource availability at nodes, which changes more rapidly than service availability. Moreover, given the opportunistic nature of the middleware, the resource discovery needs to be proactive as opposed to reactive. Currently, the Group Manager component of the Agile Computing Kernel handles node discovery this component will be extended and integrated with the underlying networking protocols to support resource and service discovery. The propagation of resource availability information will be integrated with the Environmental Sensing component described in section above Service Invocation (Client to Middleware) Service invocation begins by a client making a request for a service. Unlike a Web Services environment, the service invocation is a request to the middleware, not to the service. This allows the middleware to decide the best current instance of the service to handle the request or to create a new instance on a resource rich node. The standard Web Services approach only supports a request-reply mode of operation. In this case, the service invocation API needs to support two additional modes of operation: 9

12 asynchronous invoke, and subscription oriented (which, in turn, may be ongoing until cancelled or for a specified duration). Request-reply is the simplest mode the client invokes an operation and blocks until the operation has been completed and the results are available. Asynchronous invocation allows the client to invoke a service asynchronously and interact with the service later, to query the status or push new data to the service. Note that this mode can be realized with Web Services provided some state information is maintained across invocations. The subscription oriented mode allows the client to invoke a service which then asynchronously pushes data back to the client. This mode is not directly supported by Web Services, but is an essential mode of operation to support publish-subscribe architectures. Without this capability, the client would have to periodically poll the service to check for new data, which is inefficient. Having this capability allows the service to asynchronously push data to the client when appropriate. At the API level, this will be realized through a callback mechanism on the client. Additional APIs will allow the client to query the overall status of a service and to cancel a previous invocation (asynchronous or subscription-oriented) Service Deployment and Activation Service deployment and activation is used by the coordination component to instantiate a new service on a node. This action is normally performed in response to a request from an application to invoke a service. In some cases, the middleware may use an existing instance of the service to satisfy the request while in others, the middleware may use this mechanism to create a new instance. The Agile Computing Kernel on the target node handles the request and instantiates the specified service. If necessary, the executable code for the service is dynamically downloaded by the kernel from a specified code source. Once activated, the service is identified by a UUID that is returned by the kernel to the Coordinator Service Invocation (Middleware to Service) This is the second half of the service invocation process, where the middleware passes on a request from a client to an instance of the service. Section describes the modes of operation for the invocation Service Migration (Middleware to Kernel) The continuously changing environment may cause a particular service instance to no longer be optimally positioned. The Coordinator uses this mechanism to request the Agile Computing Kernel to migrate a service instance from one node to another node. The migration may be caused by the availability of a new resource-rich node, a change in the communications links, or due to the old node being no longer suitable. For example, a service running on one UAV may be migrated to another UAV if the first one is about to complete its mission and leave the area Service Migration (Kernel to Kernel) In response to a service migration request from the coordination component, the Agile Computing Kernel uses this protocol to transfer the service instance from the current node to the newly identified target node. If the Agile Computing Kernel is based on the Aroma VM, the execution state of the service instance is captured and migrated to the new node in a transparent manner. If the kernel is based on the standard Java VM, the service is migrated to the new node 10

13 and execution is restarted. Mockets will be used to handle ongoing communications between services as well as between clients and services, which will allow the connection endpoints to be migrated transparently. Therefore, moving a service will not interrupt the already established connections between that service and other components Connection Status Connection status notification allows the Mockets framework to notify the Coordinator about connection establishment, teardown, and loss during communication. This mechanism allows the Coordinator to keep track of established connections, react to failed connection attempts, and connection loss during communication. For example, if a client on one node has invoked a service on a second node and the connectivity is lost between the nodes, the mocket endpoint used for the service invocation will detect and notify the Coordinator about the connection loss. The Coordinator is then able to take action to try and restore the communications between the affected nodes Proposed Research Tasks Dynamic Service instantiation, relocation, and, optimization Service oriented architectures rely on locating and invoking services provided by software components in a reliable and efficient manner. In a dynamic environment, manual configuration and deployment of services will be inadequate. As the environment changes, the system will become inefficient due to the services being located on nodes that are no longer optimal. As the service utilization patterns change, services may become over-provisioned or under-provisioned. Moreover, connectivity to nodes may change thereby reducing bandwidth, increasing latency, or creating network partitions. The architecture for agile computing as described in section directly supports the requirements of this task. Realizing the architecture requires extending the current agile computing implementation to support a service-oriented architecture. Services will be defined dynamically at runtime by the application as described in The kernel will monitor service invocation patterns as well as service operation (computational load, data access, and communication with other services) and provide this information to the coordination components. The environmental sensing components will monitor computing resource availability, network reachability, latency, and bandwidth and provide this information to the Coordinator. The Coordinator, taking this information into account, will detect poor runtime configurations. As necessary, the Coordinator will create additional service instances on other nodes, relocate current instances, or terminate unnecessary instances. The Coordinator will perform this activity as a continuous process. Service invocation will be layered on top of the Mockets communications library. Service invocation may be done through asynchronous messaging, synchronous remote procedure calls (such as Java RMI) or through a web services oriented approach. Note that both the RPC and the web-services models will need to be extended to support subscription-oriented invocations as described in section These mechanisms will be layered on top of mockets to support transparent service invocation even if a service component is relocated during use. 11

14 KAoS will be integrated into the agile computing infrastructure to support policy-based control over the runtime behavior of the system. Policies can be used to control the number and location of services, the relocation of services, minimum service levels, and service prioritization within a Community of Interest. Policies will also be used to regulate the proactive and opportunistic exploitation of resources within the environment Dynamic Service Discovery Discovery in the agile computing framework occurs at two levels. At a lower level, the middleware requires that nodes and node resources be discovered in order to support opportunistic behavior. At a higher level, services need to be located by clients that wish to interact with them. Discovery needs to support both locating service definitions as well as locating instances of services. In the context of agile computing, service instances may not exist until a client makes a request for the service (see section ). Therefore, an approach like UDDI would have to be extended to support the dynamic service instantiation model. Moreover, given the unreliable nature of the network, service instances may appear and disappear randomly. The service discovery mechanism has to be adapted to operate on top of ad-hoc networks (see discussion in section ). The Group Manager component in the middleware currently supports discovery of nodes. This will be extended to support discovery of node resources as well as services available at nodes. Depending on the underlying network architecture, this capability may be integrated into the routing algorithms directly in order to optimize the network bandwidth utilization Efficient Data Dissemination and Predicate Processing Building on top of the middleware support for services, the FlexFeed component will be enhanced to support efficient data dissemination and distributed predicate processing. The FlexFeed component provides a hierarchical data distribution mechanism that continuously optimizes the data flow and data processing based on changes in the network. This effort will leverage from the current FlexFeed framework to build on-demand hierarchical data distribution graphs from sets of subscription predicates and templates. Consider the example of disseminating imagery data tagged with meta-data identifying the geographical area represented by the image. For simplification, assume a 10x10 grid of coordinates and four clients, C 1, C 2, C 3, and C 4 that have used predicates to subscribe to information being published. C 1 is interested in [0,0 to 3,2], C 2 is interested in [0,0 to 1,1], C 3 is interested in [2,2 to 5,8] and C 4 is interested in [3,7 to 4,7]. These are shown graphically in Figure 4. 12

15 Figure 4: Predicates Used by Four Clients Subscribing to Data Given these conditions and the underlying network topology, FlexFeed will build a hierarchical data distribution graph and locate the predicates at the nodes, balancing the processing load as well as the data transferred through the network. Figure 5 shows one possible processing hierarchy and the mapping of the processing elements and clients to the underlying network. Figure 5: Distributed Predicate Processing on Ad-Hoc Network 13

16 Proactive Manipulation to Maintain and Restore Communications Dynamic and tactical environments involve mobile nodes and wireless communications. Node mobility and many other factors such as interference and blockage of signals result in intermittent communications. In service-oriented as well as publish-subscribe architectures, it is quite likely that communication between a client and a service or between a data provider and subscriber is interrupted or lost. The middleware will rely upon the Mockets framework to handle communication between clients and services as well as between data providers and subscribers. Every instance of a mocket includes a MocketStatusNotifier component that uses a loopback UDP socket to transmit connection setup, teardown, connection loss warning, and statistical information. This information is transmitted to a UDP port on the local host. The information is received by the Agile Computing Kernel, which uses the MocketStatusMonitor component to receive the notifications sent from every mocket on the local host. The kernel forwards this information to the Coordinator, which maintains information about ongoing communications and bandwidth utilization. In the case of a communications loss, the MocketStatusMonitor receives an event identifying the two nodes that are unable to communicate. This information is relayed to the Coordinator, which can then react to try and restore communications. The Coordinator examines other movable nodes that can be repositioned to try and provide a communications relay. The nodes are selected based on policies as well as current tasking of the nodes. Once a node has been identified, the node is requested to move to the midpoint (or as close as possible) of the two nodes that are unable to communicate Metrics The overall goal of agile computing is to improve performance in dynamic environments by being opportunistic. The degree of agility is a measure of the ability to quickly adapt to a changing environment. The following three factors can be used to determine the degree of agility: 1. The delay between a new node becoming available (or reachable) and the resources of the node being utilized 2. The length of time for which a new node must be available in order to obtain an increase in overall performance 3. The length of time required to release a node so that the node may return to its initial state Figure 6 shows the stages that the infrastructure goes through when a resource becomes available. The duration of time for which the resource is actually available is t 4 t 0. Initially, the infrastructure goes through a discovery phase (from t 0 to t 1 ), when the availability of the resource becomes known. Then, the infrastructure needs to setup the new resource for use, which takes time from t 1 to t 2. Setup includes such activities as pushing new code to the new system and/or migrating computations to the new system. 14

17 Figure 6: The Different Phases of Resource Utilization Once the setup process is complete, the new resource is fruitfully utilized by the infrastructure. This time is represented from t 2 to t 3. This is the actual length of time during which the new resource is being productively utilized. Before the resource becomes unavailable, the infrastructure goes through a preparation phase, which typically involves moving computations out of the resource about to go offline. This phase takes time from t 3 to t 4. Once the resource disappears, the infrastructure goes through a recovery phase (from t 4 to t 5 ). This recovery phase might involve activities such as finding other systems to distribute the computations that were removed from the resource that went offline. In an ideal environment, the discovery, setup, preparation, and recovery times would be 0. The goal of the agile computing approach is to try and minimize these times as much as possible. Another interesting tradeoff involves preparation time versus recovery time. The expectation is that they are inversely proportional. That is, the greater the preparation time, the lesser the recovery time. For a system to be highly survivable, the required time to prepare should be as close to 0 as possible. The first factor time between resource availability to resource utilization measures the reactivity of the system and primarily involves the group manager and the service deployment mechanism. The second factor the length of time for which a resource needs to be available to improve performance measures the overhead of the system in taking advantage of the resource. This primarily involves the coordination and service migration mechanisms. The last factor the length of time to restore a node to its initial state is important given the opportunistic nature of agile computing. Since resources may be used for purposes other than originally intended, it is important to minimize the release time, or the time required for the system to stop using a resource so that it may return to its original function. In addition to measuring the degree of agility, a set of experiments will be used to measure the overall performance improvement of agile computing in a service-oriented architecture. Measures will include service availability, response time, and load distribution. 15

18 1.1.6 Demonstration and Evaluation The proposed research entails designing, implementing, and evaluating the agile computing middleware. The components of the system will be developed in a combination of Java and C++ and will initially be targeted to PC-based systems running either Windows XP or Linux operating systems. The underlying networking infrastructure will be based wireless communications. Three different demonstrations will be performed as part of this effort at 6, 12, and 18 months into the project. The 6-month demonstration will show the basic capabilities of dynamically defining, instantiating, and invoking services in the agile computing middleware. The 12-month demonstration will show the data dissemination and distributed predicate processing capability. Finally, the 18-month demonstration will show the continuous optimization and proactive manipulation in the context of both service invocation and in data dissemination. Air Force relevant scenarios will be developed in conjunction with AFRL for the demonstrations. 1.2 Technical Program Summary The agile computing middleware has been successfully used in the context of communications and in the context of hierarchical data distribution. The goal of the proposed research is to enhance the middleware to support service-oriented architectures and to handle distributed data dissemination and predicate processing. These goals will be achieved through the following steps:! Design and implement APIs for service definition, instantiation, invocation, and relocation. These APIs will allow applications to register and invoke services as part of the agile computing middleware.! Design and implement mechanisms to measure resource utilization by services and monitor service invocation patterns by clients.! Develop measures and design heuristics to manage the instances of services and the mapping of invocations to instances.! Interface with a COI definition in order to obtain information about minimum service level requirements.! Extend the Group Manager to support service and data provider discovery.! Integrate service discovery with underlying networking infrastructure.! Extend FlexFeed to support efficient data dissemination and distributed predicate processing.! Integrate connection-loss detection mechanism in Mockets with service invocation. 16

19 ! Implement mechanism to detect loss of data providers.! Extend coordination algorithm to manage node placement to address communication needs. 1.3 Risk Analysis and Alternatives The first risk in the proposed research is related to the Aroma Virtual Machine component. The Aroma VM has been internally developed at IHMC and is a Java-compatible VM that provides two important capabilities state capture and resource control. However, Aroma does not provide a Just-in-Time compiler, making its performance much slower than commercial Java VMs. If the performance of Aroma is inadequate, then the alternative is to use a standard Java VM. The first implication would be that an alternate mechanism will need to be developed to migrate services. This is possible but will require some alteration of the code that implements the service in order to respond to a request to move. The second implication is that the resource control capabilities would not be available. The alternative is to use a different resource management framework such as JRaf2 [11]. We are currently working with the researchers involved in JRaf2 and are integrating a prototype of the JRaf2 framework into our system, so this should not be a problem. The second risk in the proposed research is the assumption about the wireless networking infrastructure and the IP protocols. If the underlying networking infrastructure is built upon different standards (for example, the Joint Tactical Radio System), then the communications mechanisms, the group manager, and the integration with the ad-hoc networking layer will need to be adapted. The third risk area is scalability of the agile computing approach (and in particular, the coordination components). The current middleware has been deployed in environments containing less than 25 nodes. As the number of nodes increase, so does the coordination overhead. Zone-based coordination appears to be the best solution to address this problem. The fourth and final risk area is related to the standards (such as SOAP, UDDI, DDS, etc.) that are in existence and currently applied to service-oriented architectures. These standards, if strictly followed, may impose limitations on the capabilities of the agile computing middleware. For example, the standard Web Services invocation model is request-reply, which is not very efficient for publish-subscribe systems. Similarly, the standard encoding for SOAP is XML, which is verbose and bandwidth intensive. These standards need to be carefully evaluated in the context of dynamic military environments and any shortcomings should be addressed. 17