T O R O N T OThe 9th International Conference on

Autonomous Agents and Multiagent SystemsMay 10-14, 2010Toronto, Canada

Editors:Wiebe van der Hoek

Gal A. KaminkaYves Lespérance

Michael LuckSandip Sen

Workshop 28

International Workshop on Service-Oriented Computing: Agents,

Semantics and Engineering

SOCASE

 

PROCEEDINGS

5TH WORKSHOP

SERVICE-ORIENTED COMPUTING:

AGENTS, SEMANTICS, AND

ENGINEERING

(SOCASE)

2010

AAMAS 2010 Workshop

Organizers:

Michael Huhns

Ryszard Kowalczyk

Zakaria Maamar

Rainer Unland

Bao Vo

PREFACE

The goal of the Service-Oriented Computing: Agents, Semantics, and Engi-

neering (SOCASE) workshop series is to present and discuss the recent signifi-

cant developments at the intersections of Multi-agent Systems, Semantic Tech-

nology, and Service-Oriented Computing, and to promote cross-fertilization of

techniques. In particular, the workshop aims at identifying techniques from

Multi-agent System and Semantic Technology research that will have the

greatest impact on automating service-oriented application construction and

management, focusing on critical challenges such as service quality assurance,

reliability, and adaptability.

Since its first edition in 2006, SOCASE has been a forum for academics,

practitioners, users and vendors, allowing all to discuss the use of and synergy

between service oriented computing, semantic technologies, and multi-agent

systems.

The organizers would like to express their gratitude to the authors, for

submitting their work, and, especially also, to the Program Committee, for pro-

viding very thorough evaluations of the submitted papers and for the discus-

sions that followed under extreme time constraints. It was their hard work that

in the final end made this workshop possible. We also would like to thank the

AAMAS organizers and, especially, the workshop organizer Kagan Tumer, for

their support, especially when things were not going as well as originally as-

sumed.

March 2010 Michael Huhns

Ryszard Kowalczyk

Zakaria Maamar

Rainer Unland

Bao Vo

ORGANIZATION

Organizing Committee

Michael Huhns, University of South Carolina (USA)

Ryszard Kowalczyk, Swinburne University of Technology (Australia)

Zakaria Maamar, Zayed University (UAE)

Rainer Unland, University of Duisburg-Essen (Germany)

Bao Vo, Swinburne University of Technology (Australia)

International Program Committee

Ambroszkiewicz, Stanislaw, Polish Academy of Sciences, Poland

Baruwal Chhetri, Mohan, Swinburne University of Technology, Australia

Bendiab, Taleb, Liverpool John Moores University, UK

Blake, M. Brian, University of Notre Dame, USA

Brandic, Ivona, Vienna University of Technology, Austria

Branki, Cherif, University of West Scotland - Paisley, UK

Brazier, Frances, Delft University of Technology, The Netherlands

Cliffe, Owen, University of Bath, UK

Derksen, Christian, University of Duisburg-Essen, Germany

Dignum, Frank, University of Utrecht, The Netherlands

Dignum, Virginia, Delft University of Technology, The Netherlands

Eymann, Torsten, University of Bayreuth, Germany

Garcia Dominguez, Antonio, University of Cadiz, Spain

Guttmann, Christian, Monash University, Australia

Hirsch, Benjamin, Berlin University of Technology, Germany

Huhns, Michael, University of South Carolina, USA

Klusch, Matthias, German Research Center for Artificial Intelligence, Germany

Kowalczyk, Ryszard, Swinburne University of Australia, Australia

Lamersdorf, Winfried, University of Hamburg, Germany

Lessner, Tim, University of Scotland - Paisley, UK

Maamar, Zakaria, Zayed University, United Arab Emirates

Mansoor, Wathiq, American University of Dubai, United Arab Emirates

Moench, Lars, University of Hagen, Germany

Monakova, Ganna, University of Stuttgart, Germany

Nissen, Volker, Technical University of Ilmenau, Germany

Oberweis, Andreas, Karlsruhe Institute of Technology, Germany

Ortiz-Bellot, Guadalupe, University of Cadiz, Spain

Ossowski, Sascha, Rey Juan Carlos University, Spain

Padget, Julian, University of Bath, UK

Paprzycki, Marcin, Systems Research Institute of the Polish Academy of Sci-

ences, Poland

Petcu, Dana, Western University of Timisoara, Romania

Quillinan, Thomas, Thales Netherlands, Netherlands

Quoc Vo, Bao, Swinburne University of Technology, Australia>

Singh, Munindar, North Carolina State University, USA

Stein, Sebastian, University of Southampton, UK

Tianfield, Huaglory, Glasgow Caledonian University, UK

Timm, Ingo, Goethe University, Germany

Unland, Rainer, University of Duisburg-Essen , Germany

Walz, Alexander, University of Stuttgart, Germany

Weyns, Danny, Katholieke Universiteit Leuven, Belgium

Zambonelli, Franco, University of Modena and Reggiio Emilia, Italy

TABLE OF CONTENTS

Invited Talk

ISReal: Semantics, Services and Agents for the Future 3D Internet

Matthias Klusch

Accepted Papers

Governance of Services: A Natural Function for Agents

Frances Brazier, Frank Dignum, Virginia Dignum, Michael N. Huhns, Tim

Lessner, Julian Padget, Thomas Quillinan and Munindar Singh

Evolving Formal Models: Multi Agent Self-Organisation for Governance and

Regulation in Service Oriented Systems

Martin Randles, A. Taleb-Bendiab, Cherif Branki and David Lamb

Integrating Process Modelling into Multi-Agent System Engineering

Tobias Küster, Marco Lützenberger, Axel Heßler and Benjamin Hirsch

Towards Service Matchmaking of Heterogeneous Service Descriptions

Analay Balta Camejo and Alberto Fernandez

A Framework to Manage Contractual Relationships in Customer Life Cycle

Management Systems

Christian Guttmann, Leelani Wickramasinghe, Ian Thomas, michael georgeff,

Heinz Schmidt, Hamid Gharib and Simon Thompson

Abstracting Business Modeling Patterns from RosettaNet

Pankaj R. Telang and Munindar P. Singh

Governance of Services: A Natural Function for Agents

Frances Brazier1, Frank Dignum2, Virginia Dignum1, Michael N. Huhns3, Tim

Lessner4, Julian Padget5, Thomas Quillinan6, Munindar P. Singh7

1 Delft University of Technology, The Netherlands

{f.m.brazier,m.v.dignum}@tudelft.nl2 Utrecht University, The Netherlands

dignum@cs.uu.nl3 University of South Carolina, USA

huhns@sc.edu4 University of the West of Scotland – Paisley, UK

timlessner@lesshome.net5 University of Bath, UK

jap@cs.bath.ac.uk6 Thales Nederland, The Netherlands

Thomas.Quillinan@d-cis.nl7 North Carolina State University, USA

singh@ncsu.edu

Abstract. The objective of service-oriented computing (SOC) is to construct

software applications out of appropriate services available and executing in place

anywhere across the Web. To achieve this objective requires that techniques

for discovering and engaging services be developed and used across the lifetime

of the service-based applications. Doing this well requires that additional tech-

niques be developed for ensuring desired quality of service metrics and service-

level agreements. The crucial aspect of using services is thus their governance.

Keywords: Institutions; Multi-agent systems; Organizations; Service engagements;

Service enactment; Governance model

1 Introduction

The deployment of systems based on service-oriented architectures (SOA) is becom-

ing widespread and successful in many application domains. Numerous commercial

and civil organizations are actively engaged in converting their existing information

systems or constructing new systems based on SOA principles [7]. However, the SOA-

based systems being constructed are static, in that the services are known and fixed at

design time, and their possible interactions are defined and characterized completely

in advance. The use of dynamically discovered, configured, deployed, engaged, and

maintained services has not been successful yet [2]. The problem is that current service

standards, which are necessary for widespread usage of services, are unable to describe

anything other than the simple syntax and formatting of service invocations; they are

thus insufficient for characterizing the rich usage and interactions required throughout

the lifetimes of service-based applications, from discovery through maintenance [15].

In particular, service-oriented computing is intended to enable services to be dis-

covered and enacted across enterprise boundaries [13, 11]. If an organization bases its

success on services provided by others, then it must be able to trust that the services

will perform as promised, whenever needed. This entails having descriptions of the be-

haviours of the services, not just their functionality, so that their run-time interactions

are predictable, observable, and controllable. Moreover, they must be predictable and

controllable over a lifetime of interactions. Thus there is a need for what we call service

governance.

The features of service governance are well beyond what was originally envisioned

for service-oriented architectures. The features include quality-of-service (QoS) and

contracts, i.e., service-level agreements (SLAs) among the participants. Moreover, to

make this governance dynamically and autonomously configurable, the participants will

need the ability to negotiate at run-time to establish the SLAs, to monitor compliance

with them, and to take actions to maintain them. These are software agent capabilities.

However, if the introduction of agents increases the flexibility of service interactions,

it also introduces a new set of vulnerabilities, due to uncertainty and complexity that

characterize multi-agent systems.

The Web has been successful largely because its founding principles and protocols

are simple and minimal. Also, when uncertainties arise, they are overcome by rela-

tively simple indexing, ranking, and redundancy. None of these techniques has been

exploitable for services. In addition, the simplicity of services applies only to their

structure, and not to their function and behaviour, which have mostly been ignored in

service engineering.

Agents exacerbate the problems, while—surprisingly—also providing the only rea-

sonable solutions to them. The autonomy of agent-based services makes them less

predictable, but also enables them to self recover and to avoid deadlocks and livelocks,

thereby making them more reliable. Their ability to learn can increase their robustness

by being able to adapt to changing interaction environments, but also can increase their

unpredictability. Their abilities to negotiate and reconcile semantics can enable them

to re-establish connections and relationships among services and ameliorate uncertain

execution environments. The peer-to-peer interactions of agents can improve the effi-

ciency of agent-based services, particularly when they are deployed in clouds. Finally,

agents can exploit the redundancy provided by multiple alternative services.

In this paper, we present initial work towards a model for dynamic SOA, using

agent-based technology, that provides different levels of abstraction for the specifica-

tion of governance, expectations and behaviour. In the next section we will elaborate on

the motivation for higher levels of abstraction to specify dynamic SOA. In section 3 the

components of our governance model are discussed. The potential benefits of our gov-

ernance model are illustrated in section 4. The paper finishes with the first conclusions

and discussion for future work in section 5.

2 Motivation

Our point of departure is the idea of a real-life service engagement [21, 3, 18]. A real-

life service engagement inherently involves two or more largely autonomous and het-

erogeneous parties who exchange value with one another. To enact a real-life service

engagement, participants naturally rely upon technical (Web or Grid) services. How-

ever, what distinguishes a real-life service engagement is that the interactions that con-

stitute it are best understood in the business relationships among the parties, that is, on

a higher level of abstraction than that of the services’ specifications. In general, tra-

ditional operational ways of modelling and representing interactions are too low level

to be appropriate. We suggest that such interactions should be captured as normative

relationships realized within the scope of an institutional contract in which the par-

ticipants carry out well-defined roles. In this section, we highlight the challenges and

opportunities of governance through a series of scenarios of engagements of increasing

complexity.

As an example, consider a simple service engagement corresponding to a two-party

deal. For example, this engagement might transpire when a user connects to Amazon

to purchase an MP3 song, which the user can download directly from Amazon. (For

simplicity, we ignore any additional parties needed to process payments.) In this situ-

ation, the conventional approach is for the user’s application to invoke one or more of

the Amazon Web services involved in searching for and purchasing the desired song.

Notice that here the two parties find each other and interact in more or less standardized

ways. There is a presumption not only that the application understands the data models

of the Amazon services, but also understands that at an appropriate time the user be-

comes committed to paying for the selected song and that Amazon becomes committed

to providing the media for the song.

In contrast, we understand the evolving relationships among the participants as cen-

tral to the above engagement. If either party fails to perform according to its commit-

ments, we can understand that as a violation regardless of the low-level means through

which they happen to interact and the operational details of the order in which they

communicate. Moreover, it makes a huge difference at which point possible failures

of the interaction happen. If the technical interaction fails after the search but before

downloading and payment, no harm is done. The transaction can either be canceled or

restarted. However, if there occurs a failure between the downloading and the payment

(in whatever order they take place) we cannot just cancel the transaction. This (techni-

cal) failure has larger repercussions. Moreover, recognizing that a real-life service en-

gagement involves autonomous parties means that (besides possible technical failures)

there is no inherent guarantee that each party will be well behaved. For this reasons, and

following common practice, it is convenient or even essential that we model the organi-

zational or social scope within which the engagement takes place. The scope provides

a facility to monitor the interactions, record reputations, assist in matchmaking, and

ensure compliance. Unless the scope has legal powers, it might only be to able to en-

sure compliance based on threats of censure, removal of a malfeasant participant, or

escalation to a higher (such as a legal) authority.

Moreover, taking seriously the above-mentioned point about capturing normative

relationships as opposed to operational details, we grant first-class status to the scopes

as institutions. In this sense, an institution is an organization that has an identity of its

own and to which different parties must belong in order to interact with one another. An

institution could be an existing social entity (such as a university or the State of North

Carolina in the US). Or, it could be an entity that we construct for a certain family of

engagements, in which case we might term it a virtual organization. The distinction is

largely irrelevant for our present purposes.

We can understand an institution as including itself as a distinguished member along

with the parties carrying out a service engagement. Further, we specify an institution

in terms of the normative relationships it imposes among its members. Some of the

normative relationships arise between the transacting parties and some between them

and the institution itself — indeed this is why we model the institution as a distinguished

member. To this end, it is important to define the roles of an institution as descriptions

of how members of different types are expected to behave.

To return to the Amazon example, we can imagine the customer and Amazon each

participating in the Commerce institution, which can be defined as being subject to Uni-

form Commercial Code and other rules of (commercial) encounter [20]. The Commerce

institution in this sense is what one implicitly finds when conducting commerce within

a legal jurisdiction. As members of the institution, each party is permitted to buy and

sell items it owns, but prohibited from trading illegal objects (such as drugs) and so on.

Violations would expose each party to sanctions.

The governance of a service engagement is its administration, especially when car-

ried out by the participants [21]. The normative relationships placed within an insti-

tution as scope provide a natural way to achieve governance. In particular, by using

high-level specifications, we can characterize the requirements of the stakeholders pre-

cisely without having them over-constrained by operational details. In the above case,

the initialization and enactment of the engagement is constrained by the institutional

scope. The parties can decide what to trade and can escalate the interaction to the scope

(that is, by complaining), if the other party does not keep its end of the deal.

The situation becomes more interesting in engagements where the institutions are

not directly the legal system, but something more flexible. To this end, as our second

example, one can think of a customer purchasing goods not from Amazon, but from one

of the sellers on Amazon Marketplace. Here the buyers and sellers must obtain accounts

on Amazon and Amazon serves as the institutional scope. In obtaining an account, each

party enters into a contract with Amazon that specifies the rules of encounter. In an

actual business transaction, a buyer and seller would meet through Amazon, negotiate

a price (which might be realized through a fixed offer or an auction), commit, and

discharge their respective commitments to enact the engagement. Governance is richer

here because of the extra layer of the Amazon scope.

Notice that the enactment of such engagements would naturally include the parties

stepping out of the scope physically, even though they remain bound to it logically.

Specifically, the parties will use external means, such as payment and shipping agencies,

which are not bound to the Amazon rules of encounter and do not exist within the

Amazon scope. However, failure by such external means can cause the violations of

normative relationships within the Amazon scope, and the participants may suffer the

consequences as a result.

Finally, service engagement should also be considered in the business-to-business

case. Here we consider interactions between enterprises such as between an automo-

bile manufacturer and a parts supplier. Each party is an organization in its own right.

We can imagine that they carry out their trade in the generic Commerce institution that

is described above or through a more confined institution such as a Parts Exchange

(analogue of Amazon Marketplace) or even something less formal, such as a Japanese

keiretsu. Agents playing suitable roles in each organization (that is, empowered with

signatory authority) are necessary to instantiate the contract. However, the enactment

of the contract requires the participation of sub-organizations and their representative

agents lower down the respective corporate hierarchies. We can imagine this as a com-

bination of delegation and assignments of the high-level normative relationship as well.

The engagement proceeds smoothly if such coordination succeeds, but may fail oth-

erwise. In general, any of the parties may escalate what was delegated or assigned to

them, generally to the agents who originated the delegation or assignment. In other

words, each party would complain to its manager or designated agent in the super-

organization. The peers may be able to renegotiate details such as delivery times and

trucks (or not – depending on their powers and authorizations within their respective or-

ganizations). If the engagement cannot recover within the organizations, there may be

an escalation to the scope – analogous to an escalation to the Amazon Marketplace if the

seller does not send the buyer the ordered goods. The above thus illustrates governance

at the level of performance, renegotiation, and escalation.

The foregoing discussion describes service engagements and how their governance

is naturally viewed in terms of normative relationships arising within suitable institu-

tions. The same ideas can be applied in finer granularity in terms of agreements about

specific qualities of service. By formulating governance in these terms, we can show

how service engagements can be carried out and administered in a manner that respects

the details of technical services without being bogged down in their details.

It should be noticed that norms in institutional or organisational specifications tend

to abstract from the concrete events and situations that the norm is supposed to cover.

The norms of institutions are intentionally specified at a high level of abstraction to

range over many different situations and to require little maintenance over time. While

this abstraction creates increased stability over time and flexibility of application for the

norms, it also creates a problem when using norms as the abstract concepts in norms

need to be related to the concrete events/concepts that occur on the technical service

level the system. In [1] we have shown how links can be made between norms on the

different levels (using a practical account of the counts-as concept) while each level can

concentrate on the issues important for that level.

3 Governance Model

Based on the issues raised in the previous sections, we propose a governance model

for virtual organisations that comprises three levels (inspired by [4]) (1) organisations,

(2) agents and (3) services. Organisations describe real-life engagements, their context,

expectations and norms. The relationships between agents are defined by the organisa-

tions to which they belong, but agents are lead by their own reasoning abilities, desires

and beliefs. Agents activate services in order to achieve their goals. Services, or com-

positions of services, are encapsulated in the agents that make them available to others.

Knowledge (ontology) Process

(Virtual) Organization

(Representative)

S: control structure, roles,

values, type

F: norms, purpose

B: quality of ethos

Business model defining

normative relationships

Agent (Owner) S: communication, decision

making strategies, level of

autonomy

F: goals, mores/values, BDI

B: Quality of Character

Coordination model

Service (Provider) S: data types, syntax,

interfaces

F: declarative semantic

description

B: Actual QoS

Enactment

Table 1. Model overview

This governance model distinguishes for each of the three levels (1) the knowledge

(ontologies) and (2) the processes involved. In the ontology (per level) the concepts that

are used to define the three components structure (S), function (F) and behaviour (B)

are described. Table 1 provides an overview of the model.

(Virtual) organisations have a Representative. The structure of an organization is de-

scribed in terms of roles, values, etc. Organisations have their own norms and purpose:

goals and ethical function. The Quality of Ethos determines the way organisations are

perceived (their behavior is seen).

Agents have Owners. Agents have their own level of autonomy, communicate with

other agents, and make individual or collective decisions. They have their own indi-

vidual goals, mores and values, beliefs, desires and intentions. Quality of Character

defines the way they are perceived, determines their reputation.

Services are provided by Service Providers. Agents activate services using the syn-

tax, data types and interfaces published. Services are often chosen on the basis of their

declarative semantic descriptions. SLAs define the expected quality of service and the

conditions. A service is best described by the actual Quality of Service it provides.

In the next sections we will describe each of the levels and their role in the gover-

nance model in more detail.

3.1 Organization

One of the main reasons for creating organizations is to provide the means for co-

ordination that enables the achievement of global goals. Organizational structure has

essentially two objectives [6]. Firstly, it facilitates the flow of information within the

organization in order to reduce the uncertainty of decision making. Secondly, the struc-

ture of the organization should integrate organizational behaviour across the parts of the

organization so that it is coordinated.

The design of organizational structures and processes determines the allocation of

resources and people to specified tasks or purposes, and the coordination of these re-

sources to achieve organizational goals. Both in human enterprises as in multi-agent

systems the concept of structure is central to design and analysis of organizations [5].

Williamson argues that the transaction costs are determinant for the organizational

model [25]. Transaction costs will increase when the unpredictability and uncertainty

of events increases, and/or when transactions require very specific investments, and/or

when the risk of opportunistic behaviour of partners is high. When transaction costs

are high, societies tend to choose hierarchical models in order to control the transaction

process. If transaction costs are low, that is, are straightforward, non- repetitive and re-

quire no transaction-specific investments, then the market is the optimal choice. Powell

introduces networks as another possible coordination model [16]. Networks stress the

interdependence between different organizational actors and pay a lot of attention to the

development and maintenance of (communicative) relationships, and the definition of

rules and norms of conduct within the network. At the same time, actors are indepen-

dent, have their own interests, and can be allied to different networks. That is, different

business models are based on different environment strategies and define normative

relationships:

– Strict hierarchical organisation – well structured, with well defined delegation of

tasks, responsibilities, authority, reporting, monitoring/supervision and control.

– Networks – groups of organisations that together agree to collaborate, collectively

negotiate how to delegate tasks and responsibilities, how to monitor task progress,

and how to regulate their collaboration. Trust plays an important role.

– Completely distributed open market – competitive, full autonomy of individual or-

ganisations, cooperation depends solely on perception of mutual benefit.

Each of these types of organizations comes with a set of predefined patterns and

organisational roles. Thus, depending on the context in which the SOA is developed a

certain organisation type can be chosen that fits best. For instance, the automotive exam-

ple probably needs a network organization because partnerships range over sequences

of transactions and trust on timely delivery of parts is important. The Amazon market

place is a good example of a market organisation, with its ensuing norms and roles.

3.2 Agents

Agents are the decision making entities within an organisation: they activate services to

achieve their goals. This means service invocation is goal directed. This enables finding

alternative services and replanning when services fail to comply to SLAs. In that case

alternatives are sought that achieve the same goal, but might differ in implementation

details.

Agents can also act as representative of an organization. This feature allows for a

hierarchical specification of an organization in terms of divisions, departments, etc. The

example in the next section will illustrate this point where the car factory is part of a

larger car manufacturer.

In complex organisations coordination between agents is mandatory to manage de-

pendencies in their activities. Different types of coordination can be distinguished: (1)

functional coordination, (2) temporal coordination and (3) information coordination.

Functional coordination refers to the delegation of control within an organisation:

ranging from fully distributed, within which each agent fends for itself in a fully net-

worked environment to fully controlled in a hierarchical structure within which agents

only perform the tasks they have been delegated upon request and only interact with

agents with whom interaction has been requested by the top-agent. Mediated structures

in which aspects of both extremes may be combined are often encountered in practice.

Temporal coordination refers to the timing of a process. As agents are autonomous

they each have their own sense of time, their own clock. Coordination requires the

temporal aspects of interaction to be considered during design (even though, in fact,

interaction in distributed environments is, by definition, asynchronous). Dependencies

need to be defined and incorporated in interaction patterns known to the agents.

Information coordination refers to the information agents need to have to be able

to reach their goals. In situations in which agents need to interact, these dependencies

are crucial to their individual ability to perform. If information is to be shared, there

must be a means with which this is achieved: e.g. shared memory, broadcasting, multi-

casting, message passing).

The agents main purpose is to achieve the different forms of coordination run-time.

So, when unexpected events happen the agents can adapt to the new situation by rear-

ranging and coordinating the changes. This is a big advantage over the service chore-

ography where this should be done all at design time.

3.3 Service Enactment

Agents enact services to reach their goals. Services may be complex: agents may need to

orchestrate their behaviour. They may need to adapt/inform an agent if something goes

wrong. Which agent that is, will depend on the design of the system. To this purpose an

agent must be able to schedule service enactment, monitor and influence service perfor-

mance, re-orchestrate a complex service if needed and influence the choreography. An

agent must be capable of detecting malfunctioning and to adapt appropriately.

Obviously, services can be clustered and agents could then manage and use the

clusters to help locate possible services to satisfy requests from users and developers.

A procedure such as unit testing could then be used as a behavioural query tool to

test candidate services and select ones that have the desired behaviour. A negotiation

between the service requestor and providers could then ensue to establish an agreed

upon QoS and formalize a contract. The requestors and providers would commit to

honour the resultant contracts. These require agent abilities which are above those of

regular services.

4 Illustrative Scenario

In this section a car manufacturing company is modelled using the structure outlined

in Section 3. In this example, two organisations are described within the company: the

Stakeholders: Organisation Knowledge (ontology) Process

– Suppliers

– Customers

• Dealers

• Individuals

– Shareholders

– Manufacturers

– Sales

S: Board of Directors;

Shareholders meeting.

Negotiated agreements

F: Produce cars suitable for

market.

B: Profit; Cost Control for

customers; Safety; Timeliness,

“Green”.

Required to make a profit.

Cooperation / Negotiate for

resources and sales.

Timely delivery of cars.

Table 2. Stakeholders: organization view

corporate stakeholders and the manufacturing business. The stakeholders are respon-

sible for the overall corporate direction and manage the business. The manufacturing

business is one part of the business responsible for building specific cars. These aspects

are described separately.

4.1 Stakeholders

Modelling the organisation of the stakeholders entails determining the actors, includ-

ing customers, suppliers, manufacturers and sales. These actors all have a stake in the

running of the business. The structure is formal — a board of directors as well as the

requirements to hold regular shareholders meeting. Customers and suppliers have for-

mal agreements that specify their relationships. The behaviour of the business includes

requirements that can be in conflict (such as cost control, profit and “greenness”. In or-

der to be successful, an appropriate balance must be attained. The above is summarized

in table 2.

A number of aspects of the organisation can be specified as agents. In this example,

only a seller agent is modelled in table 3. In this agent, the structure relates to the

interactions between the corporate stakeholders, the customers, and the manufacturing

aspect of the business. In order to achieve the agent’s goals, it uses a number of services.

The ordering service (summarized in table 4) is enacted by the seller agent, plac-

ing orders from customers with the manufacturing business. This requires a specific

interface to the service, specifying the type of car, the customer identifier, as well as

preferences such as colour and interior. A service level agreement is used to define

the acceptable quality of service guarantees that have been negotiated. These include

absolute dates for manufacturing as well as containing penalties for non-compliance.

Another service that is used is a return service (depicted in table 5) that describes

how cars are returned to the manufacturer if found to be defective. Defective cars may

be physically defective or cars that are no longer required due to the customer changing

their mind. SLAs define the service parameters for accepting a return, as well as the

possible fees for returning cars that are no longer required yet are functionally correct.

Stakeholders: Agents Knowledge (ontology) Process

Seller Agent (Stakeholders) S: One-to-one negotiation with

customers. Not allowed to sell

below cost. Limited ability to

discount.

F: Make a profit. Sell as many

cars as can be produced.

B: Must be seen as honest and

dependable. Good reputation

helps sales.

Coordinates between

manufacturing and customers

to determine the price point

and the number of cars that can

be produced. Orders are sent to

manufacturing organisation.

Table 3. Stakeholders: agent view

Stakeholders: Services Knowledge (ontology) Process

Ordering Service (Seller) S: order(Order ID, Car Type,

Preferences, Due date,

customer ID)

F: Orders a car of a specified

type from the manufacturer

and species the desired due

date.

B: SLA defines the acceptable

time allocated to

manufacturing and delivering

cars. This is different to the

due date as it may specify

penalties for non-compliance.

Enactment of the service.

Table 4. Stakeholders: ordering service view

4.2 Manufacturer

The manufacturer is one of the stakeholders, as well as operating agents in the previous

model. Examining the structure of the manufacturer allows a more specific model to be

created (see table 6). In this case, the organisation is made up of suppliers, the manu-

facturing workers, as well as the controlling entities — the board of directors and the

shareholders. In this case, the structure is in place to actually manufacture cars for the

sales aspect to sell. The requirements here are to safely and efficiently produce the cars

while managing the costs associated with them.

The manufacturer has an assembly agent (described in table 7) that maintains both

the supplies and the order schedule so that cars are not delayed, causing penalties.

This agent determines the manufacturing schedule so that urgent orders are scheduled

quickly and also parts are ordered from suppliers so that they will arrive in time for

assembly.

Stakeholders: Services Knowledge (ontology) Process

Return Service (Seller) S: return(Car Type, Order ID,

Customer ID)

F: Return a defective car back

to the manufacturer. Defective

cars can also include cancelled

orders, changed orders etc.

B: SLA defines how long a

refund should take as well as

the “restocking fee” that

applies when order is cancelled

for non-functional reasons.

Enactment

Table 5. Stakeholders: return service view

Manufacturer: Organisation Knowledge (ontology) Process

– Suppliers

– Shareholders

– Board of Directors

– Workers

S: Building cars.

F: Produce cars for sale.

B: Safety; Efficiency;

Suitability; Cost Control.

Required to efficiently produce

cars using supplies to

specifications.

Sufficient parts should be

supplied, without large stock.

Table 6. Manufacturer: organization view

Manufacturer: Agents Knowledge (ontology) Process

Assembly Agent

(Manufacturer)

S: Determine when to order

supplies; Determine the

schedule to start building

received orders; Build cars

quickly and cheaply.

F: Build cars efficiently

Ensure stocks of supplies are

appropriate for upcoming

orders. Prevent penalties from

occurring.

B: Efficient, dependable, safe.

Coordinates between suppliers

and orders appropriate parts.

Coordinates construction

schedule to ensure order

deadlines are met.

Table 7. Manufacturer: agent view

One service that the manufacturer requires is a service to manage supplies of car

parts (depicted in table 8). This service provides stock management as well as auto-

mated ordering of parts based on existing service level agreements. This service is used

by the assembly agent to ensure that assembly is successful.

Manufacturers: Services Knowledge (ontology) Process

Parts Service (Assembly

Agent)

S: orderSupplies(Part ID,

Quantity, Date)

F: Order parts from suppliers.

This specifies the date when

the part is required as well as

the functional details of

quantity and part identifier.

B: SLA specifies the deadlines

and may describe the price

depending on how quickly the

part is required.

Enactment

Table 8. Manufacturer: assembly service view

As can be readily seen from the above examples, the model described in Section 3

provides the ability to capture the details of a business with many levels of abstraction.

5 Discussion & Conclusion

Technology and economics are together driving the development of open systems: one

pushing and the other pulling, but as yet their realization remain just out of reach for

a range of complicated and interrelated reasons. The purpose of this section is to lay

out our perspective on these issues, highlighting the (often complementary) research

that is taking place in different areas of computer science and that we believe can be

brought together to close the gap between the current state and the effective delivery

of open systems, through the adoption of a governance perspective on the remaining

challenges.

CORBA, and its like, has offered the primary approach to systems integration —

whereby we mean joining legacy systems with new ones and the on-going maintenance

of current systems — for the last two decades. While this has provided a means to con-

nect, but decouple, a variety of software components, the emphasis has typically been

on delivery within an organization. During this period, web services have appeared and

we see some migration to this technology, but more as a substitute, again within an

organization, rather than cross-organization service provision in line with the original

vision. Some of the factors, as discussed at greater length in earlier sections, that we be-

lieve discourage uptake include: operational rather than functional service descriptions,

difficulty in monitoring service provision, problems in locating and handling faults and

determining responsibility in the case of incomplete delivery of the service.

The scientific computing revolution has centred on the development and evolution

of the grid, which has adopted web services despite the issues noted above, because the

research community is relatively happy to trade resources (you can use my computer if

I can use yours) and is more tolerant of, and less litigious, when faced with failure of

provision. Additionally, the demands of capability computing, characterized by long-

running programs and complicated workflows of several such programs, have driven

the development of distributed workflow engines (e.g. Taverna [14]), YAWL [23], WS-

BPEL [12] and monitoring systems, with the objectives of (i) raising the programming

task to one of composing services using a variety of familiar procedural constructs and

(ii) handling service failure graciously so that it need not result in workflow failure

[19]. Service level agreements are playing an increasing role in grid computing, not

just as a way for a service consumer to state their requirements, but both as a basis

for negotiation (Mobach et al., 2006) between consumer and provider and as a way

of scheduling [17, 24] the best use of resources, reconciling the conflicting demands

of throughput and response time. It seems likely that SLAs have an important part to

perform in capacity computing (clouds) in helping to establish the practice of electronic

contracts for intangible goods at the same time as refining the language and instruments

of SLAs through experience. A particular challenge here is that it is rare that just one

SLA will suffice: much more likely are hierarchies of SLAs, where constituent tasks

are governed by further SLAs, but the primary contractor is not, and does not wish to

be, aware of such details. Some aspects of these issues are considered by Haq et al. [9,

8] who examine business value networks and build on WS-Agreement [10] and Unger

et al. [22] who focus on business process out-sourcing and utilise WS-Policy1. Some

factors discouraging uptake of SLAs include: the relative immaturity — by business

standards — of the tools and the lack of a proper legal understanding of and status for

SLAs, but there is growing interest, as well as a realization of the necessity of such

approaches.

Workflows began as compositions of specific services, but there are two factors

encouraging abstraction: (i) the desire for re-usability and (ii) the gradual uptake of open

systems, both of which enforce a shift from exactly what service to use to specifying

how the service shall function. This can be brought about through semantic service

description languages such as OWL-S, consequently monitoring of workflow progress

can be expressed in application terms and service failures might be resolved by finding

functional substitutes. But different organizations will have different views on what

information matters about the progress of a workflow, and likewise different policies

with respect to what constitutes an adequate substitute.

Software agents, as a technology, has now matured sufficiently that it is accepted

as a way of thinking about systems construction that works with other components,

rather than a kind of hegemony that seeks to impose a one-size-fits-all solution. Of

particular potential benefit from this domain is the research on automated negotiation

— which is already feeding into the refinement of WS-Agreement — and argumenta-

tion, distributed resource allocation and aggregation techniques and, perhaps most ap-

propriately, given the case study in section 4, the development of formal approaches

to organizational modelling. These last offer the opportunity to construct machine-

processable policies that capture high level organizational intentions and, yet whose

influence reaches down to individual decisions such as that highlighted in the preceding

paragraph.

1 Web Services Policy 1.2 - Framework (WS-Policy), http://www.w3.org/Submission/WS-

Policy/. Retrieved 20100307.

Looking back at the above, we identify (i) dynamic behaviour, (ii) formalization of

business roles and rules, (iii) response to change (over short and long term) and (iv) for-

malization of agreements (in the physical and the virtual world), as the key challenges

to be met to achieve the next level of aspirations in electronic service provision. We

believe it is clear from this necessarily partial view of a broad range of research, that

good foundations exist on which to build the next steps in delivering service-oriented

architectures — as long as we are prepared to borrow, extend and collaborate, rather

than re-invent.

In conclusion, what we have offered here is a broad assessment of the state of service

oriented architectures, in which we identify a need to address the consequences of a

changing environment in which such systems may be deployed. We propose that the

combination of software agents and organizational modelling are well-suited to the task

of providing an agile management layer whose function is directed by the dynamic

interpretation of formal models of governance. In so doing, we seek to build on a broad

range of research in service, workflow, semantic web and grid computing, each of which

brings its strengths to a complex, layered, architecture.

Acknowledgements: This work is the result of many fruitful discussions during

the Dagstuhl workshop on “Service-Oriented Architecture and (Multi-)Agent Systems

Technology” held in January 2010. We thank the organizers and all the participants, and

Christian Derksen in particular, for their contributions.

References

1. H. Aldewereld, S. Alvarez-Napagao, F. Dignum, and J. Vazquez-Salceda. Making norms

concrete. In Proceedings of the 9th International Conference on Autonomous Agents and

Multiagent Systems, 2010. To appear.

2. Alex E. Bell. From the front lines: Doa with soa. Communications of the ACM, 51(10):27–

28, October 2008.

3. N. Desai, A. K. Chopra, and M. P. Singh. Amoeba: A methodology for modeling and evolu-

tion of cross-organizational business processes. ACM Transactions on Software Engineering

and Methodology (TOSEM), 19(2):1–45, 2009.

4. Frank Dignum, Virginia Dignum, Julian Padget, and Javier Vazquez-Salceda. Organizing

web services to develop dynamic, flexible, distributed systems. In Proceedings of 11th In-

ternational Conference on Information Integration and Web-based Applications & Services,

pages 155–164. ACM, 2009.

5. V. Dignum, F. Dignum, and L. Sonenberg. Design and analysis of organizational adapta-

tion. In L. Yilmaz and T. Oren, editors, Agent-Directed Simulation and Systems Engineering,

pages 239–269. Wiley, 2009.

6. R. Duncan. What is the right organizational structure: Decision tree analysis provides the

answer. Organizational Dynamics, Winter:59–80, 1979.

7. The Open Group. Soa case studies, 2008.

8. I. Haq, A. Huqqani, and E. Schikuta. Aggregating hierarchical service level agreements

in business value networks. In Umeshwar Dayal, Johann Eder, Jana Koehler, and Hajo A.

Reijers, editors, BPM, volume 5701 of Lecture Notes in Computer Science, pages 176–192.

Springer, 2009.

9. I. Haq, A. Paschke, E. Schikuta, and H. Boley. Rule-based workflow validation of hierarchi-

cal service level agreements. In Workshops at the Grid and Pervasive Computing Conference,

pages 96–103, 2009.

10. D.G.A. Mobach, B.G. Overeinder, and F.M.T. Brazier. A ws-agreement based resource nego-

tiation framework for mobile agents. Scalable Computing Practice and Experience, 7(1):23–

36, 2006.

11. OASIS. Reference model for service oriented architecture 1.0. http://docs.oasis-

open.org/soa-rm/v1.0/, October 2006.

12. OASIS. Web services business process execution language (ws-bpel). http://www.oasis-

open.org/committees/tc home.php?wg abbrev=wsbpel, April 2007. Retrieved 20100307.

13. OASIS. Reference architecture for service oriented architecture version 1.0.

http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.pdf, April 2008.

14. Thomas M. Oinn, R. Mark Greenwood, Matthew Addis, M. Nedim Alpdemir, Justin Ferris,

Kevin Glover, Carole A. Goble, Antoon Goderis, Duncan Hull, Darren Marvin, Peter Li,

Phillip W. Lord, Matthew R. Pocock, Martin Senger, Robert Stevens, Anil Wipat, and Chris

Wroe. Taverna: lessons in creating a workflow environment for the life sciences. Concur-

rency and Computation: Practice and Experience, 18(10):1067–1100, 2006.

15. Michael P. Papazoglou and Willem-Jan Van Den Heuvel. Business process development life

cycle methodology. Communications of the ACM, 50(10):79–85, October 2007.

16. W. Powell. Neither market nor hierarchy: Network forms of organisation. Research in

Organisational Behaviour, 12:295–336, 1990.

17. R Sakellariou and V. Yarmolenko. Job scheduling on the grid: Towards sla-based scheduling.

In L. Grandinetti, editor, High Performance Computing and Grids in Action, volume 16 of

Advances in Parallel Computing. IOS Press, 2009.

18. M. P. Singh, A. K. Chopra, and N. Desai. Commitment-based service-oriented architecture.

IEEE Computer, 42(11):72–79, 2009.

19. Rafael Tolosana-Calasanz, Jose A. Banares, Omer F. Rana, Pedro Alvarez, Joaquin Ezpeleta,

and Andreas Hoheisel. Adaptive exception handling for scientific workflows. Concurrency

and Computation: Practice and Experience, 22(5):617–642, 2010.

20. UCC. Uniform code council: The global language of business. Technical report, 2005.

21. Yathiraj B. Udupi and Munindar P. Singh. Governance of cross-organizational service agree-

ments: A policy-based approach. In 2007 IEEE International Conference on Services Com-

puting (SCC 2007), pages 36–43, 2007.

22. Tobias Unger, Frank Leymann, Stephanie Mauchart, and Thorsten Scheibler. Aggregation of

service level agreements in the context of business processes. In EDOC, pages 43–52. IEEE

Computer Society, 2008.

23. Wil M. P. van der Aalst and Arthur H. M. ter Hofstede. Yawl: yet another workflow language.

Inf. Syst., 30(4):245–275, 2005.

24. Philipp Wieder, Oliver Waldrich, and Wolfgang Ziegler. Advanced techniques for schedul-

ing, reservation, and access management for remote laboratories. In e-Science, page 128.

IEEE Computer Society, 2006.

25. O. Williamson. Markets and hierarchies: Analysis and Antitrust Implications. Free Press,

1976. ISBN 13: 9780029353608.

Evolving Formal Models:

Multi Agent Self-Organisation for Governance and

Regulation in Service Oriented Systems Martin Randles1, A. Taleb-Bendiab1, Cherif Branki2 and David Lamb1

1 School of Computing and Mathematical Sciences, Liverpool John Moores University

Liverpool, UK 2 School of Computing, University of Paisley, Paisley, Scotland, UK

1{m.j.randles;a.talebbendiab;d.j.lamb}@ljmu.ac.uk; 2Cherif.Branki@uws.ac.uk

Abstract. This paper deals with the problem of formally specifying the runtime

governance of large scale, complex and service oriented computer systems. The

elegance and efficacy of process algebra models is widely appreciated whilst it

is acknowledged that reasoning and verification methods need to be defined to

sit above the actual model to provide any formal proofs. Conversely, whilst

logical formalisms have verification and deductive methods built in they lack

the expressive power and ease of coding of process algebra models. In currently

emerging Service Oriented Architectures the initial governance model rapidly

becomes outdated as emergent system features, component interactions and

self-organisation cause the system to move far away from its initial

configuration. This paper investigates governance concerns through the

specification of an initial Finite State Automata (FSA) multi agent system. An

equivalent logical model is then produced, as an observer component, which is

adjustable through runtime. The equivalent FSA model can then be derived

from the updated logic model at any time in the system’s evolution.

Keywords: formal models; situation calculus; X Machines; self-organising

systems

1 Introduction

The increasing scale and complexity of many emerging distributed computer systems,

as evidenced by the current trend towards Cloud Computing [1], encompassing

Software as a Service (SaaS) and large scale Service Oriented Architectures (SOA)

[2, 3] amongst many other developments, has caused a situation where design time

modelling cannot accurately predict the likely evolution of such systems. Similar

features are often observed within natural and biological systems: Biological systems

provide many examples of well-governed systems where interacting components

operate within an imposed or emergent structure to achieve a specific outcome. The

components exhibit highly dynamic processes whilst the environment itself is

dynamic. This means that the components must be subject to models of evolving data

structures and control of internal state. Additionally the global structural outcomes

predicate a requirement for the modelling of configuration, including the need for a

notion of communication and the ability to represent re-structuring. Prominent

examples of such natural self-organising systems include ant foraging [4] and

herding, flocking or schooling [5].

It is clear that such systems exhibit the attributes of multi-agent systems with the

components acting as autonomous distributed agents. The approach taken in this

paper is to treat software services and large-scale SOA, in cloud computing scenarios,

as multi-agent systems (MAS) modelled in suitable formalisms; permitting the same

level of governance by self-organisation as is observed within the aforementioned

natural systems.

1.1 Theme: Modelling Self-Organisation in MAS for Cloud Computing

In proposing an organisational approach more in line with natural systems for the

regulation and governance of larger scale service systems, complexity arises from the

heterogeneous nature of the participant services (agents), the specialised required

computational powers to drive the processes within the component agents and to

handle the vast amounts of resultant data and the need for extensive communication

between component agents to facilitate emergent (self-) organisation. Thus the formal

specification and modelling environment is required to capture both the dynamically

changing nature of the systems at all its levels and the static aspect of the data set at

any discrete time point. Such complexity, however, means that at any point in the

system’s evolution it is impossible to maintain a full knowledge of either resource

location or resource availability. This means that any formal modelling of the system

cannot rely on a static design model, rather the model must be adaptable and

evolvable through runtime: Specialist formalisms are required to handle this, which

will be explained and developed through this paper. The basic idea is that a logical

model of the system, whilst being difficult to code directly, provides an adaptable

system representation based on what is true for the system and the causal laws in

effect. This logical representation may then form a common language through which

the most appropriate formalism may be adopted and extracted for the required aspect

of the system, ultimately enabling code generation. The logical language is used as a

separate verification and validation layer, which, crucially, is adaptable through

runtime, as no prior enumeration of states and transitions is required. In this paper, the

approach is demonstrated through employing X-Machine formalism for code

generation with a situation calculus representation to provide system reasoning and

deliberation on the observed emergent outcome through runtime.

1.2 Contribution

This paper proposes the establishment of a logical language for reasoning on the

adaptation and evolution of multi-agent system formal models for regulation and

governance in larger scale SOA systems. It is shown how situation calculus may form

a common language whereby evolved formal models of system behaviour may be

inferred through the logic and exported to an appropriate formalism. In this regard it

is shown how this approach contributes to the grounding of system observable

signals. A specification method is outlined for the deliberative analysis of system

behaviour at larger-scales. This is demonstrated through dual state/transition logic

specifications, including a review of situation calculus and X-Machines.

1.3 Paper Structure

This paper explores the logical modelling of large-scale complex multi agent systems

evolution, in terms of communicating agents, for a formal treatment of large-scale

SOA. Section 2 provides a background through related works and motivates this

research in relation to resource allocation and governance in large scale complex

computer systems. Section 3 presents an example, from nature, based on ant foraging.

The parallel approach is emphasised with an illustration of the deliberative techniques

available from Situation Calculus for the logical reasoning. Section 4 is formed of a

case study where ant foraging is used as a service agent active clustering mechanism

in a virualised server farm. The evolved formal model is extracted and shown to

improve performance in subsequent system designs at runtime. Section 5 concludes

the paper.

2 Related Work and Background

The regulation of large scale SOA systems is dependent on being able to model and

account for system evolution. The approach taken here is to consider such systems as

being composed of multi-agents.

2.1 Formal Models for Multi-agent System Evolution

There have been many software engineering methods proposed to facilitate the

implementation of formal models of (multi-agent) system evolution, regulation and

governance. More lately some of these have been applied to multi-agent systems

utilising emergent self-organisation [6]. The problems of determining reachability and

recurrence of key outcomes, however, have hampered any attempt to ensure

correctness of systems. Formal methods are available but either lack the power to

capture the dynamics of systems or do not possess the capacity to describe the

systems completely. For instance formalisms such as VDM [7] are functional data

type models of a static nature with no straightforward method of transforming the

formal description into a working adaptable and evolvable system. Conversely Finite

State Machines (FSM) [8] or Petri Nets [9] capture system agent dynamics and allow

for a realistic calculation of livliness and deadlocks in a SOA [10] but have little

reference to component agent data or how this data is affected by each operation

through the state transitions leading to emergent outcome; thus they fail to describe

the whole system. Similarly Process Algebras, conceiving of systems as a set of

interacting FSMs, suffer from the drawback of merely modelling the agents’

behaviour. State transition diagrams or state charts incorporated into UML and further

developed into UML4SOA [11], for instance, present a more informal method that

describes dynamic behaviour and data, providing context aware services [12], for

example. The informality of this approach, however, leads to the representations

being interpretable in a number of different ways. X machines [13, 14] attempt to

extend the FSM concept by introducing the notion of memory: This allows the

machine to possess an underlying data set, which is operated upon with the inputs as

function based transitions, rather than simple labelled input transitions, between

states. This gives X-machines more expressive power, as a development tool, yet

cannot entirely provide for the detection and capture of newly emergent phenomena.

Situation Calculus and State Based Formalisms. It is evident that, in terms of a

formal model for the regulation and governance of a service oriented system using

multi-agents, Finite State Machines and state based formalisms provide a highly

amenable route to executable program code. To utilise FSMs, process algebras and

most state based formalisms in reality however, requires the additional development

of appropriate modelling and verification methodologies that have to be placed above

the primitive constructs of the formalisms. Additionally it can be noted that all states

and transitions in such specifications must be pre-defined before implementation. This

represents a major drawback in providing the required adaptability and agent self-

awareness necessary for regulating governance concerns, including resource

allocation. In contrast more can be achieved, in a situation calculus [15] agent

specification, because the explicit enumeration of states and their transition functions

is no longer required. Rather logical sentences are employed to denote what is true of

each agent, the multi-agent system and its environment and the causal laws in effect

for the domain. Thus system behaviour becomes a logical consequence of the model

specification. In addition properties of the specification can be proven entirely within

the logic and, where efficient deduction is possible, these formal specifications are

executable.

The work in this paper proposes the use of multi-agents in a logical approach,

specified in Situation Calculus [15] for runtime adapable regulation. It is proposed to

use the situation calculus as a “lingua franca” as in [16], whereby a relevant subset of

DAML-S [17] is semantically defined and translated into a suitable model for the

requirements at hand. In this way DAML-S may be used to capture the content and

capabilities of web services for representation in the situation calculus. The situation

calculus then acts as a flexible modelling language, incorporating the DAML-S

specification, allowing translation into other appropriate formalisms, whilst

permitting the reasoning and neat representation necessary for adapting and evolving

the specification to respond to emergent self-organisation. Thus an FSM or Petri-Net

model may be extracted from the situation calculus model according to the aspect of

the system being modelled: The situation calculus deals with model adaptation, whilst

the Petri-Net model can handle deadlock calculation, for instance.

The Proposed Approach. In order to demonstrate this approach it is proposed to

model a scenario in both a FSM based formalism and the situation calculus: The

situation calculus representation is combined with a parallel X-Machine definition for

expression, to formally model regulation in such dynamic service oriented systems. In

this way the expressiveness and power of transition systems, as detailed above, can be

included within a deliberative model to search for and define new service

compositions and behaviour, including emergent outcome and self-organisation. It is

assumed that the DAML-S specification is encoded in the situation calculus as

outlined in [16] and the X-Machine/FSM is used for execution whilst the situation

calculus model is adaptable at runtime. In [18] and [19] the governance and

regulatory concern of load balancing was presented as an illustrative case-study, for

formally specifying the governance and regulatory policies, in line with an envisaged

Internet of Services (IoS) [20], delivered via Cloud computing. A simulation of a self-

organising, beehive-based load-balancing algorithm [21] was used at the application

(business services) layer for optimum resource allocation with repercussions for cross

layer dynamics. The work addressed the server allocation problem in a large-scale

SOA; allocating servers to Web applications to maximise profit. The results showed

that the formal modelling of regulation and governance for resource management and

optimization was impossible to achieve, based on current methods alone, due to the

non-availability of real-time data regarding the resources. Active clustering, based on

ant foraging behaviour [4] is a recently investigated technique, for resource

manipulation, whereby like services are rewired together to provide an easy

distribution of the load on heterogeneous systems. This active clustering load-

balancing procedure [22] is used in this paper to test the application of the discussed

techniques, whereby a formal model of agent ant foraging self-organisation, as a FSM

in X-Machines, is enacted, reasoned upon through a runtime, in situation calculus,

with an updated evolved formal model extracted from the system in an easily re-

implemented X-Machine form. Thus the next two subsections introduce the relevant

features of X-Machines and situation calculus to be used.

2.2 X-Machines

An X-machine [14] functions in a similar manner to a Finite State Machine with the

addition of the associated memory. More formally an X-machine X is an eight-tuple:

X=<Σ, Γ, Q, M, Φ, F, q0, m0>. Σ and Γ are the input and output alphabet respectively;

Q is the set of finite states; M is the set of possible memories; Φ is the type of

machine being a set of functions (ϕ for example) that transforms an input and

memory state to an output and memory state ( ϕ:ΣxM→ΓxM); F is the state transition

diagram which takes as input a given state and the type of machine and outputs a new

(the next) state ( F:QxΦ→Q); q0 and m0 are the initial state and memory respectively.

Thus X-machines provide a mathematical modelling formalism for a system so

giving a means of testing an implementation against a model [14]. Encoding the X-

Machines as FSMs in a suitable logic with quantification over memory states, to

alleviate the state explosion that often occurs is the usual method of both model

checking and verification in this approach. Additionally an X-Machine description

language (XMDL) has been formulated. The use of XMDL allows a formal model

that can be processed by various tools, such as an animator, a test set generator, a

model checker and code generator. The functions take two parameter tuples, i.e. an

input symbol and a memory value, and return two new parameter tuples, i.e. an output

and a new memory value. A function may be applicable under conditions (if-then) or

unconditionally. Variables are denoted by “?”. The informative “where” in

combination with the operator <— is used to describe operations on memory values.

Therefore the functions are of the form:

#fun<function name>

(<input tuple>, <memory tuple>)=

[if <condition expression> then]

(<output tuple>, <memory tuple>)

[where <informative expression>].

The full syntax and semantics of XMDL can be found in [23].

2.3 Situation Calculus

The Situation Calculus representation [15] is a mostly first order logic approach that

views situations as action histories. Fluent values are initialised in the starting

situation (S0) and change from situation to situation according to effect axioms for

each action. The partial solution to the resultant frame problem [24] gives successor

state axioms that largely specify the system together with action precondition axioms

and the initial situation. So an initial situation, S0 is the start of the Situation Calculus

representation. An action, a, then changes this situation from S0 to do(a, S0) with the

next action, a1 say, changing the situation to do(a1 ,do(a,S0)) with a2 giving do(a2

,do(a1 ,do(a,S0))) and so on. The set of successor state and action precondition

axioms, one for each fluent and action respectively, show the changes in value of the

fluents and the possibility of completing an action in each situation accordingly. i.e. A

successor state axiom for a fluent is TRUE in the next situation if and only if an

action occurred to make it TRUE or it is TRUE in the current situation and no action

occurred to make it FALSE, with precondition axiom poss(a, s) meaning it is possible

to perform action a in situation s.

The representation of agent knowledge and beliefs in the situation calculus is

achieved by seeing the world states as action histories or situations with the concept

of accessible situations [25]. So if s1 and s2 are situations then (s1 ,s2) ∈ Ki means that

in situation s2 agent i considers s1 a possible situation with Ki an accessibility relation

for agent i. That is all fluents known to hold in situation s2 also hold in s1. So an

accessibility fluent may be specified: Ki(s1,s2) meaning in situation s2 agent i thinks s1

could be the actual situation.

So knowledge for agent i (knowsi) can be formulated in a situation as:

knowsi(φ, s) ≡ ∀s1(Ki(s1, s)→φ(s1)) [alternatively ∀s1 (¬ Ki(s1, s)∨ φ(s1) ) ]

This gives rise to a fluent to represent knowledge dynamics in the situation

calculus. However to make any axiom complete it is necessary to establish whether a

sensing action has taken place. That is if the action that occurred, to change the

situation to its successor, was the perception of the value of a fluent. So the change

was a change in the epistemic state of the agent: It is necessary to distinguish sensing

actions by writing SR(senseφ,s) to denote that the action produced a result for φ.

SR(senseφ, s) =r = value of φ in s

Thus a successor state axiom for K can be stated:

K(s2, do(a, s)) ⇔ ∃ s1( s2=do(a, s1) ∧ K(s1, s) ∧ poss(a, s1) ∧ SR(a, s)= SR(a, s1))

This formalism thus allows the representation of knowledge in partially observable

domains. This is a vital prerequisite, for the approach presented here, to produce a

scaleable methodology to enable deliberation on the symbols and signals within a

system.

2.4 Discussion: Specification Formalisms for SOA

Modelling formalisms, such as those previously described, need to exhibit properties

of openness to handle the uncertainty within service oriented operating environments.

State based approaches rely on process algebra, mathematical formalisms for

describing systems of interacting Finite State Machines (FSMs). It is a flat modelling

formalism: There are two sorts, states and transitions, together with axioms for

composing the FSMs, usually with no hierarchical structure; all the states appear in

the same layer and transitions may connect any pair of states leading to a modelling

formalism that is difficult to scale and maintain. In addition each realisation of a

model is a case specific solution: A new application usually requires a completely

new design and subsequent changes in the model cause difficulty with maintenance

issues because of the tight coupling between states and transitions; the major failing

of a FSM or process algebra approach is the necessary enumeration of all possible

states in advance. Such enumeration is impossible in this work as the evolution of

these large-scale complex SOA systems, is, in general, not predictable [26]. The X-

Machine approach, whilst seeking to address the problems, still requires that states are

known in advance. Even if enumeration were possible changes in state compositions

would result in an exponential increase in the number of system states. Furthermore

any practical utilisation of an FSM (process algebra) or X-Machine, including the

facility for deliberation on the system by itself, requires the additional provision of

modelling and verification methods to sit above the primitive constructs of the

formalism [27]. Thus the need for a formalism giving a “propositional account” [28]

is established. However, once the monitoring garnered and deliberated upon by the

system has achieved a grounding [29], it is possible to construct the X-Machine to

depict the newly evolved facet of the system. In this way the highly expressive and

illustrative features of X-Machines, including a necessary reduction in the state space

can be utilised within a deliberative observational framework to output an improved

process model (X-machine) specification. This same process could equally be applied

were a Petri-Net or other formal system is called for. Thus the situation calculus may

act as the described “lingua franca” to ground instances of novel behaviour, which are

then expressible in a range of alternative formalisms with a choice determined by

domain or parametric suitability. The next section demonstrtes this approach with a

dual specification of ant foraging behaviour (very useful for resource allocation in

large scale SOA) for X-Machines and situation calculus, where the translation can be

clearly seen and the relative merits of using situation calculus for grounding instances

of behaviour and verifying system properties is demonstrated.

3 Ant Foraging Example Specification

Ant Foraging provides a realistic scenario, from nature, to present this approach. Ants

can be viewed as low-level observational or regulatory agents whilst food particles

may be viewed as services. Here the individual ants start out at the nest, which is

positioned at coordinates (0, 0). They leave the nest and wander randomly until

discovering a piece of food. This position is memorized the food is picked up and the

ant returns to the nest. If whilst returning to the nest more food is discovered the

location is added to memory. Upon returning to the nest the ant deposits its morsel of

food and returns to the space outside the nest; wandering randomly if there are no

food locations in memory or returning to a known food source otherwise. This

example is shown in Figure 1. It may be represented in an X-Machine by: The inputs:

ぇ = ({outside,nest}∪FOOD)×POS×POS where FOOD is a set of suitable foods for

the ant and POS⊆Z gives values for the x and y position of the ant in the world.

The set of outputs are messages:

Γ = {“wandering”, “heading to nest”, picking up food”,……}

The ant has a set of possible states:

Q = {ATNEST, WANDERING, ATFOOD, TONEST, FOODSEARCH} where

wandering is the state of randomly searching for food, whilst FOODSEARCH is the

state in which the ant is returning to a known food source. TONEST is the state where

the ant has picked up some food and is returning to the nest.The ant memory has three

elements: M = (FOOD∪{none})×(POS×POS)×<(POS×POS> where the ants memory

consists of the food it is carrying or not, its current position in the world and a finite

sequence of coordinates representing the path back to a known source of food. here <

> signifies a finite list containing elements from the enclosed set.

The initial memory, assuming the nest is located at the origin is m0 = (none, (0,0),

nil) meaning the ant is not holding any food; it is at the nest and doesn’t have any

record of food sources.

The initial state q0 = ATNEST

The next state partial functions are:

move((outside, x’,y’), (none, (x,y), nil)) →

(“wandering”, (none, (x’,y’), nil)), if next ((x,y), (x’y’))

The next state partial functions are:

move((outside, x’,y’), (none, (x,y), nil)) →

(“wandering”, (none, (x’,y’), nil)), if next ((x,y), (x’y’))

movetoFood((outside,x’,y’),(none,(x,y) ,<(fx1,fy1),……(fxnfyn)>)) →

(“moving to food”,(none, (x’,y’), <(fx1,fy1),……(fxnfyn)>),

if [(next ((x,y), (x’y’)))∧(distance((x,y), (fx1,fy1)) > distance((x’,y’), (fx1,fy1)))]

Fig.1. Ant foraging behaviour

movetoNest((space, x’ ,y’), (f, (x,y), <foodlist>)) →

(“heading to nest”, (f, (x’, y’), <foodlist>)), if [(f∈FOOD) ∧ (next ((x,y), (x’y’)))

∧ distance((x’, y’), (0, 0)) < distance((x, y), (0, 0))

pickupFood((f, x, y), (none, (x,y), <foodlist>)) →

(“picking up food”, (f, (x,y), <(x,y),foodlist>)) if [(f∈FOOD)]

findFood((f, fx, fy), (f’, (fx, fy), <foodlist>)) →

(“foodsource”, (f, (fx, fy), <(fx, fy), foodlist>)) if {f’∈FOOD]

drop((nest, 0 ,0), (f, (0, 0), <foodlist>)) →

(“droppingfood”, (none, (0,0), <foodlist>)

In order to provide a notion of equivalence the states and partial functions of the X-

Machine can be represented in situation calculus:

ATNEST(do(a,s)) ⇔

ATNEST(s) ∧ [¬∃(x,y)(a=move(x,y)∧(x,y)≠(0,0))]∨ a=move(0,0)

WANDERING(do(a,s)) ⇔

[WANDERING(s)∧[pos(s)=(x,y)∧[¬∃f(a=findFood(f,x,y)∨

a=pickupFood(f,x,y))]∨ a≠move(0,0)]]∨ (ATNEST(s) ∧(a=move(x,y) ∧ (x,y)≠(0, 0))

ATFOOD(do(a,s))⇔

[ATFOOD(s)∧¬∃(x,y)(a=move(x,y))]∨∃f(a=findFood(f,x,y)∧pos(s)=(x,y))

TONEST(do(a,s)) ⇔

(TONEST(s)∧a≠move(0,0))∨(pos(s)=(x,y)∧∃f(a=pickupFood(f,x,y)))

FOODSEARCH(do(a,s)) ⇔

[FOODSEARCH(s)∧(¬∃f(a=pickupFood(f,x,y)))]∨∃(x,y)(a=movetoFood(x,y))

The memory and partial functions follow likewise:

food(f, do(a,s)) ⇔

[food(f,s)∧a≠drop(f)]∨(pos(s)=(x,y)∧∃f(a=pickupFood(f,x,y)))

none(do(a,s))⇔

[none(s)∧¬(pos(s)=(x,y)∧∃f(a=pickupFood(f,x,y)))] ∨∃f(food(f,s)∧a=drop(f))

pos(do(a,s))=(x,y)⇔

(pos(s)=(x,y)∧¬∃(x’y’)(a=move(x’,y’)))∨∃(x’,y’)(pos(s)=(x’,y’)∧a=move(x, y))

foodlist(do(a,s))=<(x1, y1), (x2, y2)…….(xn, yn)> ⇔

[(foodlist(s))=<(x1,y1),(x2,y2)…….(xn,yn)>∧¬∃f(pos(s)=(x,y)∧

a=findFood(f, x, y)∨a=pickupFood(f, x, y)]∨

[foodlist(s)= <(x2, y2), (x3, y3)…….(xn, yn)> ∧∃f(pos(s)=(x1, y1) ∧

(a= findFood(f, x1, y1)∨a= pickupFood(f, x1, y1))]

The action precondition axioms of the situation calculus specification mostly

correspond to the conditionals used at the end of the X-machine partial functions:

poss(move(x,y),s) ⇒ ∃(x’, y’)[pos(s)=(x’,y’) ∧ next((x’, y’), (x, y))]

[Also next may be modelled as an X-machine or in situation calculus; the particular

characteristics are not important for the general specification. However it may be that

the ant can move only one square, in the world at a time so that:

next((x’, y’), (x, y)) ⇒( x=x’+1) ∨ (x=x’-1) ∨ (y=y’+1) ∨ (y=y’-1) as an example]

poss(findFood(f,x,y), s) ⇒ (f∈FOOD) ∧ (pos(s)=(x,y))

poss(pickupFood(f,x,y)⇒(f∈FOOD)∧ (pos(s)=(x,y))∧(none(s))

poss(movetoFood(f,x,y),s) ⇒foodlist(s)=<(x,y), (x1, y1), (x2, y2)…….(xn, yn) >

poss(drop(f),s)⇒ ATNEST(s)∧food(f,s)

3.1 Checking the X-Machine/Situation Calculus Model

Approaches to checking properties of the model differ significantly between a

situation calculus representation and an X-machine one. Because situation calculus is

already formulated logically it is a simple matter to prove properties of the system.

For instance the statement: ∃s[ATFOOD(s)∧ATNEST(s)] is easily verified in the

logic. The process for X-machines is a little more complex as the representation needs

to be encoded into a suitable logic. A temporal logic (CTL*, for instance) is generally

used with X-Machines, taking the transitions as a timed model. This usually has two

basic path quantifiers “A” meaning for all paths through the time tree and “E” for

there exists a path. There are also five operators: X means that a property holds in the

next state; F means that a property holds at some state on a path; G means a property

holds at every state on a path; U means a property p (say) holds until another property

q (say) becomes true; R means a property p holds while q is not true with no

guarantee that q will ever become true. Then there are two new memory

quantification operators: Mx meaning for all memory instances and mx - meaning

there exists memory instances

This logic can now be used to verify the X-machine model. For instance the ant

agent is required to carry food to the nest; the model checking can verify whether

food will be dropped in the nest for memory tuple (m1, m2, m3) by stating in all states

of the X-machine either the ant doesn’t hold any food or there exists a path from that

state to another where the ant doesn’t hold food:

AG[¬Mx(m1≠none)∨EFMx(m1=none)]

Similarly it can be stated that the ant holds food at some point having previously

never done so:

E[Mx(m1=none)UMx(m1≠none)]

This statement is explicit in the situation calculus viz:

none(do(a,s)) ⇔ [none(s) ∧ ¬(pos(s)=(x,y) ∧∃f(a=pickupFood(f,x,y)))] ∨

∃f(food(f,s)∧a=drop(f))

Following this checking that the model is correct the next step is check that the

implementation is correct with respect to the verified model.

4. Case Study: Evolution by Active Clustering

This section reports on a simulation implementing the ant foraging behavior as active

clustering within a service oriented facility in cloud computing: Agent ants follow

regulatory governance policies regarding connectivity of service agents (which the

ants treat as food particles). The simulation is run, with service agents grouped by the

policies detailed in the situation calculus specification and the formal X-Machine

model extracted after a reasonable time. The system is then redeployed with the new

formal model and the performances, based on a measure of throughput (the number of

completed jobs per unit time in the SOA), are compared. Specifically in [30] Active

Clustering is considered, as a self-aggregation algorithm, to rewire a service network.

Application of this procedure is intended to group like-service instances together, in

the same way as food accumulates at the nest in the previously specified ant foraging.

This addresses the governance concern of resource allocation as many load balancing

algorithms, as illustrated in [31], only work well in cases where the nodes are aware

of their like nodes and can easily delegate workload to them. Active clustering

provides an implementation of ant foraging behaviour for efficient resource allocation

in a large-scale SOA.

Active Clustering consists of iterative executions of ant foraging behaviour by

each node in the network: Firstly at a random time point the service node becomes an

“initiator” and selects a “matchmaker” node from its neighbours. Then the

“matchmaker” node searches for, selects and causes a link to be formed between one

of its neighbours that match the service type of the “initiator” node and the “initiator”

node. Finally the “matchmaker” removes the link between itself and its chosen

neighbour.This algorithm was studied extensively in [28], showing the organisation of

a complex network towards a steady state. This behaviour exactly matches the ant

foraging algorithm with the iniator node specifying the nest location; the matchmaker

node behaving as the ant forager and the match node representing the food.

4.1 Experimental Results

The experiment was established using simulations set up in Repast.NET [32]. The

experiments were set up replicating the domain described in [21] with the initial X-

Machine formal model enacted from the previous section. The simulations were

repeated at least 20 times each. In this experiment a scale free network consisting of

100 service nodes is constructed. The number of job types (or service node types) is

equal to 10. Every 20 seconds 400 jobs are inserted into the system at a randomly

chosen service node of each type. The execution time for each job is equal to 5 sec.

The results show a throughput variation depending on the organization of network

(nodes of each type are generated and connected randomly in the scale free network

so the application of active adaptive clustering affects the results). The experiment

showed a throughput converging to around 15 jobs per second at t=600 as shown in

Figure 2.

Fig.2. Initial throughput for initial process model

The experiment was then repeated with the X-Machine model enacted subsequent

to the logical deliberation. In other words the previous runtime was used as a tuning

period, altering and updating the logical model to optimise the resource locations,

which was then derived as a new X-Machine specification. The results showed a more

rapid convergence to a throughput of around 18 jobs per second. This is shown in

Figure 3.

Fig.3. Throughput for enhanced process model

It can be clearly seen, in Figure 3, that the throughput following enactment of the

derived X-Machine model, based on capturing the evolved previously enacted self-

organised system model, rapidly reaches a steady state of 18 at around t=100. In

contrast, the initially enacted model approached a steady state of around 15 at t=800.

Thus the throughput figure shown in Figure 3 has benefitted from the self-

organisation captured in the model extracted from the run shown in Figure 2. In

practice this process would be seamless with no separation of models: Newly

acquired, improved behaviour models would be incorporated into the system at

runtime. The division was introduced into the simulation to demonstrate the

difference upon introduction of a new behavioural model.

5. Conclusion

Through this work it is proposed that such formal representations as Finite State

Machines and X-machines provide desirable features in seeking to provide efficient

and quick service oriented system development. This, however, is achieved at the cost

of relying on flat and inadaptable formal specifications. In contrast logical formalisms

provide a rich formal modelling environment providing verification and model

checking as part of the formalism whilst enabling open systems, where reasoning can

proceed on the observed system’s operating environment and enhanced improved

formal specifications can be exported.

The purpose of this paper has been to demonstrate that a logical language, with its

associated beneficial features, can act as core language, which is translatable into the

most appropriate state based formalism. It has been shown how a multi-agent FSM

and logic approach can be developed in parallel. The logic is then able to specify

observer agent components for the services that adapt to provide emergent control

based on the systems evolution and self-organisation. The observer agent possesses

the logical simulator for the system as well as being able to ground new instances of

behaviour. These instances of behaviour are then incorporated into the system design

through an FSM (X-Machine) specification; all this occurring through the runtime.

There are numerous logical techniques that may be used to reason over complex

service oriented systems. In this paper a situation calculus runtime multi-agent model,

capable of runtime introspection and adjustment, was used to encode an X-machine

design time specification. The adapted logical model is then used to derive a new

regulatory design process model for a service oriented system.

It is the subject of further work to widen the scope of this application to include

additional regulatory and governance concerns. Further works are also required to

investigate the optimum tuning periods, before improved model incorporation and

number of iterations in real practical systems. The main result of this paper is a

demonstration of a method, illustrated by simulation, to allow the dynamic evolution

of systems with updates as a consequence of the runtime self-organisation: In this way

tools are available for improving the design time specification, or runtime

governance, of large scale, complex and distributed service oriented systems.

References

1. R.L. Grossman, "The Case for Cloud Computing," IT Professional, vol.11, no.2, pp.23-27, March-April 2009

2. P.A Laplante, Zhang Jia and J.Voas, What's in a Name? Distinguishing between SaaS and SOA, IT

Professional , vol.10, no.3, pp.46-50, May-June 2008

3. C.Schroth and T. Janner, Web 2.0 and SOA: Converging Concepts Enabling the Internet of Services. IEEE IT Professional Vol.9, No.3 pp.36-41, June 2007.

4. H.Parunak, (1997) Go to the Ant: Engineering Principles from Natural Multi-Agent Systems, Annals of Operations Research 75,pp: 69– 101.

5. C.Reynolds, (1987) Flocks, Herds and Schools: A Distributed Behavioural Model, Computer Graphics 21 pp: 25–34.

6. Marco Mamei, Ronaldo Menezes, Robert Tolksdorf, Franco Zambonelli (2006) Case Studies for Self-Organization in Computer Science. Journal of Systems Architecture, 52(8), pp: 443-460

7. C.B. Jones, (1990) Systematic Software Development using VDM. Prentice-Hall, NJ, USA.

8. W.A. Wulf, M. Shaw, P.N. Hilfinger, L. Flon (1981) Fundamental Structures of Computer Science. Addison-Wesley, MA, USA.

9. W.Reisig, (1985) Petri Nets-An Introduction. EATCS Monographs on Theoretical Computer Science, Volume 4, Springer, Berlin, Germany.

10. Diego Perez-Palacin, Jose Merseguer, Performance Evaluation of Self-reconfigurable Service-

oriented Software With Stochastic Petri Nets, Electronic Notes in Theoretical Computer Science,

Volume 261, Proceedings of the Fourth International Workshop on the Practical Application of

Stochastic Modelling (PASM 2009), 22 February 2010, Pages 181-201

11. Philip Mayer, Nora Koch, and Andreas Schroeder. The UML4SOA Profile. Technical report,

Ludwig-Maximilians-Universitat Munchen, July 2009.

12. Quan Z. Sheng, Sam Pohlenz, Jian Yu, Hoi Sim Wong, Anne H.H. Ngu, and Zakaria Maamar

ContextServ: A Platform for Rapid and Flexible Development of Context-Aware Web Services.In

Proceedings of the 31st International Conference on Software Engineering (ICSE 2009), May 16-24,

2009, Vancouver, Canada pp: 619-622.

13. M.Holcombe, (1988) X-Machines as a Basis for Dynamic System Specification. Software Engineering Journal 3(2), pp: 69-76

14. S. Eilenberg (1974) Automata, Languages and Machines. Academic Press

15. H. J. Levesque F. Pirri and R. Reiter (1998) ‘Foundations for the Situation Calculus’. Linköping Electronic Articles in Computer and Information Science, Vol. 3(1998): nr18. http://www.ep.liu.se/ea/cis/1998/018/

16. S. Narayanan and S. McIlraith, Simulation, Verification and Automated Composition of Web Services. In Proceeding of the Int"l World Wide Web Conf. (WWW2002), 2002, pp. 77–88.

17. DAML-S versions 0.7 and 0.9. http://www.daml.org/services/.

18. Martin Randles, A. Taleb-Bendiab and David Lamb, Cross Layer Dynamics in Self-Organising Service Oriented Architectures. IWSOS, Lecture Notes in Computer Science, 5343, pp. 293-298, Springer, 2008.

19. Martin Randles, A. Taleb-Bendiab and David Lamb, Scalable Self-Governance Using Service Communities as Ambients. In Proceedings of the IEEE Workshop on Software and Services Maintenance and Management (SSMM 2009) within the 4th IEEE Congress on Services, IEEE SERVICES-I 2009 - July 6-10, Los Angeles, CA

20. R. Ruggaber, Internet of Services SAP Research Vision. In 16th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE 2007), pp: 3.

21. S. Nakrani and C. Tovey, On Honey Bees and Dynamic Server Allocation in Internet Hosting Centers. Adaptive Behavior 12, pp: 223-240 (2004).

22. E. Di Nitto, D.J. Dubois and R. Mirandola, Self-Aggregation Algorithms for Autonomic Systems. In Proceedings of the 2nd Internation Conference on Bio-Inspired Models of Network, Information and Computing Systems, 2007 (Bionetics 2007), pp.120-128, 10-12 Dec. 2007

23. P.Kefalas, XMDL User Manual, Version 1.6, Technical Report TR-CS07/00, Department of Computer Science, CITY Liberal Studies, 2000.

24. R.Reiter (1991) “The Frame Problem in the Situation Calculus: A Simple Solution (sometimes) and a Complete Result for Goal Regression”. Artificial Intelligence and Mathematical Theory of Computation: Papers in Honor of John McCarthy, ed: V. Lifschitz, pp:359-380, Academic Press, San Diego, California.

25. R.C.Moore, “A Formal Theory of Knowledge and Action”, In Formal Theories of the Commonsense World, eds: J.B. Hobbs & R.C. Moore, pp:319-358, Ablex Publishing Corporation, Norwood, NJ, 1985

26. S Bullock, D.Cliff (2004) Complexity and Emergent Behaviour in ICT Systems. Technical Report HP-2004-187, Semantic & Adaptive Systems, Hewlett-Packard Labs. Available from: http://www.hpl.hp.com/techreports/2004/HPL-2004-187.pdf (Accessed March, 2010).

27. A.Cerone, G.J. Milne (2005) Property Verification of Asynchronous Systems. Innovations in Systems and Software Engineering 1(1), pp: 25-40, Springer-Verlag London, UK.

28. B.C. Smith “Reflection and Semantics in a Procedural Language”, PhD. Thesis in Department of Computer Science. 1982, MIT: Cambridge, Mass.

29. M.Randles, A. Taleb-Bendiab, P. Miseldine (2006) Addressing the Signal Grounding Problem for Autonomic Systems. In Proceedings of International Conference on Autonomic and Autonomous Systems (ICAS06), pp: 21,Santa Clara, USA, July 19-21

30. F. Saffre, R. Tateson, J. Halloy, M. Shackleton and J.L. Deneubourg, Aggregation Dynamics in Overlay Networks and Their Implications for Self-Organized Distributed Applications. The Computer Journal, March 31st, 2008.

31. G. Cybenko, Dynamic Load Balancing for Distributed Memory Multiprocessors. Journal of Parallel and Distributed Computing Vol. 7(2), pp: 279-301, 1989.

32. Repast Organization for Architecture and Development, http://repast.sourceforge.net, 2003 (Accessed 10th October 2009)

Integrating Process Modelling

into Multi-Agent System Engineering

Tobias Kuster, Marco Lutzenberger, Axel Heßler, and Benjamin Hirsch{tobias.kuester|marco.luetzenberger|

axel.hessler|benjamin.hirsch}@dai-labor.de

DAI-Labor, Technische Universitat Berlin, Germany

Abstract. While today’s agent oriented software engineering facilitatesthe development of complex, distributed systems, fundamental problemsremain. One of the difficulties is that one can see only part of the sys-tem, or one side of the business, but not the whole context. BPMN isconsidered a remedy here, but while suitable for modelling some aspectsof agenthood, there are others for which BPMN does not go very well. Inthis paper, we show how BPMN can be embedded in a broader method-ology so that its strengths can be exploited while avoiding its weaknesses.

1 Introduction

The design of large, distributed applications involving several communicatingpartners can be extremely challenging. Besides the prevailing SOA solutions,agent-oriented systems are regarded as a promising approach in this domain [1].Today, a variety of multi-agent systems provide means for facilitating the imple-mentation of such systems, such as libraries and special languages for discovery,messaging, and event handling, and some provide advanced concepts like pro-activeness and autonomy. However, some general problems of distributed systemsremain, such as the alignment of sending and receiving messages in a complexcommunication protocol.

The developer sees just a part of the problem: One file of source code, oneagent’s set of rules, one side of the communication. What is needed is a holistic,integrated view on the system, showing the involved partners and their processesas they are orchestrated in the system. Additionally, everything has to be well-documented, especially in cross-enterprise projects, and technological progressis demanding shorter and shorter development cycles.

One possible solution to this problem is the application of techniques frombusiness process design to agent engineering. Over the last years, a number ofindustrial projects have investigated business process design as a way of closingthe gap between analysis and development [2]. Many ideas from agent theory,such as roles, rules, and communication, can be found in the Business ProcessModeling Notation (BPMN), too, which has already led to some efforts of map-ping BPMN diagrams to multi-agent systems, as we will see later. We will havea closer look on BPMN in Section 2.

Still, there are other aspects, for which BPMN is not intended, such as organ-isation, data, or complex algorithms. While BPMN describes business partners,i.e. roles, it does not define how these are implemented by agents, let alone theirphysical location. And while process diagrams are in general very well suited fordisplaying all kinds of control flow, modelling each single algorithm in BPMNwould not be adequate. Finally, while BPMN can refer to data types, e.g. forproperties and assignments, it does not provide means for defining them.

In order to apply business process design in agent engineering, it needs tobe combined with other techniques and additional notations. Therefore, in Sec-tion 3, we introduce a methodology, in which BPMN is used together with ontol-ogy engineering, multi-agent system design and service engineering, combiningthe strengths and balancing the weaknesses of the individual approaches. Whilethe methodology is applicable for other agent frameworks, too, we will illustrateit using the JIAC framework, providing a number of useful tools and editors (seeSection 4). Later, in Section 5, we will apply the methodology to a simple onlineauction example, before we take a look at related work and conclude.

2 BPMN

The Business Process Modeling Notation [3] can be seen as a combination ofUML’s Activity Diagrams and Sequence Diagrams. It can be understood atthree levels of abstraction:

1. The diagrams are made up of a few easily recognisable node types, i.e. Events,Activities and Gateways, connected by control- and message flow.

2. These basic elements are further distinguished using sets of marker icons,e.g. Message, Timer, and Error Events, or parallel and exclusive Gateways.

3. Each element contains a number of additional attributes, which are hiddenfrom the diagram, but contain all the information that is necessary for au-tomated code generation.

Thus, BPMN is easily understandable by all business partners, even those whohave great knowledge in their domain but do not know too much about pro-gramming and multi-agent systems. At the same time, BPMN diagrams provideenough information for generating executable program code from them.

One problem with BPMN which is often brought up is that most of thesemantics are derived from the mapping from BPMN to the Business ProcessExecution Language (BPEL), so for those elements that are not covered by thismapping the semantics are not always made clear, let alone formally defined.Still there is an increasing number of approaches describing the semantics ofBPMN using e.g. Petri nets [4–6], and version 2.0 of the specification makesthings clearer, too. But why not use Petri nets in the first place? The answeris simple: While Petri nets have very clear semantics, and basically everythingcan be expressed as a Petri net, some high-level constructs, that are directlysupported by BPMN, would result in huge, incomprehensible Petri nets.

BPMN diagrams, on the other hand, have a variety of notational elements,making them well suited for the design of distributed systems in general andmulti-agent systems in particular. The process diagrams are subdivided in pools,each representing one participant in the process, which maps to the concept ofagent roles. Using message flows for communication between pools, even com-plex interaction protocols can be modeled clearly. The “ad-hoc” process evenresembles goal-oriented behaviour. Further, the notation supports features suchas event- and error handling, compensation and transactions.

But as already mentioned, there are other aspects of a system that can notbe designed very well using BPMN alone. We will focus on these issues and howto deal with it in the next section.

3 Methodology for Process Oriented Agent Engineering

The core aspect of our approach is the application of business process design inan early stage of the development process in order to provide a holistic view ofthe entire distributed multi-agent system. As we have pointed out, BPMN aloneis not sufficient for this task, but has to be embedded in a methodology that dealswith the missing aspects, including (a) the declaration of data types, (b) design ofagent organisation and distribution, and (c) textual programming for low-levelalgorithms. Further, as one BPMN diagram shows only one business process,while a complex system might consist of a number of processes, we also include(d) use case diagrams, providing an overview of the processes belonging to thesystem and their relation to the several participants. Finally, no methodologycan be complete without iterative development, testing and maintenance.

Fig. 1. Process diagram showing the stages emphasised in this work within the com-plete methodology.

The “big picture” is shown in Fig. 1: The development process starts withuse case analysis and ontology engineering. Then, for each use case a businessprocess diagram is created. From the processes, the role model and a numberof behaviours/capabilities are derived. Both are then further refined using toolsmore suitable for this task than BPMN. Finally, the agent organisation model

and the components are integrated and tested, and the process can go intoanother iteration, until the system is eventually deployed. In the following, wewill describe the relevant steps in more detail.

3.1 Use Case Analysis and Ontologies

The methodology starts with the identification of actors and use cases of thesystem under design. For this task we adopted the use case notation from UML.Here, each actor represents an agent role, with each use case being a businessprocess in which the actor takes part. Apart from providing an entry pointinto the design, this also serves as a connection between the several businessprocess diagrams, since one BPMN diagram alone does not suffice for describinga complete system.1

Another task that can and should be accomplished in this early phase isthe (formal) definition of the domain vocabulary or ontology. However, in thecontext of this methodology it is not relevant whether this is done using UMLclass diagrams, Java classes, or sophisticated ontology languages, such as OWL.

3.2 Business Process Engineering

Next, a number of BPMN diagrams are created based on the use case diagrams.Each use case corresponds to one business process, and each actor involved in theuse case matches one pool in that process diagram. Here, the process diagramsare not used for modelling the entire life cycle of that actor. Instead, they depictonly the workflow and the communication between the actors for this specificuse case. In this regard they can be seen as a combination of activity diagramsand protocol diagrams. The process diagrams will serve as starting point for theimplementation.

As a rule of thumb, the process diagrams should contain at least each ac-tivity and each branch related to the communication with the other actors,referred to as the ‘public process’ in the BPMN specification [3]. The payload ofthe messages should also be specified using the formerly defined domain model.Of course, the diagrams can be further detailed to contain more of the actor’sinternal activities (the ‘private process’), since they can also be used as docu-mentation and for validating the final implementations against them. But as thediagrams’ complexity quickly increases as one tries to depict each detail of analgorithm, the modeler has to find an adequate compromise here. For example,while possible, it does not seem reasonable to detail a path finding algorithm likeA

∗ in BPMN; instead, a single activity called ‘calculate path’ should be used.

3.3 From Business Process to Multi-Agent System

The business process diagrams provide a view on the system as a whole thatcan be used as groundwork for the following implementation of (a) the agents’

1 Version 2.0 of BPMN includes Conversation Diagrams, serving a similar purpose.We still prefer use case diagrams, as these are more intuitive to understand.

behaviour, e.g. in the form of plans, rules, or services, and (b) the organisationalmodel, e.g. roles, agents, and agent platforms.

Of course, the derivation of agent behaviours from the process diagrams ishighly dependent on how behaviours are implemented for a given agent frame-work, e.g. imperative or declarative, as a set of rules, goal-oriented, or as hybridapproaches, and whether it is done automatically or manually. Generally speak-ing, for each pool in the different process diagrams, or more precisely, for eachstart event in the pools, one behaviour is derived, covering the workflow (branch-ing, communication, etc.) from that starting point on. For instance, a pool with amessage start event can be translated to a script for the content of the workflowand a rule for starting that script when the given message arrives.

The basic procedure of the mapping has been developed in our previous work.First, a BPMN normal form for facilitating the mapping has been investigatedand formalised using Petri nets [5]. Then, the first steps of the actual mappingwere specified, basically mapping pools to agents, processes and flow objectsto the agents plans and the control flow, and message flow to the exchange ofmessages between the agents [7]. Since then, the mapping has been adaptedin order to provide better support for systems consisting of multiple BPMNdiagrams, by taking the use case diagrams into account, too.

The use cases and actors are used for identifying the agent roles. For eachactor one agent role is defined, offering the respective behaviours derived fromthe processes corresponding to that use case. Since the business process diagramsmake no assertions towards the grouping of roles to individual agents and agentsystems, this aspect has to be dealt with in the next step.

Fig. 2 shows an overview of the models and their dependencies. Both parts ofthe transformation can be done manually or automatically. We will introduce aBPMN editor that can be used for automatically generating services and a rolemodel for the JIAC framework in Section 4.1.

3.4 Refinement

By now we have agent roles and their relation to a number of behaviours, de-rived from the use cases, and the behaviours implementing the workflow and thecommunication as designed in the BPMN diagrams.

As mentioned, the use of BPMN is not efficient when going into too muchdetail. Thus, in this step the behaviours are refined with everything that is toocumbersome to model in BPMN, e.g. complex calculations, or GUI calls. Further,the role model has to be completed with actual agents and agent platforms.

3.5 Integration, Testing, Deployment

After the different parts have been integrated, the system needs to be tested.Here, the process design can be of some help, too, as processes can be simulated,similar to a Petri net, and the behaviour of the final system can be compared tothat of the process. Most notably, the use of model driven engineering ensures

Fig. 2. Overview of models and their dependencies. Use Cases, Process Model, RoleModel, Implementation

the consistency of the resulting multi-agent system with the formerly definedmodels. Depending on the applied tools, the system (or at least parts of it) canbe generated from the models, and the models can be updated according to theimplementation. However, the latter is still a hot topic of current research.

4 The JIAC V Agent Framework and Tools

While our methodology is independent from any specific agent framework, ithighly benefits from model driven engineering, thus a certain amount of toolsupport should be provided, so that the mapping from the process models tothe implementation can be automated. In this section we will have a look at theJIAC framework, which satisfies this requirement.

JIAC V is a Java based multi-agent development framework and runtime en-vironment [8]. JIAC combines agent technology with a service oriented approachand accentuates this facet by its scripting language JADL++. Furthermore, theframework features transparent distribution of agents and services, semantic ser-vice descriptions (based on ontologies), agent management, and provides supportfor dynamic reconfiguration in distributed environments, such as component ex-change at runtime and strong migration.

JIAC V agents can be programmed using plain Java or JADL++. UsingJava, the agents’ behaviour is defined in a number of so-called agent beans,which are controlled by the agent’s life cycle. While agent beans are requiredfor some sorts of behaviour, e.g. for displaying a GUI, or perceiving or actingin non-agent environments, other aspects, such as memory access, or messaging,can be abstracted using JADL++. The language features knowledge, or facts,

based on the ontology language OWL as well as an imperative scripting partthat is used for the implementation of services, including high level languagefeatures such as parallelism, events, and many more.

JIAC comes with a set of tools, supporting development from the analysis tothe deployment of multi-agent applications. The most important tools regardingour methodology are introduced in the next sections.

4.1 The Visual Service Design Tool

Our methodology starts with defining use cases and the respective BPMN pro-cesses. This stage is supported by the Visual Service Design Tool (VSDT) [9], aBPMN editor, providing process analysis and validation tools, such as a processstructure view, a process simulator, and the generation of natural language pro-cess documentation (see Fig. 3). The VSDT is also used for creating the use casediagrams, establishing the relation of participants to processes and connectingthe individual business process diagrams to a complete system.

The VSDT includes an extensible transformation framework, which is re-sponsible for grouping the nodes of the process graphs to blocks of structuredprogramming languages (i.e. sequences, selections, and repetitions). Currently,the process diagrams can be exported to both BPEL and to JIAC’s scriptinglanguage JADL++, and more transformations can easily be added. The use casediagrams are translated to the agent role model and the relation of the roles tothe generated services. These models then serve as input for the Agent WorldEditor.

Fig. 3. The Visual Service Design Tool

4.2 The Agent World Editor

The MAS Design in JIAC is done with the Agent World Editor (AWE) [10].AWE allows for the visual creation and editing of multi-agent systems via dragand drop and supports concepts such as agent-nodes, -types and -roles or com-ponents. The applied notation is simple but comprehensive and represents theentire MAS in one single diagram as directed graph (see Fig. 4). Access to thefile system allows to reference existing agent beans or JADL services just likethe ones created by the VSDT.

A code generation feature allows for the generation of executable code fromthe visual MAS design. The code can be understood directly by the JIAC runtimeand triggers the execution of a MAS according to the design specification.

Fig. 4. Agent World Editor and JADLedit as a part of JIAC’s tool suite.

4.3 JADLedit

JADLedit [11] is a source code editor for JADL++. The tool facilitates thedevelopment of JIAC services with features such as syntax highlighting, codecompletion, and error marking (Fig. 4). Regarding the methodology, JADLeditis used for the implementation of previously generated service stubs.

As stated above, JADL++ services are using OWL as representation forcomplex data types. Thus, JADLedit allows for type safe editing of knowledge(facts). For this purpose JADLedit includes an ontology browser view, which canbe used for browsing existing OWL ontologies, providing a visual representationof their classes and properties.

5 Example

In this Section we demonstrate how our methodology is applied using the exam-ple of a simple English online auction scenario.

First, the use cases are identified using the VSDT. In our example we havethe use cases Create Auction, Place Bid and Close Auction, which are performedby the actors Auctioneer, Seller and Bidder.

The next step is ontology engineering. We have categories such as Seller andBidder, holding e.g. their nickname, rating, and contact information, as well ascategories like Auction and Bid. However, we will not go into more detail hereand fast-forward to the process engineering instead.

Each use case corresponds to a business process, and modelling these is themain task of the VSDT. Close Auction is the most interesting, so we will havea closer look at it.

Each of the actors involved in the use case corresponds to a pool: Auction-eer, Bidder, and Seller. The auctioneer starts the process when the time of theauction is over. He acts as trustee between seller and bidder, which are more orless just reacting to him. In case there are no bids at all, the seller is notified andthe process terminates. Otherwise, both the seller and the awarded bidder arenotified, and the auctioneer waits for the bidder to transfer the money. When thebidder informs the auctioneer that the money has been transferred, the auction-eer notifies the seller, who then ships the goods and informs the auctioneer. Theauctioneer then transfers the bidder’s money to the seller and finally removesthe auction from its data store. The full process can be seen in Fig. 5. While thisdiagram shows more than just the “happy path”, there are surely many moreexceptions and what-ifs needed for a real auction, but for a small example thiswill do.

Fig. 5. BPMN diagram for use case Close Auction

Next, the process has to be enriched with non-graphical elements and at-tributes, using the categories defined in the ontology, such as the messagessent, assignments made, and expressions used in branching conditions. Whilethe VSDT does provide means for assisting this task, e.g. basic validation forassignment expressions and conditions, it is still relatively laborious, and we arecurrently investigating ways to simplify this part.

Next, the VSDT’s export feature is used to generate agent roles and JADLservices from the BPMN diagrams, which are then detailed further using AWEand JADLedit.

We enrich the role model with additional roles and components needed forthe example, aggregate the roles to agents and place these agents on agent nodes.In our example, we have one auctioneer agent and some agents implementing theroles of both, seller and bidder, all situated on one node, as depicted in Fig. 6.

Fig. 6. Left: Use Case diagram. Right: Agent World Diagram. The framed portion hasbeen generated from the use case and process diagrams.

Note that while for each actor one role has been created, there are morecomponents (in this case: JADL services) that there were use cases. For eachpool (i.e. each actor participating in a given use case) one service is created,which is reflected as a component in the agent world diagram. For the seller’spool in the above diagram, a total of three services has been created, so we willtake a closer look at this one now.

The seller’s part of the Close Auction process begins with either receiving amessage telling him that his item has been sold, or receiving a message tellinghim that no sale was made. This results in two JADL services being generatedfor the seller. Further, as the ‘sold’ case can merge into the ‘not sold’ case if thebidder does not respond to the payment request, a third service is created, thecommon part of both services, which is called at the end of each of the former.

Making things further complicated, the process does not have proper blockstructure, which is required for most programming languages, including JADL++.

Thus, the activity dismiss auction is duplicated and moved to the end of the twobranches, just before the merging gateway. 2 Thus, the seemingly simple sellerprocess results in three interacting services with some shared logic.

The generated JADL services, holding the necessary communication withthe business partners and the basic branches and decisions, can now be furtherrefined and extended using the JADLedit source code editor.

6 Related Work

For our work, we evaluated a number of similar approaches which combine pro-cess modelling with agent technology.

The Agent-oriented Development Methodology (ADEM) [12] uses a combi-nation of business processes and agent-oriented models for the overall softwareengineering, while the agent model is developed by using the Agent ModelingLanguage (AML) [13], an extension to the UML 2 notation. GO-BPMN (goaloriented BPMN) is used for describing agent systems based on processes andthe goals they fulfil [14]. This seems like double work done by the modeller asthey use goals as finite states of the processes (see for example [15]). In ourapproach, we use domain ontologies to capture, analyse and model the “what”.When using process modelling, we are more interested in capturing the ideaand the expertise of a domain expert of “how” things are done or should bedone, also through different levels of abstraction. The “how” is modelled in aprocess diagram, which can be directly executed by the VSDT. They are alsotransformed to a JADL script and can be directly executed by JIAC agents. Wehave chosen the transformation approach here, because process models are notthe only source for JIAC-based applications (see also [16, 17]). So the runtimeenvironment is the integration point for heterogeneous design methods.

The Prometheus Methodology [18] also integrates the advantages of pro-cess orientation into the agent-oriented software development. The Methodologycomprises the three main topics System Specification, Architectural Design, andDetailed Design, and provides MAS development on the basis of several differ-ent diagrams. Prometheus applies processes for the detailed design of each singleagent type. For the specification of these processes, an extension to the UML ac-tivity diagram notation is used. At this point, Cheong and Winikoff have shownin [19] how Prometheus can easily be improved by different methods. They haveused Hermes [20] here to improve the design process regarding agent interactions,which is exactly the domain of BPMN, only for business processes.

Like Prometheus, the Gaia Methodology [21] has been designed to provideformally guided and comfortable MAS development. The methodology struc-tures itself into Analysis, Architectural Design and Detailed Design. Each phasecomprises the creation of various diagrams, each one highlighting particular as-pects of the MAS. In comparison with other methodologies, Gaia exceedinglyattends to organisational abstractions, with a particular focus on organisational

2 As a result, the third service, holding the common part, is in fact empty.

rules and -structure issues. Gaia is not intended to commit to the adoption ofa specific notation. With regard to the organisational structure, other notationscan be adopted to describe and represent roles and their interactions. A respec-tive appliance of AUML is described by Bauer et al. [22].

Klaus Fischer and his research team at DFKI is working on the DSML4MAS

Development Environment (DDE), a visual IDE for Jade [23] based on thePIM4Agents metamodel [24]. While they use processes for modelling agent plans,too, they use their own simple notation. One feature of DDE which is still miss-ing in the JIAC tools is that of ‘protected regions’ in the generated code, inwhich the code can be manually edited and will not be overwritten on coderegeneration.

WADE is an extension to JADE, using XPDL [25] for modelling workflows,which are translated to Java classes, where each activity is reflected in a methodstub [26]. A nice effect of this approach is that workflows can inherit from eachother, and that the control flow of the workflow can be revisited without con-flicting with the manually written code.

The Tropos methodology [27] is model-driven approach to agent-orientedsoftware engineering and consists of a visual notation combined with guide-lines for five development phases. It provides strong features for requirementsanalysis bases on the notions of actor, goal, plan, resource and dependency.For design activities it is combined with features from other software modellingtechniques such as UML sequence and activity diagrams together with extensionfrom AUML [28] or it inherits notions from the agent framework that is usedto implement the multi-agent system such as Jadex [29]. While Tropos is verystrong in analysing requirements we prefer the vocabulary and expressiveness ofBPMN for capturing and modelling the procedural knowledge of how thing aredone or ought to be done.

7 Conclusion

While agent-oriented software engineering is very useful for creating large, dis-tributed systems, it can still be difficult to design those systems so that theindividual parts fit together. A solution to this problem is to provide a view ofthe entire system, especially during the earlier development stages.

In this paper, we make a case for a methodology combining agent-orientedsoftware engineering with business process design using the Business ProcessModeling Notation (BPMN). Many aspects of agents are found in BPMN, too,such as roles and communication, making it very suitable for modelling theseparts of multi-agent systems. Still, using BPMN for a complete multi-agent sys-tems is not practical, thus our methodology does not rely on business processmodelling alone, but also includes the declaration of use cases and data types,the design of agent organisation and distribution, and traditional programming.

While the methodology itself is not bound to a specific agent framework, ithighly benefits from model driven engineering, so a certain amount of tool sup-

port should be provided. Therefore, we illustrated the methodology by modellinga simple online auction scenario using the JIAC framework and its tools.

Of course, there are limitations to visual, process oriented design of agent sys-tems. While the unstructuredness presented in our example could be resolved,there are process diagrams which can not be structured as well [30]. Further, ad-ditional research is needed on how the dynamic aspects of multi-agent systems– goals and planning – can best be integrated in the more rigid structures of abusiness process, for example by extending the concept of the ad-hoc process.Still, we believe that the example also shows the benefits of our approach, asthe complex control flow and communication between the involved partners canbe visualised intuitively using BPMN. Thus we recommend using process de-sign for a high level of abstraction and traditional agent oriented programmingtechniques for the details.

References

1. Luck, M., McBurney, P., Shehory, O., Willmott, S.: Agent Technology: Computingas Interaction (A Roadmap for Agent Based Computing). AgentLink (2005)

2. Garretson, P., Harmon, P.: How Boeing A&T manages business processes.Whitepaper, BPTrends (November 2005)

3. Object Management Group: Business Process Modeling Notation, V1.1. FinalAdopted Specification formal/2008-01-17, OMG (January 2008) http://www.omg.org/spec/BPMN/1.1/PDF.

4. Dijkman, R.M., Dumas, M., Ouyang, C.: Formal semantics and analysis of BPMNprocess models using Petri nets

5. Endert, H., Hirsch, B., Kuster, T., Albayrak, S.: Towards a mapping from BPMN toagents. In Huang, J., Kowalczyk, R., Maamar, Z., Martin, D., Muller, I., Stouten-burg, S., Sycara, K.P., eds.: Service-Oriented Computing: Agents, Semantics, andEngineering. Volume 4505 of LNCS., Springer Berlin / Heidelberg (2007) 92–106

6. Raedts, I., Petkovic, M., Usenko, Y.S., van der Werf, J.M.E.M., Groote, J.F.,Somers, L.J.: Transformation of BPMN models for behaviour analysis. In Augusto,J.C., Barjis, J., Ultes-Nitsche, U., eds.: MSVVEIS, INSTICC PRESS (2007) 126–137

7. Endert, H., Kuster, T., Hirsch, B., Albayrak, S.: Mapping BPMN to agents: Ananalysis. In Baldoni, M., Baroglio, C., Mascardi, V., eds.: Agents, Web-Services,and Ontologies Integrated Methodologies. (2007) 43–58

8. Hirsch, B., Konnerth, T., Heßler, A.: Merging Agents and Services — the JIACAgent Platform. In Bordini, R.H., Dastani, M., Dix, J., El Fallah Seghrouchni,A., eds.: Multi-Agent Programming: Languages, Tools and Applications. Springer(2009) 159–185

9. Kuster, T., Heßler, A.: Towards transformations from BPMN to heterogeneoussystems. In Mecella, M., Yang, J., eds.: BPM2008 Workshop Proceedings. (2008)

10. Lutzenberger, M., Kuster, T., Heßler, A., Hirsch, B.: Unifying JIAC agent develop-ment with AWE. In: Proceedings of the Seventh German Conference on MultiagentSystem Technologies, Hamburg, Germany, Springer (2009)

11. Burkhardt, M., Lutzenberger, M., Masuch, N.: Towards Toolipse 2. Tool Supportfor the Next Generation Agent Framework. Computing and Information SystemsJournal 13(3) (October 2009) 21–28

12. Cervenka, R., Trencansky, I.: Agent-Oriented Development Methodology (ADEM).Technical report, Whitestein Technologies (February 2005)

13. Cervenka, R., Trencansky, I.: The Agent Modeling Language — AML. A Compre-hensive Approach to Modeling Multi-Agent Systems. Whitestein Series in SoftwareAgent Technologies and Autonomic Computing. Birkhauser Basel (2007)

14. Burmeister, B., Arnold, M., Copaciu, F., Rimassa, G.: BDI-Agents for Agile Goal-Oriented Business Processes. In: Proceedings of the Seventh International Confer-ence on Autonomous Agents and Multiagent Systems (AAMAS 2008), Richland,SC, International Foundation for Autonomous Agents and Multiagent Systems(2008) 37–44

15. Whitestein Technologies: Cost Assessment of Risk-sensitive Banking Processeswith the Living Systems Process Suite (2009)

16. Thiele, A., Kaiser, S., Konnerth, T., Hirsch, B.: MAMS service framework. InKowalczyk, R., Vo, Q.B., Maamar, Z., Huhns, M., eds.: Service-Oriented Com-puting: Agents , Semantics, and Engineering: AAMAS 2009 International Work-shop, SOCASE 2009, Budapest, Hungary, May 11, 2009, Revised Selected Papers.Springer (2009)

17. Hessler, A., Kuster, T., Niemann, O., Sljivar, A., Matallaoui, A.: Cows and Fences:JIAC V - AC09 Team Description. In Dix, J., Fisher, M., Novak, P., eds.: Proceed-ings of the 10th International Workshop on Computational Logic in Multi-AgentSystems 2009. Volume IfI-09-08 of IfI Technical Report Series., Clausthal Univer-sity of Technology (2009)

18. Winikoff, M., Padgham, L.: Developing Intelligent Agent Systems: A PracticalGuide. Wiley and Sons (2004)

19. Cheong, C., , Winikoff, M.: Improving Flexibility and Robustness in Agent Interac-tions: Extending Prometheus with Hermes. In Garcia, A., Choren, R., Lucena, C.,Giorgini, P., Holvoet, T., Romanovsky, A., eds.: Software Engineering for Multi-Agent Systems IV: Research Issues and Practical Applications. Volume 3914 ofLecture Notes in Computer Science., Springer Berlin/Heidelberg (2006)

20. Cheong, C., Winikoff, M.: Hermes: Implementing Goal-Oriented Agent Interac-tions. In Carbonell, J.G., Siekmann, J., eds.: Programming Multi-Agent Systems.Third International Workshop, ProMAS 2005, Utrecht, The Netherlands, July 26,2005, Revised and Invited Papers. Number 3862 in Lecture Notes in ArtificialIntelligence, Springer Berlin/Heidelberg (2006)

21. Zambonelli, F., Jennings, N.R., Wooldridge, M.: Developing multiagent systems:The gaia methodology. ACM Transactions on Software Engineering and Method-ology 12(3) (July 2003) 317–370

22. Bauer, B., Muller, J.P., Odell, J.: Agent UML: A Formalism for Specifying Multi-agent Software Systems. In Ciancarini, P., Wooldridge, M., eds.: Agent-OrientedSoftware Engineering, First International Workshop, AOSE 2000, Revised Papers.Volume 1957 of LNCS., Springer-Verlag (2001) 91–104

23. Warwas, S., Hahn, C., Fischer, K.: A Visual Development Environment for Jade. InCastelfranchi, D.S.S., ed.: Proceedings of the Eighth International Conference onAutonomous Agents and Multiagent Systems (AAMAS 2009). (2009) 1349–1350

24. Hahn, C., Mora, C.M., Fischer, K.: A platform-independent metamodel for mul-tiagent systems. Autonomous Agents and Multi-Agent Systems 18(2) (4 2009)239–266

25. Workflow Management Coalition: XPDL: XML Process Definition Language26. Caire, G., Gotta, D., Banzi, M.: WADE: A software platform to develop mission

critical applications exploiting agents and workflows. In Berger, M., Burg, B.,

Nishiyama, S., eds.: Proc. of 7th Int. Conf. on Autonomous Agents and Multia-gent Systems (AAMAS 2008) — Industry and Applications Track, InternationalFoundation for Autonomous Agents and Multiagent Systems (www.ifaamas.org)(May 2008) 29–36

27. Bresciani, P., Giorgini, P., Giunchiglia, F., Mylopoulos, J., Perini., A.: TROPOS:An agent-oriented software development methodology. Journal of AutonomousAgents and Multi-Agent Systems 8(3) (May 2004) 203–236

28. Odell, J., Parunak, H., Bauer, B.: Extending uml for agents. In Wagner, G., Les-perance, Y., Yu, E., eds.: Proceedings of the Agent-Oriented Information SystemsWorkshop at the 17th National conference on Artificial Intelligence. (2000) 3–17

29. Morandini, M., Penserini, L., Perini, A.: Towards goal-oriented development of self-adaptive systems. In: SEAMS ’08: Proceedings of the 2008 international workshopon Software engineering for adaptive and self-managing systems, New York, NY,USA, ACM (2008) 9–16

30. Liu, R., Kumar, A.: An analysis and taxonomy of unstructured workflows. Invan der Aalst, W.M.P., Benatallah, B., Casati, F., Curbera, F., eds.: BusinessProcess Management. Volume 3649. (2005) 268–284

Towards Service Matchmaking of Heterogeneous Service

Descriptions1

Analay Baltá, Alberto Fernández

CETINIA, University Rey Juan Carlos, Móstoles, Spain

analay@ia.urjc.es, alberto.fernandez@urjc.es

Abstract. In service oriented architectures (SOA) the process of service

discovery involves the matchmaking between service advertisements and

service requests. Most approaches assume that both service advertisements and

service requests are expressed using the same description language as well as

domain ontologies. However, in large-scale open environments that assumption

does not hold. In this paper we present an abstract architecture that addresses

the semantic mismatches at service description level. In particular, we focus on

the alignment of service description models and service matchmaking on the

unified request and advertisements.

Keywords: service discovery, matchmaking, semantic web services, service

oriented architecture, agreement technologies, semantic alignment.

1 Introduction

In multiagent systems, agents communicate with the aim of achieving their objectives.

An individual agent may require a service to be performed by another entity. There

are several stages since an agent identifies a given need until the service that provides

it is eventually executed. First, the agent identifies some functionality that it is not

able to perform or that might be executed more efficiently by an external entity. Then,

candidate service providers must be located. Once a set of potential providers are

known, the agent must choose one among them. This decision can be made based on

several factors such as quality of service, price, reputation, etc. After the selection is

made the two agents might engage in a negotiation about the conditions under which

the service is going to be performed.

In this paper we concentrate on the phase of provider location. Distributed service

directories and efficient decentralised matching techniques are essential for dynamic

and scalable Web service discovery.

1 Work partially supported by the Spanish Ministry of Science and Innovation through grants

TIN2009-13839-C03-02 and CSD2007-0022 (CONSOLIDER-INGENIO 2010)

The process of discovering and interacting with a Semantic Web Service includes

[1] candidate service discovery (match advertised service descriptions against

specifications from requesters), service engagement, and service enactment.

Several description frameworks to annotate provided services on the one hand and

express service requests on the other have been proposed. They range from logic-

based complex and expressive semantic service descriptions (e.g. OWLS2, WSMO3)

to syntactical ones (WSDL4, keywords, tag clouds), with some approaches in between

(SAWSDL5). In this context, several frameworks to semantically match service

advertisements and requests have been presented in the literature [4, 6, 9, 12].

In such open environments the mechanisms for locating appropriate services have

to struggle with the additional problem of semantic mismatches among the service

description models or languages as well as domain ontologies used to specify the

concepts in the descriptions. Note that most approaches assume the use of the same

language for both service advertisements and requests. Therefore, semantic alignment

mechanisms need to be purposefully integrated into the service discovery mechanism.

In this paper we describe an architecture for service discovery where semantic

alignment mechanisms are integrated into. The rest of the paper is organized as

follows. In the next section we present the architecture. In section 3, we propose a

service description model alignment including an integrated model which contains all

the important characteristics of the existing models. We propose an integrated service

matching framework in section 4. Finally, we review related works in section 5 and

present some conclusions and future work.

2 Service Discovery Architecture

Figure 1 illustrates the proposed architecture that defines the service discovery

functionality. The architecture comprises the building components to match a service

request against a service advertisement. In particular, this proposal pays special

attention to the problem of semantic mismatches between descriptions. Semantic

mismatches are considered at two different levels:

• Service description models. Services (advertisements and requests) might be

described using different languages or models (e.g. OWL-S, WSMO,

SAWSDL, ...).

• Domain ontology concepts. Since semantic service descriptions rely on the

use of domain ontologies, the second type of mismatch is due to the use of

different domain ontologies to specify the concepts used in the descriptions.

Note that both options can be combined. For instance, two services might share the

same service model (e.g. OWL-S) but use different domain ontologies, or they might

use the same domain ontology but different service models.

2 http://www.w3.org/Submission/OWL-S/ 3 http://www.w3.org/Submission/WSMO/ 4 http://www.w3.org/TR/wsdl 5 http://www.w3.org/TR/sawsdl/

Fig. 1 Service Discovery Architecture

In the first step, we describe the mapping from the original models into a general

common model (GCM) for service discovery purposes that integrates the relevant

characteristics of service description languages. Therefore, service model alignment

consists of mapping both descriptions (request and advertisement) into the GCM.

Note that service description approaches not only differ in the language in which they

are written. They are classified at different levels of expressiveness, ranging from

complex, formal, logic-based semantic descriptions to lightweight syntactical ones.

The Service Matching module takes those two descriptions and returns the degree

of match between them. As we will see in section 4, service matchmaking may

include syntactic and semantic matching of description fragments (depending on the

source descriptions). Semantic matchmaking algorithms usually include a semantic

concept matching process to analyze the (similarity) relation between concepts used

in advertisements and requests. As it was pointed out above, those concepts might

belong to different ontologies so a Semantic Concept Alignment is carried out to solve

this problem. In this case, we keep a local knowledge base of alignments and assume

the existence of an external registry of alignments. The local knowledge base acts as a

cache of alignments used in previous matchings. The external alignment registry is

consulted to avoid carrying out a process of ontology matching if there is an

alignment published by third parties.

In the next sections we detail the building blocks of the proposed architecture.

3 Service Description Model Alignment

As commented above, service model alignment consists of defining a common model

for two different ones (the request and the candidate services), and mapping

descriptions expressed in those source models into the common model.

In the next subsection we describe the characteristics of current service description

approaches, so as to propose an integrated model which integrates the different

common models. Afterwards, we present a unified common model for matchmaking.

3.1 Service description approaches

In this section we describe different approaches to service description. We include

semantic models (OWL-S, WSMO), syntactic models (WSDL), hybrid (SAWSDL),

as well as other lighter approaches. For each approach, we concentrate on the

important characteristics from a service matchmaking point of view.

OWL-S. Web Ontology Language for Services (OWL-S) service profile is used to

describe what the service does and it is crucial in the web service discovery process

since it describes the capabilities of web services. We select the profile’s relevant

fields for service matchmaking so as to define a service by S = <I, O, P, E, C, T>,

where I represents a set of inputs (property hasInput), O is a set of outputs (property

hasOutput), P is a set of preconditions (property hasPrecondition), E a set of effects

(property hasResult), C is a set of categories (property hasCategory), and T is plain

text description of the Web service (property textDescription).

WSMO. Web Service Modeling Ontology (WSMO) offers four key components to

model different aspects of Semantic Web Services: ontologies, goals, services, and

mediators. Web Service descriptions are defined into WSMO capability by their

precondition, postcondition, assumption, effect, and their nonFunctionalProperties

(title, subject, description). For our service discovery approach, WSMO and OWL-S

share the same formalization, although these components are obtained in WSMO

from different fields: I (precondition), O (postcondition), P (assumption), E (effect),

C (subject), T (description).

WSDL. Web Service Description Language (WSDL) is an XML-based language

for syntactically describing the service, including the service name, functions, and

input and output parameters of abstract definitions. WSDL descriptions are limited in

their search by their inability to extend beyond the keyword-based matches. We

define a WSDL service S = <I, O, T> where I is a set of inputs (strings extracted

from the wsdl:input element defined in the messages of operations), O is the set of

outputs (wsdl:output) and T is a text (wsdl:documentation).

SAWSDL. Semantic Annotations for WSDL and XML Schema (SAWSDL)

introduces three new attributes: modelReference for specifying associations between

WSDL components and semantic concepts, liftingSchemaMapping and

loweringSchemaMapping for specifying mappings between semantic data and XML.

Some of the elements might not be semantically annotated. For us, SAWSDL service

is described by S = <I, O, T> where I=<Isyn, Isem> is a pair of sets containing the

inputs not semantically annotated (Isyn) and those annotated with concepts from

ontologies (Isem), analogously for O=<Osyn, Osem>, and T is the description.

Keyword-based descriptions. A typical way of describing resources is by annotating

them using keywords (or tags). It can also be applied to Service descriptions. E.g.,

seekda!6 web service search engine includes free text and tag descriptions provided by

service users, as well as WSDL files. We admit two kinds of keyword-based

descriptions (K = <Ksyn, Ksem>): syntactic (free text) and semantic (ontology-based).

6 http://webservices.seekda.com/

Tag Cloud based descriptions. The advantage of using tags in the context of

service discovery is that they supply a user-defined vocabulary based on a consensus

of how the service is perceived or used in the world [3, 14]. A tag-cloud-based service

description is a set of pairs TC = {<t, n>}, where t is a free text tag and n is the

frequency of the tag t in the cloud.

Textual descriptions. Services can be defined by free text human-readable

information. For these kinds of descriptions service discovery is based on information

retrieval techniques (IR).

3.2 Integrated Model for service discovery

From the analysis of the different approaches to service descriptions (section 3.1) we

obtain an integrated general common model (GCM).

For each approach, we present a brief description and a formal specification of the

selected characteristics from a discovery point of view. Semantic service descriptions

include concepts defined in some domain ontologies. In the following, we consider

such domain ontology O = < N, ≺ >, where:

• N represents the set of concept names, and

• ≺ is a partial order representing the subclass of relation between N concepts.

O can be considered as the union of all domain ontologies used by the different

service descriptions. Note that, for service matchmaking purposes, we only require

ontology fragments including the subclass of relation.

Definition 1. Let N be a set of concepts of domain ontologies, a general common

model (GCM) for service discovery is a tuple <IGCM, OGCM, PGCM, EGCM, KGCM, CGCM,

T GCM, TCGCM >, where:

• IGCM = <Isyn, Isem> is the set of syntactic (Isyn∈{a, .., z}*) and semantic (Isem⊆ N)

inputs of the service.

• OGCM = <Osyn, Osem> is the set of syntactic (Osyn⊆{a, ..., z}*) and semantic

(Osem⊆ N) outputs.

• PGCM is the set of preconditions. PGCM ⊆ N

• E GCM is the set of effects. EGCM ⊆ N

• KGCM = <Ksyn, Ksem> is the set of syntactic and semantic keywords, where

Ksyn⊆ {a, …, z}*, Ksem⊆ N.

• CGCM is a set of categories of the service, described semantically (Csem⊆ N)

(e.g. NAICS or UNSPSC).

• TGCM is a textual description of the service.

• TCGCM is a tag cloud. TCGCM = {<t, n>| t ⊆ {a, …, z}*, n ∈ N}.

We opt for using RDF as the representation language for the GCM. RDF is a W3C

recommendation for representing data on the Web. A lot of RDF contents and tools to

process them are available. Although RDF is less expressive than OWL-S, WSMO

and SAWSDL, it is enough for representing the information needed for semantic

service search. Furthermore, the use of RDF will also allow the exploitation of

SPARQL [19] to query service descriptions.

3.3 Mapping service descriptions into the GCM

Table 1 shows how the different elements of the GCM can be obtained from each

source service description model. The first column specifies the element of the GCM,

while each cell contains the value mapped from the model shown in the first row.

There are many straightforward mappings that consist of simple associations

between parameters in both models. For instance, in OWLS/WSMO IGCM=<φ, pt(I)>

because they only provide semantically described inputs I (Isem), where pt(I)={ t |

t=parameterType(i) ∀i∈I}. The contrary applies to WSDL, where only the syntactic

values are filled (IGCM=<I, φ>). However, SAWSDL may contain both syntactic and

semantic descriptions, thus IGCM=I since I = <Isyn, Isem>. The same is applied to the

outputs. Trivial mappings apply to preconditions (PGCM), effects (EGCM), categories

(CGCM) and textual descriptions (TGCM).

However, some fields (tag-clouds, keywords) may not be explicitly described by a

given model but they can be obtained from the rest of the description. Tag-clouds can

be calculated from textual descriptions by means of a function ∆(T ), which returns

the k most relevant words from the text T as well as their frequency. We adopt

information retrieval (IR) techniques to obtain that information through a process of

(i) word extraction, (ii) stemming, and (iii) filtering out non relevant terms (chosen

heuristically). The case of keyword-based service descriptions (where no text is

included), a plain cloud is created with frequency 1 for every keyword in the

description.

Syntactic keywords can be easily obtained from tag clouds (either original or

calculated with ∆), by simply adopting the k most relevant words (function τ(TC),

being TC a tag-cloud). The input concept name N(I) and output concept name N(O)

in semantic descriptions (OWL-S, WSMO, SAWSDL) are adopted as semantic

keywords.

Table 1. Service(S)-to-GCM mapping

GCM OWL-S /

WSMO SAWSDL WSDL

Keyword

(tag)

Tag

Cloud Text

IGCM <φ,pt(I)> <Isyn,Isem > <I, φ> <φ, φ> <φ, φ> <φ, φ>

OGCM <φ pt(O)> <Osyn,Osem> <O, φ> <φ, φ> <φ, φ> <φ, φ>

PGCM P φ φ φ φ φ

EGCM E φ φ φ φ φ

KGCM

<τ(∆(T))∪

N(I)∪N(O),

pt(I)∪ pt(O)>

<τ(∆(T)) ∪ Isyn

∪ Osyn,

N(Isem)∪N(Osem) >

<τ(∆(T)

∪ Isyn∪

Osyn, φ>

K <τ(S),φ> <τ(∆(S),φ>

CGCM C φ φ φ φ φ

TGCM T T T φ φ S

TCGCM ∆(T ) ∆(T) ∆(T) {<t, 1>| t∈

Ksyn∪Ksem} S ∆(S)

3.4 Examples

In this section we show our proposal with an example of an airline service (the Bravo

Air example7), a fictitious service that provides flight reservations based on the

specification on a flight request. We present an OWL-S and a SAWSDL

representation of that service, as well as their mapping to the GCM.

3.4.1 OWL-S

We define the OWL-S BravoAir example service S =<I, O, P, E, C, T> as follows:

I = {ba8:DepartureAirport, ba:ArrivalAirport, ba:OutboundDate,

ba:InboundDate,ba:RoundTrip,ba:AcctName,ba:Password,ba:Confirm}

O = {ba:FlightsFound, ba:PreferredFlightItinerary, ba:ReservationID}

P = φ

E = {ba:HaveSeatResult}

C = {unspsc9:Travel_agents}

T = “This service provides flight reservations based on the

specification on a flight request. This typically involves a departure

airport, an arrival airport, a departure date, and if a return trip is

required, a return date. If the desired flight is available, an

itinerary and reservation number will be returned.”

Figure 2 shows a partial view of the OWL-S profile for that service. In particular, it

shows the definition of the input DepartureAirport. There, we can see that the

semantic input concepts are obtained from the value of the parameterType property

(in this case concepts:Airport) of OWL-S input DepartureAirport in the BravoAir

service. The same applies for other inputs, outputs, preconditions and effects.

Fig. 2 OWL-S mapping

From the OWL-S service description we can obtain the service mapping described

in the GCM according to Table 1. There are no syntactic inputs, and the semantic

inputs would be the semantic concepts (parameter types) of inputs I. The same

applies to the outputs, preconditions and effects. The tag cloud includes the most

relevant words of the text T as well as their frequency. The syntactic keywords are

obtained using tag clouds with frequency 1 as well as the inputs and outputs concept

7 http://www.ai.sri.com/daml/services/owl-s/1.0/examples.html 8 ba = “http://www.daml.org/services/owl-s/1.1/BravoAirProcess.owl#” 9 unspsc = “http://www.cs.vu.nl/~mcaklein/unspsc/unspsc84-title.rdfs#”

names. As for the semantic keywords the semantic concepts of inputs and outputs

(parameter types of inputs I and outputs O) are taken. Therefore:

SGCM = <IGCM, OGCM, PGCM, EGCM, KGCM, CGCM, T GCM, TCGCM > where:

IGCM = <φ,{con10:Airport, con:Airport, con:FlightDate, con:FlightDate,

con:RoundTrip, con:AcctName, con:Password, con:Confirmation}>

OGCM = <φ,{con:FlightList,con:FlightItinerary, con:ReservationNumber}>

PGCM = φ

EGCM = ba:HaveSeatResult

KGCM = <{flight, airport, reservation, departure, DepartureAirport, ArrivalAirport,OutboundDate,InboundDate,RoundTrip,AcctName,

Password, Confirm, FlightsFound, PreferredFlightItinerary,

ReservationID},

{con:Airport, con:Airport, con:FlightDate, con:FlightDate,

con:RoundTrip, con:AcctName, con:Password, con:Confirmation,

con:FlightList, con:FlightItinerary, con:ReservationNumber}>

CGCM = {unspsc:Travel_agents}

T GCM = “This service provides flight …”

TCGCM = {<flight,3>, <airport,2>, <reservation,2>, <departure,2>}.

3.4.2 SAWSDL

We define the Bravo Air service in SAWSDL as S=<I,O,T>, where:

I = <{DepartureAirport, ArrivalAirport, OutboundDate, InboundDate, RoundTrip, AcctName, Password, Confirm},

{ai11:AirportCodes, ai:AirportCodes, date12:Date, date:Date,

con:RoundTrip, con:AcctName, con:Password, con:Confirmation}>

O = <{FlightsFound, PreferredFlightItinerary, ReservationID}, {con:FlightList, con:FlightItinerary, con:ReservationNumber}>

T = This service provides flight …”

Note that we consider semantic annotation for every input and output. In this case,

we use ai:AirportCodes and ai:Date to annotate inputs and outputs related to airports

and dates, respectively.

From the SAWSDL service description we obtain the following service mapping

described in the GCM.

SGCM = <IGCM, OGCM, PGCM, EGCM, KGCM, CGCM, T GCM, TCGCM > where:

I = <{DepartureAirport, ArrivalAirport, OutboundDate, InboundDate, RoundTrip, AcctName, Password, Confirm},

{ai:AirportCodes, ai:AirportCodes, date:Date, date:Date,

con:RoundTrip, con:AcctName, con:Password, con:Confirmation}>

O = <{FlightsFound, PreferredFlightItinerary, ReservationID}, {con:FlightList, con:FlightItinerary, con:ReservationNumber}>

PGCM = φ

EGCM = φ

10 con = http://www.daml.org/services/owl-s/1.0/Concepts.owl 11 ai = http://www.daml.ri.cmu.edu/ont/AirportCodes.daml 12 date = http://www.ai.sri.com/daml/ontologies/sri-basic/1-0/Date.daml

KGCM = <{flight, airport, reservation, departure, DepartureAirport, ArrivalAirport, OutboundDate, InboundDate, RoundTrip,

AcctName, Password, Confirm, FlightsFound,

PreferredFlightItinerary, ReservationID},

{ai:AirportCodes, ai:AirportCodes, date:Date, date:Date,

con:RoundTrip, con:AcctName, con:Password, con:Confirmation,

con:FlightList, con:FlightItinerary, con:ReservationNumber}>

CGCM = φ

T GCM = “This service provides flight …”

TCGCM = {<flight,3>, <airport,2>, <reservation,2>, <departure,2>}.

4 Service Matchmaking

4.1 Semantic Concept Matching

Since service descriptions are composed by several elements or fields, each of them

defined by concept descriptions, the process of semantic matchmaking includes a

concept matching task. This function takes two concepts, CA (advertisement) and CR

(request), and returns the degree of match between them.

Many of the current proposals for defining the degree of match between service

advertisements and requests are based on subsumption checking of concepts present

in inputs and outputs of service descriptions. We adopt the four degrees of match

proposed by Paolucci et al. [12]: exact (CA = CR), plug-in (CR subsumes CA),

subsumes (CA subsumes CR) and fail (otherwise).

Several similarity (or distance) measures for concept matching have been proposed

in the literature, although their application to the concrete domain of service matching

is very limited. One of the most well known distance measures between concepts is

the length of the shortest path between them in the taxonomy, proposed by Rada et al

[16]. Other proposals further refine that approach ([8, 10, 20]).

We propose a combination of service matching and concept similarity. In [4] we

describe how both approaches can be combined into a unified service selection

framework which returns a numeric value that can be used for ranking services. The

ranking function compares the level of match first (exact, plugin, subsumes, fail), and

then the level is refined with the (numerical) similarity value. The degree of match

between two concepts is defined as follows.

Definition 2. The degree of match between two concepts CA (advertisement) and

CR (request) is given by:

+

=

=

otherwise

CsubsumesCifCCsim

CsubsumesCifCCsim

CCif

CCchconceptMat

RARA

ARRA

RA

AR

0

),(2

1

),(2

1

2

1

1

),(

Where concept similarity (sim) is calculated as [10]:

≠

+

−= −

−−

otherwise

CCifee

eee

hh

hhl

1

.)C ,sim(C 21

21ββ

ββα

where α ≥ 0 and β ≥ 0 are parameters scaling the contribution of the shortest path

length (l) between the two concepts and the depth (h) of the least common subsumer

in the concept hierarchy, respectively.

4.2 Service Matching

Since service descriptions consist of several components (inputs, outputs, ...), the

similarity between services must be defined based on its individual elements (e.g.

each of its inputs) and aggregation operators.

For service matching, given the GCM representation of the service advertisement

(GCMA) and the service request (GCMR), we analyze the common elements defined in

them. Only those non-empty fields belonging to the intersection of both (GCMA ∩

GCMR) are considered here, as they define the common model to A and R (CMAR).

For each pair of the common elements we propose a matching algorithm taking

into account the semantic concept matching, being boolean (0, 1) in the case of

syntactic values. Finally an aggregation function is applied to combine the results.

Definition 3. Given a service request GCMR and a service advertisement GCMA

where, according to Definition 1, GCMR= <IR, OR, PR, ER, KR, CR, TR, TCR > and

GCMA= <IA, OA, PA, EA, KA, CA, TA, TCA >. Then, the degree of match between GCMR

and GCMA is calculated as:

dom(GCMR, GCMA) = f(IM(IR, IA), OM(OR, OA), PM(PR, PA), EM(ER, EA),

KM(KR, KA), CM(CR, CA), TM(TR, TA), TCM(TCR, TCA))

IM, OM, PM, EM, KM, CM, TM and TCM are defined below.

As a service matching example, we will use the services described in sections 1.1.1

and 3.4.2 (S1GCM and S

2GCM), acting the OWL-S example as the service advertisement

(GCMA = S1GCM) and the SAWSDL as the service request (GCMR = S

2GCM).

Output matching (OM).

In line with Paolucci’s proposal [12], an output matches if and only if for each

output of the request there is a matching output in the service description, i.e. the

service provides all the outputs required.

Given OR = <ORsyn, O

Rsem> and OA = <O

Asyn, O

Asem>, OM(OR, OA) is calculated as a

combination of the semantic match (OSemM) and the syntactic output match

(OSynM). If both services include semantic and syntactic outputs, then a linear

combination of those matches is calculated. However, it may occur that some of the

sets are empty. In that case, we apply only the semantic match if both semantic

descriptions (ORsem and O

Asem) are available. Otherwise, only the syntactic match is

calculated, completing each set of syntactic outputs with the names of the semantic

concepts (N(ORsem) or N(O

Asem)) if any of them is specified. The next equation gives

the details.

≠∧≠∧≠∧≠=++

≠∧≠∧≠∧=∪

≠∧≠∧=∧≠∪

=∧≠∧≠∧=

≠∧=∧=∧≠

≠∧≠∧=∧=

∨=∧≠∧≠

=

otherwise0

O O O O if1| OSynM* OSemM*

O O O O if))N(OO ,OSynM(O

O O O O if)O ),N(OOSynM(O

O O O O if))N(O ,OSynM(O

O O O O if)O ),OSynM(N(O

O O O O if)O ,OSynM(O

) =O (O O O if)O ,OSemM(O

)O ,OM(O

synA

synR

semA

semR

synA

synR

semA

semR

semA

synA

synR

synA

synR

semA

semR

synA

semR

synR

synA

synR

semA

semR

semA

synR

synA

synR

semA

semR

synA

semR

synA

synR

semA

semR

synA

synR

synA

synR

semA

semR

semA

semR

AR

φφφφβαβα

φφφφ

φφφφ

φφφφ

φφφφ

φφφφ

φφφφ

The semantic match is obtained by taking, for each output in the request, the best

match (section 4.1) against the ones in the advertisement. The worst case (minimum

value) is then chosen to combine the best matches, i.e.:

{ })o,ch(oconceptMat Max Min )O ,OSemM(OAR

OoOosem

Asem

R

semAA

semRR ∈∈

=

At the syntactic level, we check whether all the required outputs are provided by

the service:

⊆

=otherwise

sym

0

OO if1 )O ,OSynM(O

synAR

synA

synR

In our example, OM(OR,OA) = OSemM(OR

sem, OA

sem) because only the service

request includes syntactic outputs. Note that exactly the same semantic concepts are

used in the output annotations in both services. Thus: OM(O2

GCM,O1GCM) = OSemM(O2

GCM, O1GCM) = Min Max {conceptMatch(O1

GCM, O2GCM)}

= Min(Max(1,0,0), Max(0,1,0), Max(0,0,1)) = 1

Input matching (IM).

For input matching (IM), an analogous approach is followed, but with the order of

request and advertisement reversed.

In this case, there are exact matches for all the inputs except for the concepts

ai:AirportCodes and ai:Date (request) vs con:Airport and con:FlightDate

(advertisement). Analyzing the ontologies in which those concepts are specified, we

can see that con:Airport is a subclass of ai:AirportCode and con:FlightDate is a

subclass of Date.

In both cases, the ConceptMatch is 0.73, (taking α, β = 0.5, l= 1, h= 1).

As occurred with the output matching, only the semantic match is calculated: IM(I2

GCM,I1GCM) = ISemM(I2

GCM, I1GCM) = Min Max {conceptMatch(I1

GCM, I2GCM)} =

Min(Max(0.73, 073, 0, 0, 0, 0, 0, 0), Max(0, 0, 0.73, 0.73, 0, 0, 0, 0), Max(0, 0, 0, 0,

1, 0, 0, 0) , Max(0, 0, 0, 0, 0, 1, 0, 0), Max(0, 0, 0, 0, 0, 0, 1, 0) , Max(0, 0, 0, 0, 0, 0,

0, 1)) = 0.73

Precondition/Effect matching (PM/EM).

Since preconditions and effects can usually not be expressed in a taxonomy or

ontological hierarchy, rather more complex formalisms (e.g. SWRL rules) are

proposed to describe these. We are not aware of service matching approaches which

practically exploit precondition/effect matching at the moment. It seems to be not

entirely clear, how precondition/effect matching can be done in open service

environments, which might also be a reason why they have not been considered e.g.

in SAWSDL. For these reason we consider preconditions and effects specified by

concept definitions, and keep them as they were specified in the original model.

This way, it is up to the matching process to deal with those descriptions. For the

moment we take a simple approach (concept matching), although it is a matter of

future research how to improve that aspect.

{ })p,ch(pconceptMat Max Min )P ,PM(PAR

PpPpAR

AA

RR ∈∈

=

{ })e,ch(econceptMat Max Min )E ,EM(EAR

EeEeAR

AA

RR ∈∈

=

Keyword matching (KM)

Given KR = <KRsyn, K

Rsem> and A = KA = <K

Asyn, K

Asem>, keyword matching is

based on the syntactic and semantic keywords:

)K,KKSynMatch( * )K,KKSemMatch( * )K,(K KM synA

synR

semA

semR

AR βα += ,

with α, β = 1.

For syntactic keywords the degree of match is determined by the ratio of

coincident keywords of the candidate service (A) and the service requested (R).

RA

RA

∪

∩= A) R,KSynMatch( .

For semantic concept keyword, we adopt Ehrig [2] measure to compare sets of

concepts:

∑

∑

∑

∑

∈

∈

∈

∈ ⋅=

Aa

Aa

Rr

Rr

a

a

r

r A) R,KSemMatch(

with )...),(),,(),...,,(),,(( 2121 arsimarsimrrsimrrsimr = , a analogously.

Tag-cloud matching (TCM)

In the context of service matching, tag-clouds have a natural correspondence to the

typical vector space model used in standard information retrieval. Using the vector-

space model, each tag-cloud is represented as a vector in term space and each term in

the vector is weighted according to the standard tf-idf weighting scheme [17]. In the

vector-space model, similarity is calculated using the cosine measure. To prevent

large clouds having undue influence during similarity matching, each vector is

normalized so that it is of unit length on the hypersphere.

Text matching (TM)

In the case of text element, it also has syntactic information (or other syntactic

element) so we apply IR techniques to determine its matching degree.

Category matching (CM)

For the category field, which may be described by a concept from an ontology, a

0/1 value or the result of the semantic concept similarity function is taken,

respectively.

We require that for each category in the request R at least there is one matching

category in A. Therefore, similar to output matching:

CM(CR, CA) = )}c,ch(cconceptMat{MaxMin AR

CCc AA

RR ∈∈ c

Finally, service matching must combine the similarity value for each of these

fields, Definition 3 (dom(GCMR, GCMA)). Different options can be considered for f

(f(IM(IR,Ia), OM(OR,OA), PM(PR,PA), EM(ER,EA), KM(KR,KA), CM(CR,CA),

TM(TR,TA), TCM(TCR,TCA)) ). If we consider those fields as a conjunctive set (i.e. all

are expected to be matched) then a triangular norm (e.g. the minimum) can be used.

However, for the moment, a more general approach is taken: a weighted sum of

each similarity, where the weighting parameters are equally distributed (i.e. the

mean).

4.3 Concept Alignment

In the previous section we saw that current service matchmaking algorithms are based

on checking the relations between the concepts that appear in the different fields of

semantic service descriptions. If the concepts being compared are defined in different

ontologies then semantic alignments must be considered instead of obtaining a fail

match.

An alignment (or mapping) between two ontologies O and O’ can be described as a

quadruple [11]: <e, e’, n, R>

where:

- e and e’ are the entities between which a relation is asserted by the mapping

(e.g., formulas, terms, classes, individuals)

- n is a degree of trust (confidence) in that mapping

- R is the relation associated to a mapping, where R identifies the relation

holding between e and e’.

In this work we are not concerned about ontology matching techniques, but on the

use of alignments. Thus, we are interested in representing and querying mappings

between ontologies. We propose using RDF as the language for expressing

alignments, so that they can be published on the web and queried using SPARQL. In

particular, we use the format of the Ontology Alignment Evaluation Initiative13.

5 Related Work

Some (not many) other efforts have been made trying to align or compare different

service description approaches. We set out from existing conceptual comparisons

between OWL-S and WSMO [15], OWL-S, SAWSDL and WSDL [7, 13] to obtain a

general model description of services that facilitates their discovery.

Giantsiou et al. [5] propose a service meta-model in which found services are

transformed and represented in RDF. Their meta-model and discovery approach is

influenced by light weight approaches (SAREST [18] and SAWSDL). Differently, we

focus on both lightweight and semantic techniques, allowing other description

models.

Most of the current approaches to Semantic Web Services matching, particularly

those based on OWL-S, are based on subsumption reasoning on concepts included in

the descriptions (e.g. [9, 12]). Klusch et. al [6] present a hybrid matchmaker that

complements logic based reasoning with approximate matching techniques from

Information Retrieval. In this sense we also propose a hybrid approach, which

combines subsumption checking, concepts similarity and information retrieval.

However, we focus on several different service description models and consider the

alignment of domain concepts.

6 Conclusion

In this paper we have dealt with the problem of service discovery in open systems.

We proposed an architecture that has semantic alignment as a first citizen component.

In particular, we discussed in detail the alignment of service description models, and

the transformation of them into an RDF common model. We also proposed the

combination of service matching and concept similarity into an integrated service

matching framework.

Domain ontologies can be specified using different languages. We address that

aspect at the semantic concept matching implementation level, where we consider (for

the moment) ontologies written in RDF, OWL and WSML. At the service model

mapping level we only need to copy the concept without any reasoning with the

ontology.

The implementation and evaluation of the proposed framework is part of our

ongoing work. We plan to adapt, transform and extend existing test collection (e.g.

the OWL-S TC, SAWSDL TC)14 as a starting benchmark for our experiments.

13 http://oaei.ontologymatching.org/ 14 http://www.semwebcentral.org/projects/owls-tc/ or /sawsdl-tc/

7 References

1. Burstein, M., Bussler, C., Zaremba, M., Finin, T., Huhns, M. N., Paolucci, M., Sheth, A.

P., and Williams, S. A Semantic Web Services Architecture. IEEE Internet Computing 9,

5, 72-81. 2005.

2. Ehrig M. Ontology Alignment: Bridging the Semantic Gap. Springer. 2007.

3. Fernandez, A. et al. Closing the service discovery gap by collaborative tagging and

clustering techniques. In 2nd International Joint Workshop on Service Matchmaking and

Resource Retrieval in the Semantic Web (SMR2), pages 115–128, Karlsruhe, 10/2008.

4. Fernandez, A., Polleres, A., and Ossowski, S. Towards Fine-grained Service Matchmaking

by Using Concept Similarity, ISWC-2007 Workshop on Service Matchmaking and

Resource Retrieval in the Semantic Web (SMR2). 2007

5. Giantsiou, L., Loutas, N., Peristeras, V. and Tarabanis, K. Semantic Service Search

Engine (S3E): An Approach for Finding Services on the Web. In LNCS, Volume

5736/2009, pages 316-325. Springer, 2009.

6. Klusch, M., Fries, B., and Sycara, K. Automated semantic web service discovery with

owls-mx. AAMAS ’06: Proceedings of the fifth international joint conference on

Autonomous agents and multiagent systems, pages 915–922, NY, 2006. ACM Press.

7. Kourtesis, D., Paraskakis, I. Combining SAWSDL, OWL-DL and UDDI for Semantically

Enhanced Web Service Discovery. Springer Berlin / Heidelberg. Pages 614-628. 2008.

8. Leacock, C. and Chodorow, M. Combining local context andWord- Net similarity for

word sense identification. In Christiane Fellbaum, editor, WordNet: An Electronic Lexical

Database, pages 265–283. MIT Press, 1998.

9. Li, L and Horrocks, I. A software framework for matchmaking based on semantic web

technology. Int. J. of Electronic Commerce, 8(4):39–60, 2004.

10. Li, Y., Bandar, Z. and McLean, D. An approach for measuring semantic similarity

between words using multiple information sources. IEEE Trans. Knowl. Data Eng.,

15(4):871–882, 2003.

11. Paolo Bouquet, Jérôme Euzenat, Enrico Franconi, Luciano Serafini, Giorgos Stamou, and

Sergio Tessaris. Specification of a common framework for characterizing alignment.

Deliverable D2.2.1, Knowledge web NoE, 2004.

12. Paolucci, M., Kawamura, T., Payne, T., and Sycara, K. Semantic Matching of Web

Service Capabilities. In ISWC, pages 333–347. Springer Verlag, 2002.

13. Paolucci, M., Wagner M., Martin M. Grounding OWL-S in SAWSDL. Springer Berlin /

Heidelberg. Pages 416-421. 2007.

14. Papathanasiou, M., Loutas, N., Peristeras, V., Tarampanis, K. Combining Service Models,

Semantic and Web 2.0 Technologies to Create a Rich Citizen Experience. M.D. Lytras et

al. (Eds.): WSKS 2009, LNAI 5736, pp. 296–305, 2009

15. Polleres, A., Lara, R. A Conceptual Comparison between WSMO and OWL-S, WSMO

Working Group working draft, 2005. http://www.wsmo.org/2004/d4/d4.1/v0.1/.

16. Rada, R., Mili, H., Bicknell, E., and Blettner, M. Development and application of a metric

on semantic nets. IEEE Transactions on Systems, Man and Cybernetics, 17–30, 1989.

17. Salton, G. 1989. Automatic Text Processing: The Transformation, Analysis, and Retrieval

of Information by Computer. Addison-Wesley.

18. Sheth, A., Gomadam, K., Lathem, J.: SA-REST: Semantically Interoperable and Easier-to-

Use Services and Mashups. IEEE Internet Computing 11(6), 91–94 (2007).

19. W3C World Wide Web Consortium. SPARQL Query Language for RDF. W3C

Recommendation 15 January 2008. http://www.w3.org/TR/rdf-sparql-query/.

20. Wu, Z. and Palmer, M. Verbs semantics and lexical selection. In Proceedings of the 32nd

annual meeting on Association for Computational Linguistics, pages 133–138,

Morristown, NJ, USA, 1994. Association for Computational Linguistics.

A Framework to Manage Contractual Relationships in

Customer Life Cycle Management Systems

Christian Guttmann1, Kumari Wickramasinghe1, Michael Georgeff1, Ian Thomas1,

and Heinz Schmidt3

1 Faculty of Medicine, Nursing and Health Sciences

Monash University, Melbourne, Australia

{christian.guttmann|kumari.wickramasinghe|michael.georgeff|ian.thomas}@med.monash.edu.au

2 School of Computer Science and Information Technology

RMIT University, Australia

hws@rmit.edu.au

Abstract. The management of a customer life cycle aims to maintain and ad-

vance contractual relationships between customers and service providers. Many

models of customer care management specify processes and goals under the sim-

plifying assumption that critical conditions in the environment are completely

known and do not change. However, in real world applications, many conditions

can not be fully specified at design time because of the incomplete and uncertain

information about the environment and the behaviour of customers and providers.

With such customer care models, a life cycle is managed poorly and the customer

possibly lost. Research on belief-driven processing of goals suggests that this

incompleteness and uncertainty arises from “changes and deficits in an agent’s

mental attitudes” of customers and service providers. Following this research,

our interest is in understanding the effect of these changes and deficits on the

management of contractual relationship. To keep contractual management on-

track, this paper offers an initial adherence and variation component that monitors

agent’s mental attitudes, recognises mental changes and deficits, and if required,

intervenes to move an agent’s behaviour back on-track to perform the specified

processes and goals. We empirically investigate the influence of forgetful ser-

vice providers during contractual formation by means of a simulation-based ex-

periment. A finding is that adherence support enables contract parties to form a

contract quickly, particularly when the parties are grossly forgetful but react to

interventions well.

1 Introduction

The management of a customer life cycle aims to maintain and advance contractual

relationships between customers and service providers. In Customer Life Cycle Man-

agement (CLCM), a customer moves through several stages until he/she eventually be-

comes loyal, without losing them on the way to abandonment, attrition, churn, and

migration [1]. In industry, a customer is often characterised by properties related to

his/her lifetime value. Cutler and Sterne [1] provide a comprehensive explanation of

basic measures of a customer’s lifetime value expressed in terms of loyalty and propen-

sity. According to [1], the customer moves through five stages:

– Reach. How well you gain the attention of a potential customer (e.g., through tai-

lored advertising).

– Acquisition. How well you bring a potential customer into your sphere of influence

or how well you succeeded in reaching the customer (i.e., clicking on a web site or

signing up for a news letter).

– Conversion. If and how a customer performs specific activities and how to turn

her/him into a registered or paying customer (e.g., downloading documents from a

web page).

– Retention. How well you keep a customer (i.e., monitoring the customer, offer

adequate products and encourage repeat purchases).

– Loyalty. How to turn the customer into an advocate for the company (i.e., promot-

ing the company and its services and products).

During all of these five stages of CLCM, it is critical to monitor a customer’s be-

haviour, recognise key events (or the absence of key events) that could reduce a lifetime

value, and intervene adequately to prevent the reduction of a customer lifetime value.

Monitoring, recognition and intervention of all contract parties (i.e., customers and part-

nering service providers) are particularly critical when new contractual relationships are

formed, and when existing relationships are renewed and modified.

Consider the following example of managing contractual relationships of a cus-

tomer with a telecommunication company. Billy has a contract with TELCOX, his In-

ternet provider. The contract has expired and Billy believes to have found a cheaper

offer by a competitor, and he considers to change to the competitor. What Billy does

not know is that TELCOX could offer a bundle of his Internet service with his mo-

bile phone service. This bundling makes his overall expenses cheaper than changing

providers, and cheaper than continuing his existing contract with TELXOC. Regret-

tably, TELCOX’s basic CLCM system does not recognise Bill’s intention to change

providers until it is too late: as a customer, Billy is lost. An advanced CLCM system

monitors Billy’s behaviour and recognises his intention to change and his ignorance

regarding the bundling option (we refer to this ignorance as a belief deficit). The infor-

mation obtained from this recognition is then used to intervene in Billy’s life cycle as a

customer: Billy is informed about the possibility to bundle services, and as a result he

chooses to stay with TELCOX. This monitoring-recognition-intervention cycle enables

TELCOX to keep Billy as a customer and also move him towards becoming a more

loyal one [1].

Developing an advanced CLCM architecture comes with great challenges. If we in-

tervene, but recognise Billy’s mental state incorrectly (i.e., we falsely assume that Billy

is ignorant about the bundling option, but he actually knows about it), he might be an-

noyed about the intervention which reduces his life time value and he may be lost as a

customer even when applying an intervention. In this case, it might be worth expending

more resources on the recognition of Billy’s mental state (e.g., additional phone calls

and emails). This additional expenditure may assist in building a more accurate model

of Billy’s mental attitudes, and thus enabling the application of better interventions.

Also, even if we have recognised Billy’s mental state correctly, the intervention must

be sufficiently strong and targeted. If, after informing him about the bundling possibil-

ity, Billy still intends to change his provider, TELCOX can strengthen its intervention

by additionally offering him a 10% discount on his mobile phone and Internet bills. A

more targetted intervention takes into account that Billy’s wife moves overseas, and the

intervention may then include an offer to significantly reduce the costs of long distance

calls. Simply informing a customer may not be an adequate intervention all the time,

sometimes we need to consider stronger and more targeted interventions. The applica-

tion of an intervention needs to be carefully assessed as more effective interventions are

also more expensive.

This example demonstrates the challenges that an advanced CLCM system needs to

address, and shows the complexity of an effective monitoring-recognition-intervention

cycle in managing contractual relationships during a customer life cycle. The issues

discussed in this paper are as follows.

– Monitoring: when and how to monitor the behaviour of a customer to check if

processes are on-track according to their design specifications (i.e., if the customer

is moving towards becoming loyal)

– Recognition: when and how to recognise key events (or absence of key events) to

decide on applying interventions.

– Intervention: when and how to intervene to move processes back on-track.

– Monitoring-Recognition-Intervention Cost: how much effort to expend for the

achievement of any of the above outcomes.

To our knowledge, no existing research has addressed all these issues completely

and comprehensively [2–9]. Our research aim is to develop an advanced CLCM sys-

tem, and this paper shows first steps towards reaching this aim. To this end, we use

and extend the well established BDI theory [10, 11]. BDI enables a representation of

a cognitive agent that reasons with constructs such as beliefs, intentions, desires and

plans. We follow Bratman’s, Rao and Georgeff’s and Castelfranchi’s research on belief

dynamics [10–12] to address the issue of mental changes and deficits. This paper makes

the following contributions.

– Offers a first and initial contract management architecture with adherence and

variation support to cope with changes and deficits in mental attitudes of agents.

– Extends the BDI formalism to address mental changes and deficits following

research on belief-driven goal processing [10–12].

– Demonstrates and evaluates this framework using as example domain the distri-

bution of services to health care providers of chronic diseased patients.

This paper is organised as follows. Section 2 discusses the background of this re-

search and also related research. Section 3 offers a formal representation of our adher-

ence and variation support approach. Section 4 investigates a first initial evaluation of

this approach using as example chronic health care management. Section 5 summarises

the contributions of this research.

2 Background and Related Research

This section introduces the overall project under which we investigate contract manage-

ment, and research related to this work.

2.1 Intelligent Collaborative Care Management (ICCM)

As part of a larger project, which we refer to as the Intelligent Collaborative Care

Management (ICCM) project [13, 14], we built a computational framework to study

the management of contractual relationships. ICCM investigates Customer Life Cy-

cle Management (CLCM) settings with a particular focus on unreliable and non-

conformant agents. The ICCM systems includes three stages.

Composition Contractual

Commitment

Service

Delivery

Contractual Task-Level

Specification

Environment

Coordination -Level

Specification

Implementation

Level

Service Delivery

Task-Level Specification

Task Level

Specification

Coordination

Specification

Fig. 1. ICCM architecture: Basic Model of Customer Care

1. Composition: develops a care plan by composing services that are intended to re-

alise the customer’s and service provider’s objectives;2. Contractual commitment: manages contractual relationships between the service

providers and the customer;3. Service delivery: manages the execution of the contractual obligations by the ser-

vice providers and the customer.

As shown in Figure 1, the three stages are implemented using two specification lay-

ers: a coordination-level and task-level layer. These specifications define the properties

of a CLCM domain. The domain information shared among all the three stages are de-

fined in the coordination-level specification and the domain information associated to

each stage is defined in the corresponding task-level specifications. Using such a frame-

work, ICCM investigates the management of contractual relationships and delivery of

services at run time.

In a tightly coupled world (deterministic, well understood and with few control

paths), it is possible to specify all business processes and the flow of control and data

among the processes. However, the specification of an exact flow at design time is

challenged in dynamic environments where customer objectives and business processes

change dynamically and where different business units interact to realise customer and

provider objectives (Figure 2). A possible solution to this challenge is to extend the clas-

sical service-oriented architecture notion to “loosely coupled” services from a service

layer to a business layer [15].

2.2 Related Research

The management of contracts is an essential element in several customer life cycle man-

agement systems [3, 4, 6]. Jennings et al. [3] use an agent-framework called ADEPT.

ADEPT is one of the first agent-based systems that investigates an industrially deployed

customer life cycle system. Trastour et al. [6] study the early pre-contractual phases of

a customer’s life cycle management, but with no consideration on adherence and vari-

ation support. Another approach [4] investigates requirements engineering processes

that employ continuous management using state-oriented life cycle models. However,

all these frameworks consider no regulation (i.e., they assume a free market), and none

of them use adherence support for the management of contracts or variation support for

the renewal and modification of contracts.

Composition Contractual

Commitment

Service

Delivery

Environment

Incomplete,

Uncertain and

Bounded

Resources

Implementation

Level

Adherence Support

+

Contractual Variation

Support

Adherence Support

+

Contractual Variation

Recognition

Contract Commitment

support specification

Service Delivery

support specification

Adherence &

Contractual Variation

Specification

Fig. 2. ICCM architecture: adherence and variation support to cope with uncertainty, incomplete-

ness and bounded resources

In the above CLCM frameworks, agents are often assumed to behave “as they are

supposed to behave”, i.e., according to the design intentions of a system [16, 17]. If

a planned execution is off-track, related research suggests to repair or replan proce-

dures [8] or to enforce norms by detecting critical states and then punishing the viola-

tors [9]. Our interest is not in punishing individuals, nor in replanning or repairing plans

– all research areas in their own right [8, 9]. We aim to prevent the failure of customer

management processes and losing a customer by detecting critical precursor events and

applying adequate intervention.

3 Problem Description and Research Objective

The management of contractual relationships is required at all stages of Customer Life

Cycle Management (CLCM). This paper focuses on a critical issue of contract man-

agement: the initial formation of contractual relationships. The formation of a con-

tract is the process of achieving a legally binding agreement between two or several

parties at the beginning of a life cycle between customers and providers. A contract

is then the basis for renewals and variations to advance existing relationships. In the

context of CLCM, a contract defines the terms and conditions of service delivery of

service providers and customers. During contract formation, service providers and cus-

tomers enter into negotiation to achieve mutually acceptable terms of business. This is

done through an exchange of requests and proposals describing aspects of an accept-

able agreement. The outcome of this negotiation is a contract, specifying the terms that

all contract parties consider acceptable. These terms can include delivery dates or the

content of the service being delivered.

We aim to develop a framework for contractual formation and management under

the following two domain properties (also depicted in Figure 3).

– Specification of contract management processes under partial regulation. Con-

tract management has been studied widely [2, 5, 3, 4, 6, 7], but often under a simpli-

fying assumption made for a free market framework with no (or limited) regulation,

where transactions are driven by supply and demand, and terms and conditions of

contracts are defined only by the contract parties. In reality, many markets operate

Adherence and Variation Specification

Task-Level Specification

Contract Formation Contract Management (including variation and renewal)

How to prevent failure

How to react if fails

How to prevent failure

How to react if fails

Process directed

(based on

governance policy)

Process directed

(based on

partnership agreements)

(mental

attitudes)

Physical

World Provider and

Consumer

Service

Delivery

Services

Contract

Management

Services

Input

Input

Fig. 3. Overview of Contractual Commitment: Formation and Management.

under partial regulation, e.g., where governments enforce guidelines or where part-

ners agree on regulated interactions. One reason to assign tasks under partial reg-

ulation and not in a free market is to reduce transaction cost that are incurred due

to opportunism and bounded rationality [18, 19]. Our framework discusses contract

management under partial regulation, and as an example of this partial regulation,

we use service distribution in chronic health care.– Adherence and variation support to improve a customer lifetime value. Un-

like previous frameworks that focus on repair and recovery or rely on the effect of

punishments when an execution goes off-track [8, 9], our approach aims to prevent

the failure of management processes in the first place. Our interest is in managing

changes and deficits of an agent’s mental attitudes (based on the Belief-Desire-

Intention formalism [10, 11]). Such changes and deficits can jeopardise the man-

agement of a contract. Our adherence support monitors agent behaviour, detects

precursor events indicating possible off-track behaviour, and intervenes upon the

detection of such events to move the management processes back on-track.

In this paper, we focus on forming contractual relationships, which is a critical part of

managing contractual relationships [2, 3, 5].

4 Adherence and Variation Support Framework to ManageContractual Relationships in Customer Life Cycle ManagementSystems

This section first describes an initial framework to manage contractual relationships

based on mental attitudes, and then describes an example application.

4.1 Theoretical Consideration of Changes and Deficits in Mental Attitudes

We describe mental deficits using Bratman’s “future-directed intention” [10] concept

that is also the basis for the BDI agent architecture [10, 11], and Castelfranchi’s belief-

based goal dynamics [12]. We assume that humans are goal-directed agents, and our

investigation of a conceptual framework to demonstrate how models of the mental atti-

tudes of human agents affect how they follow management processes. Bratman’s notion

of “future-directed intentions” [10] states that humans decide in advance on a plan for

the future and then use this plan as a basis for taking actions. We consider the obli-

gations of agents prior to forming a contract as future-directed intentions (i.e., they

agree to follow the regulations underlying contract formation). In addition, the model of

belief-based goal dynamics [12] proposes that beliefs are at the core of selecting and ex-

ecuting goals: humans commit to obligations based on beliefs at commitment-time and

following guidelines depends on execution-time beliefs of an agent. Following these

two research streams, we introduce the notion of three types of deficits in an agent’s

mental attitudes that can lead to unreliable and non-conformant behaviour. We denote

a Belief of an agent with upper case B, a Plan with upper case P, and an Intention with

upper case I.

– A belief deficit is defined as an agent

• not having a belief B (but should have one) required to activate a goal (e.g., an

agent forgot to make an appointment), or• having a belief B that incorrectly represents a fact in the domain (e.g., an agent

believes it needs to attend an appointment at 3pm, but the actual appointment

is at 11am).

A belief plays a significant role in the activation of goals of a BDI agent. If an agent

has a belief deficit, a goal may not be activated and pursued.– A plan deficit is defined as an agent.

• not having a plan P (but should have one) to pursue a goal (e.g., if a podiatrist

does not know how to respond to a request by a GP), or• having a plan P’ different to a correct plan P that pursues the correct goal (e.g.,

if a podiatrist sent a wrong response to the GP).

With a non-existing or incorrect plan, a BDI agent is not able to pursue a goal.– An intention deficit is defined as incorrectly prioritising goals (e.g., if a patient

thinks that it is not important to go to the podiatrist to check his/her feet).

With regard to failure prevention, monitoring and recognition is focused on

favourable precursor events that have not occurred or unfavourable precursors that have

occurred. A favourable precursor indicates that processes are executed according to

specifications. The absence of favourable events implies that there is a change or deficit

in a contract party’s mental attitude. Deficits prevent parties from executing actions

required for executing actions properly.

Monitoring, Recognition and Intervention of Mental Attitudes The adherence and

variation support consists of monitoring, recognition and intervention processes. To

monitor the behaviour of a contract party, we adopt a combination of intrusive [20]

and overhearing [21] methods. The intrusive approach requests agents to communi-

cate required data, and the overhearing approach monitors the message exchanges

among agents passively. The mental-state recognition process is aimed at detecting the

deficit associated with the favourable or unfavourable precursor event. At the end of the

DA

Contractual

Commitment

CPA GP

CPA 1

CPA 2

CPA 3

CPA 4

CPA PAT

AA PAT

AA CPA

AA CPA

AA GP

AA CPA

AA CPA

Fig. 4. Applying the framework to chronic health care provision.

mental-state recognition process, a detected precursor event is associated with a belief,

intention or a plan deficit. The aim of an intervention is to encourage agents to perform

corrective actions to move the management processes back on track. We currently fo-

cus on monitoring, recognising and intervening belief deficits, but in the future we plan

to identify all three types of deficits, and then apply a tailored intervention strategy. In

future research, we also associate an intervention with different levels of effectiveness

as well as different levels of cost.

4.2 Application of Framework: Health Care Service Distribution

We consider as an example of managing contractual commitments the assignment of

services to providers in chronic disease management. This assignment involves the dis-

tribution of a set of services (which we refer to as a careplan), and offers as output a

commitment of different contract parties to perform services. After contractual com-

mitments are formed, service delivery can commence, which is managed by the service

delivery stage of the ICCM system (Section 2.1).

In the service distribution example, we have an agent that performs functional dis-

tribution tasks, which we refer to as a Distribution Agent (DA). The DA handles basic

service request processes. Contract Party Agents (CPA) act as proxies of health care

providers. Each CPA can have deficits and can change its mental attitudes, and hence

is associated with an AA that is monitoring, recognising and intervening the behaviour

of a CPA, if required. We define two specific CPAs, the CPAGP and CPAPAT which

have different responsibilities to the CPAs. The data and processes maintained by these

individual types of agents are defined in the following paragraphs. We used a general

mathematical approach to specify the agents, but other agent specification methodolo-

gies can also be used (e.g., [22, 23]). We decided to implement this approach using BDI

agents (Figure 4).

A DA coordinates the distribution of services specified in a careplan that has been

computed in the composition stage (Section 2.1). The DA processes request/response

interactions of CPA’s, approvals of AGP, and informing agents of updates regarding

contract revisions.

Definition 1. A DA maintains the following data model.

– A careplan: Careplan CP = {s1, . . . , sn}, where each si is a service.

– A careplan with assignments CP′ = {< s1,CPAk >, . . . , < sn ,CPAl >}, where

each element is an assignment tuple of a service si ∈ CP and a contract party

agent CPAj . CP′ is an empty set at the beginning of the formation process.

A DA executes two main processes.

– requestAgreement (si, CP , CPAj ) Seeks agreement from CPAj to perform service

si in careplan CP .– handleResponse (si, CP , CPAj ) If CPAj response is

• agree: CPAj is assigned to service si

• conditional agree: AGP is requested to approve. If AGP response is∗ approve conditions: CPAj is assigned to service si

∗ disapprove conditions: CPAj is removed, a request is sent to next provider• disagree: CPAj is removed, a request is sent to next provider

Example 1. In the management of patients with a chronic disease, the DA has a care-

plan: S = {s1, s2, s3}. This plan demands the participation of three Health Care Provider

(HCP) types (contractual commitment of these types): a podiatrist for s1, an optometrist

for s2 and an educator for s3. The DA requests an agreement, i.e., requestsAgreement,

from a given podiatrist, optometrist, and educator. The podiatrist joins the care team

(agree), the optometrist suggests changes (conditional agree) and the educator denies

participation (disagree). The DA assigns the service s1 to the podiatrist. For the op-

tometrist, the DA seeks approval by the GP (the responsible supervisor of this contrac-

tual formation) regarding the suggested changes to the careplan. In this example, the GP

approves the conditions, and the optometrist is assigned to s2. The educator does not

agree, and the DA sends a new participation request to a next educator. The next educa-

tor then agrees to be assigned to service s3. We now have a careplan with assignments,

and a contractual relationship formed among all HCP’s.3

A CPAj is an agent that acts as a proxy of a service provider. A CPAj ’s responds

to requests sent by the DA.

Definition 2. A CPAj executes the following processes.

– respondRequest (si, CP ) CPAj can respond in three ways to the DA request.

• agree: CPAj agrees to perform service si in CP• conditional agree: CPAj agrees to perform service si if CP is changed• disagree: CPAj does not agree to perform service si in CP

An agent CPAGP represents the GP that approves the assignments of services and

approves suggested changes by CPAj . CPAGP communicates to the DA.

Definition 3. An CPAGP executes the following processes.

– approvesChanges (CP ) If a CPAj suggests changes to the careplan CP.

• approve: inform DA changes are approved• disapprove: inform DA changes are not approved

– approvesCareplan (CP ) All service assignments are completed.

In the healthcare domain, CPAPAT represents the customer. CPAPAT receives only

updates about the progress of the distribution, and its processes are not defined.

3 In future research, we investigate how changes made to a careplan assignment will prompt

agents to revise previous agreements (this could potentially be a complex task as each revision

may cause agents to re-negotiate an agreement to the new changes in the careplan assignment).

ALGORITHM: Distribution.

INPUT: Careplan CP = {s1, . . . , sn}OUTPUT: Careplan with assignments CP ′ = {< s1, CPAj >, . . . , < sn, CPAk >}

1. For each si ∈ CP requestAgreement (si, CPAj)

(a) Response from CPAj

i. CPAj : Agreeii. CPAj : Conditional Agree

A. CPAGP: approveChangesB. CPAGP: disapproveChanges

iii. CPAj : Disagree: requestAgreement (si, CPAj)

(b) AAGP : checkValidity (CP)(c) CPAGP: approveCareplan (CP)

Fig. 5. Distribution Algorithm for Health Care Domain.

Adherence and Variation Support Agents An AAk monitors the behaviour of a cor-

responding CPAj , recognises changes and deficits, and intervenes if activities (or the

absence of activities) of providers are expected to jeopardise the distribution of tasks.

Definition 4. An AAk executes the following processes.

– Monitor-Recognise-Intervene (CPAj ) Intervenes if a CPAj is performing un-

favourable activities or is not performing favourable activities. A recognised event

can trigger an intervention to remedy one of the following deficits.

• belief deficit: AAk performs an action that corrects or reinstantiates a belief

(e.g., send CPAj a reminder)• plan deficit: AAk performs an action that corrects or reinstantiates a plan

(e.g., send CPAj instructions)• intention deficit: AAk performs an action that reprioritises an intention (e.g.,

send CPAj information of current priority)

The AAGP of a CPAGP checks if a careplan is valid (e.g., and if the distribution of

tasks is completed), and it informs the CPAGP if a careplan is ready for approval.

Definition 5. An AAGP executes the following processes.

– checkValidity (CP′) Check if the careplan assignment is

• invalid: inform CPAGP agreement not ready for approval• valid: inform CPAGP agreement ready for approval

Using the above data and process models of individual agents, the distribution al-

gorithm followed by agents is shown in Figure 5. This algorithm is a specific instance

of contract management for health care distribution using specific governance policies

and task level specifications.

5 Experimental Setup

This section presents an empirical simulation-based study investigating the influence of

response behaviour and adherence support on the efficiency of the algorithm in Figure 5.

This study illustrates the model of chronic disease management specified in Section 4.2.

5.1 Experimental Parameters

To investigate the above issues empirically, we implemented the distribution algorithm

defined in Figure 5 and the agents defined in Section 4.2. We evaluate the algorithm by

varying four parameters: response type, response delay, forget fullness, and adherence

support. These experimental parameters are assigned a range of values in the simulation.

– Response Type (RT) defines two types of uniform distributions that initialise the

average type of response across all contract party agents (i.e., whether they agree,

conditionally agree, or disagree).

[RT 1] Agree ( 1

3), Conditional Agree ( 1

3), Disagree ( 1

3)

[RT 2] Agree ( 2

3), Conditional Agree ( 1

6), Disagree ( 1

6)

[Agree]s will assign the CPAj in question to a given service si.

[Conditional Agree]s requires an approval by the GP. [Disagree]s

causes the DA to seek participation from another CPAj+1 of the same type.– Response Delay (RD) defines six negative exponential distributions with a varying

rate parameter λ. Each distribution specifies a different degree of response delay.

[RD Very Punctual] Nexp(λ = 1)[RD Punctual] Nexp(λ = 5

6)

[RD Neutral – Punctual] Nexp(λ = 4

6)

[RD Neutral – Late] Nexp(λ = 3

6)

[RD Late] Nexp(λ = 2

6)

[RD Very Late] Nexp(λ = 1

6)

The negative exponential and Gaussian distribution functions are implemented us-

ing an inverse sampling method.– ForgettFullness (FF) defines six types of agents expressing a chance of whether

an agent forgets to respond to a DA request. This initialisation is based on a normal

distribution N(CIµ = 0.5, CIσ = 0.1), truncated at ]0, 1[. A random value V is

drawn from this distribution, and the next highest upper value to V in the following

ranges defines to which FF group an agent belongs.

[FF Always Forget] V = 0[FF Very Forgetful] 0 < V < 0.2[FF Often Forgetful] 0 < V < 0.4[FF Sometimes Forgetful] 0 < V < 0.6[FF Seldom Forgetful] 0 < V < 0.8[FF Never Forget] 0 < V < 1

The value V drawn from this distribution is then used as a threshold value to deter-

mine whether a fact has been forgotten. This is done by drawing a random value V’

from a uniform distribution between 0 and 1 and compare it against the threshold

value V. If V<V’ then the agent forgot (belief deficit), if V>=V’ it did not forget.

So, if V=0.5, then the value to which V’ values are compared is 0.5, and the FF

group is FF = “Sometimes Forgetful” as the next highest upper value of 0.5 is in

the group: 0 < V < 0.6.– Adherence Support (AS) defines whether the adherence agents are active.

[AS No Adherence Support] All AAs disabled[AS Adherence Support] All AAs enabled

This adherence support will remedy belief deficits of agents by reminding them that

they need to respond to requests. In the future, we investigate adherence support to

cope with plan and intention deficits.

0

1

2

3

4

5

6

7

8

9

10

0 2 4 6 8 10 12 14

RD = Very PunctualRD = Punctual

RD = Neutral -- PunctualRD = Neutral -- Late

RD = LateRD = Very Late

0

1

2

3

4

5

6

7

8

9

10

0 2 4 6 8 10 12 14

RD = Very PunctualRD = Punctual

RD = Neutral -- PunctualRD = Neutral -- Late

RD = LateRD = Very Late

Fig. 6. Left figure (without adherence support): Number of confirmed services (Y-Axis) plotted

against the number of days (X-Axis) since an agreement request was sent with the 6 response

time settings. Right figure, with adherence support

We constructed parameter-based settings where we varied the values of the exper-

imental parameters RT, RD, FF and AS, resulting in a setting for each combination of

the experimental parameters: RT×RD×FF×AS=2 × 6 × 6 × 2 =144.

A simulation run of a setting executes the distribution algorithm (Figure 5) under

a particular combination of the experimental parameters. All agents are implemented

using Jason [24], an interpreter for AgentSpeak(L) and an abstract language based on

the BDI architecture [11].

5.2 Efficiency Metrics

The efficiency of the algorithm (Figure 5) is measured by how many providers are

assigned to services in the careplan (a measure of how well the contractual relationships

are formed, and an indirect measure of the expected development of a customer lifetime

value). We refer to this measure as the Number Of Confirmed Services (NOCS). This

measure is represented by the value obtained from the service provider’s simulated

response behaviour. The plotted results are averaged over 100 simulation runs for each

combination of experimental parameters. These results are also normalised to compare

different numbers of services and providers specified in the careplan.

5.3 Results

The purpose of this experiment is to examine the efficiency of adherence support on dis-

tribution (an instance of contract formation) under different simulation settings relating

to the response behaviour of contract party agents. We first comment on the results

obtained from settings where agents exhibit different behaviours for the parameter Re-

sponse Time (RT). In these settings, CPAs have not forgotten to respond to requests.

Instead, the response is set at a future day according to a negative exponential function.

This is to simulate typical delay situations. In Figure 6, the x-axis shows the number of

days after the DA has requested an agreement by the CPAs, and the y-axis is a function

of the number of services that are confirmed per day (same for Figure 7). As seen from

the left plots of Figure 6, settings with agents that respond very late, Nexp(λ = 1

6),

have a strong negative influence on the Number of Confirmed Services (NOCS). The

average measure of NOCS becomes increasingly better as the agents respond earlier.

This contrasts to a situation where agents receive interventions on a regular basis when

0

1

2

3

4

5

6

7

8

9

10

0 2 4 6 8 10 12 14

FF = Never ForgetFF = Very Forgetful

FF = Often ForgetfulFF = Sometimes Forgetful

FF = Very ForgetfulFF = Always Forget

0

1

2

3

4

5

6

7

8

9

10

0 2 4 6 8 10 12 14

FF = Never ForgetFF = Very Forgetful

FF = Often ForgetfulFF = Sometimes Forgetful

FF = Very ForgetfulFF = Always Forget

Fig. 7. Left figure (without adherence support): Number of confirmed services (Y-Axis) plotted

against the number of days (X-Axis) since an agreement request was sent with the 6 forgetfulness

settings. Right figure, with adherence support

a precursor event is not detected (right plots of Figure 6). Here, the results obtained

indicate that late CPAs change their response behaviour after an adherence agent sent a

reminder. The reason is that the agent response time (the day of response after a request

was sent) is resampled from the negative exponential function, and thus increases the

chance of an agent to respond earlier. This shows that late responders benefit from our

adherence support mechanisms, even if they do not experience deficits in their beliefs.

We now discuss the results for agents that are forgetful, and start with the results

obtained without adherence support (left plots in Figure 7). As the CPAs forget to re-

spond to agreement requests (FF), the formation of agreements progressively becomes

worse and NOCS decreases accordingly. In fact, if all agents forget to respond then

no service is assigned to any service provider (FF=Always Forget). The reason is that

CPAs simply have no belief that would trigger them to respond to a request, and this

constitutes a belief deficit that is permanent. This contrasts to distribution with adher-

ence support (right plots in Figure 7), where adherence agents remind agents on a daily

basis. As seen from the right plots of Figure 7, the forgetful CPAs start off with a low

level of NOCS, but recover quickly as the days pass. The reason is that our adherence

support remedies the belief deficit. The agent that has a deficit does not have a belief

and cannot act according to the specified management processes. If an intervention is

successful (in this case, if an agent is reminded by an AA), the lacking belief of a CPA

will be reinstated, and the agent can then proceed as planned, i.e., pursue the goal of

responding to the DA.

These results encouraged us to perform a further experiment, where we measured

the ratio of benefits/costs of each intervention against NOCS, shown in Figure 8. These

results give a first insight into the evaluation of trade-offs between benefits and costs of

adherence support on contract management. The costs are normalised for the number

of interventions, where the maximum number of intervention is 135 (9 interventions

maximum per day × 15 days) and they are weighed based on the day when they are ap-

plied. Figure 8 shows a particular instance of these runs where 7-8 interventions yield

the best benefit/cost ratio – any more interventions, and the cost exceeds the benefit.

Any less interventions, and we would have not fully utilised the maximum benefit of

applying interventions. Overall, our results (Figures 6, 7 and 8) demonstrate that set-

tings with adherence support reach a higher level of efficient contract formation than

settings without adherence support.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 2 4 6 8 10 12 14

RD = Very PunctualRD = Punctual

RD = Neutral -- PunctualRD = Neutral -- Late

RD = LateRD = Very Late

Fig. 8. Benefit/cost net value: number of confirmed services divided by cost for interventions per

day (X-axis) against the number of days (X-Axis) since an agreement request was sent with the

6 forgetfulness settings.

6 Conclusion

This paper investigates the influence of adherence and intervention mechanisms on the

process of managing contracts, particularly when agents exhibit unreliable and non-

rational behaviour. This behaviour is due to deficits in an agent’s “mental attitudes”

(a term from the Belief-Desire-Intention paradigm). These deficits influence how well

an agent can follow specified processes, and if certain events indicate an off-track be-

haviour, our proposed adherence support system can remedy this situation. We inves-

tigated the adherence support system by means of a simulation-based experiment. A

finding is that our system has a positive influence on managing contractual relation-

ships, not only when agents forget to respond to requests (i.e., when they have belief

deficits), but also when there is a delay in an agent’s responses. First indicative results

on the trade-off between benefit/costs of interventions show that a cost effective number

of interventions can be determined when reaching a contractual agreement.

Our current model offers adherence support at an adequate time (e.g., after a certain

period of time has passed) and with an adequate content (sending info that addresses

precisely the prevailing deficits of an agent CPAj ). Relaxing this assumption may raise

a number of issues, which we plan to address in the future. We plan to further investigate

how contract management is influenced when “too little” and “too much” adherence

support is offered. We also plan to design/evaluate market structures, where incentives

and perhaps price structures can improve the overall conformance of plan execution.

Acknowledgements This research was supported in part by the British Telecom

(CT1080050530) and the Australian Research Council (LP0774944). We gratefully

acknowledge the contributions by Dr Simon Thompson and Dr Hamid Gharib of the

British Telecom and Professor Leon Piterman, Dr Kay Jones, Associate Professor Peter

Schattner, and Mr Akuh Adaji of the Depart. of General Practice, Monash University.

References

1. Cutler, M., Sterne, J.: E-Metrics: Business Metrics For The New Economy, Cambridge

(MA): NetGenesis Corp. 2000. Online im Internet 12 (2000)

2. Smith, R.G.: The contract net protocol: High-level communication and control in a dis-

tributed problem solver. IEEE Transactions on Computers 29(12) (1980) 1104–1113

3. Jennings, N., Faratin, P., Johnson, M., Norman, T., O’brien, P., Wiegand, M.: Agent-based

business process management. International Journal of Cooperative Information Systems

5(2) (1996) 105–1304. Carlshamre, P., Regnell, B.: Requirements lifecycle management and release planning in

market-driven requirements engineering processes. (2000) 961–9655. Xu, L., Weigand, H.: The evolution of the contract net protocol. In: Advances in Web-

Age Information Management: Second International Conference (WAIM). Lecture Notes in

Computer Science, Springer-Verlag: Heidelberg, Germany (2001) 257–2646. Trastour, D., Bartolini, C., Preist, C.: Semantic Web support for the business-to-business

e-commerce pre-contractual lifecycle. Computer Networks 42(5) (2003) 661–6737. Erl, T.: Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall

(2005)8. van der Krogt, R., de Weerdt, M.: Coordination through plan repair. Lecture notes in com-

puter science 3789 (2005) 2649. Jakob, M., Pechoucek, M., Miles, S., Luck, M.: Case studies for contract-based systems. In:

Proceedings of the 7th international joint conference on Autonomous agents and multiagent

systems: industrial track, International Foundation for Autonomous Agents and Multiagent

Systems (2008) 55–6210. Bratman, M.E.: Intentions, Plans, and Practical Reason. Harvard University Press (1987)11. Rao, A.: Agentspeak(L): BDI agents speak out in a logical computable language. In: Pro-

ceedings of MAAMAW 96. Volume LNAI Vol. 1038., London, Springer-Verlag, Berlin, Ger-

many (1996) 42–5512. Castelfranchi, C., Paglieri, F.: The role of beliefs in goal dynamics: Prolegomena to a con-

structive theory of intentions. Synthese 155(2) (2007) 237–26313. Wickramasinghe, K., Guttmann, C., Georgeff, M., Gharib, H., Thomas, I., Thompson, S.,

Schmidt, H.: Agent-based intelligent collaborative care management. In: Proceedings of

AAMAS-Volume 2, IFAAMS (2009) 1387–138814. Guttmann, C., Thomas, I., Georgeff, M., Wickramasinghe, K., Gharib, H., Thompson, S.,

Schmidt, H.: Towards an intelligent agent framework to manage and coordinate collabora-

tive care. In: Proceedings of the first workshop on Collaborative Agents – REsearch and

development (CARE 2009). Lecture Notes in Computer Science, Springer-Verlag, Berlin,

Germany (accepted in 2009, to appear in 2010)15. Georgeff, M.: Service orchestration: The next big challenge. DM Review Special Report

(2006) 1056195–116. Zambonelli, F., Jennings, N., Wooldridge, M.: Organizational abstractions for the analysis

and design of multi-agent systems. Agent-Oriented Software Engineering: First International

Workshop, AOSE 2000, Limerick, Ireland, June 10, 2000: Revised Papers (2001)17. Horling, B., Lesser, V.: A survey of multi-agent organizational paradigms. The Knowledge

Engineering Review 19(04) (2005) 281–31618. Williamson, O.: Markets and hierarchies: some elementary considerations. The American

Economic Review 63(2) (1973) 316–32519. Williamson, O.: The economics of organization: The transaction cost approach. American

journal of sociology 87(3) (1981) 54820. Horling, B., Benyo, B., Lesser, V.: Using self-diagnosis to adapt organizational structures.

In: Proceedings of the fifth international conference on Autonomous agents, ACM (2001)

53621. Kaminka, G., Pynadath, D., Tambe, M.: Monitoring teams by overhearing: A multi-agent

plan-recognition approach. Journal of Artificial Intelligence Research 17(1) (2002) 83–13522. Wooldridge, M., Jennings, N., Kinny, D.: The Gaia methodology for agent-oriented analysis

and design. Autonomous Agents and Multi-Agent Systems 3(3) (2000) 285–31223. Giunchiglia, F., Mylopoulos, J., Perini, A.: The tropos software development methodology:

processes, models and diagrams. Lecture Notes in Computer Science (2003) 162–173

24. Bordini, R., Huebner, J., Wooldridge, M.: Programming Multi-Agent Systems in AgentS-

peak using Jason. Wiley New York (2006)

Abstracting Business Modeling Patterns from

RosettaNet

Pankaj R. Telang and Munindar P. Singh

North Carolina State University, Raleigh, NC 27695-8206, USA

prtelang@ncsu.edu, singh@ncsu.edu

Abstract. RosettaNet is a leading industry effort that creates standards for busi-

ness interactions. The RosettaNet standard defines over 100 Partner Interface

Processes (PIPs). The PIPs specify the business interactions at a syntactic level,

but they fail to capture the business semantics of those interactions. This paper

builds on a commitment-based approach for business modeling. It presents an ap-

proach that defines commitment-based business patterns abstracted from Rosetta-

Net PIPs. This paper validates the patterns by using them to model a well-known

real-life use case of a cross-organizational business interaction.

1 Introduction

The competition in the global economy compels organizations to provide high-quality

products and services at an attractive cost. It forces organizations to identify contextual

processes and activities, and to outsource them to other organizations that specialize

in executing those processes. A few examples of such processes are human resources

management, workplace management, payroll, call center, and IT infrastructure man-

agement. By outsourcing such processes, an organization reduces operational expenses,

and at the same time gains access to specialized resources for the contextual work. The

outsourcing results in a network of organizations. To conduct business, these organiza-

tions engage in a complex set of service interactions.

RosettaNet [6] is a leading industry effort that creates standards for business inter-

actions. The RosettaNet consortium consists of over 500 organizations of various sizes,

and from various industry sectors. These organizations use elements of the RosettaNet

standard, named Partner Interface Processes (PIPs), to transact business that is worth

billions of dollars. A PIP specifies two-party interactions for some specific business

purpose. For example, a buyer requests a quote from a seller using PIP 3A1, and a

seller requests financing from a financing processor, on behalf of the buyer, using PIP

3C2. A PIP specification contains a document that informally describes the purpose of

the PIP, any assumptions, and the outcome. Additionally, a PIP specification provides

an XML DTD or XML Schema that corresponds to the structure of the messages that

the participants in the PIP would exchange.

RosettaNet PIPs specify the business interactions at a syntactic level, but they fail

to capture the business meaning of those interactions. For example, in PIP 3A1, a buyer

sends a request for quote to a seller, and the seller responds either with a quote, or a

referral. RosettaNet leaves important details unspecified. If the seller responds with a

quote, does the seller commit to the buyer to sell the goods at the quoted price? Does

the buyer commit to the seller to buy the goods at the quoted price if the buyer acknowl-

edges the quote? The PIP leaves such questions regarding the business meanings of the

interactions to human interpretation.

In our previous work [10], we present a high-level business metamodel to capture

the way in which cross-organizational service engagements are carried out. This paper

uses the business metamodel to abstract business patterns from the RosettaNet PIPs.

Note that these patterns are not operational patterns like the workflow patterns [7]. In-

stead they are high-level patterns that specify the essence of the business. They provide

flexibility in business execution.

There are two key motivations in abstracting these patterns. First, since the patterns

are at a business level, business analysts can easily compose them to develop a de-

sired business model. Second, a model composed from these patterns serves as a formal

specification that can be used to verify an operational model defined in any technical

standard. Organizations frequently migrate their business process implementations to

newer technologies to benefit from the improvements those technologies offer. In such

technology migration, the high-level formal specification verifies the correctness of the

new implementation.

Contributions The main contribution of this paper is an approach for abstracting busi-

ness patterns from RosettaNet PIPs. It applies the patterns to a real-life business sce-

nario. The paper highlights the shortcomings of the existing PIPs, and identifies new

PIPs that are necessary to model complex service engagements.

Organization Section 2 provides a background on the RosettaNet PIP standard and

introduces our business metamodel. Section 3 presents business patterns for a subset

of the RosettaNet PIPs. Section 4 applies the patterns to model an aerospace scenario.

Section 5 concludes the paper with a discussion of the related work and some future

directions.

2 Background

We now review some key background on RosettaNet and on our approach.

2.1 RosettaNet

The RosettaNet standard specifies over 100 PIPs for various business processes in the

eCommerce supply chain. The standard classifies the PIPs using clusters and segments.

A cluster represents a major business process of the supply chain. A cluster is subdi-

vided into segments that represent subprocesses of the cluster’s business process. Each

segment contains many PIP specifications. For example, Cluster 3 represents the Order

Management process, and Segment A of that cluster represents the subprocess Quote

and Order Entry. Segment A contains PIPs such as 3A1, 3A3, and 3A4. The standard

employs three views to specify a PIP, the Business Operational View (BOV), the Func-

tional Service View (FSV), and the Implementation Framework View (IFV).

The BOV informally describes the business process that the PIP implements. It

specifies the two partner roles, and the business activities that the roles execute. A busi-

ness process flow diagram shows the business activities, and the flow of business mes-

sages between the roles. For each activity, BOV specifies performance controls such as

the need to acknowledge receipt, nonrepudiability of the receipt, and the timeout for the

acknowledgment.

For a PIP, the FSV derives from the BOV, and specifies the RosettaNet services. It

specifies the message exchange sequence in a business transaction dialog, and for each

message, it specifies message exchange controls. These controls include the time within

which an acknowledgment is required, the time within which a response to an action is

required, and whether authorization is required for an action.

The IFV specifies the message formats as XML DTDs or XML Schemas. For each

message, it specifies the communication requirements such as the need for a digital

signature, and secured transport.

2.2 Business Metamodel

This discussion is extracted from our previous work [10]. A business model specifies

how business is conducted. We concern ourselves with business models that involve

two or more participants. The business participants, abstracted as roles, participate in

a business relationship. The participants create, manipulate, and satisfy commitments

in a relationship. They execute tasks for each other that enable them to achieve their

respective goals.

Three distinct phases characterize business execution. First, in the agreement phase,

participants enter into an agreement, and create commitments toward each other. Sec-

ond, in the assembly phase, the participants delegate or assign commitments to others.

A participant may delegate a commitment that requires the execution of a task which is

not a core competency of that participant, or due to some other economic motivation.

Third, in the enactment phase, participants execute tasks to satisfy their commitments.

Figure 1 describes the business metamodel.

Agent: a computational representation of a business participant. An agent has goals,

and executes business tasks. For each business relationship in which an agent par-

ticipates, it enacts one or more roles.

Role: an abstraction over agents that helps specify a business relationship. Each role

specifies the commitments expected of the agents who play that role along with the

tasks they must execute to function in that role.

Goal: a state of the world that an agent desires to be brought about [1]. An agent

achieves a goal by executing appropriate tasks.

Task: a business activity viewed from the perspective of an agent.

Commitment: a directed obligation from a debtor to a creditor [8]. A commitment

C(DEBTOR, CREDITOR, antecedent, consequent) denotes that the DEBTOR is obliged

to the CREDITOR for bringing about the consequent if the antecedent holds.

executes

requires

refers to

Agent

Commitment

Role

plays

desires

Goal

TaskBusiness

Relationship

specifies

debtor creditor

Fig. 1. Business metamodel [10]

A commitment can be in one of the following states: inactive, active, detached,

satisfied, or violated. Before a commitment is created, it is inactive. In this state,

the debtor has no obligation toward the creditor. A commitment may remain in-

active forever if it is never created. Alternatively, if the debtor and the creditor

negotiate and create the commitment, it becomes active. The negotiation may also

create a detached commitment, that is, the antecedent of the commitment may hold

upon creation. For an active commitment, active timeout may occur if neither its

antecedent nor its consequent is brought about within certain time period. In that

case, the commitment expires. If the antecedent of an active commitment is brought

about, then the commitment is detached, or if its consequent is brought about, then

it is satisfied. After a commitment is satisfied, if its antecedent is brought about, it

remains satisfied. Similar to active timeout, for a detached commitment, detached

timeout may occur if its consequent is not brought about, causing the commitment

to be violated. Conversely, if the consequent of a detached commitment is brought

about, it is satisfied.

Business relationship: a set of interrelated commitments among two or more roles

that describe how business executes among the participating roles.

3 Business Patterns From PIPs

This section describes the approach to abstract business patterns from RosettaNet PIPs.

It describes the business pattern for the Request Quote PIP 3A1 in detail, and for PIPs

3A4, 3A6, 3B3, and 3C6 in brief. Due to limited space, we present business patterns

only for a subset of the PIPs.

A RosettaNet PIP specifies two-party interactions that contains two participant roles.

Since the notion of a role in RosettaNet is similar to the concept of a role in our business

model, a role from a PIP simply maps to a role in the business pattern. In a PIP, a busi-

Receive

Need to order

Buyer

Seller

Analyze ordering

needs

Request a

new quote

Set quote

specifications and

create a quote

request

Send message

Can we meet the

requirement of the

quote request?

Do we want to

suggest another

supplier?

Collect detailed information for

the quote line items (fixed/

negotiated price, configurable/

stand alone product, freight, tax,

purchase order required)

Collect suitable

supplier’s

information

Send quote Send referral

Receive Receive

Yes

3A1

3A1 3A1

Yes

No

Yes

Fig. 2. Usage-Request Quote PIP 3A1 (verbatim from the RosettaNet specification [6])

ness participant enacts one or more roles. In our business model, an agent represents a

business participant and it enacts one or more roles.

In a PIP, a role enacting participant executes an activity. In our business model, the

concept of a task models an activity, and a role enacting agent executes one or more

tasks. Although a PIP specifies one activity per role, that activity can represent more

than one real business activity. We model each of the real business activity as a task in

the business pattern.

Unlike RosettaNet specification, the business pattern captures the business meaning

of the tasks that the roles execute in terms of commitments. There can be multiple

interpretations of the business meaning of a PIP. In this paper, we present one possible

interpretation that naturally derives from the PIP’s description. We now describe the

business pattern for PIP 3A1.

Figure 2 shows the usage diagram from the RosettaNet description of the Request

Quote PIP 3A1. It shows a buyer that desires to purchase certain goods. The buyer sends

a request for a quote to a seller. If the seller can satisfy the requirements of the quote, it

sends a quote to the buyer. Otherwise, the seller sends a referral of another seller to the

buyer.

Figure 3 shows the business pattern for the request quote PIP 3A1. The pattern

figures use the notation of Figure 1. The subscript on a commitment indicates its state:

Buyer Seller

[reqQuote,

quote]

[reqQuote,

referral]

Buyer Seller

C1A: goods

[reqQuote,

timeout]

C1 C(SELLER, BUYER, pay, goods)

Role Tasks

Buyer reqQuote, pay

Seller quote, referral, goods

Fig. 3. Business pattern: Request Quote PIP 3A1

I for inactive, A for active, D for detached, and S for satisfied. The roles in Figure 3

are the same as the roles in the PIP. The BUYER role is capable of executing the tasks

reqQuote, and pay. The task reqQuote is mapped from the request quote activity of the

PIP. The SELLER role is capable of executing the tasks quote, referral, and goods. In the

PIP, the SELLER executes confirm quote activity that means either sending a quote, or

sending a referral. It derives the two seller tasks, quote and referral. If the seller sends a

quote, the seller commits (C1) to the buyer to shipping the goods if the buyer pays. On

the contrary, if the seller sends a referral, or if the seller fails to respond and a timeout

occurs, then no commitment is created.

Similar to the business pattern for PIP 3A1, we derive the patterns for PIPs 3A4,

3A6, 3B2, and 3C6. Figure 4 shows the business pattern for the Request Purchase Order

PIP 3A4. This PIP presumes that a commitment C1 exists from the seller to the buyer

to sell certain goods for some price. The buyer sends a purchase order to the seller. If

the seller accepts the order, the buyer becomes committed (C2) to the seller to pay if

the seller ships the goods. On the contrary, if the seller rejects the order, then the seller

cancels its existing commitment C1.

Figure 5 shows the business pattern for the Distribute Order Status PIP 3A6. After

a buyer and a seller negotiate, and create commitments C1 and C2, the seller reports

the progress of its task of shipping the goods to the buyer. If the seller reports that the

goods are shipped, then the seller satisfies its commitment C1. This detaches the buyer’s

commitment C2 to pay the seller.

Figure 6 shows the business pattern for the Notify of Advance Shipment PIP 3B2. In

this pattern, the seller ships the goods, and sends a ship notice to the buyer. By shipping

the goods, the seller discharges its commitment C1.

Figure 7 shows the business pattern for the Notify of Remittance Advice PIP 3C6.

The buyer sends a remittance advice to the seller, to pay for an order. This PIP presumes

[sendOrder,

timeout]

Buyer Seller

C1A: goods

[sendOrder,

rejectOrder]

Buyer Seller

C1I: goods

[sendOrder,

acceptOrder]

C2A: pay

Buyer Seller

C1A: goods

C1 C(SELLER, BUYER, pay, goods)

C2 C(BUYER, SELLER, goods, pay)

Role Tasks

Buyer sendOrder, pay

Seller acceptOrder, rejectOrder, goods

Fig. 4. Business pattern: Request Purchase Order PIP 3A4

that the buyer has a commitment C2 to pay the seller. The buyer discharges C2 by

sending the remittance advice.

4 Evaluation: Aerospace Aftermarket Services

This section applies the RosettaNet business patterns to model the cross-organizational

processes developed under the European Union CONTRACT project [11] in the domain

of aerospace aftermarket services.

Figure 8 shows a high-level process flow of aerospace aftermarket services. The par-

ticipants of this process are an airline operator, an aircraft engine manufacturer, and a

parts manufacturer. The aircraft engine manufacturer provides engines to the airline op-

erator. Additionally, the manufacturer services the engines to keep them operational. If a

plane waits on the ground for an engine to be serviced, the manufacturer pays a penalty

to the airline operator. As part of the agreement, the airline operator regularly provides

engine health data to the manufacturer, and may proactively request the manufacturer to

perform engine maintenance referred to as scheduled maintenance. The manufacturer

analyzes the health data and informs the operator of required engine maintenance re-

ferred to as unscheduled maintenance. As part of servicing the engine, the manufacturer

Buyer Seller

C1A: goods

C2A: pay

Buyer Seller

C1S: goods

C2D: pay

[reportStatus]

reportStatus

goods

[reportStatus]

reportStatus ¬goods

C1 C(SELLER, BUYER, pay, goods)

C2 C(BUYER, SELLER, goods, pay)

Role Tasks

Buyer pay

Seller reportStatus, goods

Fig. 5. Business pattern: Distribute Order Status PIP 3A6

Buyer Seller

C1A: goods

C2A: pay

Buyer Seller

C1S: goods

C2D: pay

[shipNotice]

shipNotice

goods

C1 C(SELLER, BUYER, pay, goods)

C2 C(BUYER, SELLER, goods, pay)

Role Tasks

Buyer pay

Seller shipNotice, goods

Fig. 6. Business pattern: Notify of Advance Shipment PIP 3B2

can either refurbish or replace the engine. The manufacturer maintains a supply of en-

gines by procuring parts from a parts manufacturer. Figure 9 shows how the RosettaNet

patterns model the business arrangement between the manufacturer and the operator.

Using PIP 3A1, the operator requests a quote from the manufacturer to provide

aircraft engine along with the maintenance service. The operator also requires the man-

Buyer Seller

C1A: goods

C2A: pay

Buyer Seller

C1D: goods

C2S: pay

[remitAdvice]

remitAdvice

pay

C1 C(SELLER, BUYER, pay, goods)

C2 C(BUYER, SELLER, goods, pay)

Role Tasks

Buyer remitAdvice, pay

Seller goods

Fig. 7. Business pattern: Notify of Remittance Advice PIP 3C6

Engine Manufacturer (E) Parts Manufacturer (P)Operator (O)

Operate Aircraft Monitor Engine Health

Inform Maintenance

Schedule Maintenance

Operate Aircraft Remove Engine

Replace Refurbish Supply Parts

Scheduled

Unscheduled

Fig. 8. A high-level model of the aerospace aftermarket process (verbatim from the Amoeba [2]

paper, originally from CONTRACT project [11])

ufacturer to pay a penalty if an engine is down. By sending a quote, the manufacturer

creates the commitment C1. In C1, the manufacturer commits to (a) provide the engine,

(b) create the service commitment C3, and (c) create the commitment C4 to pay the

penalty in case of the engine downtime. The manufacturer makes the commitment C1with the condition that the operator pays for the offer, and creates the commitment C5to provide engine health data if requested.

Oper Mfg

Oper Mfg

C1A: engine & create(C3)

& create(C4)

3A1

Create(C1)

Oper Mfg

C1A: engine & create(C3)

& create(C4)

C2A: pay & create(C5)

Oper Mfg

C1S: engine & create(C3)

& create(C4)

C2D: pay & create(C5)

C3A: provideService[i]

C4A: penalty[i]

3A6

engine,

Create(C3),

Create(C4)

3A4

Create(C2)

PIP NEW

Create(C5)

3C6

pay

Oper Mfg

C1S: engine & create(C3)

& create(C4)

C2D: pay & create(C5)

C3A: provideService[i]

C4A: penalty[i]

C5A: repEngineHealth[i]

Oper Mfg

C1S: engine & create(C3)

& create(C4)

C2S: pay & create(C5)

C3A: provideService[i]

C4A: penalty[i]

C5A: repEngineHealth[i]

C1 C(MFG, OPER, pay ∧ create(C5), engine ∧ create(C3) ∧ create(C4))C2 C(OPER, MFG, engine ∧ create(C3) ∧ create(C4), pay ∧ create(C5))C3 C(MFG, OPER, requestService[i] ∧ ¬expired, provideService[i])C4 C(MFG, OPER, engineDown[i] ∧ ¬expired, penalty[i])C5 C(OPER, MFG, reqEngineHealth[i] ∧ ¬expired, reportEngineHealth[i])

Fig. 9. Operator and manufacturer interactions modeled using business patterns

If the operator finds the quote acceptable, it sends a purchase order to the manu-

facturer using PIP 3A4. By sending the purchase order, the operator commits to the

manufacturer to pay, and to create the commitment C5 if the manufacturer fulfills the

offer.

Using PIP 3A6, the manufacturer informs the operator that it has shipped the engine,

and created the commitments C3 and C4. The manufacturer satisfies its commitment C1,

and it detaches the commitment C2. In the commitment C3, the manufacturer commits

to the operator to provide service on the engine upon a request from the operator. There

can be many instances of the service requests, and the manufacturer commits to provide

the service for each of those requests so far as the request is made before an expiration

date. As per the commitment C4, the manufacturer commits to the operator to pay a

penalty in case of the engine downtime. Similar to the service commitment C3, the

manufacturer commits to pay penalty for each instance of engine downtime that occurs

before an expiration date.

Mfg Sup

Mfg Sup

C6A: parts

Mfg Sup

C6A: parts

C7A: payS

3A1

Create(C6)

3A4

Create(C7)

3B2

parts

3C6

payS

Mfg Sup

C6S: parts

C7D: payS

Mfg Sup

C6S: parts

C7S: payS

C6 C(SUP, MFG, paySup, parts)C7 C(MFG, SUP, parts, paySup)

Fig. 10. Manufacturer and supplier interactions modeled using business patterns

In the aerospace scenario, the operator (buyer) needs to notify the manufacturer

(seller) that it created the commitment C5. The RosettaNet specification lacks a pattern

for such a case in which a buyer notifies a seller of satisfying certain terms of a purchase.

We assume a new PIP for this case. Using this PIP, the operator notifies the manufacturer

that it created the commitment C5. As per C5, the operator commits to report the engine

health to the manufacturer if the manufacturer requests for it.

The operator pays the manufacturer by sending a remittance advice using PIP 3C6.

This satisfies the commitment C2.

The above interactions result in the business model with the active commitments C3,

C4, and C5. These commitments form the basis of the business engagement between the

operator and the manufacturer. For example, due to the commitment C3, an operator

request for service, prior to the expiration date, creates a detached commitment from

the manufacturer to the operator to service that instance of request. The commitment

C3 remains active forever, but after the expiration date it never detaches. Therefore, the

participants can purge the commitment after the expiration date has passed.

Figure 10 shows how the business patterns model the business engagement between

the manufacturer, and the supplier. When the manufacturer desires to purchase certain

parts, it sends a quote request to the supplier using PIP 3A1. If the supplier responds

with a quote, the supplier commits (C6) to shipping the parts, if the manufacturer pays

the supplier.

If the manufacturer finds the quote acceptable, it sends an order to the supplier using

PIP 3A4. This creates the reverse commitment C7 from the manufacturer to the supplier

to pay if the supplier ships the parts.

Eventually the supplier builds the parts, and ships them to the manufacturer. The

supplier notifies the manufacturer of the shipment using PIP 3B2. This satisfies the sup-

plier’s commitment C6 to ship the parts, and detaches the manufacturer’s commitment

C7 to pay the supplier.

The manufacturer pays the supplier by sending a remittance advice using PIP 3C6.

The manufacturer therefore satisfies its commitment C6 to pay the supplier.

5 Discussion

This paper presents an approach to abstract business patterns from RosettaNet PIPs. It

applies these patterns to model a real-life use case. The paper highlights some of the

shortcomings of the existing PIPs, and identifies the need for new PIPs. For example, in

real-life purchase scenarios, a buyer not only pays a seller, but also satisfies terms and

conditions of the sale. However, RosettaNet assumes that the buyer only pays the seller,

and it has the PIP 3C6 for that purpose. A PIP that the buyer can use to notify the seller

that it satisfied certain terms and conditions is lacking in RosettaNet.

Several RosettaNet PIPs merely allow the participants to exchange information.

They do not create or manipulate commitments. Since our patterns give primacy to

the commitments that the participant agents create and manipulate, they are not suitable

for such PIPs.

5.1 Related Work

Nitto et al. [5] elicit that the systems in the open environment will need to be highly

dynamic, and self-adaptive. Toward that end, they call out the need for natural, and high-

level design abstractions for modeling such systems. Our research aims at developing

such abstractions. This paper extracts business patterns from RosettaNet PIPs in terms

of the high-level abstractions from our business metamodel.

There is a large body of research work that aims at creating a catalog of reusable

patterns for business interactions. However, most of this work is based on low-level ab-

stractions. For instance, Zdun et al. [12] propose a set of pattern primitives, and patterns

for process-driven service oriented architecture. These patterns use low-level concepts

of data and control flow to model the service interactions. They fail to specify the busi-

ness relationships between the participants. In contrast, the patterns from this paper are

founded on the business relationships defined in terms of commitments.

Singh et al. [9] propose a set of commitment oriented patterns for service interac-

tions. They describe a pattern using a statechart that shows lifecycles of the commit-

ments. In contrast, this paper describes patterns using a graphical language based on

the business metamodel. Our graphical language is more natural as it emphasizes the

roles and tasks in addition to showing commitments, and their states.

Kotinurmi et al. [4] and Haller et al. [3] incorporate semantics at the lower-level

of data in RosettaNet PIPs. They develop an ontology using Web Service Modeling

Language (WSML) for the PIP payloads and choreographies. In contrast, our work

identifies business level meaning of the PIPs in terms of the commitments.

5.2 Future Directions

This work opens up several interesting directions. Of these, we are pursuing the devel-

opment of formal techniques that involve formalizing the patterns and to verify compli-

ance of low-level operational model with respect to a given business model. We expect

also to develop a catalog of well-defined reusable patterns for business modeling. A

systematic methodology to specify business models in high-level terms would also be

crucial to the greater success of this effort.

References

1. BRG. The business motivation model, 2007.

2. Nirmit Desai, Amit K. Chopra, and Munindar P. Singh. Amoeba: A methodology for model-

ing and evolution of cross-organizational business processes. ACM Transactions on Software

Engineering and Methodology (TOSEM), 19(2):6:1–6:45, October 2009.

3. Armin Haller, Paavo Kotinurmi, Tomas Vitvar, and Eyal Oren. Handling heterogeneity in

rosettanet messages. In Symposium on Applied Computing, pages 1368–1374, 2007.

4. Paavo Kotinurmi and Tomas Vitvar. Adding semantics to rosettanet specifications. In Pro-

ceedings of the 15th international conference on World Wide Web, pages 1059–1060, 2006.

5. Elisabetta Di Nitto, Carlo Ghezzi, Andreas Metzger, Mike P. Papazoglou, and Klaus Pohl.

A journey to highly dynamic, self-adaptive service-based applications. Automated Software

Engineering, 15(3-4):313–341, 2008.

6. RosettaNet. Overview: Clusters, Segments, and PIPs, 2008. www.rosettanet.org.

7. Nick Russell, Arthur, Wil M. P. van der Aalst, and Natalya Mulyar. Workflow control-flow

patterns: A revised view. Technical report, BPMcenter.org, 2006.

8. Munindar P. Singh. An ontology for commitments in multiagent systems: Toward a unifica-

tion of normative concepts. Artificial Intelligence and Law, 7:97–113, 1999.

9. Munindar P. Singh, Amit K. Chopra, and Nirmit Desai. Commitment-based service-oriented

architecture. IEEE Computer, 42(11):72–79, November 2009.

10. Pankaj R. Telang and Munindar P. Singh. Business modeling via commitments. In Proceed-

ings of the 7th AAMAS Workshop on Service-Oriented Computing: Agents, Semantics, and

Engineering (SOCASE), volume 5907 of LNCS. Springer, 2009.

11. C. J. van Aart, Jirı Chabera, Martin Dehn, Michal Jakob, Kristof Nast-Kolb, J. L. C. F.

Smulders, Patrick P. A. Storms, Camden Holt, and Malcolm Smith. Use case outline and

requirements. Deliverable D6.1, IST CONTRACT Project, 2007. http://tinyurl.com/6adejz.

12. Uwe Zdun, Carsten Hentrich, and Schahram Dustdar. Modeling process-driven and service-

oriented architectures using patterns and pattern primitives. ACM Transactions on the Web,

1(3), 2007.