ࡱ> XZUVW@ ajbjbqq KPl$xxxxP,|xJRp@@@@k""" "R R R R R R R,ZT zV5R"g"k"""5Ru/@@',u/u/u/" @@Ru/:h"Ru/u/52N|#Qp43Sxx,P.#QJRJRP.BWu/BW#Qu/Implementing QoS-Adaptation in Coordination Artifacts by Enhancing Cougaar Multi-Agent Middleware John Zinky, Richard Shapiro, Sarah Siracuse, Todd Wright BBN Technologies jzinky@bbn.com, rshapiro@bbn.com, ssiracus@bbn.com, twright@bbn.com Abstract Coordination Artifacts are first-class software entities that encapsulate an abstract communication pattern either among Agents or between an Agent and its environment. By separating these Coordination Artifacts from Agent implementations, both are simplified and acquire a nearly parallel structure. Coordination Artifacts provide an ideal means for dealing with systemic issues, including survivability, allowing the remaining Agent code to focus solely on its domain/business logic. Coordination Artifacts can be implemented as a small set of extensions to the existing Cougaar Agent middleware. In this paper, we present a design for Coordination Artifacts and their implementation in Cougaar. 1. Introduction Coordination Artifacts (CAs) are first-class entities that encapsulate an abstract communication pattern either among Agents or between an Agent and its environment. They are designed to separate communication mechanisms from the domain-specific work of any given Agent[1, 2]. The new objects that encapsulate these communication patterns provide a clear locus for dealing with systemic issues such as security, reliability, and performance. In particular, a Coordination Artifacts inherent properties (specialization, encapsulation, malleability, and controllability [3]) provide the necessary support for handling adaptation to changes in Quality of Service (QoS) requirements or resource constraints. That is, Coordination Artifacts can be QoS-adaptive if they change their behavior to overcome resource constraints and meet QoS requirements. Because systemic concerns can be handled in the Coordination Artifacts, the remaining Agent code can restrict itself to domain issues. Domain logic can be represented in the Agent in the form of relationships among the states of the roles it plays in various Coordination Artifacts. Patterns in these relationships can then trigger domain data processing, i.e., purely procedural code executed locally. Coordination Artifacts have a similar logical level, but the data processing in this is distributed and must therefore be relatively simple. In this paper we describe an architecture and a working implementation of Coordination Artifacts that supports QoS-adaptive features. We show how Artifacts can adjust their behavior dynamically to meet QoS requirements within the constraints of the available resources, thereby improving survivability. We will use an existing Agent environment, the Cognitive Agent Architecture (Cougaar) [4], to illustrate the construction of Coordination Artifacts. Cougaar has many middleware services that can be combined in various ad hoc ways to implement Coordination-like behavior Artifacts, but has no direct support for Coordination Artifacts as such. We will present a set of extensions to Cougaar that provide that support in an organized way. The remainder of this paper is outlined as follows. Section 2 defines the key concepts of Coordination Artifacts, augmented by an overview of our extensions. Section 3 presents a useful duality of structure between Coordination Artifacts and Agents. Sections 4-6 describe our implementation of Coordination Artifacts, including an overview of the existing Cougaar architecture and a description of how it can be extended to support Coordination Artifacts. Section 7 looks at Coordination Artifacts from a life-cycle perspective, and examines the kinds of QoS-adaptation that can be added to each phase. Section 8 looks at Coordination Artifacts from the environmental perspective. The final four sections fill out the picture: an example (9), a brief analysis of the overhead introduced by CAs (10), related work (11), and conclusions (12). 2. Definition of the Coordination Artifact Coordination Artifacts are infrastructure abstractions that support Objective communications. As described in existing literature, Coordination Artifacts have these key features: specialization, encapsulation, malleability, and controllability -- features that are foreign (and sometime contrary) to Agents[3]. The most obvious embodiment of the notion of artifact for Agent coordination is represented by a dedicated abstraction, provided at design time by the coordination model, and enacted at runtime by the corresponding coordination infrastructure.[5] Coordination Artifacts are therefore first-class entities on a par with Agents. In the basic model, a Coordination Artifact is characterized by having (i) a set of interfaces which can be accessed by Agents (ii) a local shared state between the Coordination Artifact and an Agent (iii) a coordination behavior specification, in which to describe the artifacts formal behavior[3]. Figure 2 illustrates the structure of a Coordination Artifact. We extend this model slightly by assuming that Coordination Artifacts explicitly define a set Roles, where a Role is simply a well-defined interface to the Artifact. The notion of a Role makes the abstract conception of operating instructions more concrete: a client of a Coordination Artifact always plays a specific Role relative to that Artifact, which the client indicates when it binds to the Artifact. Clients, in other words, are Role Players. Each Role in any given Artifact can potentially be played by any number of clients. With this extension, the behavior of a Coordination Artifact can be described as consisting of actions affecting the shared state among its Roles. Borrowing some terminology, a Facet of a Coordination Artifact is the code that implements a single connection to a given Role, and a Receptacle is the clients interface to that facet.  Figure 2: Coordination Artifact Characteristics The primary advantage of treating Coordination Artifacts as first-class entities is that the instances provide an ideal site for dealing with systemic issues in communications. Extending Coordination Artifacts to make them QoS-adaptive enables them to react to the constraints imposed by the physical environment. This may require specializing a generic coordination pattern into a customized component. This context-specific Coordination Artifact uses specialized knowledge about the expected coordination behavior and run-time knowledge about the resource constraints to pick the best implementation strategy to meet the situation. In general, Coordination Artifacts are designed to operate across Agents to implement a specific systemic concern. This is analogous to a cross-cut in Aspect Oriented Programming. Just as an Aspect cross-cuts the dominant Object Oriented decomposition, so an Artifact cross-cuts the Agent decomposition of a society. The resulting advantages are likewise analogous to the advantages of dealing with system issues via AOP[6]. An Agent can use Coordination Artifacts to interact with other Agents or with the environment itself. As such, the Agent becomes a hub of activity for processing information presented to and extracted from Coordination Artifacts. The Agent does not have to worry about the mechanics of coordination, which allows it to concentrate on its domain processing. Figure 3 shows an Agents various Coordination Artifacts. 3. Dual Nature of Coordination Rules The introduction of Coordination Artifacts creates a duality within the society. Once the Artifacts coordination logic is abstracted from the Agent code, the Agents business/domain logic can also be described as actions affecting the shared state among its Roles. In this case, the Roles are those played by the Agent in each of the Artifacts to which it is connected. We refer to this abstract behavior as Coordination Rules. Both Coordination Artifacts and Agents therefore implement behavior that can be represented in Coordination Rules. The coordinating logic of an abstract set of Coordination Rules primarily involves dependencies between Roles and actions to be taken when particular collections of dependencies are active at any given time. Declarative rule languages are ideally suited to this form of expression. The use of a rule language has several advantages. First and foremost, rules expose the logical dependency structure much more clearly than a procedural language. They present sets of dependencies together instead of distributing them through procedural (if/then) statements. Also, the fact-based pattern matching used in rule systems does not, in general, care about the order in which facts are asserted. This relieves the programmer of a considerable bookkeeping chore when the exact order in which new information enters the system is not known a priori. Rule engines also have an intrinsic modularity that can be very useful in the context of dynamic adaptation: the behavior of a collection of Rules can be modified dynamically by adding Rules, without any need to modify existing ones. Finally, Rules have useful formal characteristics, although we have not take advantage of them to date: they can be modeled, analyzed offline, and used to generate efficient runtime code[7].  Figure 3 Agent Processing Data from Coordination Artifacts While a collection of Rules can do a good job at expressing coordination logic, Rules are not well suited to complex data processing, which is a significant part of an Agents workload as well. A selected Rule language must therefore interoperate easily with whichever conventional programming language is used for the raw processing. In the case of Cougaar, the rule language must be callable from and able to call into Java. In our prototype implementation, we use Jess[8] as our Coordination Rule language. In principle however, any suitable rule language would work. An example of this kind of interoperability between Jess and Java, in which abstract logic written in Jess can call out to data processing written in Java, can be seen in the example below in section 9. So far we have emphasized the structural similarities between two kinds of Coordination Rules, but there are important differences in their implementations. An Agent is a locally self-contained object. It might have to do arbitrarily complex domain processing, but all of this processing is co-resident. Agents do not, in general, have to worry about QoS requirements and other systemic issues for their internal data processing. Conversely, Coordination Artifacts are distributed entities. Data processing in a Coordination Artifact is relatively simple because this processing deals almost exclusively with data transfer and translation. At the same time, this processing is heavily affected by systemic issues, including quality of service concerns. The ability to adapt to changes in QoS requirements becomes increasingly important, not only to the effectiveness of the Artifact, but to its performance as the society scales to hundreds or thousands of Agents. These differences and similarities have some implications on the organization of Agent code when the infrastructure supports Coordination Artifacts. Agents will now primarily be designed as interrelated sets of coordinations among the various Roles they play. In Cougaar and other systems that use Blackboards, this in turn has implications for the Agents style of interaction with its Blackboard. The entities on the Blackboard can now be partitioned in fact-bases, with one fact-base per Role. The fundamental logic of any given Agent then becomes a collection of Rules that coordinate among the fact-bases representing Role-specific subsets of Blackboard entities. In other words, Agent logic becomes a matter of detecting patterns across multiple Roles and their associated Artifacts, and triggering domain specific actions based on those pattern matches. An example of this kind of coordination can be seen below. 4. Existing Cougaar Infrastructure Taking a step sideways, this section will review those parts of the Cougaar middleware infrastructure that can be used in the construction of Coordination Artifacts. The following section will describe more specifically how the architecture described above was realized in Cougaar. Cougaar has been used in the construction of large-scale distributed Agent-based systems[4, 9, 10]. Cougaar provides a comprehensive infrastructure for developing robust societies of distributed Agents, with support for security and scalability built in. Several kinds of components in Cougaar are useful as building blocks for Coordination Artifacts. More specifically, these include Blackboard-based data representation and message routers[6]. Cougaar Agents communicate via a publish-and-subscribe mechanism, implemented in each Agent as a membership-transactional Blackboard with predicate-based publish/subscribe semantics. Logically, the Blackboard is an arbitrary collection of objects. Communication Plugins called Logic Providers subscribe to the Blackboard and look for objects that should be transferred to other Agents Blackboards. Logic Providers come in many types, each with domain-specific behavior for moving objects between Blackboards. For example, a simple relay Logic Provider might merely copy an object to all Agents in a Community. The task/allocation Logic Provider will request an allocation from a remote Agent, and also predict the allocation before it officially arrives. This allows the allocation to be rescinded, allowing for recovery if either Agent fails. Logic providers use a Cougaar service called Message Transport Service (MTS) to send messages between Agents. The MTS takes care of all the communications details, and Logic Providers treat the MTS as a reliable message transport. The Metrics Service monitors the underlying computer, storage, and communication resources. For example when special network management support is available, the Metrics Service can determine whether a communication path is available to a remote Agent without sending test messages. The MTS adjusts the behavior of its protocols based on the resource constraints exposed by the Metrics Service. Cougaar is component-based middleware closely modeled on Java Beans Bean Context API[11]. It supports Service Oriented Architecture: in general; inter-component communication happens via services. The implementation of a service is provided by a Service Provider, which registers its services with a Service Broker at any level of the component hierarchy. Cougaar adds layers of insulation to this Service Oriented Architecture (SOA) in two ways. Binders between parent and child Components control which services are offered to the child, and in what form theyre offered. In addition, Service Proxies can be introduced between server and client objects. These proxies can be simple forwarders, or can implement arbitrarily complex adaptive behavior.  Figure 4: Cougaar Component Model QoS-adaptation happens at each component layer. For example, the Blackboard object can be tagged with a QoS requirement for a lifespan. If a Logic Provider cannot send a message to the remote Agent within the lifespan, the object is removed from the Blackboard and the message is flushed from the message transport. Cougaar infrastructure has many other components to help implement QoS-adaptation[9]. Some common examples follow. The Cougaar service discovery mechanism is a mechanism for finding an Agent that offers a service. Through service discovery, other services can be contracted upon the request of any Agent with access to the service. The distributed Yellow Pages Service (YP) in Cougaar helps to prevent bottlenecks and to balance workload. An Agents information can be contained in multiple YP Servers for retrieval later. The Metrics Service provides information regarding resource consumption and performance measures. The Metrics Service especially provides necessary systemic information to be used by the sensors in a QoS-adaptive Coordination Artifact, potentially initiating some level of control over its data Figure 4 shows how Plugins can be composed into an ad hoc Coordinations using these mechanisms. The Blackboard fulfills the function of the pool of facts for each Role. Blackboard objects can be tagged with a Role and a Community. This effectively partitions the Blackboard into pools associated with each logical Coordination. The Plugins convert the underlying infrastructure components from an SOA model into a Blackboard model. The infrastructure components interface to the non-Agent system, the physical environment, or other Agents. These components form a kind of connectionless Coordination, since they can be generated and removed dynamically, and they are not explicitly named. Ad hoc Coordinations of the kind described above have been shown to work in large control societies created for the Ultralog[10] system. The Ultralog project created control societies for managing the security and robustness of a large distributed logistics application, with over 1000 Agents running on over 100 hosts. In one of the evaluations of Ultralog, testers removed 45% of its computer and networking resources. Despite this loss, the control society was able to reconstruct the failed logistics society Agents, and the society continued to process the application. Part of the success of creating a robust logistics society was due to the use of the distributed Blackboard for communication between Agents[12]. While ad hoc Coordinatons can be made to work directly on existing Cougaar infrastructure, true Coordination Artifacts, with all the advantages they offer, require extensions. In the next section we will discuss what needs to be added to Cougaar to provide this support. 5. Extending Cougaar Infrastructure to Implement the Architecture In the previous section we looked at some parts of Cougaar that could be assembled into ad hoc Coordinations. Of course Coordinations constructed in this way are not first-class entities and do not realize all the potential that Artifacts have. To implement true Coordination Artifacts as a new layer of the Cougaar middleware turns out to be a surprisingly simple procedure. The architecture needs to touch the Cougaar infrastructure only at two points. First, we need a new service to register new Artifacts and find available ones in short, a Coordination Artifact Broker. Second, the facets of each Artifact need to translate between Blackboard objects and Rule-engine objects (Facts) in a coherent way (Figure 5). Implementing the Coordination Artifact Broker is obviously trivial. The second point touches at the heart of how Artifacts work in Cougaar: in a very real sense, the procedural code implementing the Facet classes for any given Artifact is all the Java code an Artifact developer needs to write (keeping in mind that the logic of the Coordination itself is expressed in a rule language like Jess). Figure 5: New and Existing Layers To support this form of development, Role Player entities, which in Cougaar are typically Plugins, use a formulaic body of code for each Blackboard execution cycle: allow each Facet (through its corresponding Receptacle) to deal with changes to the Blackboard (this would typically result in corresponding fact changes); run the rule engine (this could result in changes to another Players Blackboard); allow each Facet (through its Receptacle) to deal with new state of the fact set. Two general sorts of issues arise immediately. First, it is important to keep in mind that an Artifact instance is inherently a distributed object. A single conceptual Artifact is implemented as a collection of Java instances, one for each Agent that plays a role in it. This collection of Java instances is loosely coupled through Facets, and this distributed collection of Facets need to communicate with one another in a loosely coupled way. Cougaar Relays provide the support for this style of communication. Secondly, inheritance of Coordination Artifact classes introduces some wrinkles both in the inheritance of procedural code (Facet implementations in particular) and the inheritance of Rules. In general, the hierarchy of Coordination Artifact kinds has to be mirrored by a similar hierarchy of Facet kinds, although not all Artifact layers will introduce new Facet classes for every Role. Although somewhat inelegant, this presents no conceptual difficulties. In possible future developments we will consider generating skeleton code here. By convention, the Rules at any given layer should be grouped together in a file. The Artifact or Role Player can then load these files dynamically. Using Rule files in this way provides a simple from of multiple inheritance, although care must be taken with firing order. The ability to load any number of Rule files offers an opportunity for dynamic reconfiguration not unlike Aspects: newly loaded files of Rules can transparently modify existing behavior at the new layer. Other forms of cross-cutting can of course also be used at lower layers, through existing Cougaar mechanisms[6]. 6. Coordination Artifact Architecture In our current implementation of Coordination Artifacts, the top-level structure is isomorphic to Cougaars service-oriented-architecture (SOA) design: Coordination Artifacts are roughly analogous to Services in SOA. But unlike the generic Service interface, extensions of Coordination Artifacts (CAs) are used only to describe particular kinds of Artifacts, not in general to define extensions to the generic interface. In this sense Coordination Artifacts are also very roughly analogous to Components in the CORBA Component Model Coordination Artifact Providers describe entities that can find or make Coordination Artifacts of some particular kind. They are very similar to Service Providers in SOA. Coordination Artifact Brokers are registries for Coordination Artifact Providers. These registries are therefore very much like Service Brokers in SOA. In addition, the CA design defines three other generic interfaces of interest: Role Player: Any given Coordination Artifact kind (as managed by a Coordination Artifact Provider) defines a set of Roles, and any client that wishes to connect to an Artifact must specify which Role it intends to plays. All clients must therefore implement the Role Player interface, which describes callbacks that the CA might wish to invoke on a client, for instance to assert or retract facts. Receptacle: A Role Players access to a CA is mediated by an entity called a Receptacle, a term borrowed from the CORBA Component Model (CCM). A Receptacle is the Role Players perspective on the connection between it and some CA. Facet: The CAs access to a Role Player is mediated by an entity called a Facet, a term also borrowed from CCM. A Facet is the CAs perspective on the connection between it and some Role Player. Facets and Receptacles are always paired one to one. Facets are also the point at which inter-Agent communication occurs: a single conceptual Coordination Artifact is actually a distributed object, the pieces of which are linked together by Facets. The implication of this is that most of the real communications work of a Coordination Artifact is implemented in Facets.  Figure 5: Coordination Artifact Components The standard protocol for registering a new Coordination Artifact Provider would then be as follows (see Figure 5): - The Provider looks up the Coordination Artifact Broker as an SOA service and registers itself as being available for use. (Fig 5, 1) The standard protocol for requesting a connection to a Coordination Artifacts is: - A Role Player looks up the Coordination Artifact Broker as an SOA service and requests to play a particular Role in a particular Coordination Artifact, where the latter is described by a type name and some qualifiers, possibly including QoS qualifiers. (Fig 5, 2) - The Coordination Artifact Broker looks for a Provider that supports the given type. (Fig 5, 3) - That Provider looks for an existing Coordination Artifact that matches the qualifiers, or creates one if none exists yet. (Fig 5, 4) - The Coordination Artifact creates a Facet/Receptacle pair for the new connection and informs the Role Player of the Receptacle. (Fig 5, 5) - At this point the Role Player is free to assert facts into the CA though the Receptacle; the Facets are free to communicate between one another; and the Facets are free to assert facts into a Role Player through the Receptacle. (Fig 5, 6) The use of a rule language implies the existence of one or more rule engines. Where do these engines live? In the current implementation, each Role Player has its own engine. We locate the engine there because the coordination dependency logic in an Agent requires the ability to handle Rules in which the left hand side can refer to multiple Coordination Artifacts. By contrast, the inter-Agent dependencies inside an Artifact do not have this requirement, and in general cannot have it, because the Agents often reside in other JVMs. The implications of locating the engine in the Role Player Agent are as follows: The Coordination Artifacts must be able to assert, retract, and modify Rules in that engine. For this reason, the Role Player interface supports these methods. Role Players must likewise be able to assert, retract, and modify Rules in another Players engine, and it can only do this through the Artifact. The Receptacle interface therefore must support the same three methods. The duality now becomes particularly obvious. The key job of the Artifact now stands out clearly: it must be able to move facts from one engine to another, in a transactional way. The Role Player Rules need to be able to distinguish the origin of any given fact, i.e., which specific Role of all the Roles played by this Player asserted it. Put another way, the collection of Facts in the engine at any given time can be partitioned into equivalence classes, or fact-bases, of one per Role. We do this in the current implementation by explicitly defining a fact-base Fact type, asserting a fact-base fact for each Role, and tagging every other fact with a slot whose value is a fact-base Fact. 7. Coordination Artifact Life-Cycle So far we have been looking at Coordination Artifacts structurally. In this section we look at them from a life-cycle perspective, with the following epochs: specification, implementation, construction, Role-binding, invocation, Role unbinding, and destruction. An explicit life-cycle gives Coordination Artifacts the hooks for adding QoS-adaptation. We will briefly describe the types of QoS-adaptation that are appropriate for each stage of the life cycle. Specification time: In our architecture, the specification of an Artifact consists of its Roles and its identifying parameters. Roles are concerned with the underlying logic of the coordination. Parameters are in a general way concerned with distinguishing any pair of Artifacts of the same kind. Parameters are a natural place to specific dynamically determined QoS requirements. At Role-binding time, the Artifact Provider can then use these requirements to construct a suitably configured Artifact instance (this remains for future work). Implementation time: The bulk of the implementation of a Coordination Artifact type consists of two parts. The coordination logic is implemented in a Rule language, e.g., Jess. This describes the relationships between the Artifacts Roles. The Cougaar infrastructure linkage is implemented in Java in the Facet code, and is generally concerned with the translation between Blackboard objects and Facts. In future work, Facet code might be partially generated from an abstract specification, something like the way the CORBA IDL compiler generates stubs and skeletons from abstract interface descriptions. The core implementation of the Coordination Artifact class itself is generally very simple: it merely needs to create the right sort of Facet for each Role. The implementation of the Coordination Artifact Provider is the point at which support for QoS-adaptation re-emerges. One of the key features of QoS-adaptive code is the existence of multiple ways of undertaking a task, with each having different resource requirements and QoS properties. The Provider must add code for selecting the best choice based on the state of the underlying resources. Construction time: Coordination Artifact Providers are created in two ways. Some Coordination Artifacts are loaded as Plugins and are therefore created in the same as any other Plugins. In the other case, some of the standard system/environment Artifact Providers are created as part of the Artifact Broker, and can therefore always be assumed to be available. In either case, when a Provider is created it must register itself with the Broker. Role-bind time: Agents must find a Coordination Artifact and bind to a Role. During binding, the given Artifact Provider must find or make an Artifact matching the given QoS-requirements. Once a suitable Coordination Artifact exists, it binds a Facet/Receptacle pair of the right kind to the requesting Role player. At this point the connection between the Artifact and the client is visible from two perspectives: the Facet represents the Artifacts perspective on the client, and the Receptacle represents the clients perspective on the Artifact. This connection point allows Facts to pass between the Artifact and the client, and gives the Artifact limited access to the clients Blackboard and rule engine. Invocation time: Once binding is in place, the Agent interacts with the Coordination Artifact by asserting and retracting facts for its Role and by executing Facet methods (through the Receptacle) in a Blackboard transaction. Support for QoS adaptation can also come into play here by encoding QoS requirements, for example lifespan, in a facts slots. The Coordination Artifacts can use these QoS requirements to make tradeoff decisions for transferring facts between Roles. Groups of facts can be added in a transaction to maintain consistency or to help bundle facts for efficient transfer. High-level services can also be performed when facts are inserted. For example, facts can be translated to a different ontology or data structure based on the destination Role. Finally, if a remote Agent fails, the Coordination Artifact must reconcile the loss of a Role with the other Agents. Role-unbind time: When an Agent no longer needs to play a Role it can unbind itself from the Coordination Artifact. The Roles fact-base is removed from the Agent Blackboard. Unbinding may also cause facts to be changed or removed in other Roles rule engines. Destruction time: When all Agent Roles been have unbound, the Coordination Artifact should be removed from the society. 8 Coordination Artifacts as a Unifying Interface to the Environment Interaction with the physical environment is a job traditional Agent middleware has left to the Agents themselves, making the workload of these Agents potentially cumbersome. To alleviate this burden Coordination Artifacts should not only perform mediation between Agents but also interface to the underlying physical environment. A physical system may have existing code libraries that give access to some feature of the physical environment. When the library is implemented using a component-based system such as Java Beans[11], the services are managed through the use of a Service Oriented Architecture (SOA). While the SOA approach offers an advantage over traditional language-based libraries, the services are often still too low-level to be used effectively by Agents, for example because of threading issues involving synchronous calls versus asynchronous callbacks. Therefore an additional layer is needed to convert from SOA services to the software style used to implement the Agent, such as a Blackboard interface. The interface to the physical environment is easily encapsulated via Coordination Artifacts, and consists of three layers: the physical environment itself, the existing interface libraries, and the infrastructure glue. Figure 6 shows how Coordination Artifacts can be implemented to interface between various kinds of external environments.  Figure 6: Diversity of Coordination Artifacts Some examples of physical-layer services that are relevant to QoS-adaptation are: setting Diffserv code points to increase the predictability of communication; interfacing to network management systems (e.g., Hewlett Packard OpenViewTM) to get resource configurations; and reserving time slices on real-time hosts. Adding survivability features to a society like this could happen at several layers. Using QoS-adaptive techniques for components[6], Aspects could be added to the Message Transport Service to drop messages. This is an example of the use of aspect-oriented programming (AOP) techniques within the Cougaar infrastructure itself. At another layer, the Facet implementation in one of the Coordination Artifacts could be specialized to support timeouts in its use of Relays. This is an example of classical object-oriented programming (OOP) in the context of Coordination Artifacts. At yet another layer, additional Rule sets could be loaded into the rule engines to alter the logic of the Artifact. This is an example of an implicit characteristic of Rule systems: new Rules can be thrown in to the mix at any time to alter the total behavior of the system without any need to modify existing Rules. 9. Time Sync and Traffic Matrix Example As prototypical examples, two kinds of Coordination Artifacts were implemented: a wrapper for the Cougaar Alarm Service and a generic multicast query-response. The alarm Artifact is an example of the use of CA methodology to encapsulate communication between an Agent and the computing environment. The Alarm Artifact allows the use of time-based Rule logic: activity can be enabled only at given times, or delayed for a given time; in either case expressed either as relative offsets or as absolute time. The Alarm CA supports one role, known as sleeper. A Sleeper asserts an Alarm, the state of which changes from sleeping to expired at a specified time. An Alarm CA does not contribute any domain logic directly; rather, if an alarm expires when other domain conditions are satisfied, domain work is triggered. As is generally the case with rule systems, the exact order of these events is not relevant: no bookkeeping is required on the designers part to keep track of these various events and conditions. The second prototypical CA is an abstract query-response multicast, in which each query can generate any number of responses. The query-response abstraction was further extended by two specific forms of query, TimeSync and TrafficMatrix. The generic Query/Response Coordination Artifact is concerned with propagating queries to designated members of a Community, and gathering the responses to each query. The content of the query and the response are left indeterminate. The Roles of such an Artifact are clear: those of requestor and responder. The Facets for these Roles use standard Cougaar Community mechanisms to create relays of the right kind. These relays transmit the query and response facts back and forth. Finally, the rules are very simple: when a query fact appears in a requestor Role, that fact is propagated to all responders; when a response fact appears in a responder Role, that fact is propagated back to the requestor. Specific kinds of Query/Response handle the next layer. In particular the Rules at this layer must translate between generic query and response facts into more specific varieties. Finally, the client Role Players define Rules of their own: how to respond to a query request (i.e., which response fact to generate) and how to process a completed query. The TimeSync Coordination Artifact implements a simple barrier synchronization. The TimeSync CA specializes the generic Query/Response in several ways. First, it must determine in advance of posting a query how many responses it expects. Second, it waits until that many responses have come in before the query is considered to be finished. Finally, the content of the query and response are empty, since the point of the query is simply synchronization (ordinarily, queries and responses would consist of domain-specific data). The TrafficMatrix Coordination Artifact merges locally gathered inter-Agent message statistics into a global matrix. In this case, the CA specializes the generic Query/Response primarily by means of content: the query content is empty, since the CA itself implies the query. The response content is domain-specific: the traffic data from the responding Agent. Unlike the TimeSync CA, in which a query finishes when enough responses have been received, a TrafficMatrix query finishes after a predetermined length of time; late responses are ignored. This implies the use of a supporting Alarm artifact. As an example of an Agent coordinating three Coordination Artifacts, we implemented a prototype that uses the TimeSync and TrafficMatrix Coordination Artifacts together with a supporting Alarm. In this example, the domain logic includes four Roles and two Coordination Artifacts, each with its own Cougaar Community. One Agent simultaneously plays two of those Roles, coordinating between them (see Figure 7). This Agent plays the responder Role on a TimeSync Artifact and the requestor Role in a TrafficMatrix Artifact; whenever it receives a TimeSync query it generates a TrafficMatrix query. Jess rules for this coordination appear below in Figure 8. The support logic includes an Alarm and its associated Role.  Figure 7: Sequence Diagram of an Agent as Coordination There are several interesting points to note: Fact bases: Earlier we described the partitioning of collections of facts into Fact Bases. Such a partition is represented in Jess as a fact-base Fact. The existence of such a Fact implies not only that the Agent running this code plays a role in some CA, but also that the connection to the CA has been successfully established. This provides a very convenient mechanism for dividing the Rule space into logical parts and running the Rules for each part only when appropriate. Call-outs for domain processing: At two points in the rule logic, once on the query side and once on the response side, the Agent must do some more-involved computation. Rather than implement this computation awkwardly in a rule language, we rely on tight integration between Rules and Java. Alarms: The example in Figure 8 also shows the use of Alarm artifacts to link the TimeSync and TrafficMatrix. When an Agent playing the Responder role in a TimeSync CA receives a TimeSync Query, it will generate a TrafficMatrix Query, swap the rate matrix, and set an alarm for 10 seconds (first Rule). As the TrafficMatrix Responses arrive, they are processed (third Rule). When the alarm expires, the TrafficMatrix Query is considered done and a TimeSync Response is sent back to the TimeSync master (second Rule) 10. Overhead Analysis Adding another layer to the Cougaar infrastructure to support Coordination Artifacts increases the overhead for inter-Agent interactions. This overhead occurs mainly in interfacing the Cougaar Blackboard with the new Agent rule engine and running the rule engine itself. Other processing needed to perform the Coordination is implemented in the same way that the ad hoc Coordination was performed without Coordination Artifacts. Note that binding to the CA does not have a big impact on performance, because binding is done once for the duration that an Agent is acting in a Role.  Figure 8: Rules for TrafficMatrix Master Table 1 shows the results of running a simple query/response coordination using various society configurations. These measurements were performed on the prototype implementation of Coordination Artifacts, which has not been tuned for performance. The hosts were 2.6GHz, single processor Pentium 4s with 2 GB of memory, running Linux. The network connection was 100MBps Ethernet. The Cougaar version was B12_0 alpha. The columns represent various types of Coordinations. No CA is the case where the Coordination was implemented in the traditional ad hoc manner, i.e., without the new CA layer. With CA is the case where the new CA layer was used to implement coordination. Multicast CA is the case where the Cougaar Community service was used to send the query to a Community of responders, though for this experiment only one responder was used. The rows in Table 1 represent various computing environment configurations. 1-host 1-node is the case where both Agents were on the same host and in the same Java VM. This removes the biggest source of overhead, which is serializing inter-Agent messages. 1-host 2-node is the case where the Agents are on the same host but in different Java VMs. 2-host 2-node is where the Agents are on different hosts. Notice that the 2-hosts case has a higher query throughput, because some of the query processing can be done in parallel. The No CA column is consistent with previous Cougaar performance measurements[13]. No CAWith CAMulticast CA1-host 1-node10075304321-host 2 nodes 1551081042-hosts 2-nodes 198137130Table 1: Inter-Agent Query/Responses for Various Society Configurations (Queries/Second) As expected the CA overhead affects the 1-node case (50% decrease) more than the 2-node case (30% decrease). This is because the CA overhead is large relative to other Cougaar overhead. But as the 2-node case shows, the CA overhead is small relative to the overhead of serializing inter-Agent messages. We have not made measurements to determine the source of the CA overhead, but we do expect the overhead to lessen if we implement new logic providers that directly support Coordination Artifacts. 11. Related Work in Coordination Artifacts Other projects have also used the notion of Coordination Artifacts to implement Agent-to-Agent communications, but their implementations fall short of full support of QoS-adaptation. TuCSoNs Coordination Artifact system is a proposed extension to the FIPA inter-Agent communication standard[14]. TuSCoN [15, 16] is based on the use of tuple-centers[17]. TuSCoN is a descendant of Linda, which made popular the distributed Tuple-spaces paradigm[18]. Tuples are typed structures with a vector of typed data fields. Many distributed clients can add, request, or remove tuples from a logically centralized tuple space. TuSCoN extends this model into a tuple-center, which adds Prolog-like Rules to process tuples as they are added and removed from a center. The Rules become the behavior for the center. Some research is available on how to add QoS-adaptation to Linda-like tuple-spaces. Limbo[19] adds two extensions to Linda to help QoS-Adaptation for mobile applications: (i) tuples and tuple requests are augmented with QoS attributes, such as time-outs, (ii) the global tuple-space is partitioned into multiple-named tuple-spaces that are restricted to a limited type of tuple. TSpaces[20] implements a standard centralized tuple-space, but it uses robust message-based middleware as its implementation infrastructure. Lime[21] adds a new operation called reactor that is triggered asynchronously based on the state of the tuple-space. Coordination Artifacts should include all these features and more. To better support QoS-adaptation, we have extended Coordination Artifacts to include: Addition of facts and Roles at design time, which limits the kind of data that can be asserted to a Coordination Artifact and the relationships between the Roles being coordinated. High-level services, including data structure translation (future work). Addition of facts and Roles at design time: We introduced two extensions at the interface between Coordination Artifacts and their clients. Roles are a typed portal into an artifact that assigns its operations to a specific part of the coordination. Facts add types and named slots to tuples to define the QoS requirements for handling the tuple. In this design, the artifacts tuple center is further organized and divided into a fact-base per Role, providing control over data flows between Roles played by Agents. Figure 9 illustrates this partitioning.  Figure 9: Tuple-Space vs. Fact-Role Implementations The advantage of partitioning an Artifacts tuple space into fact-bases for each Role is threefold. First, the complexity of instructions and operations are reduced to focus on a specific type of Agent interaction with the Coordination Artifact. This interaction can have explicit QoS requirements associated with both the Role and the facts. Second, a Roles fact-base is local to the client Agent playing that Role, so the direct interactions with the Coordination Artifact are not burdened with typical distributed system issues. In some sense, the local fact-base is a cache or proxy for the Coordination Artifact. Third, the Coordination Artifact can implement the coordination behavior by controlling the data flow among fact-bases. Since these data flows are distributed, and hence susceptible to physical constraints, they can have custom implementations using standard QoS-adaptive middleware [22, 23]. The main difference between a fact-Role implementation and the TuCSoN tuple-center approach is in how the data is moved between Agents. Both use a high-level language to define the behavior of the coordination, but in the fact-Role approach, the actions are specified as the composition of pre-existing components implemented in the Agent middleware. The underlying components can have robust implementations that include pragmatic handling of error conditions. Note that both schemes could have the same external interface to Roles, i.e. the restricted fact-bases. The main difference is in the implementation of the plumbing between fact-bases. High-level services, including data structure translation[24]: This feature stems from the communication function of an artifact, which is to move data from one Role to another. A role can use various knowledge representations as appropriate for that Roles function, because the Artifact acts as a translating mediator. An Artifact can do these translations based on the properties of the communication path. Moving ontology-based data structures will require further extensions to the Coordination Artifact approach in order to support an ontology standard such as OWL. 12. Conclusions The structure of Agent interaction in a Multi-Agent Society can be understood as a set of relationships among Roles played by each Agent. By organizing coordinated sets of Roles into first-class systemic objects, i.e., into Coordination Artifacts, the design of both Agents and the communication between them, as represented by those Artifacts, can be simplified. The resulting Artifacts provide an ideal place for handling systemic issues, including the dynamic adaptation to changes in Quality of Service. Finally, Coordination Artifacts can readily be implemented using existing Agent infrastructure. 13. Acknowledgements This paper builds on ideas presented at the KIMAS conference [25] and in a companion paper on scaling Coordination Artifacts[26]. The work described here was sponsored in part by DARPA UltraLog contract number #MDA972-01-C-0025. 14. References [1] A. Omicini, A. Ricci, M. Viroli, G. Rimassa. Integrating Objective & Subjective Coordination in Multi-Agent Systems. AAMAS04. [2] A. Omicini. Towards a Notion of Agent Coordination Context. Process Coordination and Ubiquitous Computing, Chapter 12. HYPERLINK "http://www.crcpress.com/"CRC Press, October 2002. [3] A. Ominici, A. Ricci, M. Viroli. Coordination Artifacts: Environment-based Coordination for Intelligent Agents. AAMAS04. [4] Cognitive Agent Architecture. http://www.Cougaar.org/ [5] A. Omicini, HYPERLINK "mailto:s.ossowski@escet.urjc.es"S. Ossowski, HYPERLINK "mailto:aricci@deis.unibo.it"A. Ricci. Methodologies and Software Engineering for Agent Systems: The Agent-Oriented Software Engineering Handbook, Chapter 14. HYPERLINK "http://www.wkap.nl/"Kluwer Academic Publishers, June 2004. Coordination Infrastructures in the Engineering of MultiAgent Systems. [6] J. Zinky, R. Shapiro, and S. Siracuse. Complementary Methods for QoS Adaptation in Component-based Multi-Agent Systems. The 2004 IEEE First Symposium on Multi-Agent Security and Survivability. [7] M. Schumacher. Objective Coordination in Multi-Agent System Engineering Design and Implementation. Volume 2039 of LNAI. Springer-Verlag, Apr. 2001. [8] M. J. Wooldridge and N. R. Jennings. Intelligent Agents: Theory and Practice. Knowledge Engineering Review, 10(2), pages 115152 (1995). [9] Cougaar Developers Guide v. 11.4. http://Cougaar.org/docman/view.php/17/133/CDG_11_4Final.pdf [10] Ultralog Home page: http://ultralog.net [11] SUN Java Beans Home Page: http://java.sun.com/products/javabeans/index.jsp. [12] A. Helsinger, K. Kleinmann, and M. Brinn, A Framework to Control Emergent Survivability of Multi Agent Systems, AAMAS, 2004. [13] J. Zinky, R. Shapiro, S. Siracuse, S. Ford, and D. Wells. Case Studies of Node-level QoS Adaptation in Cougaar, OpenCougaar Conference, 2004. [14] A. Omicini, A. Ricci, G. Rimassa, and M. Viroli, Integrating Objective & Subjective Coordination in FIPA: A Roadmap to TuCSoN. AI*IA/TABOO Joint Workshop (WOA 2003), Italy, September, 2003. [15] TuCSoN page: http://lia.deis.unibo.it/research/TuCSoN/ [16] A. Omicini and HYPERLINK "mailto:franco.zambonelli@unimo.it"F. Zambonelli. TuCSoN: a Coordination Model for Mobile Information Agents. 1st International Workshop on Innovative Internet Information Systems (HYPERLINK "http://www.idi.ntnu.no/~monica/iiis-98/"IIIS98), Pisa, Italy, June 1998. [17] A. Omicini and E. Denti. From tuple spaces to tuple centres. Science of Computer Programming, 41(3):277294, Nov. 2001. [18] N. Carriero and D. Gelernter. Linda in Context. Communcation of the ACM, April ,1989. [19] N. Davies, S. Wade, A. Friday, and G. Blair Limbo: A tuple space based platform for adaptive mobile applications. Proc. Intl Conf. on Open Distributed Processing/ Distributed Platforms, 1997. [20] T. Lehman, et al. Hitting the distributed computing sweet spot with Tspaces. Computer Networks (35) 2001. [21] A. Murphy, G. Picco, and Gruia-Catalin Roman. Lime: A Coordination Middleware Supporting Mobility of Hosts and Agents. Submitted for publication. [22] Quality Objects (QuO) home page: http://quo.bbn.com [23] G. Heineman, J. Loyall, and R. Schantz. Component Technology and QoS Management. International Symposium on Component-based Software Engineering (CBSE7), May 24-25, 2004. [24] J. Lee and T. W. Malone, Partially Shared Views: A Scheme for Communicating among Groups that Use Different Type Hierarchies. ACM Transactions on Information Systems, January 1990, pp 1-26. [25] J. Zinky, S. Siracuse, and R. Shapiro, Using QoS-Adaptive Coordination Artifacts to Increase Scalability of Communication in Distributed Multi-Agent Systems, KIMAS, March 2005. [26] S. Siracuse, J. Zinky, R. Shapiro, and T. Wright. Scalable MAS-Based Control Systems Using QoS-Adaptive Coordination Artifacts. 2nd Workshop On Challenges In The Coordination Of Large Scale Multi-Agent Systems AAMAS Workshop.July 2005.  l{_`\]_r7C*JO!3IJ & !!# $$$b(j(**. .-/A/3374Y4777788N8O8889999:(:s:t:->0>1>5>h>6NH jB)U jUNH6]7cd  :hi# ` x x@&@&@&`7cd  :hi>!""##%**R*X-144457:r=>b@٤و}zwE(# V#UR< ->!""##%**R*X-144457:r=>b@d@@DG{JK$ x#@&h>x>>>Y@Z@b@c@ABRBC2CCCCCCC(E.E%L+LM N+P,PSSST_YuYZZ[[n\y\]^I^S^^^-_2_aaa%a&aFa`jdjjjjjkkl"l:lClnnppUqYq4uFu@v`vvwyy1}B}6~G~OJQJ5CJOJQJ5 jU jlU6NH jCUNH6Ub@d@@DG{JKKKL+PNP4R6TRVcWXXX_YZ[\n\]^aaaGaaBbbcdd޸|yvspkhc`] _Z!  !  !3  !  !   !B +(9UW=`+-<1S#U#KKKL+PNP4R6TRVcWXXX_YZC!Eƀ˕f x+Z[\n\]yw4C!Eƀ˕fC!Eƀ˕fC!Eƀ˕f]^aaaGaaBbbcddywniwdwdww x$a$$`a$C!Eƀ˕fC!Eƀ˕f defhphijjlllnp s4uvy1}6~~~~NP~:;cVDduϖԙþÜÆ{xspmhc#l78+#a++mro++!  !  !  !1  &defhphijwC!Eƀ˕fC!Eƀ˕fjjlllnp s4uvy1}6~~ywuwsssssssw+C!Eƀ˕f C!Eƀ˕f  ~~~NP~:;cVDduϖԙ !g` x@&#+ۀ܀)*NOIMgi78ˋӋ׋ދ(05B`inw~  ghinģȣ3@.;<IE`ap~3ګ{|ȬjuKH$ jcU5 j&UCJH*6 jӖUNHZԙ !gi3CDEKS`apuy}~ž~wple^W + Z + _ + op + t + x + } +  +  +  +  +  +  +  +  + ++)++y+16[9ggi3CDEKS` +$If`+` `apuy}mtcccc +$If`$$Ifl\  *80,4 la}~mxccccmxccccm +$If`$$Ifl\  *80,4 la 3Tѯjh̳\ 0\"y㢝㚗㒍~ytoje`tf,l++%<p#r!  !  7+++QR + V$3Tѯjh̳qo#C!Eƀ˕f C!Eƀ˕f + uv2QRi ch!rv! ^-.RZ STcgj)Uj)UjW(Uj'U jU6NH jUNH6P̳\ 0\"y{C`+ xn{%&STUbc '();VbGLaCJNHj*6U j6UjJ*U jU6+{CX*ZOPQ`aĿ.^0iEwx CX*ZOPQRSTUVWXYZ[\]^1$7$8$H$ & 0` P@^_`a1$7$8$H$ & 0` P@ / =!"#$%' 0/ =!"#$% P B)DdH0>  # A"B(ySVVt_(D0T(xfg~pSJcgSc₊n+BU..BiTTR(W X%hR 6Կ_ΣF$8ƟV@EW*{.M=h_rMpY%Aׇ1 3E{'}\LԯW墝}M7| 9kΏW s>&p]ykطJ=ɹ-%oUz)>*l_)[(YwuJs*M^4U~ {LλEk-Z&O>$3AIqv{kwy]^9$?OU7(zc<^$(kIy [h | HSd<%D9^s)Yf^S:ȣU$Q,<]9'Cܯ}$?2*m˹l9Y)ie6Mt}I6 Ya_Z4 fC9-ZO>䠶_ ZGC(h -zBEwhZ<-zBHhE8y~py*\#Zid4Mf@d4M&B rLJYy&ڜ6gM!)6Цڜ6gM# m<}(whmDr̀Fi&C8`ga69G" kmܫASs2>Nc?io.5=E-^((>jLm{Ict}&Au6WxH4g@Ox8M8U}џ>S/hOG<\[< =_ޯ0aۥz@Mý;iŠwOuJ%؆z1Vv;v|1cSJnFW~<>uȸWRJV)%jJWDî(Ջ񓓣ӓ*laY#\|H;TwOC;rT: çBϤwȃXX?_"N"ޏun0*aGyD=[ >ͱ<;mΪP\O{!ZaWl $ тIh\y rQA*AT rQi#6\4mLȽ[ϗ^w,-_eG9`5-"wla"._m4qvu;/Bߚy @| +oQA l#rnij6ͨͳ;ݎYXZ~'ob]{q,my0c6fM> ~=3s_ Vz_7%+~(]|%(V$'M[$97q yOF>/hcJx,!cHƒ6S?ӝp8|Ni/6S@ I.~ "ť@8/q*Hp8}]wAgqAsn<8[:We[59Ꜧ'DoMпFSo}$^wj&gkFhQe|Cg4s=Ff[1[i5X?3=0 z5<1/ٖ~hZˬ.j[]jŪKC -FcPԖJTXKkzu]@E -@Q/Z+ճzԿ[f뚚!DwUFDr;rHK7`tGqZw^+%|o4e7~D|ԸiҒ=՚XZ}):UTQ“~JG2~#=ib@ (G!w w4l C G6zQk tŸ-fԅS/Cit=&7 ͠/h.;i!mLhͦ,ZG#zbZh>z!%^C GѿNGэf3k7G)' iT摼y(RM`p#Pw/xڭ tEǻ~~$,"0B>v}1`LXKI@ d7HD@@td !("?`p|~M9ǜ;]u[uUZ4SWG6JZXd ZRwn#o ] 5B75V5Դgg^e׵ xa"E<(DI d EE$/|{#2=q A!8%ډ"h$r^PQT$R(`Eq29^R]av%W#E@b Ѯ+8.a!gaMY)oۧWcHjxu-5ڥ jWGE6Ym2޾:z*1-EDZ IgQ—H'ΈKNSm*gU7(ߩ"gX< 8'9贔2\{^|g@<-#E[^,w#0_TK*ⲛ >Gi,:NrŕZ-N8qCDc `F6O3LcdLF2i ۈCF 0yQbtcMtb(+Ε(kQ,?L .̏DI8ci-?O[x< _Mx5QSKճ4_R5SNՅVtP=LU-*PR*(MSWu8N!cmT7j1_dLW3 5xFM6 F5zbAL0 :L3tcLF0f4zr.8dDCУ3=:AУ+1У'GQ?~A4h:|]Be"t]&AIet]C4K!VrD ڣ#Х>ЧBBs>O5>R;=jQa,Wj1KFh&AL4:e@ c?OA Sq3瑅Zخ"^:"/4y(q9ucyXP=9mWiOᔅa,]Aqit3-sNܟrGh?"1WO[, 1Cy+)ؘ=_gb-ӥLngmog/g(>q,+èQ#GJ̒{ }ZJ"|%k|Rӡ_-P\{ۻȳFY29kTV7b|/[SE#JUp+nJr >6WhVU)b;y;?6" q骽RltK@lDL!bsvBB8Sb+8ح*~P*\Pn*i2]rj$g(¸( VI"6G塢\T( /xw[w '? ,<ӹ`bxڞg>7rp̧|Zg>4ch؇:<{Yg>JK0 7c1>bi=[.| EJ`<Ȁ3ɼ"׀݈]cFMIh{v'$\K#ϰ"ׁ}hͳuBS3T9*Ǜ ց`lDL.b7UȻ yWAUyy&Qzڍ5͓@ڞ}E_ }kNo-|!^VE 1̉%o=cz:67!@_=`?qшƸ Rm|_EAn_-s]Y˜m6#š]7=Yx;`hnf2k/Yȗ|Y.{ɬʌ k ]+m_w1_"K@ 3^foq l7hjnM7k͏){qe.]to=udff]] hLNH:*kfi?=!mD[ϴm]tI'ձyYz;?ﱪncՠSVo*`|C MTZd."pZzyXW߾*k"owG;Dn:m}i(;uX:e_{"Tt}qApaz4**BEkPj]j[C^3Tj"o+>c)>ܞ}E)ؗv&e}˪= %Q2Vll[ۊ-}~ wG\wwǸ˓=]6 v *Ndf5 Sś0žhaZVhCy7ϴRY`Z 9tE4t,syv/-Vr ٌy|Ǹs8s68O}+u~[yJu՜k[;_c}_s7:!g:1v9/;ug8 `);}1 [g>_sA|ڙGL|$~Γ!<$CNϛpjqrӅ:xXt~žBا&دطؿǺ?`_kc>~ľ?Y]/9@6={:No[J3~i(MPmgU=YE鉪>>IM` BM?_wB7;l{G<=&ۇCz}@ogПgz=CO$}=QjgOXӟ-bFmᳺV_#jf?ٺ{dY_+"}麽Nb7 |=Ohgah12 }dGgOP XzO3,9e؟+k? =Xtצּq1CoJ8{}wXg 3VKޭ%oq &߉wkNyLķ9RN$xj{qWwbəNhED"mtLԧ+ɕ*#)ekY(c<*{|B'axJ2Q~%ӤFceʐiCSeCzQ6ٲ$[ٚ^mu6ګe+(vEe}*'&}!+wGYNɖvDTzlq4eiDC- єˇhA~,t@V KVAh ֺB T֣ 3OOsd%!],˳r 4I|Խ_{P]vrgw+D;G6d]'?'+HC^Ww /Jцf'ۛ~иMg+9?P Ճ3d"VK;BZ9irEd%#t9ZxxKP<EtA~L&jA۩'}bO#h3φDc|q؂nJCO) u&[Q$GQMnD.5ԊkQGI]77@nLOrsʏPNBz6R \0gݏ+)DgR/PW;ޜSF0.ӏ t =4tf.-l8 ZChM =Oob h+oRJjʴ4hN} >OsVDKzQ^G&w@&ƳKVr^a\ѼFއ^^$B8Ddl/Hml>  # A"B KQ.s^A^)0TRxOUj KQ.s^A^6_*u9I xm tUՕ=ܯso ,!K\3eT?>D@!D!8`Bm`0qMCFA)UG-2|U2DC ߽=V>Ͼg{GZDtZW uX~G,-xtMlFݧqA-{fk53;}ŚahhMA wf􊖾YmuέV,Ҵٷh#>kWjV3ιv5cmt;G}VҊTk#+ hmUt8gR-p^*Wg@[YY@yEɊʊJ!G.'V:٨_RJܻbEiwn_(KIDrl>eZ~Fah?]0o lkjnXLΧhQޜwn7O-r Z@:JVvh%"?\_ۡ]jFUZgoi :l@Zz?A7beyUeŒHZfzǡ;κj6Г:뭔1q;AI{ MhZ،VCrVհo3B3VPGܵFkk7wR+;wY!_tj7V{1F5a @ONc(2%'B$F:bG>(F?}A2nrjl5빖!Yv],!p VhyA)[d%ǰSB$2f-tA+5[頕>cuu72oeہ:XLUˤjZN%v;8~MT8`Րh~aIbmmFīɫ&#:[N<S{OvJ3}b^~KfLOjf{\eǏ'OD\銙NRLWtBC6\b9.18Lԙ^4s BnbC~O>3=庙3=?܁b{tL'gb{tBC6\b9.1Lgo a&B LSt1ӡ ?Љ'>_7\1CLǯ5uh3]13]19銙ujV[Ejrk3uoЂ:͊ݪp ?ЉcцuKdreEoW-_Qd]go7(3zV@G`ꀣ}F~(wD?7}J˄ƨԳ%׬UX&,lV4]N@Ov>:_DKȟ/'bo#3wH4LvY1뉯'o=?f_Pgu4ROll6BxR? UhL06atcSzwv9:-!vN0! -j<Lvc3u3z3fod_Ph. 0c/7'u'2>PRoDޅ=Ȼ@I)ّ9lE  zbSNrhd=~`7s ?#h6Gv1Ѓx=X;Gdo>Y!zCLg8 ƨy\gj'DN`C"sH =s;\)r?;u#r\^%W'YlۜmFmbtu9wv8WX_P=' yt)7czr:hn v3項A 4'Z7ckXEC|ysȟþaaz|Ln~q уxiyIczӥЎѷA~zR}@;;{-џF eJ&H$rKN}!{`+< Ђ:t !܇٬gį}}X)(Z^C*YTQ7j'ݡ_ZUgT)#ٷ {(-b]/epB/ I3JԻmTL m{FqR̴2{x'699{xV]S|h]p13~ ,1zg=&窚ƧvL.0>.R#hI~\~8Սl^]b Ĥa)srPh7ޑ\yC_ю{8UWE9~x*ʽb7HbBP,HS/"4(5A]G=*RBAUV1Iub/MTz:)NW(x%ⰷX[¹{5n3u*EEz{ {ϟOKvqBxlCf|.3WISկ_|U'ǪRrzM:mqQTP/|6 ˃/^^:%|6>&~k-Rz6sguɐ- G,KpU>Jp!Cj `4\("X _j(ȅq0A \[Nc !\q.98 GO }w!g<}Xn懱>Kir}6]kP u9> xڭX tyͼ7nH6]LzSTFYHD ` dI &BB -S[VPSOҠ)*RTN4A?E"I M6s>}{gg7(PEѕ%DjEEPI8V(455 H0`;JO7*}aTS֙n%1XgJJgǞ;VJ2Z68l I?Ndt[S-mF /7T]EW~wJhW0^kr!J7 ۴gH)kuLhH0ju v\2JQX(;/WrMM8Lb '/_c+%eŁ5l[>L:\MwHHݏ(+a>>lGf>Ww;Hwp̹^ʔ$:-Vuz"='/r×LM嶄%n-~N-h3Otm4̣]?6WVh@+!oX@f]cӹL_\Z0_R-W#‚@L%z_]+4&z,/)z1ֿ3iw?μ\9hP9ֽ/,NMNεJ 4$>US fBch)tv\O@0TMB C|< ?eND[QLg^I򉔞Zp˘%S fBch-[0aP7!܁-N&$G1e;|(7=v+eJ>Dc/:*k ll&>>}DЮ`!hG){{lJރXI=d/e6Nf'hA>v}-˱AyX*NGLF6^rʡ/Gr&dً ay%/?5ݴ^E'ٹ=$)h"eϠ94!oMRiЦ{#^]=Ke,{;}~4e<dd nZ,_N&jN蚭V#;j "B*+U[V4W:~XmUs=}ex6dB-E6'-g>IN>&Ut08ṗ\ڥͦaOD}-kN2tjsq ~C Ns:XJK^cBS(%Yl08pd֥aXle @&-@z2'0Q+&jEVLԊNPY'Y?I`T6Vce<6s͘ ~8GJMWCW?Mf hZ!%4mжW"^ ]%[EeNB{>ex;B+5=^f.2 @;$l$u؁v I;lg @;$4=Zx` 8@?cN @;$^ƿNb8 ;mEgJG11X'X؁,@(&j݂ C4! lu0A&9, ;I{M% @[v VQw H`}A`؁C^$ @;l&>>}D- @;lw}✿\JfqًKJPVY~^IxKі"q_b}7i{ug1v5p I>ڛwOdswgw$蓐7x֎Z8?~+[ =d KtƦ܍qt{Z J>swWӹ񻟤wgұOGtuykyAz8ϥK^ch+:IЕ@$m7]!t]ˮ߁Q`{+^hWG]il% xN֩s%'hp5@ _2C| @̈=8L"Y-4=xH'[bԃ39Uރ7 Fs0a z3M%YьZo>mU7m9 l0D1cbf 6Rۀ1Q#kD lF*8?̈́~6d{́@'`w\mtx}^f>OTF*h 56~s:| X!6P.#O4z)pTY.u uxeb^IiJ]V\_Qnssix$Md y.y'k$ćFc¯!YG N*ltFX=9yǓ#Ed,7v2O!y>"|5I/.5rFǁ-򿓯_Q4*?H%x۝5yS:6X42GLUlYȤ]xj8L&,0(Dd >  # A "BZ(q ?"L6(1D0T.(8$>[mAq ?"L$g đE 4xu |MWOC1 AměҖxDif:! Iz+?5ӇGbTմO@L[m"P-U"mH?k}k}ι/"*bszuza"T{*w;W֖ˬY,t"k}IyK9#07w%F[D-ZVi3ѹ;b\]v黬Ecrwm໢fZ]Ջb$Эm{GO?—Fp.|,36;/p4uQN B GYyٝ?VĬyթD;qFjNk%l"fݳ2tX?-mWk0T=vDp|F{w.oo'KT?d K, rUo/W=.yrI U8;mNys^1^Gup2Χ!-ee[w)V#J*O%UخJ5UMJ $ UY:7o\[UswS' גŪ;.jVj0RBhڰm_u?lĸݲe2HG=xJU)\8SSCʠȸj)͇6>99(h|)y&LrBuby9fꆞ'!Y۱Mzxi-IR{ƮH'_s9K /Y}OU_'YhaƖq6cFp&Lozp6ce",8l6f ؆WAY7Jkxurڿw7G'Y\ʹ͒to FIOt&Z='#HS`-z7^< [WjIW7:{K"s!H~2aS/PO iD}o>iL67;pze1XN]5:p\An!?;vNa/zPH} e9Q[4 Wq-]W~u//up}"rNכI ?ޟ'3}0\PX9@Qor#ok;UoϳWS)F.`z%>C`)*N2z7 FeC*Иi 4c4XoH dN+Иj=D=Do[KmdFګC1[tߪûHuI ,IԴISoC{2d06}&fV:x 8+ч zl*|}:&[V`09K\){TwWW{6I&dd/p/P :xr?؊3%ӊ}jùke @{b)"Fo?54<`0O! ASέVO7z5t_ zy$qvKT9tz`.b<-ǿgl}7nP#a+pVL7x=6|ί97顕7r|VyO'|m9sÙV>#g9[M> ^'{.(CC aX9K-^1%?U^Hy:94U^ejǞ\ fitLg&3Eѳ,5W/f =2Wf>CED76f=C3R W;M}rG3vİN<=NjgNao~@5ҟwtou~sG6f`d3vVY* |;A럫ywsGwwASB+vg2 IMw/z wd!7I7t>&Y##!oKn# .؎="}~:#߃,Y dp Vv]ɪ 2XA;h=W`I4;9;t{D^a~`YE "20JS*N=P)SrYTDH#@m)\mWʠD.XDOr].Zr6jMX_pq=5KVriޫXZ{XGUKZͬ9YWz naY," 4P=z0 - %? YGΫGP|ǩzzQ${XzCԕJܦ6HgU,2R뤫:%zinE}pb{Jj0_5Y)؏qID&o< _Y?l(B?k/r]/4Px;m!=>>ad\e .߮sZ T~,G+eskݔ^UbfbP*e+5MQ!=D{bP ~EWf|I%gP QvUpX[{XQDVDf#NtbpdQ-_MޑhSsr3ru)#5}sm 9u }MI,331b>RV +:%5Z:[.}C6)-o=x>"ۤ49 }x>ڌ@_AN(^F9Ld<[,VflĽP."2rM|`·r(۱Kz b%Yu!^WD>{\'6ⳖU  o/Û6 cmfSlǫ*HF+{y齏'n=ګcB'kD+>..?_q1c\066Sb/0 o[X#cd6c+F_UڿTdOTo3.$KI%!f}LS)Dx?%ߢ^SSxi&(jQuWSy[4cGڻ*{7߻H^}:WtGcO3J𩁿Uy=Gs6S)zBUro&{־Gn5rf }.s0[sH_zerURRF!16sg:)I{ JݚrF1rk+ƨ(qkhֱ7t*ތ[qn=cBGNݑTaOC A'O: $IWw'tӱtJwA~<O^}^S3ͭm'xR>6>d;֐?%}%܀0z|U%b7;>6~5ۡ_@bKv;_7V5s <ʃt[;~%n/Ƿ?X;~"mJ<(8 hđE 4+xڝ X{fQ  AT)SdQ-0S{ z̼u6XYnk&ngGx33眙wΜ3e9E ,ζ'AZ5{\U&\%V.rԜ."`L˺ K0D*(oVeUGوWe`XMT gY2oR:]:u:Jq\Ȕѳ5[n7dXްwv}._pkbB:誫ޑWqմY^ּ[EųxCƏN A 7WRE_J+tlt\^-%;b|noF%'-B*?JQ5>**ϗqC!Brkw"h?lS83Qחҟ=cQk)/ӬXX+b 6e/fPiȧ͆ʯiGwZ5ﱈ{, WЧ*h{v̌gsO'IL#qtYAyjw>B9s܎v:r~^Gt\)ᆓGw3$ԗ:<3}BjP;}:oS0d=5}:FUE1z'o 7 fu>ߢ:锬 ):hCi>4I4N4A1:Ff4L7ݜ@ Q p؄AeW݂:6$`vnEa֝1B "Kw[N0N$w9gy@/ ˮНDj*b8#C!g b:s>Cܷ~l7p2{G6bs9N WOĴLޠ6s_5O_ܢuK][#A@KNȓ9'|I$ ^A{$ra>J!AnIV· 3W|<ȋz! e,ȗȕHQч39҉bXs,b>`>M E_C`?[§V y1Bzv= A\Ggg=5-0^s#n궈I'Йj5OP (-݅t BLC>u8u$rn0AFFvbЎ%γT`|Xߡ[c8o%,Dti"ƚܚg1 B6qh k]s"酼(k`?aSajzP|OiiujGH "/~X #я xv,Ə7Ma "p~E!^@E,[A~0GAra^\ cl}XOo 7q87Ø1hW枋s-ƹ{{0g)3&涡Ğm q7ԧ>>EQ>@ ">Ǖ. D9ݐ?s{̹lJe-e%pe(q^DE\gK%peýyV8O rO<8cˇeU.L={?{>{uα#>>GuuYo_ ݶ8#q6F])CysnLȝX1UȑphE3y4\}90g( &OD^'z^}1MGw;]{9{p7kQ{.Ư `SӜ wC1\*&R!E3D]pDKĬ.kd7>)מ%!<)I *|{w|k^[S|;T{aw"Z,͇zwUݣ$y\0U21;d6] a1~!d#F$N*ތ.dJ,]7jlaHL~ГI)"cߐK\X4U)`i/X,lT2?Iϡ49O2%[yb\`HL>!C2H![.(-s\6+=25hgܮ>e^ m5nzQ#b!>.C@^neG.8B)䠞 SZK)6LoM{~Y(: , n|MC)mA߀/Pg9|N*xOJF{l2lݘ]3/3π&l@=WBv+aϼG<״=Vã(w£hD]ޢh,RX^G]"CƋG@PESQDM1VSq ܳq\2$OGx 70E ,B 8YtDu='|/8l 7،:Y_ye M_S.(@ *< QyT_P}WqTͧfj  mz@DiPx!j.suxǓv;z+yi M.0藎Ã]dX֡.+_g%ZOV('?,g}=Z. ]ŗ[Կy-E4Y |  VIJc|O '=l6ÞOl=E{(~}ulJ#':Cca,E.!r4Itb,b{]9:_Lso:':q?N/t~6:9`{(w"?966l/w}1:a_C8fwk|S9ʐ&./XL7Yǭ" 7,0~E&Oq@=tjW:* oxFQa[o2|{UzDM@;Y辶uOTUszd >02Z?؛0?FGE$úR`=ٷȴK:Dd45fg>  # A"BUnopJd1m0T)`tP^+nopJdA4>H xpT} cA~ m[&)ˆl`iHEZA1LG%CFfǒt"!$~ .v={}oO.xI*os!CqǮX+h4[W݇˸El~;Gl'ݪg&!*,?{ZuOY- =>L JPGJݱRq#.`'p8k`  ;V!f5Xւ"hyX;Fh߷+R/vډFН,Q1NvCC+f|qW\%>d1#lH ?wa@P 1A,ǣ~ D]rκSur;Y<>7Cb'H:DCAb=w>KT+CUxUVކt8bO740]ỳ2agA`QpLd`:->x3 >Zw2)Ui<ؼU_]s/0CV6ْug#s"/Ƈ߈v"f(6veR~~WtD(U!z(+u2'004Qɏ Ĕ2P*Q>ħA||ǘ4=,01iOo DeN],?[T';wϙ;l}mUfkA!Rd͖`Ctw%Tu6qZ^iyw֡ΉסGUwV"rTt"pH힋NkG^ic=X)|d4م̾Ӏ5fz~ƿF{z;HV_͑HSuOJþ:\/CJsA|haocNX|_;CL.se]+uy(bWmPb[y Xǐ'wOתUy空s;;}g<}sY4u8mǦ{tY6zȄ- ,ipLd`:->_[=K]9}TvOos֭ķM4Dt^6UtWvE17DRN.Q(uE ؕ:uщlM0(*=;EbA(|Mpy!"/s1+̍6mO?{n|W437u4T{dt-^͛Ƈ?}]'R%LOK/LOgnRq~^h,աzh G8KU,UC/lf;L1.jW=4 WMy3t\s#R-oꎗ-|sA~΅0C\Su =?ލ.p *YCxI;Qavuk]݁1 zYznպeZ?|:Si#N ]Q zt;u_V'vj_v 1jbgN=:b`eͰCy;h;<Ӝd [8Md7=кfσC>&kk Y6F261Ѻfg\0]~NDQ)1v8u%rhUpŨ6@J3*[`B+X汪+x`c׬Prf33\~~`1YǢf. `C뇯 knC\ԂZ" OwoctXѲt{zҘg/̿ƊøǠ!V <|̽ y ZUǪBD l3u 'x܋oo?Ry,.Lu>A[ /Sx[2=FOz _[* NhN#{-*n.$~qx ީv w^6b8}OB7>6~FZ/~}F~З{=4''Q @ފ{ xmlfvfvoo}{{`(U?P(;DBڦqb6g8X"U )F)_"` TT(Ԃ._l6O=}<ϳ3;5 d7Q?LZ>{פ*KX#W<#xF,cb1`"^-~cJTbrG7hӄ=s=\}ާxF.K29,H֛)>4ZKրհWA[ JXeAc X ցçDƩ: b0x$&4>`/4>%<وHOFxeZlGi9vv=x'ei'>H =8;F: 30(R[UO4?-޷4l_ƈ}Tn#䐵4jDYMv5ha !V`mQ➧7 z'^U kFQ'kzWx7hQRj&D7_yqp[D?/ND{ɦЎA-JUPS/!h=mćy7뫶ŪJCUd[,f,kCLZ]v(q@(}sV"kraWZ.B.fD B+HwE*]‡ 1$ myzMݱV>}d<8.l>xKi|p3ohk޸Wj"!W$q(bqQ*-3*mL"ƪPDtr#U &,]de 1젭Ux3c؉w/I&ɞȡlO@1~M)0ᚠw{|Աu:v>cUDOpwf3 4e)`'8a`h\0^4:4DmAߋQf!ҕUgUB=U#XV U.0*pN>{&[ ; Z6||0_#2AH64wVe }_1U#X d:WӜ_&ogvl8 >}_"CR aWȗ qоKw@ B+c[PqoħO6zQ?*p?*pslqqRLb_< \ .") Ni*ȗlga`YraYbC 3K36h^`HhBSq|y"m}”ldiRRuM5xa|E#^Uۼ\WI8n q{S(;Yk3HT潠Gz/Qpv~97{$7+=)R i\kp*[nkRZ6AqGG: ^?ǠC c;}0üZ|upa:í>KE\ٓf]n:SX]rPJJbev -8nz+S췢|u+{1gwBP`v/(q:E%Eؾ$DE]#v ֵ@qGeO/a۟#}y~ywH ,S`(V n抏GU7@`q  XBٓӾf lz~mxk]!4 50:47Nwq~YY x@F#.bm3|W)S,1kqRc)N6zIaL>|ddMC# y__!J*z4ٛkCTGN%>Vjm9lU"װ̀ZW0wU"^ⶶVj5r6BCE9Ѹb\XIDd/>  # A"Ba+ [,͒]0TU=~7]_-a+ [,͒Pdv(, xmW xTEzst{! хE4!\. j ##1!FKQDA*rfمxnK .*"GX][!G]Wt{03WRf\*Y=]c.W0 \[lV*C}1>?Jք{1%/+c^L֔f&e,{%",z匈0 \X=Fd<cײSFG)r-],\E1,Jqq'iE#+0ADxS8qũ_q%E%V"~hõ `]-ކXMys;zqlXBgd[Gkh*YB(L Ŝ'\- .l1 įxXESqF8.%b=|@%x@ }D=H?F+ Pˡ ^ oS? ,%Y{%~l1{-\RX@aK vGn+{ V􄪱N[6z{fcDCpjH[p . w&02~+Dznկv;uSܭN7L>T ``{u,T2V3_jS=LyDsJ;DxY~jLne8-%b}9 [Y~r.hs> eՙ۹,AlMֆ#ݳ5,K؃2$WSs3Sҥg^OOkRڙe}|=<\_Ч 4a'޿iL@hI|)aۉFDhKϿ|vJ ;ln螟n6G}^37ػ _≻Z {?Rm=kzI͟x6rPT7=YI45u|qhN\#P`m?h)8C }#;HtA'ux'pBNC.oӎW;9 ?t?9iӆ$YO:MAq҉7k[zSŎ;rw WQKEeqk8k_3y"jW5:SF&z\ L@aPM`8> Op@X}ٵߥC> unG卽Fg<׹;eZE^πzt]ҩYOt]@xB? 87!zOz B.r1<.߃G\Ȑp9FolfM992:M"dSGʽ쾝5N}q,ny3/V2~YG_tgS1 >F7fӢ,djh-K,#|ZHOv y p}}:~̓ew 0v(, xڕW xE骚7 х(rE@8W5'0GKC@AuT\,B G8p$⺈*d?SWuUuM_# ICIՍZ*$nYRrhImٶDи^H_91?]%o1G?"沽hp[h3y}ĮoѲrLפŲ3#iJc>>bFy+jB=wH4!GcX+Tsrٚjp2p73̶UCV_drscY9yٹ9ϰeybygKbBҲmUT9ӭI֥UϹOYS;LVwz5q!Z$Z3,/3t; ԩf36p "3\ m3} katW,wxvV4c8ovU6եj B.3KV[Pո,=,/ E ntmػuHF{A_CK0.cuBЯiIcuc},:,Q]35ώ5k3a1oJkw.^ / aZ`M[C ;Dq(y|N8&E ѡNX؈vf4F8G#ztPC󩙽z%r:eB?hV B{/Y˅[mj7_Yǚuti-MQHch=F)R7h)@Cr#&RS<P.\Qwgy>a?@*ր? >Nj@_X{lw) _ҁB2&QV[]]]7kE%+h}7#43r7A22Dd2wf24YNgpV)iZCKzzNm-tXnzQ~ByzɝVvk-WV}J~= =3c[,ֱw۩E\GpޥT-2R#S)+2zF;h{=툴" I5pO`owwc7wt %g[}tsێ1(Fӣ4J|^"CWjO Yka<i)O;՘7U&ӸKk\kŇ/Bqg z4V4a"^)0szƜb<0ro℄3Z|DT>N 2Vyr# 䕭rΉcm邳l–5>ߩl+nDlͲ=ζ[[j4ZEdk&-omN ac6kilتfwe]x$G2wX/*\fuV}jc﵌;_|o9^*Iw3&mذh,/IO&oXsuε9v;ށh$7zPgC8ϠW/*ώaK rZ5YdϒWpVHe;nx8 ǖ*P FP˝jՁ9^<7:@=D[ Zßn /xI˫=tjU>om<zygON3O~aƯw7&dث{;y]\y𰷍OO>Sn>}_2c%8aؠ'?{{nx=1V ';"*Wa8jk6R5k UM:lWu`JU}7|wB_nWU+xQsU[} T: Wm#ԃ0FycZnr!KewRáB35B55ꪡ )nx(E;9|ɗS9jlHK>o+lKdxCN7+>C34|Zc>G9cghT5Rѥb\P竧q+Yr&t X8"i11_gT<1&&WqNB`b<1^M"ķ1Lw(q _7|.g$h*Q0ruY%RV;y-Zي?K{;Kp*MWyvS V->3ϜPA($ą+ N0Ww CK!䵽e?j=&Ђ-] g pZﰱjY2Мyý̃TZ$ pk3A̭Ztճv Stoq 2_VS$Dd. D  3 A?"B#KD1<{ΐσ@7#0T#^UKD1<{ΐσ@7"Y{Zc6-q)><RI1V.8zΝG%] vk)UnlSX5 yZyi,i4XR|֠n'$7iW^.Kĸ&/(YP!Ewe@[?){|$;bfGᙗ3{fv?sfɞ&uΝ?t]LJ 5:Zf 5f+iYr2)Zi'9ReO&j>J,ZZj*ZI&RsH"b?WY=[ԭj?2RIjoRZ}K}I/IoojKT fREž3 Ej}"jO|#ԘRٌc:c'D[~faOʭ֡pfgu:cg8:_nY'oQZ\\Z'`a>O,(*/-).(/I~"it/=h~AyI޼>W/( 2@ӤZ(߰,ߠ~sm,cV˽jԏ<-V<]avjz~zjɟ \M;lgæO .[i' $aکi@60\.r!h6DrA>s1N3Lv&imF\csxݫwcVE<9e [+ _p"jFYDv+]np@4B{!^~+[}Ɖy헁d19{vGj߽{ЩS5Whw' ҆k 'a%: aD++ Vbxg'^qĂ'w~=x8K3y䬞j&Nn4)Z4[YOS\wܠYp m@+ D6OГW4,iZ=zU$kd4 2 wHgNn.' zDU9=-' x`ý/Q!4% 3C'. ; [,/b߯WF'w}r뫼+5o4{`uOz] ŞЧ;urc1>}v۞ ?+7o' On}'7xu%\8?3WίcRL^xcʭa[gxظ[g|~0.E?c=x3vn5^2X,ds8hbs]3u3pa}vlJW3GÆG#w^>/5R+yi?4mvC@+TWiZ&?%@jh!>ZHchE ۟69~2= Cc6L%;#n$ad)ñrCMUF+'mZᮜUϐ+Wp?YXE*p?l-z= {ya+!P^ꌸ#Q&3L;o">q T鬢¢YB|ntX^4r4@I&eU//ʯK}$˗xh֬y :{-|#i/gE:*i/@e:iy2}4 ObrLpF}{_!O,!`F}`;!~ ƉyRZ`I%l% ;y#?+/Ed#{Wd`GYMu۠?Kn&W;;*r&`Ӈ1SA>bgFfPWq?7<}RO.WSy\Vu6Tޢ}vXLp}7#WSy,SVh%`*{2rm;??1N̓| | {5{jQK9~,/#WS;*%LnVb0\,h6LE>rqbjq TᑏNj#am(|ݢ/B{_XZrwE$>kY@ҬDQ{R ! y8!ma3W/"ZUr5PM|B58X𑫩|_t9ʟ\r1@w6GtB "#},Ɖyz)eT8|ȻWSgdFW+ 4/#WSMckPPh?yJ]o&1ד~{W\˽ 1p4SO9b "o&? h9ʱfq];sI"n%;ya@^؝{|^7+폯W^go֗*ouڕ+"5=J+?4a:Un"vߙڣa&u(7Gy%\9V/j: */~\vUCu/ʏ E_nrU٢BDU MH',>d~AyusX*/( FlP-ŇjhL6k鷜8NOJYdl#6}e?C 1.AFݷ~ԡcbOϾzݭb+ Zw.)볂>#/p 3G:KR3(X9"`;J?% _[}GcN9`'}׎t;rJ +ؑv/zޑ+O"O#l̢e#Ѣ²kbl;Q[ZXQxK K+3랞)32V@qпѨXӺ{. 182s1FM kbyOj5^׫ 1']";߁ pvUŸ ].#}=.&v f]#Jt0g%:P6v68yeDq΋ ]9'(iq4WBh q5t_~nwi 0ىQGi̳w^!cH^Wy7.dw6v(}f=󽭐*n$Hw;߁4 W_ 4%ysυ.\s;rao1h3~+]KO F npB#Ǡ[5 ZCߎv-B WÿЯF\q?f(죴 mu\~띫Fٽg5.6_fdJ/euo{,wMyeבidvüjeVcwgdHWh^U7C_ۑYR,,?N{[dq H39*p}&Xͫ*$IS3tOFMUNjf5SO7fWDk V3 '#b3ݲFM341d'FMU5 x&6So9+d1p*l8JY2`Ev3ԐPFf{Sw6C c}֡ռFc&`FIvJ:f ٳRo_uJ>ռFcANܩN}^uv5ji;#C5ΙaZ|sehQƩxB IOywe8A!uՋ ] }17EpIҀ cC>X ]@D̳ D5)VN|" ]XsU} Zt \!| )6 &tg".Kq?;`Sk5 m#*ãsLʰ]w?2 h7M% Lagc2ᦫEbY@J)6ύ? ]0bs;\q `1h3TȢmT7 +E1薻Yu[oA\-BY3τ.Le)g;I^sKpmݠVӷBv_ LC4=` V!!f}2>GC%Ȁ==*etU|Tn)m& s1m>c$umb]&vs}+&-,x198VW8FJ $ *v">H\WN (f: m؎35v[4_ ;QO_s|AQO%_ z|^glD4: QM5?-։jBTCA @4(Ub*0٬3l\>T2J`D}f{ѷD| A6!K{OZPV fXBv*+o]UO>b3}i:Dd\<-_Zu-b* q|G/_qr-аs$JӬXb}>nQ)m>+1q+ d>ޣGQjQNw8 do 똑c=J̢V(dL._Ppgی7 '|{q߿E2)5<;ّi 62*VT-Ő`F&Z]7&-XpY~E#z{DW|DnsLV77SiLeM_|ou JCr)njWM{}wCq?ЏE8~S^v7U>-³{ͦ 9rs4\T:ngZIgH۠߆m!JJFgυ?\s7?Σ 8{[!/ZS?{ʡ ojUSpuB xnXc X"nq?oXI;`WѯfWHM1bsLB;K :Kl6!nMe7lh,B }.f3TΣx-B̳Ɯ72>ms]OcL)\ĸ W o'A#C}c  K3Od2|:_hD"}Ҫ|B\!#E3s 2?+fy;+l&M"M(MM5l{;+ojHQM@RTPb$T`lD ,#L)Hd ԃVڄ,ZNU𠕢f3TBvd{+ɗhɗ`? !3"6ޫG vdφʵvـar}Mp/EVq2:fplC?mr?`| v`|TVc'} C6}G68$4KZѵ)]L h + qVPzF*qj/!As} > 0a*g= WסM T̳ Dd5*G4׉+E=tbuĵ(f5J,V(vL3˄>qY3MR~1Iʼn\`7Tcʷ31Y^WNQ^9+NƎzZɅj4vA2N1 9eMP"攕daNbWnr#Ӂ4`XaЅ#.Vq?_ZÕ+xh]Y@}g2QNT?Ge*@󽭐;q2tw>٬d -kQe@9ZVAS m &tg".Kq?IxLA݃61gUW =ρOjYuVAoGS3D<ċGI}SJݽg铴U_\lDUwHh1iYDkFU|a=%;qe=BE\%ʭNELѲT}oq|Ne[!^S9 E}{b gϋ9K EliaEbxX K/=Dd@PKM>  # A"B ^Bm\C}L j0T Fa,繰TcL^Bm\C}L Mpb2x]lWݹw;hȶQuRՖ@_J\;C?!*l'T :h&!>$uv6vy)`}|IjFJovS#|s9sgF{̜#r+B;=9y};K^V=s3.*!>͎q6E#qATL`m9gLB .gZΘu$mCv C  Zwk+#_Vhvb:;َ3fN۰!Qk }bw {2EXB[&s_Z:=uR C j+z5*Uȑ/T%{ հm|B'5cZ'U6b7S^!1#bԡfOoV(5_M~l`d۶a/ C 6jg!vm9Ӱ9]ӵ9]{mXNלNi C Y+ƿ6ClZ@|aeHE#Ov5Nv5Ma ]hNv'I+ fY\0f۽+ĂL9,aGDF%O%%Œlm퐭 Z :KLʓbZ[z.+Tl VCHV*Y*eoCF5Q8*w ѾM:)$IrӬg8b_BS'!S0{[yO~a v7]|T}Rݾ?.<_WѮ~oga;-F;E씝qSΫ c|+릸mŽ'buN+VKzGuYh3p?&V{+0k:unw YPalu(:g{߈* jZVĢYuXd4PZATBZ9r+qPbR),)'bٛB;[SLb1Kĸ.E/7m VoMkS=@-o=MT]An rSny~?/U 6йΝv75;!7Bk_/ cuT_POcMqD_x@H(F}BeoC N1c4;ڇ#="1WSt$CCB AQ+jS5zB_*тrU짭^,k7k󽵵 w{kuNZ,b" 5P0/#uhTs}޷D|Nzc 'jݯwz4@͂z]rk>uhrXlܓRldDpQmhx72F"/0ч_=Wz1jH Vt~)lUR.ӏy2c4<⡒.zeV)Ė{VV.]~vZTv*]]=GT:/U-zC[rKsjTN;TNTS7t\݄[:]MKDFKK2ĝ*S:@349!TAjdFlMլn0uw&զ>PmzNTE}lB~~\u3c: h9~'nM~{ <{1> Mpb29xڥ[lUϙ3f; -(Hb/ zy4v{-0{i-]M/6ZJ/ݠ$`v[Mv[ey`_S\01&YUncEZ|ݒoYRKʵ|7RPL?D?LiHo9ۊ6"|A eaxCȆآb)5q#[10 8qdzNfS>cXU*Ә0& ^-ZjEJ f n5F\= 2dxRtxġ"jVԜdV\r+A,[@)/0R r/9J!+EUD)UL*!ny2xe\=l#acm7#Q=q^ l75*Wl9L3Fx" s'OZaV',K0= k֢fԬŬ9[q /L3cG!>mES$ dSjf[S"3f9w{>G#F vZ k|A#Feuy6 쐈b@7(A4/@=S 'lvRhKEJXS("B+CV&/zPj^ 1^Zm:,FDv ȟZoVlof|6g2@YC?fjsJd 4&/m\i0c@;hZ5)(:O 6@qvaxGi$VR,H/P Y!%r5S sa}+z6Yb` ;=lsV*Fe:wNtD.tFwWZ+NM`3OAsV>OU8J F{*-|LAiu+W?Ny9jll];=MNd5\޽]_7?ɮR/7iWm 'z]b@OogWJG}avv2V;g̚Ue,X^zM/{wYӞΞPdOI|V,s+?-2ohtG~{V^;B馍N Fr]K*{xzHo@Go1UfeZ9,O_U28JCUNZK Rk*>>sy٦TG29j4]*vk*uPG:Vٻl3}w`0f^KTPHJat\\sjWni)dS@ ;Jx!ɋ5yݵq]5`5X_ WC~ZP#ͨF*p5n Pwwϻ[Ұ_쇷Y7SBJp#=W_h?_1cx+]-<}3VHDdT%.v  C 2A:rules2.tiffC"bG_?u6WC IhGn`G_?u6WC IPNG  IHDRTFgAMAܲ pHYs   IDATxA*@؃!B`[ԉ$@dL믿w۶TǕٶ\Z7"-p_׿u D 3g9Eӟ2˶ DsjJLxWlQz\mENFZ|m-0SpL,B?{Jg~g)Y1סKf3P z6{Tjo Q!-LQkHoȺ{,F~V{?A=qVvӏG{tI[*UHu2dХ@IYR WDAnmwtIWS]UȔ8W1̘Pc ' =^FhjCa Cx y"0ud [ h2\~WJ[)=1tm/ǰUqObٴ|T?ٿUUlz6$WFuy0O mR{ejCŪnzEFuuu?l8NH˫ZjyeWT|e#6 8l11=lBK L&ͭer&PbK\A\KE9=S%z3h"EuUM+a y+s[h|^*2e^Wkz;.<(v9rը%Jp!WLD캯M{\vleeM_ʃMl== GVP80\`%*P/WӀ斺 Ֆ5=UWe]O8gޱ'lw0+#YgvZp<8\t1:!4@j4{JBOftg*"a2%sU6Y ٱkٽ7ξQ7 V{WyQGcpuna|8L.jFȨJj O Ļ*7ْ6i=N<1:[q'IZՂF-F)5h;avݫlv)d5O$~n6QðPU=–Zt)뵵۴Uж0fsGy|BwbJw9?eʌd)V>=s5Ok0T]sUn_E*EaoOdd=o{k,O3*91! YQc//vro1 c*U)dgZK1N5U}uxlބۛ}*7aP{IbU&q/%WKBgZnmMN!N=7x#a4FoMp9!go^ŋ=4˂%x 5mf~WApC^':&v`7h`Ʋl7i] =  @O"֠~KFPI~冼b<_)gwQz^m ^-$xvk=6<5xt,sH} ygReQ;j-V/SR]jIVjvߨԩcTd[ja1ۇlVfۇ~eU~>Cn+[^P*9 r)~Hd~YհdVeDt÷woܦy自^5t BOpgָ^ήu&ܐs'Q d. [qb+=}q8)!t3l6R:'u** ZWk!_>Z'!{ ( |f_Yf!7KbJw9?oF$KQշ9qydb9vbRZޒG[jI˜(g Z^{]a4ܦ^UrV2!7qSHƪf^T+.ǪRz#2ݘf*2dNeO˽e{o]{bta=03>ڇ7CpHE\Tmm:o%++ݩ7X t=?.d28=x 5m&g^^i =2W8K`~j*ܐ2kZJu>'YvтTQnA1ݿY0ۆح6oIV˹gTZ_+%\z^i=qίR^>h}#6Ճ=g~f`>SR]jIV>9⬴5CN=yt>)[Vqu-rr y1U񵒯z B|,?m`T\K]Ҟ ( s8ڮy[@0LGfm^jFnڃWOk'6)-7V#u'tU Z9CPopbka);?ϸ =ʗֺ̳p|uKՇ?ۖG^%=롲ȊLXl塨$1zu- Х11O$-MRn%V‡6eUHWl~l]yݏVstk83Llcjc̰McWgd|sv:hZ-v-d7U ?-Նv.BuHT^5%)ɩݣaH?t"{qmjڒ=3YCLQD|s''OO[fX(q[RU]MU7DiϐC<=! J:?6oVl3RV\ئvz|h,?Wem. ?MWMe^9¤ǯ#'vՇ&%2«+eHK6!azӖ_[)P-C'ǓuU[{Z[x3$+M ? LQ zn6CuVUWd$NPյv8ag1FA׀co*iφX*?폳<)ܶg9<:sH`ϒVÕ7*.W6[~JUKvgzjI+jC-wOϵ`g`4xF%)0 .%΄W)Qob\VKRdegRn*ᅰq{޳ AwB~ohx-tb0H a 5iRCH a 5iRCH a 5iRCH a 5iRCH a 5iRCH a 5iRCH a 5iRCH a 5iRCH a 5iRCH a 5iRCH a 5i49P~2|"{U0irx'$5FPZ$mJӥ=go~x6bz%Uټ%3)O=ͪ<Y੩mUB0t5PeC)'0ytI[*{S*hW[b=s1<6ZQisN|4]v>Z{eDqC1 "'[{kk %0sc?6:u%w,|ޗw )݋=5̊@zCBZ=s-,E 0jmfέ7UFRɶmΠЯb#(ZpS\*<RpžEEޔHf}~3*J6)e;-g ac<핓`tBৠF9$͝U`vpUl`B(p*(Bbλ= k;QpcS:`\P33gjJY%Ko3LjWmV;i*]~{ZW/U~@L?J9b[}CԪh[T@!ܮ,R5$+%25궩joAtpPp݄Ԕ*ǘ]MT:3VgKF>ai.ݾTՇ@Þ*vZwvOkLT`=[]ۆ7䭚_DEk)]3%Z2bE?v]-P?WU`eRF QSПr6 p_HyUDf2XTk*k0OUFu=yZ{]卓}(v?ar`٦2Ϫє|( IDATUʺ1'{S}%;N^]蟵 Av_ܟqyK+Z3?=ǑGTK{Ү2%)׎V=n<23/$;=hg~Zy!IE<K=N7Į=2Ԗlzj!3ZHU*u%.;W%̪IBR`R'g\Ą\|SgLjĸ>(vC gp$$ P^˵mJ\<'?EI*ϞHWU8͇'g`6M[-POqp!o>9'8٭7ӅkSUf\4ҵYԾ/$۫,z._Q]fsZ"%ߡ66dvypN*:XJmʲcR3juW p-եINܡ ^uG)aSVM946oĊ=aa{A zbFH!LayЂNuk:7ϚT4 ^%՟eRU,4^jB~!՞QVgloW"OdM y|~ބ:6s[UUlTj4˪p~2x zYܳ#jtɚ}Âʹ|zoVMc:H-Ԕ {2EE|3{{+u՟]$)`zHER|Cuԕ7&Z|kH9֙6w=P X4_=iQE2U=6wUuW%gr l3Z>ֲ٦F'uIǍ;'ܐWq&FpՃ>fݨ]jJUm['0$Y)YKAc'Q7Ud9S3P9i/ћA{| j ə~w#}GSZ{f}ذ#oW )Zۡ@0S{BHp y<kue`͢Gߕo9,SI)aɹbgc C6K]19C%*P/WǠ斺 Ֆ5=UW%U_>N1N23yǞZu2 J])\Ce+9ԺȬu(o,ERfuv\4jGB뫛r yzﺓo3QC؅H?w 0PxjUTRN6M`;Vݾ:nk*gN_ЩHPsQJWh!̀|{P#qΩ|p|]ҰgU5iƙrC$tfJU}+ÞG&ag-v!-~T!,r-UevMm:U5(j+=rC^>klMUPx*Wk>"ӍijF"CN4~][ֵ'VJS =C}?~cJ9;.j^d_YN޸&Kئ&]Iݝ q#Mg޳r N&7nP3Ѧara^%{Avp*{b yl!TWsuo7-xKN?4c+mZ,an[l+oȋpJ|O*%{edz<"3 nȓȼnʳhiy\J0{9h?Z$2:ۣ֒,SlFtiL<5x^ ec9}-v+Ӡ .bt&r{h6#3l$o18۫C㹛>(9j7P"''ݐj__+wp-GF5!%9Ұͱ93O t}[phֶ&aH=zUybsrcI8Rw{B7:_b [3G.[󌻰`ѣ|nK< AW'T}Xˋ!*mJy$;Q2ݳ*{VJCWpM ]jnO]UwU[}&7m׃].z1aSW7l8$$8`?KiH 1| Qo)Ϲ*U/GKA}9<^TU'Y2T$UߐO#gjQI[x&gIײrߴzP7mqyZ%Pj;q)񴩟Wa'Zֲp>QRy`ѡX Vl4 {Ϝ^}L~ yC>}OxWlU)=p!GګOd<RCH a 5iRCH a 5iRCH a 5iRCH a 5iRCH a 5iRCH a 5iRCH a 5i49P~2|pԔePIj y9c*m %LW)՞3L~}1f(ŪT9RT_ eotG{˱n Bi,?w3Sps rRkUPݝvgK"uWS6cy<p;is20NUH}ēSr6tX[V7ʯd&.B5mb.=d#~:8?ey*Ceϻ1[CڰٙS*º#S"6Wi.5Q3I.f6 .p5PWQc鱹J9 48U[̱uǑ}mq"%WIɥF{h nZ}k[Wc5d@VSiH!<ղ?KJɪ.O=C,F5^UݥR\6njjm@۩0R;x!ym( Kdsq0| 'CSV%j)%c "خ7tuݢ܂֎~O-8X+}qKzrD-~C(Q7UȑfkE%JN`EШgjVTԉ̳]#{S7]e(72_!bmWTezUJ8Y8R3 P,a^Sa'ag7ۅԂh5囑_& L~V V٭螪=-w'1։/m*s F劧:.pK{.u#Jʖdrx;~w<ߚ/?/S0 /-#B^^Xe8 5,z0 .OEYun;Ԁ$ !ySiɅVq%tXt`*OxH y'i\T3G5ug ].蓽!LƩ]ڀyiiZw! 5ụwemw -ryS[]Ov0 G%¢@:|C1z#LH1zc 9̦RCH  ?=2r5[!]z'JWqC[<4RsX 5{yԔ {q' Pg|Խ[3yejf7@ :Or4IDAT@2yͥ3+ɶG؜6ܘiЭu]i-9[`3)=/QʶP[+SƳkdžbtO.q%~K>,.Jٜr7Q;j-6.SR]j qzHʱݲy"/l֑ &غT +϶v<>ݰ0` u6>,swz.<^}P@w T2e\Sg~{TZe$IDQ-~ja5EBTl=VÇٺzzP#eTz9V6aIԙBi3Y?>:qyeT8 :9DBg@ztQ:Vڿ<+_ߓ)\ :|p|^Ұc׬I3ܐ7_=L ȔoS3Pr:.%yUn(簵{jag0|(oL)ӟn=^ K5"70Qr ^yO675Iy¹n{,Kvr+U?`h0ۭ4Ko0 4@j!LfAvZW ltM2|i3Y0&@RÆ<RCH a 5SaÇHؐx>>X2Bfg>~vgG2[,Y<̅ ϵ[#HfOp>0]"U=)0?wiYX~%3H*N{aԮlBM춅n=1ɕU<%2_Pg><)ιXV)5 r]U-R` UPZcOLrg63 ,M;gwזX#weu:f6{Zp8ea"0bx\H6{TZUf)'goZNU<);l%;3>dRvoP쉫3ԦHd,W=ՐD]hV;UWjVL En-jFj,8ׂ>lK{mj\T#f! 4䐄'@rѐHWGBdžTR yᆼ;2r yG˵_rO0LgǶˆoʳd|,#iHii7tZXQStC^SNy O T%Z(O ' &\pCQjI݀%aˮWsUUK]{C^*dU9~ )v>#HqC'è{C_b[)g&oKv>JBU{wmY/Gnu.eW7SᆼŜ4Axܐw'/AnH a 5iR7yqc>IENDB`Dd+,>   # A "BiO;WO2h"E0T=T@3ѻ#gY>Z4O;WO2h"D/Sl$4 xmXTTU?o Z@ V%dդD$2((ʿNqҶFdhfv㺻Z\=L~{;w ^['D|9*C*xl!zAʹ}bAg3ȝ$zCWh[<+'Y Ih77"NrI'/8;^90"Tvs"SsKVy 5KSڎ!HD2~!-OHQҡ+yZϊ<. S&~;edud"qn'Sh魑Ю֑ Kg@yWC`-umBFf7a:$kd`ԜD [E?Cg+}Bwc,2.sN>'ѷNJ?`y4Hd㔏qM6Nt3pZzGV=zO+Z2O]vQ=xF422{ա_~-r:9Q{8ڴ mZ;_90pǵfk @6phmZ&!3^&`m8 #urN,[e܊zc-o,r!w3؋|=8U+x~(Gl=A&Հ[aVNg}Jҫ~t9]asî<-@5 5"#u*t b53Tb@B^伋/Oi/-җ4v.4^>kAFf[X.h@><53ZԳy>˕ځ VO&kiFA&HH+*-.tte2;#:r'$z1A2詼RO5|>oy?Kg&}+(i>ѧ@~F|+k4Wm1I; l>7-R484 @1o@? {/9֩_9RO39TdķkEyqWv7& sJ=<'*)i/ ĝ1كL9Mˤ\!ƁU? k\iOCO1Aoû*?1OV,zd%%+BPzλ\: E}oyr/|ǹvX^93Vk%腮LX2W2a{a+SwX-B &h5Iꖵ[@fO+C7UV@ ޳FFfwkPM@!*5U 4"άFG^;L|mGYXYvZzkSk2um]B׾.ڋ@/:|z8:}Xv0 3št랑NS$;o1NSs~oę NyȚaby8izKg!1!3F 4#EӀT )x@ o/z #6ԭ[oE6\'0722nZi{ӴwȧiqշN3O晐ӴIspأtp Zzxe!^wگkpM4z瑑u*B9ׁ=':ؿU>b7C C9b(s',:E7xDBcKdR+pHu~&Fx3dLmA' Hh"\qo䰹|"ك%^h5V3c eU=w=<V'YNZJFe.| 9iA+z墖^_)7dHo% OV0SҾ墖^EJ 6xxSl$4 xڭX pT}eoZKҖBA$%aHD1-HR lB0?H2@28643U22" 1S mfWmf{w0cbKFA ]fIFL2o6%3X;D3omm57 DٳT$72צ3K(uMXU#hE;DY-~jnZJ+qsWq,ZCF fZ2Z>u6b(@#=VGCn1! 1Z/ƨyB TTo@||߀S@ڋ,gE8O-l\~#rp|4cuT^W^XXnfM7!I b9[zUU_jIur/.x#r 8O>##gE3__vY gw4v@J)7#m}uiphT'ӁBv %3N;F b<0|<4cuԍ__-w~5$hy͆'Iz>ßAu4,!Mp)|~"Tr* %H=Z"7DUjÿye!VRx* Ч >)OATIuƩ2(SObżVN;J颟.Sb|4cuGN#g˧p[.f~hňS _x*|"o:#e+0IxMòYNj1|14cu4J^7Jɲʒ)SOZsI$+duèYdhT'G*Ʈ*x t'Q8-fY U mrTr쿱6kuzh;xۻ:{B]l0)%/~ N:~?fbA"p"4c=?`;=@{_.CX+|8ﬣx]޹c{= h!z#|qrM)h;yxO9/rUj[g>ӈy8O|h_n*5vȧX?ӤYK_ -keP+w:!C!NSAR}'1^ᜌOt4nv# GQAnM}w1hQQDlҲzy&x__zX;]iWu>%|~KWZɳW JE\:ͷ[kzuC= n#f]P㝨.Xǖ=".4wo9xu7 $|G:4w px1cAN<^r]UTo8[Eg > Heading 9 <@& CJOJQJ<A@< Default Paragraph Font"O" ai1  x "" ai2  x <C< Body Text Indent `DR"D Body Text Indent 2 `6>2> Article Titleh<^hCJ8B8 Author $`6CJ,R, Header  !8b8 Page number$a$OJQJ0>@r0 Title$a$ 5CJKH:^: Normal (Web)dd[$\$,O, Authors$a$CJ.O. AuthorAffil6$!$ AbstractH"@H Caption$xx`a$5CJOJQJ2O2 Reference `CJ<O< AbstractTitle$a$5CJ0`0 HTML Address6<T< Block Text x]^DOD Bullets#! & F ^`P"P TableContents"$(`a$ CJOJQJ4O24 Graphic#$x`a$*BB* Body Text$x4PR4 Body Text 2 %dx2Qb2 Body Text 3&xCJHMArH Body Text First Indent '`XNX Body Text First Indent 2(hx^h`HSH Body Text Indent 3)hx^hCJ*?* Closing *^,@, Comment Text+L Date,FYF Document Map--D M OJQJ4[4 E-mail Signature.,+, Endnote Text/`$` Envelope Address!0@ &+D/^@ CJOJQJ:%: Envelope Return1OJQJ, ", Footer 2 !.2. Footnote Text3>eB> HTML Preformatted4OJQJ2 2 Index 158^`82 2 Index 268^`82 2 Index 37X8^X`82 2 Index 48 8^ `822 Index 598^`822 Index 6:8^`822 Index 7;x8^x`822 Index 8<@8^@`822 Index 9=8^`8:!R: Index Heading> 5OJQJ,/, List?h^h`020 List 2@^`030 List 3A8^8`04"0 List 4B^`0520 List 5C^`20B2 List Bullet D & F66R6 List Bullet 2 E & F67b6 List Bullet 3 F & F68r6 List Bullet 4 G & F696 List Bullet 5 H & F:D: List ContinueIhx^h>E> List Continue 2Jx^>F> List Continue 3K8x^8>G> List Continue 4Lx^>H> List Continue 5Mx^212 List Number N & F6:6 List Number 2 O & F 6;6 List Number 3 P & F 6<6 List Number 4 Q & F 6="6 List Number 5 R & F b-2b Macro Text0S$  ` @ `a$ OJQJmH IB Message HeadergT8$d%d&d'd-DM NOPQ^8` CJOJQJ6R6 Normal Indent U^,O, Note HeadingV0Zr0 Plain TextWOJQJ(K( SalutationX.@. Signature Y^>J> SubtitleZ$<@&a$ CJOJQJL,L Table of Authorities[8^`8D#D Table of Figures\p^`p>.> TOA Heading]x5CJOJQJ TOC 1^&& TOC 2 _^&& TOC 3 `^&& TOC 4 aX^X&& TOC 5 b ^ && TOC 6 c^&& TOC 7 d^&& TOC 8 ex^x&& TOC 9 f@^@(U@q( Hyperlink>*B*LL Paper-Titleh$x`a$5CJ$OJQJ&)@& Page Number8V@8 FollowedHyperlink>*B*  a            a" #zzzzzzzz z z &2:ENZyc4oz;З!"agowXL(  h>uahlu|~KZ]dj~g`}̳C^aiknoprstwxy{}b@dԙajmqvzUnknown John Zinkyʺӻ߻ ˼%Tb'aXXXXXX|B$vzBs~T&B$b~J9oO? B$БH2 goDB$.|)DAB$ Fa,繰TcLB$T@3ѻ#gY>Z4 B$* cX`%5OB${)ns B$ayg #;B$l)ņ2P_2zyd'B$2gdAuB$K6JTK8B$o-n<H"@B$%8v1OhQB$uŢ8oACSY B$0$`6P ҊB$8$>[mA 0e0e     A@  A5% 8c8c     ?A)BCD|E||c"$`@0(  B S  ?a _Hlt501695463b@b DKin<C`c     JM58\]%%((l*o*++$,+,../%/////X0_011112255r7y788n:u:::::;;<<9<@<;=B=>>??/?BCCDDDDiEpEEEFF,F9FEFRFGGiGpG!I(IJJJJMMRR)S2SSS]]bbhhLhOhijkknn;n>nnnooooqqttttCuFu~~~~_iŃ̃(05Bhpy;H=EJW͒ W_dqۗ;HŘ͘=Dڙ}ZgV]7:$¢ڤݤ\bڥߥjp}קڧ 03chȨͨϨ֨ĩɩ&)¬:=[cƹ#*׻߻ ).CKhkrx ~ $.5>D XbflKRZ_glw|}Z_18kpv 2:?ENUrubjot;HPQb79T c 4=&Yc6: $$%&*&)G*E0M01177 << ?cjNWϨר\aR[\}"LThz;WXmbZNPQb::::::::::::::::::::::::::::::::::::::::::::::::::::::::: R Shapiro6Tiger:Users:rshapiro:Desktop:MASS05-CA-postfinal-1.doc R Shapiro6Tiger:Users:rshapiro:Desktop:MASS05-CA-postfinal-1.doc R Shapiro6Tiger:Users:rshapiro:Desktop:MASS05-CA-postfinal-1.doc R Shapiro6Tiger:Users:rshapiro:Desktop:MASS05-CA-postfinal-1.doc R Shapiro6Tiger:Users:rshapiro:Desktop:MASS05-CA-postfinal-1.doc R Shapiro6Tiger:Users:rshapiro:Desktop:MASS05-CA-postfinal-1.doc R Shapiro6Tiger:Users:rshapiro:Desktop:MASS05-CA-postfinal-1.doc John ZinkyKjzinky:Desktop:SASSI:CoordinationArtifacts:MASS05:MASS05-CA-postfinal-2.doc John ZinkyKjzinky:Desktop:SASSI:CoordinationArtifacts:MASS05:MASS05-CA-postfinal-3.doc John ZinkyEjzinky:Desktop:SASSI:CoordinationArtifacts:MASS05:MASS05-CA-zinky.doc|4\R}>Q~vP*O0gHzH>GVC4F EJNDbUIIZrH , 3 l eJ$r dm)fZFlPTBVsgJh`Қ`!u Tb]~/IfN^`.^`.88^8`.^`. ^`OJQJo( ^`OJQJo( 88^8`OJQJo( ^`OJQJo(hh^h`. hh^h`OJQJo(*h ^`OJQJo(h ^`OJQJo(oh   ^ `OJQJo(h R R ^R `OJQJo(h ""^"`OJQJo(oh ^`OJQJo(h ^`OJQJo(h ^`OJQJo(oh bb^b`OJQJo(^`OJPJQJo(- ^`OJQJo(o   ^ `OJQJo( R R ^R `OJQJo( ""^"`OJQJo(o ^`OJQJo( ^`OJQJo( ^`OJQJo(o bb^b`OJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(zz^z`o(.JJ^J`.L^`L.  ^ `.  ^ `.L^`L.ZZ^Z`.**^*`.L^`L.h hh^h`OJQJo(h 88^8`OJQJo(oh ^`OJQJo(h   ^ `OJQJo(h   ^ `OJQJo(oh xx^x`OJQJo(h HH^H`OJQJo(h ^`OJQJo(oh ^`OJQJo(^`o(.^`.pLp^p`L.@ @ ^@ `.^`.L^`L.^`.^`.PLP^P`L.^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(h ^`OJQJo(h ^`OJQJo(oh   ^ `OJQJo(h R R ^R `OJQJo(h ""^"`OJQJo(oh ^`OJQJo(h ^`OJQJo(h ^`OJQJo(oh bb^b`OJQJo(zz^z`OJPJQJo(- JJ^J`OJQJo(o ^`OJQJo(   ^ `OJQJo(   ^ `OJQJo(o ^`OJQJo( ZZ^Z`OJQJo( **^*`OJQJo(o ^`OJQJo(gJh` 3 ~}|<(u TbIIm)(IflPH eJ$T( @CJ0OJQJo(" (/@CJ$OJQJo( !DEKS`apuy}~Ob@0_@0@0@EE|~EEaP @ GTimes New Roman5Symbol3 Arial7Courier3Times5 Tahoma? Courier New;Helvetica;Wingdings"qh˕f˕f˕f Tb5L C>0dh2q;Flexible QoS-Adaptation Through Self-Managing Agent Systems John Zinky John Zinky Oh+'0, @L h t  '<Flexible QoS-Adaptation Through Self-Managing Agent Systemslex John ZinkySohnohnNormaln John ZinkyS2hnMicrosoft Word 10.1@F#@xCa@;Ca@;Ca  ՜.+,D՜.+,x4 px  'esbT <Flexible QoS-Adaptation Through Self-Managing Agent Systems Title< 8@ _PID_HLINKS'A*f(http://www.idi.ntnu.no/~monica/iiis-98/ZQ "mailto:franco.zambonelli@unimo.it  http://www.wkap.nl/EGmailto:aricci@deis.unibo.itR mailto:s.ossowski@escet.urjc.esDJhttp://www.crcpress.com/L g :rules2.tiff  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDFGHIJKLNOPQRSTYRoot Entry FJ"a[Data +1TableBWWordDocumentKSummaryInformation(EDocumentSummaryInformation8MCompObjDObjectPoolJ"aJ"a FMicrosoft Word DocumentNB6W