Framework Semantic for Rudder Middleware Infrastructure
Zhen Li The Applied Software Systems Laboratory Rutgers University Email: [e-mail]
Abstract
Rudder is a generative agent-based middleware with intelligent deductive capabilities and effective coordination services for Grid autonomic applications. It provides a coordination environment to develop and enable self-managing systems, adopting multi-agent based management and reactive tuple space coordination technology. Rudder employs context-aware agent mechanism and tuple space coordination technology to enable system context and self awareness, monitor and analyze, police denition and distributed execution. This paper provides the semantic framework for Rudder operational semantics and system behavior, in which the reactive tuple space is considered as fucus design abstraction. The goal of the framework is to provide a precise specication of the system transition and run time state to help understand the system design and implementation, opening the possibility of using verication techniques to analysis the system run time behavior.
1 Introduction
Computing and communication capabilities are becoming increasingly pervasive and autonomic, the next generation software and hardware components will live in a fully connected world,interacting with each other and inuenced by their execution environment. Far from considering the underlying infrastructure as a raw communication media or a global information repository, it can be exploited as a globally distributed computing system where any kind of computation on distributed data and coordination among distributed entities can be performed. The structures and behaviors of software systems composed from these autonomic entities will be complex and highly dynamic,these systems strive for self-management with respect to the areas of system conguration, protection, healing, optimization, and open to new components that are unknown beforehand. Composing and managing these applications requires the underlying infrastructure to provide effective management and environment to make the heterogeneous entities (computation services and information resources) to harmoniously interact. A promising approach is to provide a middelware layer, which advocates deductive abilities over the component internal behavior and their interactions to achieve self-adaptiveness to the changing environment using system knowledge. Autonomous agents with the ability of problem solving, rationality, reactivity, self-adjusting organization in complex environment are clearly welcome. However, effective coordination manner is required to support agent communication and interaction as well as harmoniously integrate the individual agent work into larger meaningful whole system behavior. An innovation is to exploit a high-level middleware to provide a powerful solution to the coordination on the communication infrastructure. Recently many projects and commercial products have adopted this method to extend the tuple space coordination model to coordination infrastructure to integrate computation services and resources into applications dealing with the dynamism, heterogeneity and
complexity of the computing environments, as exemplied by JavaSpace [18], TSpaces [20], Lime [22], and Tota [21]. Tuple space coordination model origins from Linda, in which the tuple space is a shared message store exploiting the generative communication [8], which is based on the following principles: (i). Asynchronous communication which decouples senders and receivers in space and time. A inserted tuple will exist independently in the tuple space until it is explicitly removed by a receiver and the tuples are equally accessible to all receivers but bound to none. (ii). A associative multi-cast medium. Multiple receivers can read a tuple written by a single sender using with a pattern-matching mechanism instead of location and producer. (iii). The interfaces provided by tuple spaces are very simple, which only require the operations to write, read, and remove tuples. Using these qualities, tuple space paradigm can provide ad-hoc and scalable collaboration environment for the participants, in which joiners do not have to discover or connect to the participants. Reactivity stems from embodying computational capacity within the coordination medium to let it issue specic programmable reactions[9]. No longer as a mere message repository with the stateless associative mechanism in Linda, the tuple space has its own states and programmable behaviors as specic reactions to access events and add side effects to the operation semantics. Reactive model makes the generative coordination medium dynamically extensible while keeping the semantics of the basic communication primitives untouched. For example, local policies can be implemented as reactions to achieve specic access control and defend the system integrity from undesired malicious operations. Separating concerns between algorithmic and coordination issues [10, 11, 12] by allowing the specication of coordination rules as high-level directives makes the reactive tuple space model an effectively coordination mechanism. Rudder [2] middleware for Grid autonomic applications provides a generative coordination architecture adopting multi-agent based management and reactive tuple space coordination technology. The goal of this research work is to precisely dene the operation semantics of Rudder and promote the prototype implementation and application design. The remainder of this paper is organized as follows. Section 2 discusses the related work and motivation. An overview of Rudder is presented in section 3. Section 4 is devoted to present and explain the informal semantic framework. Section 5 denes the formalized framework. Finally, conclusion and future work are described in section 6.
2 Related Work and Motivation
A coordinated system is dened as a collection of coordinated entities interacting in the coordination space [1]. The semantics of a coordination model has been dened by different approaches without a common criteria. Coordination models shape the space for the coordinated entities to interact with each other by providing coordination media, coordination language and communication protocols. Coordination models have been traditionally formalized using process algebra by well-known works such as [13] [14], in which different entities and abstractions involved in coordination process are given a uniform representation as terms of the algebra, such as CCS [4] and calculus [6]. Evolution of a coordinated system is described by means of a structural operational semantics (SOS) [15], where the system is transited by execution of a coordination primitive. The viewpoint of coordination as a language is endorsed by these approaches. A coordination system S is modeled as composition of data item and agent A, simply denoted as E.1, E.2 and system evolutions are described by R.1,R.2 and R.3: A ::= 0|in(t).A|rd(t).A|out(t).A S ::= 0|A| t |(S||S) S||out(t).A S|| t |A (E.1) (E.2) (R.1)
S||rd(t).A|| t S|| t |A S||in(t).A|| t S||A
(R.2) (R.3)
Although this approach can effectively support the specication of coordination model in a simply way, it falls short in providing the suitable abstraction level to represent how the interactions act between the coordinated entities and medium. For example, the two steps of handling in primitives by sending a removal request and receiving a reply later can not be distinct in the above denition, in which only the reply is represented and the request is implicit. Differently, some recent work endorsing the viewpoint of coordination as a service [3] to satisfy the requirements of complex software system. The key idea is to separate the coordination entities, medium and interactions, promote the coordination medium as the rst-class abstraction in coordination model. A coordinated system is generalized represented by three separated spaces, the coordinated space, interaction space and coordination space, each with a design abstraction. In Rudder framework, the approach of coordination as a service is adopted and the three spaces are mapped to the actual computation, coordination, and communication design abstractions. The precise semantic specication is important for programming under the highly dynamistic environments, where the nondeterminism provoked by the variety interplays between the heterogenous components can lead to unexpected behaviors. The informal semantic specications can even lead to incorrect systems [5], it is necessary to provide a formal way to precisely describes Rudder architecture and clearly describe the run time coordinated system behaviors, and help the design, implementation and verication of coordination infrastructure correctness. Further, this formal semantic framework can provide the precise guide for implementations, as a tool to analyze the expressive power of the coordination primitives, opening the possibility of using verication techniques to analysis the system run time behavior.
3 Rudder Overview
Rudder [2], a multi-agent middleware for Grid autonomic applications, enhances the functionality of Linda with reactive behavior extensions provides the middleware services for AutoMate[19], which includes a contextaware agents framework together with a coordination model based on a global decentralized tuple space. The goal of Rudder is to harmoniously integrate the multiple individual autonomic component activities to the whole meaningful system behaviors adapting to the changing requirements and run time context. The architecture builds on two concepts: Software agents that can dynamically dene, deploy and execute rules to achieve their self-adaptive behaviors, operate within exible organizational structures while being situated in the dynamic environment context. Agents communicate, negotiate and coordinate with each other by associatively reading, writing or removing tuples using different pattern-matching algorithm, which suits well for Grid applications to discover and exchange information in the uncertain, dynamic and heterogeneous environment. A decentralized reactive tuple space can effectively and scalably supports the distributed agent coordination and enable the self-managing properties of the autonomic application. Besides the inherent highly uncoupled asynchronous communication character, reactive tuple space can support other typical paradigms such as publish/subscribe. Using this quality, it can provide a scalable ad-hoc collaboration environment for the heterogenous autonomic elements. The agent framework consists of three types agents. Component agents and system agent exist as system services, while composition agents are transient and are generated to satisfy specic application requirements. Each agent is identied by its unique id, which is used for keeping tracking of who issued requests and who will receive replies. This set varies according to activeness of passiveness the component agents and system agents,
transient generation of the composition agents. Component agents provide components with uniform access to middleware services and dynamically congure, deploy and control components. System agents monitor, schedule and adaptively optimize physical resource utilization. Agents communicate and coordinate using tuples, which are put to the tuple space by executing an out operation, retrieved by performing in destructive operation, and read by executing rd non-destructive primitive. Rudder employs self-adapting autonomous agents and tuple space based coordination to reect the adaptive strategies and policies to applications, while keeping the semantics of the basic communication primitives untouched. This architecture provides the core capabilities for supporting autonomic compositions, adaptations, and optimizations, effectively enabling the self-managing autonomic systems [2]. To dependable design and implementation of Rudder, the sematic frameworks for this middleware are presented in the following sections.
4 Rudder Semantic Framework
Endorsing the viewpoint of coordination as a service, Rudder architecture is separated into three spaces according to the design abstraction and described in terms of transition system. In this paper, we assume that only one global tuple space exists, the communication infrastructure is reliable and orderly (not to loose message and not change their delivery order).
4.1 Informal View
The whole system conguration is dened as three separated abstractions: the computation space, the communication space, and the coordination space which is the focus of this framework. The coordination infrastructure is described from the aspects of computation space including the agents as coordinated entities, reactive tuple space medium as coordination space abstraction, and the communication space. The system conguration evolves according to the execution of coordination primitives triggered by interaction events basically request and reply, which are mediated in communication space using messages. The semantics of coordination primitives associative to a set of corresponding events. For example, the in primitive asks the tuple space for a tuple matching the provided template. The semantics of this operation can be dened in terms of events: request for a tuple matching the template; reply from the tuple space containing the matched tuple. These event tuples span the three space, trigger the system transition.
4.2 Computation space
Rudder computation space includes the independent context-aware peer agents as coordinated entities, which carry computational activities participating in the coordination process by invoking the coordination primitives. The entities involved in the computation can freely work both in parallel (along the time dimension) and concurrency (along the space dimension). An agent is assumed to be a nite sequential single-thread and the agent computational activities are supposed to be always well formed with respect to the expected interaction protocol of primitives(e.g., situations like in.rd.0 never occurs). The synchronous nature of the primitive rd, in will cause the agent to block after sending the corresponding request and until a reply is provided. When an agent invoke a primitive, a request event is produced and will be consumed by the coordination space. Conversely, when a reply event occurs, an agent may consume it and carry on its computation. From the agent view: (i). The behavior of the reactive tuple space defaults to the Linda-like tuple space when the events bring no triggered reactions. (ii). The result of the invocation of the tuple space primitive is the sum of the effects of the primitive itself and of all the reactions it triggers, altogether perceived as a single-step transition of the tuple space state.
4.3 Coordination space
Rudder coordination space is assumed to be a global abstraction with dynamic programmable reactive behaviors. It can be fully programmed by administrators and peer agents to enable environment-specic and applicationspecic coordination, thus providing more secure and exible coordination activities. The coordination space is modeled as tuple space medium with reactions triggered by admissible reaction events. We assume the basic unit of reaction is atomically consumption of one event and reactively producing a multi-set of replying event, leaving the the case of reactions involving coordination with the agents as future work. And the actions triggered by an event is executed autonomically before serving any other events, so that the agent perceive the result of consuming the event and executing all the associated actions together as a single transition of the tuple space state. The associated matching mechanism is represented as a predicate associated to dene the subset of events to be consumed which triggers the reactive behavior. Tuple space is the global coordination medium providing the environment for the system. It is a logical shared associative memory used to contain multiple identical tuples without ordering. Far from as a raw communication media or a global information repository, Rudder extends tuple space model as the coordination infrastructure to separate agent coordination from computation, thus reducing the programming complexity. Tuple space provides the coordination services by emboding computational capacity, which can be dynamically programmable using the specic stateful reactive tuples. Tuple is the basic elements of information. A tuple in Rudder is an arbitrary XML document,which represents a set of self-described elds. To dene a eld type, one must dene this element in the correspondence DTD document. The order of the eld values passed as parameters to the XML element construction denes their ordering. Any eld of a tuple has either a dened actual or a wildcard value (formal). A template is similar to the tuple, but may contain wildcard and used only in input operations. A necessary part of a tuple is credential dened as attribute and not used for matching, to which standard security method can be used (e.g., role based access control), and the description in the examples are only used for illustration. A lease eld species how long the tuple will be available in the space. Reactive tuples are specic stateful tuples engaged in the ongoing interactions. A reactive tuple consists of Condition which associates the dened computations called Reactions to the triggering events, and Guard specifying the manner indicate to how and when the reactions will be executed (e.g.,enable, immediately, once), and treatment of possible failure that occur during the reaction execution. Notices the Reactions can be dened as outside computations which have no side-effects on the states of the reactive tuple. Matching The tuple pattern matching uses a basic textual comparison between the corresponding string based elds of tuple and template such that: (1) A template can contain formal values wild cards * and ? to match any value in the string eld, and the type can be dened by user in the same namespace/ontology of the interaction entities (2) The values of the dened elds in the tuple correspond to the values in the eld of the template. (3)The return of the matching function and the patten matching algorithms can be specied and extended (e.g.,1 or many, XQuery based matching). (4)The matching mechanisms can also be used for the reactive tuples considered as meta-level tuples enclosed in a logic separated tuple space. Primitives Tuple space provides primitives of out, in, rd, which are dened as following: out(t) an asynchronous operation that inserts tuple t to the tuple space. The executing process continues immediately. in(t) a synchronous operation that removes from the tuple space a tuple t matching template t the values of the actuals in t are assigned to the formulas in t, and the executing process continues. If many matching tuples found, only one of them is arbitrarily removed and returned with actual values assigned to the formal elds of that template. If there is not any matching tuple, the process waits for one to be appear. rd(t) searches and returns a matched tuple like in, but the tuple will not be removed from the tuple space.
We assume the non-blocking out primitive with unordered semantics and the tuple (message) will be eventually materialized in actual data. The execution of out causes some pending request (rd, in) receive it, however which one is non-determinately. Blocking rd primitive with semantics is executed only when t actually occurs in the space, then the process can carry on. Blocking in has the similar semantics, however the tuple t will be removed when the tuple actually dropped from the space. Besides the necessary arguments dened above (e.g. in needs a provided template), more arguments can be extended without affecting the basic dened semantics.
4.4 Communication space
The communication space materializes the coordination requests and replies performed by the agents and tuple space into communication messages. The request produces the messages using send and consumes the messages using recv. The underlying communication infrastructure is reliable (without loosing messages, failures, and preserve the message delivery order). The events from the coordination space are intercepted by the communication space that actually produces messages raise pending request in the communication space and will be orderly processed later. For each singlethread agent, a queue is assigned for processing its requests. Invoking the non-blocking out, a request will be added to the queue and unordered stored in the tuple space. Issuing the blocking operation of rd or in, an pending request added to the queue and blocking for the reply with the matching tuple. However, which agent will receive the tuple is non-determinism.
5 Formal Framework
This paper will focus on the general formal specication of the coordination model instead of the implementation language syntax, such as XML based tuple structure. Details of computations will also be ignored, such as the autonomous behaviors of the context-aware agents, execution of the installed reactions inside the tuple space and message delivery of the communication infrastructure.
5.1 Notation
The following syntactic conventions are adopted in this paper. Given any set or multi-set X, let x range over X. Union of set is denoted by , union of multi-set is denoted by . || denotes parallel composition operator, 0 A is the zero of the structure, and denotes empty set. a A labelled transition system is denoted by a triple (X, Actx , { |a Actx }), where X is a set of states, Actx a is a set of observable atomic actions, labelled transition relation X X for every a Actx expressing the a state x can evolve into the state x by the execution of action a, denoted by x x .
5.2 Basic Semantics
A tuple space is a multi-set of tuples. T denotes tuples ranged over t, and T denotes the template tuples ranged over t, all of the tuples come from T = T T . t = (t1 , ..., t
(t) ), i
{1, ... (t)}ti T T
(R.4)
Correspondingly the basic matching predicate is dened by match(t, t) to formally express the fact that a tuple t matches a template t,iff t = t or substition t = t, denoted by match(t, t) and t denotes the associated substitution result., while match(t, t) is used if there is not a tuple matching t. Specically, in Rudder the basic matching of tuple t and a templatet satises the following denitions,
(t) = (t)
i I (type(ti ) i I (value(ti )
(R.1) (R.2) (R.3)
= type(ti )) (type(ti ) = f omal) = value(ti )) (value(ti ) = f omal)
Where (t) returns the cardinality of tuple or template, I = {1, ..., (t)}, and type(ti ) returns the type of the ith eld number i , and value(ti )returns the value of the ith eld. The matching is true iff R.1 the number of elds in the template must be equal to the number of elds in the tuple; R.2R.3 for every eld in the tuple, the type (value) of the eld must equal the corresponding eld in the template or the corresponding template eld is formal. t denotes the data item is actually materialized in tuple space. Primitives are denoted by O = {out(t), in(t), rd(t)}. Specically ?oAi (t) denotes the agent A with Id i invokes the primitive o on t, in which ? {, } denotes the direction, represents the request event to the tuple space, whereas denotes the successfully returning tuple t from tuple space (or failure of the operation). c Extending the matching to reactive tuples TR with condition c which describes how the reactive tuples associate to the triggering event, and the set of reactions R to be atomically executed. The match is generally dened to describe how the reactive tuples associate to the triggering event. Specically, if the condition of the reactive tuple is dened as ?oAi (t). The matching rules dened in R.1,R.2,R.3 should be applied to match(?oAi (t), tc ), R denoted as match(t, t). Rudder coordinated system conguration is represented by an explicitly composition of the three transition system states: (A, M, C), specifying the current states of the computational space, coordination space, and communication space and evolves with the three system transition.
5.3 Computation Space
A peer agent in the computational space are assumed to be a nite sequential single-thread performing the request operations o O, with O = {out(t), in(t), rd(t)}, agent process blocks only after invoking the primitives in(t), rd(t) until it gets positive reply ack (for there is no predicate queries inp and rdp, there is no need to consider negative reply). In the case of multi-threaded activities, the above constrains should be released (e.g., the agent can produce many requests, one for each thread and wait for all replies), and will be left for future work. a The behavior of each agent E.1can be understood as an interactive component (A, Acta , { |a Acta }), Acta = O {ack} with the actions of Acta identied by agent id. Each agent can interact with its environment by producing request event o through invoking the coordination primitives and eventually consuming the replies from the tuple space using ack. A ::= oAi .A| ack Ai .A|A + A (E.1) Acta .A denotes an agent that invokes the primitive of Acta then behaviors like A. And + denotes the nondeterministic choice and can be decided only be replies. We assume the agent are always well formed with respect to the expected interaction protocols of primitives, e.g., in(t).rd(t).0 never occurs, and the agent will not terminate after issuing in, rd, which will eventually be served. Clearly, the computation space are represented as a set of agent A A, denoted by A ::= 0|A|A||A (E.2)
Where 0 is an agent that can do nothing or inactive. The states of the computation space evolve as a transition a system denoted by (A, Acta , { |a Acta }), Acta = O {ack}, in which each A A evolves according to the following rules: o.A A
o
(R.1)
ack.A A ack.A + ack.B A ack.A + ack.B B
ack ack
ack
(R.2) (R.3) (R.4)
Rule R.1 describes the invocation of operations out, in, rd raise request o. In rule R.2 agents invoking the rd, in consume the reply event from tuple space using ack and then carry on. The non-determinism of which one consume the reply is dened in Rule R.3 R.4.
5.4 Coordination space
We assume that there is only one global coordination medium, the invoked primitives are orderly served and for each query rstly apply match and then match if needed. At a given time, the state of the tuple space is given by the multi-set of occurring tuples and the multi-set of pending requests denoted by W , while Ws W denotes the set of pending queries in W which can be satised by some tuple in T . Specically, if oAi t W , where o {in, rd} and t T satisfying match(t, t), then oAi t Ws . Similarly, R W denotes the triggered reactions be executed, where R( oAi t) represents the multi-set reactions by event oAi t which satises the match predicate. Particularly, ?oAi t if R(?oAi t) = , the behavior of the reactive tuple space default to the tuple space. m The global coordination medium represented by (M, Actm , { |m Actm }), where Actm = {oAi } {reactions}. The state of the coordination space is a nite composition of the materialized tuples t , pending queries Ws , and the multi-set of reactions R to be executed. M ::= W | R | t | M | M||M (E.1)
The transitions for each M Mare discussed in the following separately waiting (take events as input), speaking (return answers) and reacting (handle reaction execution) phrases according to the state of the Ws and R. If Ws = R = and o = out, M ||W M If Ws = R = and o {in, rd} M ||W M ||W
o i t
A
o i t
A
{t}||W ||R( oAi t)
(R.1)
{ oAi t}||R( oAi t)
(R.2)
Rule 5.4 denes the transition according to the out operation, which results in inserting the tuple t in M without changing W . Rule R.2 represents the transitions raised by rd, in resulting adding a new pending request into W without changing M . If Ws = , R ...