QoS Aspect Languages and Their Runtime Integration Joseph P. Loyall, David E. Bakken, Richard E. Schantz, John A. Zinky, David A. Karr, Rodrigo Vanegas, and Kenneth R. Anderson BBN Technologies/GTE Internetworking, Cambridge, MA 02138, USA
fjloyall, dbakken, schantz, jzinky, vanegas, dkarr,
[email protected] http://www.dist-systems/bbn/com
Abstract. Distributed object middleware, such as CORBA, hides systemand network-speci c characteristics of objects behind functional interface speci cations. This simpli es development and maintenance of distributed objects, contributing to their growing acceptance. Critical applications have Quality of Service (QoS) requirements, however, such as real-time performance, dependability, or security, that are hidden by middleware. Because of this, application developers often bypass distributed object systems, thus gaining little or no advantage from the middleware. We have developed Quality Objects (QuO), a framework for developing distributed applications with QoS requirements. QuO provides a set of aspect languages, called Quality Description Languages (QDL), for specifying possible QoS states, the system resources and mechanisms for measuring and controlling QoS, and behavior for adapting to changing levels of available QoS at runtime. This paper describes QuO's aspect languages, their usage, and how they interact with the QuO runtime system to form the QuO framework.
1 Introduction Distributed object middleware, such as CORBA [5], hides system- and networkspeci c characteristics of objects behind Interface Description Language (IDL) speci cations, which describe how clients and objects interact functionally, i.e., the methods that can be invoked on an object and the types of data that can be exchanged. This simpli es development and maintenance by promoting abstract design, code reuse, and interoperability, and has contributed to the growth and acceptance of distributed object computing. However, many distributed applications have quality of service (QoS) requirements in addition to their functional requirements. Applications such as multimedia, video-on-demand, national security, military, health care, medical, and nancial systems often have critical requirements such as real-time performance, synchronization of data, security, and dependability. Current commercial distributed object middleware products fall short of supporting QoS requirements because they hide the details necessary to specify, measure, and control QoS and to adapt to changing levels of QoS. Because of this, developers of critical applications often nd themselves
programming around the distributed object abstraction and gaining little or no advantage from middleware. The problem gets worse as the number and diversity of distributed applications increase and as applications are distributed over wide-area networks (WANs), which are inherently more dynamic, unpredictable, and unreliable than LANs. We have developed Quality Objects (QuO) [7, 4], a framework for developing distributed applications with QoS requirements. QuO provides the ability to specify, monitor, and control aspects of the QoS in an application, and to adapt to changing levels of QoS at runtime. A major component of the QuO framework is a set of Quality Description Languages (QDL) for specifying possible QoS states, the system resources and mechanisms for measuring and providing QoS, and behavior for adapting to changes in QoS. This QoS speci cation, monitoring, and adaptation are aspects of the program that would normally have to be distributed throughout the program, cross-cutting the components and objects comprising the functional decomposition of the program. Because of this, the QuO framework and QDL represent an instance of aspect-oriented programming (AOP) [1]. AOP allows programmers to divide an application into both functional components and aspects, more global concerns that cross-cut the functional decomposition. QDL consists of aspect languages for describing aspects of a program related to QoS: providing it, monitoring it, and adapting to changing levels of it. In this paper, we describe QuO's aspect languages; how they are used to specify, measure, control, and adapt to QoS; and how they interact with the QuO runtime system to form the QuO framework.
2 Overview of Aspect-Oriented Programming In Aspect-Oriented Programming (AOP) [1], a program is divided into aspects of concern, each of which is programmed separately in a language suitable for expressing the particular aspect. The application is constructed by weaving the aspects together into a single, executable application using code generators. Aspectual decomposition is di erent from, but complementary to, functional decomposition. In functional decomposition, problems are divided into procedures, objects, modules, etc., each of which is programmed to hide its implementation and expose its functional interface. Each functional module is usually compiled into a speci c section of code in the application's executable code. In contrast, aspectual decomposition divides a problem into aspects, i.e., global concerns that cut across functional module boundaries, such as distribution, synchronization, or security. The executable code that deals with each of these aspects does not exist in a speci c section, but occurs throughout the application's executable code. Traditionally, programmers would pepper code throughout each module to satisfy each aspect, until the modules become tangled with concerns. AOP avoids the \tangling of concerns" phenomenon [1] by providing abstractions that correspond to the di erent aspects. AOP allows programmers to divide an application into both function components and aspects.
Code generators, called weavers, distribute the aspect code into the proper places throughout the application. QuO provides an example of aspect-oriented programming. QuO allows an application developer to specify the aspects of QoS contracts, system state monitoring and control, alternate implementations, and adaptation strategies which would traditionally be interleaved throughout a critical application. QuO's code generators weave these together into a single application.
3 Overview of QuO QuO is a framework supporting the development of distributed applications with QoS requirements. QuO provides the ability to specify, monitor, and control aspects of the QoS in an application, similar to the way in which application code and IDL, ORBs, and operating systems specify, monitor, and control the functional behavior. We give a brief overview of QuO in this section. More detailed discussion can be found in [7].
3.1 Execution model of a QuO application In a traditional CORBA application, a client makes a method call on a remote object through its functional interface. The call is processed by an ORB proxy on the client's host, which marshals the clients data, and passes it to an ORB on the client's host. The ORB delivers the call to an ORB on the object's host, where an ORB proxy unmarshals the data and delivers it to the remote object. The client sees it strictly as a functional method call.
Logical Method Call
Client SysCond
Delegate
Object Developer
Contract
QoS
SysCond
SysCond SysCond
ORB Proxy
Application
SysCond Contra ct
SysCond
Delegate Developer
SysCond
Mechanism/Property Manager
Specialized ORB
ORB Proxy
Specialized ORB
Middleware Mechanism Developer
Network
Client
Network
Server
Fig. 1. A remote method invocation in a QuO application
As indicated in Figure 1, a QuO application adds additional steps to this process. In addition to the client program, ORB, and remote object (all components of a CORBA application), a QuO application adds the following components:
Contracts, which specify the level of service desired by a client, the level of service an object expects to provide, operating regions indicating possible measured QoS, and actions to take when the level of QoS changes. Delegates, which act as local wrappers for remote objects. Each delegate provides an interface identical to that of its remote object, but provides locally adaptive behavior based upon the current state of QoS in the system. System condition objects, which link QuO contracts to resources, mechanisms, objects, and ORBs in the system. These allow QuO to measure and control QoS.
QuO applications also include property managers, mechanisms, specialized ORBs, and ORB wrappers that provide non-functional (i.e., QoS-related) capabilities. QuO replaces the bind function provided by many CORBA ORBs with connect. When a client calls connect to bind to a remote object, QuO instantiates the appropriate delegate and contract, and hooks up the client, delegate, contract, system condition objects, and ORB proxy. Figure 2 illustrates the steps that can occur during a remote method call in a QuO application. When a client calls a remote method, the call is passed to the object's local delegate instead (1). This is transparent to the client, since the remote object and the delegate have the same interface. The delegate can trigger contract evaluation (2), which grabs the current value of all system conditions (3) measuring aspects of the system's state. The contract consists of a set of nested regions which describe the relevant possible states of QoS in the system. Each of these regions is de ned by a predicate on the values of system condition objects. The contract evaluates the predicates to determine which regions are active (i.e., their predicates are true) and passes the list to the delegate (4). The delegate chooses how to process the method call based upon the current regions (5). For example, the delegate might choose between alternate methods, might bu er the call, or might simply pass the call through to the remote object. Upon a method return (6), the delegate can evaluate the contract to obtain the current QoS regions and select a behavior based upon the current regions. The delegate nally returns control to the client (8), passing back any return values, out, and inout parameters. Contract evaluation can also be triggered by changes in some system condition objects, i.e., those that are observed by the contract (7). Other system condition objects, especially those whose values change frequently, are non-observed and do not trigger contract evaluation. Regardless of how contract evaluation is triggered (by a method call/return or change in a system condition), a transition from one active region to another can trigger transition behavior, which consists of client callbacks or method calls on system condition objects.
Client Functional Code Method call 1
8 7
Contract
4 7
3 73 Syscond
Delegate
6
6
Callback
QuO Kernel 2
5
QoS requirement
7
Mechanism
Syscond Manager
ORB Network ORB Object
Fig. 2. Example remote method call in a QuO application
3.2 The QuO Toolkit for building QuO Applications
As indicated in Figure 1, the development of QuO applications requires an additional role over those necessary to build a distributed application: Application developers who develop functional code for the clients and distributed objects; QoS developers who develop QuO contracts, system condition objects, callback mechanisms, and object delegate behavior; and Mechanism developers who develop system components, ORB wrappers, mechanisms, and libraries providing access to or control of system- or ORBlevel capabilities. To support the added role of QoS developer, we are developing a QuO toolkit, which consists of the following components: A suite of Quality Description Languages (QDL) for describing contracts, system condition objects, and the adaptive behavior of objects and delegates The QuO kernel, which coordinates evaluation of contracts and monitoring of system condition objects Code generators which weave together QDL descriptions, the QuO kernel code, and client code to produce a single application program. The QuO kernel and runtime system are described in detail in [15].
4 The QuO Aspect Languages and Code Generators QuO currently provides two aspect languages, collectively called Quality Description Languages (QDL): a Contract Description Language (CDL) and a Structure
Description Language (SDL). CDL is used to describe the QoS contract between a client and an object. This includes the QoS that the client desires from the object; the QoS that the object expects to provide; regions of possible levels of QoS; system conditions that need to be monitored; and behavior to invoke when client desires, object expectations, or actual QoS conditions change. CDL is described in detail in [4]. SDL describes the structural aspects of the QuO application. This includes the implementation alternatives of remote object, including alternate implementations (i.e., object instances) of IDL interfaces and alternate methods on speci c objects, their tradeo s, and characteristics. It also includes the local adaptive behavior of object delegates and binding and connection strategies. We are also currently designing a third aspect language, the Resource Description Language (RDL). RDL will describe available system resources and their status. Figure 3 illustrates the QDL aspect languages and how the QuO code generators weave them together to create QuO applications. We currently have parsers and code generators for IDL, CDL, and SDL. The code generators generate Java code for the following:
contract classes connection code that creates or locates the appropriate contract instances, delegates, and system condition objects, and hooks them up code that is woven into the QuO runtime code for triggering and performing contract evaluation, grabbing the values of system condition objects, etc.
In addition, the code generators generate code for both client-side and serverside object delegate code. They generate delegates written in both Java and C++ code, to interface to client code written in either of these languages.
4.1 Contract Description Language (CDL) CDL is a language for specifying a QoS contract between a client and object in an application. The contract describes the QoS that the client desires and that the object expects to provide in terms of a set of operating regions; behavior to invoke to adapt to or notify of changes in QoS; and interfaces to elements of the system that can be used to measure and control QoS. In this section we brie y describe CDL, by example. A more complete discussion of CDL, including its syntax and semantics, is provided in [4].
Elements of a CDL contract. A QuO contract consists of the following:
a set of nested operating regions, each representing a possible state of QoS. Each region has a predicate indicating whether it is active (the predicate is true) or not (the predicate is false). transitions for each level of regions, specifying behavior to trigger when the active region changes.
references to system condition objects for measuring and controlling QoS. These are either passed in as parameters to the contract or declared local to the contract. System condition objects are used in the predicates of regions to get values of system resources, object or client state, etc. and used in transitions to access QoS controls and mechanisms. callbacks for notifying the client or object. Callbacks are passed in as parameters to the contract and are used in transitions. typedef sequence LongSeq; CORBA IDL interface Targeting { long calculate_distance_to_target(in long xcoord, in long ycoord); long identify_target(in long xcoord, in long ycoord); };
delegate behavior for Targeting and repl_contract is obj : bind Targeting with name SingleTargetingObject; group : bind Targeting with characteristics { Replicated = True }; call calculate_distance_to_target : region Available.Normal : pass to group; region Low_Cost.Normal : pass to obj; region Available.TooLow : throw AvailabilityDegraded; return calculate_distance_to_target : pass_through; default : pass_through end delegate behavior;
Code Code Generators Generators SDL
contract Replication( object client, object server ) is ... negotiated regions are region Low_Cost : ... region Available : when client.expectations.requested > 1 => reality regions are region Too_Low : when measured region Normal : when measured > 1 => transitions are transition any->Too_Low : client.callbacks.availability_degraded(); transition any->Normal : client.callbacks.availability_back_to_normal(); ... transitions are ... end Replication;
Delegate
Contract
QuO QuORuntime Runtime
CDL
Fig. 3. The QuO code generators The contract organizes the possible states of QoS, the information needed to monitor and control it, the actions to take when QoS changes, and the times at which information is available. The nesting of regions can be used to arrange regions according to logical groupings of information or time. For example, the contract in Figure 3 contains two sets of nested regions, an outer nesting called negotiated regions and an inner nesting called reality regions. The negotiated regions represent the QoS desired by the client and the QoS that the remote object expects to provide and their predicates consist of system condition objects that interface to the client and object. The reality regions represent the QoS measured in the system and have predicates consisting of system condition objects that interface to system resources. This grouping distinguishes the QoS associated with operating modes of the client and object, which will likely change infrequently, from the measured QoS of the system, which will probably change more frequently.
A programmer programs a contract class in CDL. At runtime, a connection between a client and an object is established, creating an object delegate instance, and creating a contract instance and passing in pointers to the client's expectations, client's callbacks, and any other necessary system condition objects or callbacks. Any system condition objects local to the contract instance are created and connected to the contract instance. contract Replication( syscond ValueSC ValueSCImpl ClientExpectedReplicas, callback AvailCB ClientCallback, syscond ValueSC ValueSCImpl MeasuredNumberReplicas, syscond ReplSC ReplSCImpl ReplMgr ) is negotiated regions are region Low Cost : when ClientExpectedReplicas == 1 => reality regions are region Low : when MeasuredNumberReplicas < 1 => region Normal : when MeasuredNumberReplicas == 1 => region High : when MeasuredNumberReplicas > 1 => transitions are transition any->Low : ClientCallback.availability degraded(); transition any->Normal : ClientCallback.availability back to normal(); transition any->High : ClientCallback.resources being wasted(); end transitions; end reality regions; region Available : when ClientExpectedReplicas >= 2 => reality regions are region Low : when MeasuredNumberReplicas < ClientExpectedReplicas => region Normal : when MeasuredNumberReplicas >= ClientExpectedReplicas => transitions are transition any->Low : ClientCallback.availability degraded(); transition any->Normal : ClientCallback.availability back to normal(); end transitions; end reality regions; transitions are transition Low Cost->Available : ReplMgr.adjust degree of replication(ClientExpectedReplicas); transition Available->Low Cost : ReplMgr.adjust degree of replication(ClientExpectedReplicas); end transitions; end negotiated regions; end repl contract;
Fig. 4. A Sample CDL Contract - Replication
A simple CDL example contract. Figure 4 illustrates a sample CDL contract
with CDL keywords in boldface. This contract speci es and controls replication for a QuO application. The client has two operating modes, one in which it desires a high level of availability from the remote object and another in which it does not require the high level of availability and desires to use fewer resources. This contract is simple, the client either requests one replica (encoded as the Low Cost region) or more than one replica (encoded as the Available region). Each negotiated region has a set of reality regions, representing when the measured replication is lower than, higher than, or exactly as desired. The negotiated region predicates use the client's expectation system condition object, ClientExpectedReplicas. It is passed as an argument to the contract because it is probably shared by all the contracts in which the client is involved, and therefore must be created outside the contract. The reality region predicates use a system condition object called MeasuredNumberReplicas, which observes the actual number of replicas. The reality region transitions notify the client about changes in the number of replicas. The negotiated region transitions access mechanism routines to control the level of replication. A transition to either of the Low regions noti es the client via the callback method availability degraded. A transition to either of the Normal regions noti es the client via the callback method availability back to normal. The keyword any is used to indicate that the contract and client don't care in which region the transition originated. Callback behavior is speci ed in the callback code (probably in the client or a separate object). The negotiated region transitions use a replication policy manager system condition object, ReplMgr, that is passed into the contract. When the client changes its desired replication, causing a transition between negotiated regions, the method adjust degree of replication is called to suggest a new level of replication.
4.2 The Structure Description Language (SDL) SDL allows a QuO programmer to specify adaptation alternatives and strategies based upon the QoS measured in the system. Currently, SDL allows a program to specify behaviors to invoke for method calls and/or returns based upon the current regions of contracts when the calls or returns occur. Later versions of SDL will also allow QuO programmers to specify QuO connections, i.e., the contracts, delegates, system condition objects, remote objects, and clients that need to be created or located and how they are hooked together to create a QuO application.
Elements of an SDL description. An SDL description is essentially a large table, in textual form, associating method calls or returns with contract regions, and specifying behavior for each relevant association. It consists of the following:
a list of interfaces and contracts for which the SDL description is specifying adaptive behavior a list of method calls and/or returns, each of which must be a method on one of the interfaces. These are the method calls and returns for which the QuO programmer wants to specify adaptive behavior inside each method call and return, a list of contract regions, each of which is a region on one of the contracts listed above. These represent the states of QoS that can trigger the adaptive behavior for method calls and returns. inside each method and contract region association, a behavior speci cation. The speci ed behavior can choose between alternate object bindings, choose between alternate methods on an object, create new bindings, throw an exception, or execute a section of code. default behavior speci cations. These can be speci ed within a method call or return speci cation, to be used for that method call or return and any other contract regions not enumerated. A default behavior can also be speci ed to be used for any method calls that aren't explicitly listed.
The code generator creates a delegate for each interface in the SDL description. Each delegate acts as a local wrapper around a remote object and presents an interface to the client with the same methods and argument types as are compiled from the remote object's IDL interface. However, it also generates two dispatch statements, i.e., switch statements in Java and C++, within each method, one for the call and one for the return. The dispatch statement checks the current regions of the relevant contracts and dispatches the proper behavior. The code inside each case of the dispatch statement is generated from the behavior speci cations in the SDL description. interface Targeting f long calculate distance to target(long x, long y); g;
Fig. 5. Simple IDL for a targeting interface
A simple SDL example. As an example, consider the SDL description in
Figure 6. This is a simple SDL description with only one interface, Targeting, speci ed in Figure 5, and one contract, Replication, speci ed in Figure 4. This SDL description creates two bindings for the delegate, one to a speci c object (known by a CORBA name server as SingleTargetObject) and a second to a replicated object group, i.e., an object tagged with the characteristic that it is replicated. Since these bindings are speci ed at the beginning of the SDL description, i.e., before the behavior table, they are established upon delegate creation. That is, the delegate code generated by the code generator will establish
delegate behavior for Targeting and Replication is obj : bind Targeting with name SingleTargetingObject; group : bind Targeting with characteristics f Replicated = True g; call calculate distance to target : region Available.Normal : pass to group; region Low Cost.Normal : pass to obj; region Available.Low : throw AvailabilityDegraded; default : pass to obj; return calculate distance to target : pass through; default : pass to obj; end delegate behavior;
Fig. 6. SDL that chooses between replicated and non-replicated server objects these bindings upon creation and initialization of the delegate. As described below, the SDL language also permits dynamic binding to objects. Following the binding section is the behavior table, arranged as a list of method calls and returns, with region names nested inside them, nally with behavior descriptions nested inside them. The SDL description in Figure 6 essentially chooses between sending a remote method call to a single object or to an object group based upon whether the client desires and is getting availability through object replication. When the calculate distance to target method is called, the delegate checks the Replication contract and chooses one of the following behaviors:
When the client desires availability and is receiving it, i.e., the contract is in the Available negotiated region and the Normal reality region, the method call is passed to the object group When the client does not desire availability and everything is okay, i.e., the contract is in the Low Cost negotiated region and the Normal reality region, the method call is passed to the object When the client desires higher availability than what is measured, i.e., the contract is in the Available negotiated region and the Low reality region, the delegate chooses to throw an exception. This can save the cost of a remote method call when the measured QoS indicates the call is likely to fail or the client needs to be noti ed immediately of an exception. When the method returns, any value returned is passed through to the client. For all other method calls, i.e., the default behavior, the delegate will pass the method call through to the corresponding method on obj.
Overview of SDL features and semantics. Structure descriptions written
in SDL have the following form:
delegate behavior for interfaces interface list and contracts contract list is
local variable declarations adaptive behavior descriptions default behavior description
end delegate behavior;
The header speci es the interfaces for which delegates need to be generated and the contracts that determine their behaviors. The code generated from SDL code builds a delegate object for each interface in interface list, containing a dispatch statement for the regions in each contract in contract list. The next section, i.e., local variable declarations, contains a list of statements binding local variables to remote objects. The current version of SDL allows a delegate to bind to remote objects by interface type, by name, or by QoS characteristics. Bindings in the declaration section of an SDL description, as illustrated in Figure 6, are established when a delegate is created and initialized. In the behavior description parts of the SDL description, the variables can be used to refer to the local objects. The variables can be rebound in the behavior descriptions. The adaptive behavior descriptions section describes the dispatch statements for the generated delegates. It takes one of the following forms: call method name : region behavior list default behavior return method name : region behavior list default behavior
The rst form speci es the behavior to perform when a client calls a remote method. The second speci es the behavior to perform upon the return from a remote method call. The method name can be simply the name of a unique method in one of the interfaces or can be an interface name followed by a method on that interface. The region behavior list is a list of contract regions, inside of each is nested a behavior speci cation. Each element of region behavior list is of the following form: region
region name
:
behavior statement list
The region name is the name of a unique region in one of the contracts or the name of a contract followed by the name of a region in that contract. The default behavior statement above is simply the keyword default: followed by a behavior statement list. A behavior statement list is a list of alternative behaviors. SDL currently supports the following speci cations of behavior in a behavior statement list:
Choosing between methods and/or remote objects. The delegate uses SDL's pass primitive to pass the method call through to any method on any remote object to which the delegate is bound. This statement is one of the following forms: pass to var; pass to var.method; pass to method; pass through;
If var is speci ed, the delegate passes the method call through to the remote object to which var is bound (var must be bound in the declaration section). If var.method is speci ed, the method call is still passed to the remote object bound to var, but to the alternate method method, which must currently take the same number and type of arguments as the original method. The third and fourth forms of the pass statement are only meaningful if the delegate has a binding to only one remote object. The pass through statement passes the method call to the corresponding method on the remote object. The pass to method passes the call to the alternate method on the remote object. If the delegate has bindings to more than one remote object (i.e., either the delegate header speci es more than one interface type or there are binding statements in the local variable declarations section), the semantics of the third and fourth forms are unde ned. Throwing an exception. A statement of the form throw exception; can be used to throw an exception without making a remote call. Breaking and/or establishing a binding to a remote object. The delegate can choose to rebind any of its bindings or establish a new binding in order to try and improve QoS, access a service previously not available, etc. The following statement speci es this: rebind [var] [exclusive] [to iface] [with name name | with characteristics ch list]; This rebind statement breaks and/or establishes bindings to objects at runtime by interface type, by name, or by QoS characteristics. Using this feature, a remote connection that is not satisfying its expected QoS can be broken and reestablished with di erent mechanisms, a di erent object, or a di erent implementation of an interface. The optional keyword exclusive tells the QuO runtime to rebind to an object di erent from the current binding. Without the exclusive keyword, the QuO runtime is free to bind again to the same object, providing it has the speci ed interface (iface), name (name), or characteristics (ch list). The characteristics are currently speci ed by a list of keyword/value pairs, as illustrated in Figure 6. The list can use any relative operator, e.g., < or
