Organizing Web Services to develop Dynamic, Flexible,Distributed Systems

Frank DignumUtrecht University

Utrecht, The Netherlandsdignum@cs.uu.nl

Virginia DignumUtrecht University

Utrecht, The Netherlandsvirginia@cs.uu.nl

Julian PadgetUniversity of BathUnited Kingdom

jap@cs.bath.ac.uk

Javier Vázquez-SalcedaUniversitat Politècnica de

CatalunyaBarcelona, Spain

jvazquez@lsi.upc.edu

ABSTRACTWeb services are increasingly behaving as nodes in a digital, dy-namic ecosystem. On the one hand, this new situation requiresflexible, spontaneous and opportunistic collaboration activities tobe identified and established among (business) parties. On the otherhand, it also requires engineering approaches able to integrate newfunctionalities and behaviours into running systems and active, dis-tributed, interdependent processes. In this paper we present a multi-level architecture, combining organisational and coordination the-ories with model driven development, for the implementation, de-ployment and management of dynamic, flexible and robust service-oriented business applications.

1. INTRODUCTIONA new generation of networked applications based on the no-

tion of software services that can be dynamically deployed, com-posed and adapted will make it possible to create radically newtypes of applications. These applications will be able to commu-nicate, flexibly reconfigure at runtime, adapt to their environmentand dynamically combine sets of simple, specialised, independentservices into more comprehensive (business) services. This will re-quire profound changes in the way software systems are designed,deployed and managed, replacing existing “design in isolation” en-gineering with new approaches able to integrate new functionalitiesand behaviours into running systems and active, distributed, inter-dependent processes.

Technical progress in the area of service-oriented architectures(SOAs) in recent years has been impressive, with new models, toolsand standards emerging to cover a wide range of core and relatedfunctions. The main areas of progress include:

• interoperability (SOAP [19], WSDL [22] and OGSI [15]);

• discovery and management (UDDI [14] and WS-Management[4]);

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.iiWAS2009 December, 1416, 2009, Kuala Lumpur, MalaysiaCopyright 2009 ACM 978-1-60558-660-1/09/0012 ...$10.00.

• orchestration and choreography (WS-BPEL [7], XPDL [23],ebXML [13] and WS-CDL [21]);

• association of semantics with Web-services (OWL-S [20] andWSMO [24]).

Furthermore, advances have come from a variety of sources, in-cluding enterprise interoperability, grid computing, software en-gineering, database and knowledge-base theory, artificial intelli-gence, object-oriented systems and logic.

This rapid progress has, for the first time, raised the realistic pos-sibility of deploying large numbers of services in intranets and ex-tranets of companies and public organisations, as well as in the pub-lic Internet, in order to create communities of services that are al-ways connected, frequently changing, open or semi-open, and formthe baseline environment for software applications. However, thisshift brings about not only potential benefits, but also serious chal-lenges for how such systems and applications should be designed,managed and deployed. Existing approaches in some important ar-eas (such as security, transactions and federation) tend to cover onlytechnology issues such as, for example, how to secure a protocolor connect federated directories, without considering the paradigmchange that occurs when large numbers of services are deployedand managed over time. In particular, existing approaches do notoffer satisfactory answers to the following questions:

• How to manage workflows in non-trivial environments, wherenot all services are owned by the same organisation? Sincewe cannot assume that all parties are either benevolent orthat they will deliver results unless explicit obligations aredefined and enforced, should workflows be agreed upon byall parties before they can be executed?

• How to align the configurations and settings needed by a ser-vice to operate with those of the operational environment?

• How is service execution affected by issues of trust, rights,obligations and prohibitions?

• What if critical applications simply cease to function if ser-vices provisioned from third parties disappear or malfunc-tion?

• How to deal with knowledge representation, when connect-ing or binding together two or more actual entities or servicesusing different ontologies?

These issues point to the need for a “social layer” as part of theservice interaction context. From an engineering perspective, newapproaches are needed that take an holistic view of service environ-ments, and take into account not only the properties of individualapplications, but also the objectives, structure and dynamics of thesystem as a whole. In recent years, research in fields as diverseas social science, management science, economics, biology, dis-tributed systems and multi-agent systems has analysed, modelledand explained a wide range of social phenomena often seen in hu-man and animal societies and tried to apply those results to com-putational systems. In particular, techniques have been developed,that:

• Make it possible to characterise and model the organisationalstructures commonly used by humans to organise themselvesin societies with particular needs;

• Capture coordination patterns that are often used betweenhumans to solve common problems (e.g., to sell goods orachieve specific goals);

• Characterise autonomous actors in an environment and modeltheir potential, rational behaviour (in order to predict, for ex-ample, how individuals will act in the context of a given setof “rules”).

The rest of this paper describes how we try to deal with the issuesmentioned above using the ALIVE1 architecture. In the ALIVEarchitecture, the service layer is extended with a coordination andan organisation layer. Each of the layers deals with some specificissues mentioned above avoiding a monolithic solution.

This paper is organised as follows. Section 2 describes a de-tailed view of the architecture. The three subsequent sections pro-vide more details for each of the three layers - namely organiza-tion, coordination and service - and their connections. In section6 some use cases are presented that illustrate the usefulness of ourapproach. The final section gives the conclusion and outlines di-rections for future research.

2. PROPOSED ARCHITECTUREThe proposed ALIVE architecture combines model driven devel-opment (MDD) [16] with coordination and organisational mecha-nisms, providing support for live (that is, highly dynamic) and opensystems of services. ALIVE’s approach extends current trends inengineering by defining three levels in the design and managementof distributed systems: the Service Level, the Coordination Leveland the Organisation Level, illustrated in Fig. 1, and explained be-low.

The Service Level extends existing service models, in order tomake components aware of their social context and of the rules ofengagement with other components and services, by making use ofsemantic Web technologies. This “semantification” is particularlyuseful when highly dynamic and frequently changing services (theWSs in Fig. 1) are present in the system, as the meta-information ineach service description (stored in a service directory) eases suchprocesses as finding substitute services if a given service does notrespond to invocations.

The Coordination Level provides the means to specify, at a highlevel, the patterns of interaction among services. In current ser-vice oriented systems the coordination between services is spec-ified using choreography and orchestration languages. However,1The ALIVE research project (http://www.ist-alive.eu/) isfunded by the European Commission within the 7th FrameworkProgramme for RTD (contract FP7 215890).

these tools assume that the coordination patterns are designed off-line and the whole workflow is predetermined. This works fine inapplications where the system is designed by people beforehandand no adjustments to the workflow are needed during execution.However, problems arise when workflows have to be changed dueto changing circumstances or unavailability of services. In ALIVEwe use a variety of powerful coordination techniques from recentresearch in the area [5, 12], based on agent technology. For thesetechniques a special kind of services are introduced at this level:agentified services. These services are organisation-aware, that is,they are aware of the system objectives and manage task allocationand workflow generation and agreement. Because the agents areaware of the purpose of a workflow they have handles to changethe workflow within the limits that it still fulfills the same purpose.Also, at the coordination level agreed workflows can be adaptedwhile the system is running – this is very useful when the systemhas to react to failures or exceptions (e.g. failing payment or book-ing systems).

On top of the coordination level we define a further level, theOrganisational Level, which provides a social context for the Co-ordination and the Service levels. The organisation level specifiesthe organisational rules that govern interaction. It is assumed thatthe organisational level is the most stable description of the systemin the long term. So, many facets are described only in an ab-stract way so as to allow for more than one implementation and/orchanges of implementation (different services, workflows, interac-tion patterns) over time. The most striking example of this ab-straction is that, on this level, the system is defined on the basisof goals and results and we abstract away from the specific actionsused to accomplish these results and goals. In some sense, the or-ganisational level defines the playground within which boundariesthe coordination and service levels can move. It thus secures someoverall stability of the system and guarantees global results that arerequired of the system. Although the organisational level is quitestatic we also use recent developments in organisational dynamics[18] to allow the structural adaptation of the global system overtime. This is important when frequent changes of rules and restric-tions are expected, but should be used as little as possible.

The ALIVE architecture can be seen as a service-oriented mid-dleware supporting the combination, reorganisation and adaptationof services at both design- and run-time. These activities followorganisational patterns and adopt coordination techniques. Fur-thermore, the MDD paradigm integrated in the architecture offerssignificant assistance to system developers, as it provides semi-automated transformations between models at the three levels de-scribed above, as well as the capacity for multiple target platformsand representation languages. Finally, there are graphical tools tosupport system administrators in the management of a distributedsystem. The Monitor Tool allows the administrator to inspect thestatus of a system’s execution, getting information from the dif-ferent components in the on-line architecture (especially from themonitoring components). In this way the administrator can keeptrack of the events generated at execution time and inspect howthe system handles them. The Service Set-up Tool can be used bysystem administrators to check and modify the setup of the run-ning environment. Finally the Service Matchmaking Tool (also usedoff-line) allows administrators to search manually for services thatmatch a given task description (by using the matchmaker compo-nent) when the system is not able to cope with a particular issueor the administrator wants to change manually an automatically se-lected service for another that is considered more suitable for rea-sons not modelled within the ALIVE framework.

In the next three sections, a more detailed description of the ar-

Figure 1: ALIVE Multi-Level Architecture

chitecture is provided. Complementary theoretical aspects are de-scribed in [1] and related methodological aspects are described in[2].

3. THE ORGANISATIONAL LEVELAs can be seen from Fig. 1 we use a special tool (the OperettA

Tool) to model the organisational level of the system. The toolis based on the framework for Agent Organizations (OperA) [3],which is a general framework to specify the organizational contextof multi-agent systems. Within OperA an organisation is viewedas a set of entities (the stakeholders) and their interactions, whichare regulated by mechanisms of social order. One important as-pect of the organisational models built by this tool is that they ab-stract away from the low-level details of the services that may beinvoked. The interaction with some end users (see section 6) hasshown that this abstract specification is easy to understand to non-software specialists, easing the validation of designs by end users.The functionality of this tool is extended by the Dynamic Organi-sational Modelling plug-in, for those applications which need extramethods and components to handle dynamic organisational change.

The Model Checker is used to verify some properties of organ-isational models. E.g., if a role of manager depends on a role ofsalesman to get information then an interaction scene is definedwhere this information exchange is modelled. This component notonly is used at design time but can also be used on-line duringthe execution of the system. The Model Checker Tool thus com-plements the OperettA Tool, and is linked directly to it through abutton in the OperettA interface.

The organisational model designed on this level is specified interms of four structures:

• The social structure specifies objectives of the society, itsroles and what kind of model governs coordination.

• The interaction structure describes interaction moments, asscene scripts, representing a society task that requires the co-ordinated action of several roles, and gives a partial orderingof scene scripts, which specify the intended interactions be-tween roles.

• The normative structure expresses organisational norms andregulations related to roles.

• The communicative structure specifies the ontologies for de-scription of domain concepts and communication illocutions.

We will briefly explain what types of things are modeled by eachof these structures.

3.1 Social structureThe social structure of an organization describes the objectives

of the society, its roles and what kind of model governs coordina-tion. The central concept in the social structure description is therole. Roles are abstractions providing a means of generically ad-dressing stereotypical (expected) behaviours (i.e. whoever takes upa role is expected to behave in a particular way) [3]. Roles identifyactivities necessary to achieve organisational objectives and enableabstraction from the specific actors and/or services that will even-tually perform them. That is, roles specify the expectations of theorganisation with respect to the actor’s activity in the organisation.Roles are described in terms of objectives (what an actor of therole is expected to achieve) and norms (how is an actor expected to

behave). Furthermore, role descriptions also specify the rights as-sociated with the role. Actors of institutional roles are fixed andcontrolled by the society and are designed to enforce the socialbehaviour of other agents in the society and to assure the globalactivity of the society. External roles can in principle be enactedby any actor, according to the access rules specified by the society.Typically, services that are not under direct control of the organi-zation are modeled on the organisational level by external roles.E.g. when a weather service is used from a third party, the role ofthis party in the entire process should be specified and modeled asan external role with its own objectives (e.g. sell its services to asmany parties as possible).

The notion of role is closely related to those of cooperation andcoordination. Societies establish dependencies and power relationsbetween roles, indicating relationships between roles. These re-lationships describe how actors can interact and contribute to therealization of the objectives of each other. The relations betweenroles are expressed in their role dependencies. The role dependencybetween two roles means that one role is dependent on another rolefor the realization of its objectives. Each role dependency givesrise to an interaction pattern in which the actors fulfilling the rolesdelegate tasks and report on their activities.

3.2 Interaction structureThe interaction structure describes a partial ordering of a num-

ber of scenes in which the roles interact. In some sense it definesa very abstract workflow of the whole system. Following pathsthrough the different scenes should lead to fulfilling the overall ob-jectives of the organisation. Each of the scenes specifies whichroles interact, its intermediate states of interaction (interaction pat-terns) its desired results (scene results) and the norms regulatingthe interaction (scene norms). The specification of the expected in-teraction in scenes is based on the concept of landmark patterns.Landmark patterns give a partial ordering by describing temporalrelationships between landmarks. Landmark patterns describe thestates that must be part of any protocol that will eventually be usedby actors to achieve the scene results. Landmarks and landmarkpatterns thus provide an abstract and flexible way to describe ex-pected interactions.

A scene is related towards the achievement of one or more objec-tives. Usually all role objectives should be related to scene results.Scene results are declarative state expressions that describe the de-sired final states for the scene, that is, the states in which the sceneends and actors can leave it successfully.

3.3 Normative structureThe normative structure is the part of the Organisational Model

that represents the collection of norms and rights related to the so-cial and interaction structures. In our framework norms define theobligations, permissions and prohibitions of the actors in the or-ganisation, related to the roles they play, or to a particular areaof activity. We distinguish regulative and constitutive norms [6].Regulative norms regulate agents behaviour enacting roles. Theyare expressed by means of deontic declarative expressions. Consti-tutive norms regulate the creation of institutional facts. The con-stitutive norms will be part of the ontological specification of thesystem in the form of "counts-as" statements. E.g. sending creditcard number, security number and name counts as payment. So,the constitutive norms indicate which concrete actions and factsare related to the organisational concepts. The regulative norms arespread over role norms, scene norms, and transition norms:

• Role norms specify the rules of behaviour for actors perform-ing that role, irrespective of the interaction scene.

• Scene norms describe the expected behaviour of actors in ascene.

• Transition norms: Impose additional limitations to actors at-tempting to follow a transition between two scenes. Theseare typically used if a result in one scene limits the possibil-ities of accessible scenes afterwards (e.g., buying somethingin the auction scene creates an obligation to pass the paymentscene afterwards).

Role rights (also role-rights or role capabilities) indicate the capa-bilities that actors of the role receive when enacting the role. Theseare capabilities that an agent usually does not possess but whichare inherent to the role. E.g. as a customer of a bank I can use theInternet banking facilities of that bank.

3.4 Communicative structureIn the communication structure the communication primitives

are described. I.e. both the message types that can be used as wellas an ontology that defines the concepts used in the messages andthe rest of the specification. Practically, it is possible to connectOperettA to a domain ontology, use the entities of the ontology inthe organisational model, and ensure the consistency of the entitiesacross the different structures of the organisational level and a con-sistent connection between organisational model and coordinationmodel.

The message types that can be used at the organisation level in-dicate what type of protocols can (or should) be used to implementinteractions. If only "delegate" or "order" messages and "accept"and "reject" messages are specified the protocols will be very sim-ple and direct, but also limited in functionality. If "requests" and"answer" are allowed the door is opened to negotiations over tasks,which allows for far more flexibility.

4. THE COORDINATION LEVELThe organisational model of the system is meant to provide a

kind of background model for the rest of the system that indicatesthe boundaries and norms to which the system should adhere. Theidea is thus that this organisational model will hardly ever changein the lifetime of the system. In contrast, the coordination and ser-vice level parts of the system are supposed to adapt to the currentsituation. Therefore they have an off-line, design component andan on-line component that is used while the system is running.

The Coordination Design Tool is used by designers and systemadministrators to create and manage the coordination model of agiven application. The coordination level connects the high level,abstract objectives of the organisation to workflows that invoke ser-vices that can actually achieve those objectives. To achieve thisconnection the level consists of two main components, the agentsand the workflows (or plans). The tool assists the user in the defi-nition of actors and tasks, the generation of the agents that will per-form the actual coordination tasks and the inspection of predefinedand generated plans. We use agents at this level because we do notonly want to create static workflows that will achieve the organisa-tional objectives, but we want to be able to create these workflowson the fly from existing plan libraries and also be able to adjustthem when circumstances require so. In order to do this we needagents that can fulfill organisational roles and thus "know" aboutthe organisational objectives for that role and the boundaries withinwhich that role has to act. Using knowledge about the purpose ofa workflow, planning knowledge and rights and duties attached tothe role the agent can reason and negotiate with other agents whichis the best course of action to reach the objectives of the organi-sation. We will now briefly describe the agent component and the

workflow component of the coordination level. After that we willdiscuss the monitoring tool and its role in adjusting the system tochanging circumstances.

4.1 Agents for coordinationAs can be seen from fig. 1 the agents at the coordination level

have three main tasks: planning, enacting and monitoring. Partof the specification of the agents comes from the role descriptionat the organisational level and ontological knowledge. The agentsare supposed to play a particular role in the system and thus theobjectives of the role, the interactions it should participate in andits rights and duties are used as the basis to define the goals (fromthe objectives and landmarks), plans and beliefs about the world.Although the organisational level describes what the agent shouldachieve (playing a particular role) it does not indicate how thisshould be done. So, the planning component is designed at the co-ordination level. Of course, agents should be endowed with enoughcapabilities to reach their objectives.

The actions of the agents can still be more abstract than the actualservices that are used on the service level, but they also can directlyuse available services. Therefore we see agents as agentified ser-vices that are organisation-aware and able to coordinate with othersaccording to a given organisation and coordination model. Theyare able to:

• Incorporate the description of an organisation role, includingits objectives, rights, obligations and prohibitions;

• Build, at run-time, local plans to fulfill the role’s objectives;

• Coordinate its activities with other agentified services, thusbuilding a partial global plan [11].

Agentified services can interact with normal Web services by meansof standard SOAP and REST interfaces. Furthermore agentifiedservices communicate coordination-related issues to other agen-tified services using protocol-based conversations expressed in acoordination language (based on GPGP) implemented over SOAP.The exchanged plans are abstract workflows possibly with tasks re-ferring to abstract services rather than to concrete ones (e.g., “mapservice” instead of “Google Maps”). When a plan is agreed upon,an agentified service will look (via the matchmaker component) forservices that can fulfil the abstract tasks, binding them together.

The matchmaker agent is a special agent that forms a gatewayfor the agents to the service level matchmaker component. Usinga matchmaker agent avoids each agent having to incorporate theprotocols to communicate with the service level matchmaker. Theycan now communicate with the matchmaker agent using requestsfor abstract services using the same language and protocols theyuse as for communicating with the other agentified services. Thematchmaker agent will translate the requests for abstract servicesinto service level queries and give answers back to the agents.

Finally, the agents at the coordination level also monitor the ex-ecution of the services (workflows) they invoke. One or severalMonitoring Components will then aggregate and analyse events re-lated to the execution of services, the fulfilment of coordinationplans and the achievements of role and/or organisational objectives.During the on-line execution, events are generated by the compo-nents (viz., the agentified services), whenever deviations, excep-tions or failures are detected that cannot be handled by the agen-tified service itself or the existing coordination plan in place. Insuch situations the current organisational model is evaluated andthen either (a) the objectives affected by the detected issue may bere-evaluated (their priority may be lowered or they may even be

dropped completely), or (b) more significant changes in the organ-isation model may be required (for instance, changing the rights ofa role). In case (a) the agent’s coordination modules will create anew plan based on the updated organisational objectives. In case(b) the updated model is sent to the Agent Generator component to(re)generate the agentified services that populate the system. De-pending on the set-up preferences of the administrator, the mon-itoring component may be a separate component used by severalagentified services or may be a federation of several componentsinside the agentified services themselves.

4.2 WorkflowsAs said before, the coordination level also supports the defini-

tion, composition and import of actions (descriptions) to be usedby the agents. A distinctive trait of the coordination models createdby this tool (in comparison with other orchestration and choreog-raphy technologies [7, 23, 13, 21]) is that the coordination modelsalso abstract away from the low-level details of the services thatmay be invoked. Actions are specified using an identifier (name)and their pre- and postconditions. This specification allows the useof (simple) planning systems to create workflows from actions toachieve certain goals. The designer is thus able to design the wholecoordination level of a distributed system by means of actors, tasks,plans and plan coordination mechanisms. The Agentified Servicesare the ones that connect, at execution time, the abstract tasks withthe actual services that are invoked. Apart of the dynamism this so-lution brings at execution time, this also allows end users to inspectand better comprehend coordination models.

5. SERVICE LEVELThe service layer connects existing, real-world services to the

coordination and organisational layers of an ALIVE organisationby mapping concepts, functionality and the rules of engagementwhich are already in existence to those relating to the organizationbeing synthesized. The service layer is concerned with the descrip-tion of services, components for selecting appropriate services fora given task and the execution and monitoring of services associ-ated with a given organisation. We will describe the service levelin three parts: the services, the matchmaker and the execution andmonitoring of the services.

5.1 ServicesOf course, the central entities on this level are the services. The

Service Design Tool is used by designers and system administratorsto generate or inspect service descriptions, edit service templatesand register them in the service directory. In order to discover orinvoke a particular service we use externalised descriptions of theservices properties and its semantics. These descriptions providethe necessary information about service interfaces and service op-erations and may be functional (relating to the actual operation andsemantics of the invocation of service operations) or non-functional(describing properties of a service, operation or interface which donot relate to the operational properties of that service). Functionaldescriptions are given for each operation of a given service andare typically broken down into Inputs, Outputs, Preconditions andEffects. Inputs are data which must be passed into an operation,descriptions may include a syntactic model of this data (e.g. XMLschema fragments) as well as semantic descriptions of the meaningof this data (e.g. OWL Classes for particular data types). Outputsare data which will be passed out of a service operation upon itssuccessful completion. As with inputs these may include syntacticdescriptions of the data being passed or semantic descriptions ofits meaning. Preconditions are descriptions of the state of affairs of

the world which must be satisfied at the point of invocation in orderfor a particular service operation to execute successfully. Precon-ditions may describe restrictions on the types of inputs acceptedby the service operation or external properties (such as constraintson the state of the service itself) which must be held to be true.Finally, Effects are descriptions of the new state of affairs of theworld which will be satisfied upon the successful invocation of agiven service operation. As with preconditions these may relateto the outputs of the service or to internal state of the service (orthe world). Effects may be conditional on the inputs to the servicesuch that invoking the service with one type of input might yieldone effect while invoking it with another would yield a differenteffect.

These descriptions may be incorporated into the services them-selves, or may be provided externally and may already be definedfor existing services or may need to be defined separately in or-der to incorporate existing services into an ALIVE organisation.Typically Service descriptions are broken down into "syntactic" de-scriptions which describe the interfaces, operations, operation typeparameters and interaction patterns of particular services, and "se-mantic" descriptions which extend these underlying descriptionswith higher-level information describing the semantics of opera-tions and their parameters in such a way that services may be in-voked by (semi-)automatically by intelligent agents or components.

Service operation descriptions are collected into a single serviceinterface description which defines the operations available for asingle service interface. In addition to defining the service oper-ations, service interface descriptions also define how those opera-tions are bound to particular protocols, (e.g. SOAP) and in somecases include the service endpoint address of the service interface.Service interface descriptions are represented using the Web Ser-vices Description Language (WSDL). Each service will have ex-actly one service interface description. In top of the service de-scription the service process model gives a high-level (semanticallygrounded) interpretation of a given call of a service interface de-scription, with each parameter (input or output) corresponding toan ontological type in OWL (as opposed to a simple XML type inWSDL).

In its turn the service process model is part of the service pro-file. The service profile describes the properties of a service whichmay be used during service discovery in the context of semanticweb services. In the context of OWL-S a service profile includesthe simple process model for a given service operation (top-levelinputs, outputs preconditions and effects (IOPE)), a taxonomic de-scription of the service which allows services to be selected by cat-egory, and other non-functional properties. Once a given service isselected only the process model and service grounding are requiredto invoke the service. Each service which may be used within theALIVE framework will have an associated service profile. For ser-vices which do not have a pre-existing service description it con-tains only the process model which can be inferred from an existingservice interface description.

When a given task is to be executed a process model will beselected using the matchmaking process and a service groundingwill be used to substitute appropriate input parameters into the ac-tual service invocation and to extract the relevant output parametersfrom any return values.

As indicated before, services can also be External Services. Thatis, existing, third-party services that have not been designed follow-ing the ALIVE methodology. These external services can also beinvoked at execution time according to their service description.Usually, however, external services are not consumed directly; in-stead, this is done via service adaptors. Service adaptors allow ex-

ternal services to be utilised for suitable organisational tasks. Typ-ical examples of adaptation are type translation services to adapta service interface to the entities and data types used by a givenorganisation.

5.2 MatchmakingIn order for an ALIVE organisation to be constructed and en-

acted, appropriate services must be selected for each functional unitof work within the organisation. The process of discovering suchservices is generally referred to as service discovery and match-making and may be conducted automatically based on publishedservice descriptions or with human assistance using the ServiceMatchmaking Tool (a human interface to the matchmaker compo-nent), allowing designers and system administrators to search forservices matching a given task description or satisfying a given ser-vice template and registering it in the service directory.

The Matchmaker is responsible for the discovery of appropriateservices that fulfil the requirements of a given task. Depending onthe level of abstraction of the task to be fulfilled, a matchmaker mayquery a service directory directly or by the use of service templates,which are intermediary descriptions linking higher-level goals ortasks (as specified in the Coordination Model) with specific serviceinteractions. A template includes a parameterised process modelfor a class of services in terms of pre- and post-conditions. If thedescribed process is of some complexity, such description may in-clude an abstract workflow fragment indicating required sub-stepsin the process. Parameters in a template are specified as abstracttypes linked to the variables or parameters in the process model.The parameters are dynamically bound at execution time into con-crete ontology instances and/or concrete service process modelswhen the template is selected by a matchmaker. Service templatedefinitions are stored in a Template Repository.

The Service Directory is a repository for service interface de-scriptions, service process models and service profiles. It supportsseveral query mechanisms for the discovery of specific servicesbased on their syntactic and/or semantic descriptions. Service di-rectories are used as part of the service discovery process in theservice layer and during the construction of abstract workflows inthe coordination layer. When a workflow is being constructed thecoordination layer may query service directories to determine if agiven service description can be satisfied. When a specific serviceis being bound to a give service process model in the executionphase a service execution framework will search and query one ormore service directories in order to list potential matches for a givenservice description which will in turn be filtered and ordered by oneor more service matchmakers. Depending on the requirements andsize of the distributed system, one or many service directories maybe deployed.

The matchmaking process operates in two phases: (i) identifica-tion of a candidate set of services, based on IOPE, using a subsumestype matcher [10], then (ii) computing a preference order based oncriteria supplied by the client, which is in effect a partial-order overthe subsumes requirement, through which we can construct eitherexact or plugin matches since these are both subsets of subsumes.

We have chosen to adopt the currently leading technology ofOWL-S as the basis for service description and matching. An OWL-S matchmaker is a service registry that supports service queryingbased on the service semantics, captured in corresponding OWL-Sdescriptions. It can be thought of as the analog of UDDI registriesfor web services, with the addition of OWL annotations to supportmore precise service specifications through the use of ontologies.

Here we provide a broad description of how the matchmakerhandles a matching query. At the very least, the query must de-

scribe the signature of the desired service, that is the classes of theinput and output parameters. Essentially such a signature expressestwo facts: (a) That the input parameter classes represent what theclient promises to be able to supply to a matched service in order toinvoke it. Thus, with the input parameter classes the client claimsthat it can fulfil any of these classes, that is it has, for any of theseclasses, an (indirect) instance of it, and (b) That the output param-eter classes represent what output is required (and can be handledby) the client. In other words, the user wants the service to produce,for any of these classes, some value that belongs to it.

The matchmaker then computes and returns the maximal set ofservices such that: (a) Their input parameters can be fulfilled bythe client, assuming only its advertised capabilities. That is, if theclient would be able to supply arguments to the exact service signa-ture it requested, then it can provably invoke the matched service.Note that a service may have more relaxed constraints on the inputsit requires, for example it may declare inputs that are superclassesof what the client can supply, thus they can by definition be fulfilledby a value that would fulfil the subclass, or it may declare fewerinputs, and (b) Their outputs (assuming the service is not abnor-mally terminated or unavailable) are guaranteed to supply a valuefor any output classes the client requested. Note that the serviceoutputs may be more specific (that is, subclasses) than the clientrequested, or it may produce more outputs, which could, of course,be ignored. The above matching criteria coincide with OWLS-MXsubsumes matching level [10].

After identifying the set of candidate services, the matchmakermay further order them according to the client’s preferences, sothat it finds the “best” results, according to the client’s perspective,on top and might, for example, be interested in “just the 5 bestmatches”, discarding the rest. The matching services may be aug-mented with further, arbitrary information to aid finding the best ofthem. For example, out-of-band information such as reliability orperformance statistics may be associated with services. The match-maker offers extremely flexible support for capturing and honour-ing client preferences. All that is needed is to define a partialorder function for the matched services, according to which thematchmaker orders the results, starting from the best elements tothe worst. This is much like sorting a list according to a total order,only more powerful. For example, the client may express prefer-ences such as “My top preference is for services that specify inputclasses closest to the ones I requested; then I care equally aboutbetter scoring services by textual descriptions against my descrip-tion, and finally services with good reliability”. The specification ofpreferences may be arbitrarily complicated. To cope with this, thematchmaker offers a small partial order algebra with composableoperators, capable of expressing arbitrary preferences in a conciseway, and which can be evaluated in order to find the best resultsaccording to it.

The objective is to create a PartialOrder[Match], which is thenapplied to the last function. We now summarise the key operators(given some type E):

1) create: [E] (dominates: (o1: E, o2: E) → boolean) → Par-tialOrder[E], which takes a binary function capable of compar-ing two objects and determining whether the first dominates thesecond

2) map: [E, T] (po: PartialOrder[T], mapper: (T → E)) → Par-tialOrder[E], whose purpose is to allow the construction of, say,a partial order over services by means of a metric function thatmaps a service to some measure. Thus, given some functionService → Integer, for some measure, we can construct a Par-tialOrder[Match] from a PartialOrder[Integer].

3) flatten: [E] (pos: Iterable[PartialOrder[E]], metaorder: PartialOrder[PartialOrder[E]]) → PartialOrder[E], whose purpose is to con-struct a single partial order of services from several partial or-ders, where the latter each captures the orderings of servicesaccording to a single client preference criterion while the resultreflects their combination by client preference ordering, such asin the (natural language) example in the preceding paragraph.

4) topElements: [E](elements: Iterable[E], po: PartialOrder[E])→ List[List[E]], whose purpose is to construct blocks of (mu-tually incomparable) results, where each succeeding block isdominated by some element of a preceding block.

Thus, we are able, with a high degree of generality able to iden-tify services that do what is required and furthermore to order themaccording to arbitrarily complex (as far as this is expressible inOWL) criteria.

5.3 Service execution and monitoringEach service has one or more service end points, which allow

communication with service consumers. In the case that a providerof a service is internal to the organisation, each of these end pointswill be associated with a service execution environment and a cor-responding agent which manages service invocations for that provider.For a given service interface, there may be more than one serviceprovider. A service endpoint is a deployed service interface, whichmay be invoked by a service consumer, either within or outsidethe organisation. Each service end point has (at least) a Servicelocation (URI), Service interface description (e.g. WSDL descrip-tion) and optionally a semantic description (process model) of theservices functionality and semantic description of the services non-functional properties (service profile). Service end points will bediscovered (through the service discovery and matchmaking pro-cess) in order to achieve specific goals within the organisation.These endpoints will be invoked by agents within the organisationas part of the process of those agents achieving specific organisa-tional goals.

A service execution framework may offer and/or consume webservices. Each service execution framework may be responsiblefor exposing multiple services. Internally deployed services areexpected to follow specific work flows, in cases where decisionsmust be made within these workflows the workflow execution en-vironment may delegate this decision making to a software agent.Service execution frameworks are used within the service layer todeploy the services which will be offered by the organisation andmanage the direct execution of the workflows associated with thoseservices. Service execution frameworks receive plans from thecoordination level as abstract workflows which will be deployedwithin the framework. As workflows are executed the service ex-ecution framework will pass service execution events to the ser-vice monitoring framework which account for significant eventsin the service execution process. When an abstract workflow isdeployed within an execution framework, the framework will useone or more service matchmakers in order to determine appropri-ate services for specific abstract workflow tasks, in addition wherematches require service adaptors those adaptors will be deployedwithin the execution framework.

The execution of the services is monitored by the service moni-toring framework which provides a means for tools at both the ser-vice level and at higher levels to aggregate and analyse events re-lating to the deployment and execution of services. Each executionframework will be associated with a given monitoring frameworkwhich will receive messages relating to the underlying service ex-ecution. The monitoring framework will store these messages and

allow historic interactions to be queried.

6. APPLICATION SCENARIOSThe ALIVE multi-level architecture is especially useful for sce-

narios where changes can occur at either abstract or concrete levels,and where services are expected to be continuously changing, withnew services entering the system and existing services leaving itat run-time. For example, when there is a significant change at ahigh level (e.g., a change in the organisational structure), the ser-vice orchestration at lower levels can be automatically reorganised.Another example is the automatic adaptation of higher levels whenlower ones suffer significant changes (e.g., the continuous failurein some low-level services). The ALIVE architecture is currentlybeing applied to three real-life applications:

• Dynamic orchestration of distributed services on interactivecommunity displays – The concept of interactive communitydisplays (ICDs) is to build a virtual space within which peo-ple in urban communities can interact and share knowledge,experiences, and mutual interests. ICDs integrate urban in-formation (in real time) and create public spaces in the In-ternet for people living in or visiting a city. ICDs are beingdeveloped all over the world in the context of digital cities[8]. An important question concerns why urban informationspaces attract people given this era of globalisation. The In-ternet has triggered global businesses, and at the same timeenables us to create rich information spaces for everyday life.While the Internet makes research and businesses global, lifeis inherently local. Business requires homogeneity to allowglobal competition, while life is heterogeneous, reflecting thedifferent cultural backgrounds [9]. TMT Factory, one of thepartners of the ALIVE project, is creating a personalised rec-ommendation tool which provides city services to residentsand tourists through ICDs These ICDs, installed in urban en-vironments, display tourist information and other services,dynamically personalised according to user preferences, ge-ographical location and local laws. The ALIVE architectureprovides support for the organisational modelling of the dif-ferent entities that offer services to users and dynamicallyadapts service composition in case of service failure.

• Communication in entertainment domains. Calico Jack Ltd.,another partner, is developing an Entertainment Communi-cations Router, a system that exploits the richness of onlineentertainment systems by coupling them with online socialnetworking resources. It manages the roles, identities andsocial relations that users have in different fora (e.g., Face-book, Second Life) to support rich forms of communicationbetween players driven by their social relations. In this casethe ALIVE architecture provides support for high-level con-text definition and management, including the description ofthe information routing rules according to the users’ socialrelations.

• Dynamic crisis management. THALES B. V., another part-ner of the ALIVE project, is creating an emergency simula-tion tool for the Dutch emergency forces. This simulator ef-fectively explores diverse crisis management scenarios whena natural disaster has escalating city- and nation-wide con-sequences, allowing policy makers to evaluate current andpotential emergency policies and procedures. The ALIVEarchitecture provides rich ways to describe all stakeholdersin different emergency scenarios, their roles, responsibilities

and dependencies and suggest the coordination strategies thatcan emerge according to a given set of policies.

Due to space limitations we cannot describe all three scenarios indepth. We will just discuss some of the advantages that the ALIVEframework brings for the crisis management scenario. More infor-mation about the implementation of the scenario can be found in[17].

6.1 Crisis management using the ALIVE ap-proach

In the crisis management scenario, we assume that a major stormis emerging above the North Sea after a long period of dry weather.Initially, the storm reaches the Port of Rotterdam, Europoort. Oneof Shell’s refineries is at risk: large quantities of petroleum productsand associated dangerous chemicals may be dispersed at any mo-ment. As the disaster progresses, several dikes are breached, flood-ing northern Rotterdam. Due to recent weather conditions severalinland dikes outside of Rotterdam have dried out completely. Sud-den inundation of water causes them to weaken and breach as well.This causes other suburbs of Rotterdam to flood as well.

The Netherlands has an extensive crisis management structureto respond to such disasters. This structure is based on the sever-ity of the disaster, and allows local, regional and national author-ities to take action where necessary. Most incidents are relativelyminor, and do not require much cross-organizational interactions.However, when a more complex crisis does arise, this structure de-fines how first responders within a safety region, that is, the po-lice, fire and medical services, municipal governments and otherservices, are to cooperate. Procedures for coordinated regionalincident handling in the Netherlands, GRIP (Gecoordineerde Re-gionale Incidentenbestrijdings Procedure) have been standardized2

by the Dutch Ministry of Internal Affairs. GRIP levels provide amechanism to describe the severity of a problem. As a crisis growsand more responders become involved, more organization betweenthese responders is required. At a regional and national level, theLOCC acts as a dedicated crisis management coordinator with linksto all of the emergency response services/organizations.

The organizational model in ALIVE specifies the necessary com-ponents of the crisis management domain at a level of abstrac-tion that allows the organization to remain stable over the differentGRIP levels, but still providing enough meaningful information tohelp the simulation design. The social structure (i.e. roles and de-pendencies) of the crisis management organization is depicted infigure 2.

Each role in the organization has its own objectives and norms.Informally, the objectives of the roles shown in figure 2 are as fol-lows. The Coordinator is responsible for solving the crisis, theGovernment wants to be informed at all times of the situation sta-tus, the Medics aim at evacuating and/or treating casualties, the Po-lice must maintain order, the Firemen to save/rescue people and as-sets, the Army should provides logistic support and the InformationProviders (which denotes a group of several roles with the sameobjectives) are responsible to provide reliable information.

The number of agents playing a role can change from one GRIPto another. For example, at GRIP-1, the Police role is typicallyenacted by a single agent (i.e., there is only one Police Officer in-volved in the crisis handling). At GRIP-2, however, the police rolemight be enacted by several units. These police units, while theiroverall interaction with the coordinator remains the same, now havean internal structure (a hierarchy in this case) and Police-specificcoordination and control mechanisms (e.g., the order objective can2http://www.handboekrampbestrijding.nl

!""#$%&'("#)

*"+%,-)

.-$%,/)

0%#-)

1#23)

4&5"#2'6"&)

*#"7%$-#)

8"7-#&2-&()

8)

%&5#'/(#9,(9#-:)

/9;;"#()

#-/,9-:)

,"&('%&2-&()

"#$-#)

2-$%,'+)

'//%/('&,-)

</('(9/=>)

#-;"#(/)

%&5"#2'6"&)

2'&;"?-#) 2'&;"?-#)

.)

.)

.)

.)

.)

Figure 2: Organizational Role Dependency Graph.

be divided in sub-objectives, for example, regulate traffic, patrolsector B5, etc., which are assigned to different units). These inter-nal structures are unimportant for the crisis management organiza-tion, and can safely be abstracted from. Roles which can have suchinternal structure (at a higher GRIP) are denoted with an M ; inessence, the role is enacted by a multi-agent system (or, sometimeseven, by a multi-agent organization).

Note that some of the roles will not be enacted at the lower GRIPlevels (e.g., the roles of Government or Army will not be relevantin GRIPs below GRIP-2 and GRIP-3, respectively).

A simple interaction structure is depicted in figure 3 definingthe order in which the interactions between the roles in the orga-nization should take place. Interactions are grouped into scenes,where a scene reflects a meaningful (on its own standing) subset oforganizational interaction related to the achievement of a (set of)(sub)objectives.Each scene in the interaction structure can be further detailed asa landmark pattern. Figure 3(C) shows the landmark pattern forthe Handle Incident scene. Landmarks denote the important statesthat should be reached in the achievement of the scene, and thelandmark pattern imposes an ordering over these landmarks to de-note the order in which these important states should be reached.The landmark pattern of the Handle Incident scene has 2 land-marks: evaluate_severity, and evacuate_people leading to a endstate where location is safe.

This organization structures are used at Coordination Level todetermine concrete workflows and interaction protocols. An exam-ple of such protocol is depicted in figure 4.

As mentioned above, the landmark pattern provided for the sceneHandle Incident at OL only specifies two important objec-tives (landmark states) to be achieved by role enacting agents dur-ing scene execution. Therefore, procedural information needs to beadded at CL, as described in the workflow in figure 4. Differenttypes of emergency situations will call for different interpretationsof the OL descriptions.

The resulting workflow patterns contain abstract actions that areexecuted by services at the service level. As the services for thissimulation are all internal, this part is pretty straightforward andleft out for reasons of space.

7. CONCLUSIONSThe ALIVE framework aims to support the design and devel-

opment of distributed systems suitable for highly dynamic envi-ronments, based on model-driven engineering, and three intercon-nected levels: service, coordination and organisation.

The crucial distinction of the ALIVE approach from existingones is that it provides an organisational context (such as, for in-stance, objectives, structures and regulations) that can be used toselect, compose and invoke services dynamically. ALIVE also pro-vides a notion of organisational awareness to some components(such as the agentified services at the Coordination Level or thematchmaker component at the Service Level) that can direct systemexecution in order to achieve higher-level organisational objectives.One of the effects is that exceptions can be managed not only at thelower level (as in other service-oriented architectures) but at higherlevels, looking for alternative ways to fulfil a task or even a fullabstract workflow by agreeing upon a new plan of action. Further-more, organisational and coordination models are defined at a levelof abstraction that allows non-expert end-users to support better thedesign and the maintenance of the system.

The first version of the ALIVE tool suite is now under develop-ment and will become available through the project’s Sourceforgesite3.

AcknowledgementsThis research has been carried out within the FP7-215890 ALIVEproject, funded by the European Commission. Javier Vázquez-Salceda is partially funded by the Ramón y Cajal program of theSpanish Ministry of Education and Science. We are grateful toDimitris Andreou for detailed discussions on the design and func-tion of the matchmaking process and of course to all other membersof the ALIVE consortium.

8. REFERENCES[1] ALIVE project: ALIVE Theoretical Framework.

http://www.ist-alive.eu. Retrieved 20090823.[2] ALIVE project: ALIVE Methodology Document.

http://www.ist-alive.eu. Retrieved 20090823.[3] Dignum, V.: A Model for Organizational Interaction: based

on Agents, founded in Logic. PhD thesis, UniversiteitUtrecht, 2004.

[4] DMTF: Web Services Management.http://www.dmtf.org/standards/wsman/.Retrieved 20090823.

[5] Ghijsen, M., Jansweijer, W., Wielinga, B.B.: Towards aFramework for Agent Coordination and Reorganization,AgentCoRe. In: Coordination, Organizations, Institutions,and Norms in Agent Systems III. LNCS, vol. 4870, pp. 1–14.Springer, Heidelberg (2008).

[6] Grossi, D.: Designing Invisible Handcuffs: FormalInvestigations in Institutions and Organizations forMulti-agent Systems. PhD thesis, Universiteit Utrecht, 2007.

[7] IBM: Business process execution language for web servicesversion 1.1, July 2003.www.ibm.com/developerworks/library/ws-bpel/.Retrieved 20090823.

[8] Ishida, T., Ed.: Understanding Digital Cities: Cross-CulturalPerspectives. MIT Press, Cambridge, MA, USA (2000)

[9] Ishida, T.: Digital City Kyoto. Communications of the ACM,vol. 45, no. 7, pp. 76–81 (2002)

[10] Klusch, M., Fries, B., Sycara, K.: OWLS-MX: A hybridSemantic Web service matchmaker for OWL-S services.Journal Web Semantics, vol. 7, no. 2, pp. 121–133 (2009)

[11] Lesser, V: Evolution of the GPGP/TAEMSdomain-independent coordination framework. In AAMAS

3http://sourceforge.net/projects/ict-alive/.

Figure 3: Organizational Interaction Pattern.

Figure 4: Possible workflow model at CL to deal with the scene Handle Incident of Figure 3.

’02: Proceedings of the First International Joint Conferenceon Autonomous Agents and Multiagent Systems, pages 1-2,New York, NY, USA, 2002. ACM.

[12] Matskin, M. et al.: Enabling Web Services Composition withSoftware Agents. In: Proc. of the Conference on Internet andMultimedia Systems, and Applications. Honolulu (2005)

[13] OASIS: The Framework for eBusiness. April 2006.http://www.ebxml.org/. Retrieved 20090823.

[14] OASIS: Universal Description, Discovery and Integration(UDDI) version 3.0.2. OASIS, 2002. Available at:http://www.uddi.org/pubs/uddi_v3.htm.Retrieved 20090823.

[15] OGSI Alliance: OGSI Specifications.http://www.osgi.org/Specifications/HomePage.Retrieved 20090823.

[16] OMG: Model Driven Architecture.http://www.omg.org/mda/. Retrieved 20090823.

[17] Quillinan, T., Brazier, F., Aldewereld, H., Dignum, F.,Dignum, V. Penserini, P., Wijngaards, N.: DevelopingAgent-based Organizational Models for Crisis Management.In AAMAS’09 Proceedings of AAMAS 2009, IndustialTrack. IFAAMAS.org, Budapest, Hungary, (2009).

[18] van der Vecht, B., Dignum, F., Jules, J., Meyer, Ch., Dignum,V.: Organizations and Autonomous Agents: Bottom-up

Dynamics of Coordination Mechanisms. In: 5th Workshopon Coordination, Organizations, Institutions, and Norms inAgent Systems. Estoril (2008).

[19] W3C: Simple Object Access Protocol (SOAP) 1.1. W3CNote, fromhttp://www.w3.org/TR/2000/NOTE-SOAP-20000508.Retrieved 20090823.

[20] W3C: OWL-S - Semantic Markup for Web Services, 2004.http://www.w3.org/Submission/OWL-S/.Retrieved 20090823.

[21] W3C: Web Service Choreography Description Language(WS-CDL), 2005.http://www.w3.org/TR/ws-cdl-10/. Retrieved20090823.

[22] W3C: Web Service Description Language (WSDL), 2001.http://www.w3.org/TR/wsdl. Retrieved 20090823.

[23] WfMC. XML Process Definition Language (XPDL).Document Number WFMC-TC-1025: Version 1.14Document Status - Final (2005).

[24] WSMO working group: Web Service Modeling Ontology.ESSI cluster http://www.wsmo.org/. Retrieved20090823.