2010 FOURTH INTERNATIONAL CONFERENCE ON

RESEARCH CHALLENGES IN INFORMATION SCIENCE

PROCEEDINGS

RCIS 2010

Nice, May 19-21, France

EDITORS: Peri Loucopoulos Jean Louis Cavarero

2010 Fourth International Conference on Research Challenges in Information Science

Copyright © 2010, by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved.

Copyright and Reprint Permissions: Abstracting is permitted with credit to the source. Libraries are permitted to photocopy beyond the limit of U.S. copyright law for private use of patrons those articles in this volume that carry a code at the bottom of the first page, provided that the per-copy fee indicated in the code is paid through the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923. For other copying, reprint, or republication permission, write to IEEE Service Center, 445 Hoes Lane, Piscataway, NJ 08854. All rights reserved.

IEEE Catalog Number: CFP1040D ISBN: 978-1-4244-4840-1

Library of Congress: 2009905529 ISSN: 2151-1357

Additional copies of this publication are available from: Curran Associates, Inc. 57 Morehouse Lane Red Hook, NY 12571 USA Phone: (845) 758-0400 Fax: (845) 758-2633 E-mail: curran@proceedings.com

SPONSORSHIP

We wish to thank the following organizations for their contribution to the success of this Conference.

INTRODUCTION

The series of the IEEE International Conferences on Research Challenges in Information

Science (RCIS) aims at providing an international forum for scientists, researchers, engineers and developers from a wide range of information science areas to exchange ideas and approaches in this evolving field. While presenting research findings and state-of-art solutions, authors are especially invited to share experiences on new research challenges. It is a big pleasure for all of us to celebrate this fourth edition of RCIS for which we sought research focusing on foundational or technological aspects as well as research based on experience and describing industrial aspects on the following main topics: Databases, Information Systems, Web Systems, Business Process Modelling, Analysis and Design, Intelligent Agents, Ontologies and Knowledge Discovery from Data. Of course, we express our appreciation to all Program Committee members for their involvement in the evaluation of submitted papers. It is not an obvious task to select a relevant subset of submitted works, but with their support, diligence and expertise, we have been able to prepare an exciting scientific program. For this fourth edition, we received 148 papers. Each submitted paper was carefully evaluated based on originality, significance, technical soundness, and clarity of expression by three reviewers. From these submissions, 48 were selected as long papers and 19 as short papers to be presented at the conference. Additionally, 5 doctoral papers were accepted. In addition, the conference program is properly complemented with three renowned keynote speakers, Colette Rolland (University of Paris 1 Panthéon Sorbonne), Brian Fitzgerald (University of Limerick) and Roël Wieringa (University of Twente). Thanks to all of them for sharing this event with us. This is for sure a strong added value for this fourth edition of RCIS. We are grateful to local organizers for their assistance in solving any problem encountered. RCIS 2010 would not have been possible without their big efforts ; they selflessly offered their time and energy to make this conference a success. Finally we welcome you to Nice, we hope you enjoy this conference and benefit from the scientific program but also from sharing your experiences with colleagues from around the world. Peri Loucopoulos (General Chair) Jean Louis Cavarero (PC Chair) Nice, France, April 2010

RCIS STEERING COMMITTEE Oscar Pastor (Technical University of Valencia, Spain)

Jean Louis Cavarero (University of Nice, France)

Martine Collard (INRIA Sophia Antipolis, France)

André Flory (INSA Lyon, France)

Colette Rolland (University of Paris 1 Panthéon Sorbonne, France)

CONFERENCE COMMITTEE

General Chair: Peri LOUCOPOULOS (Loughborough University, UK)

PC Chair: Jean-Louis Cavarero (University of Nice, France)

PC Co-Chair: Nadine Tournois (University of Nice, France)

Doctoral Papers Workshop Chair: André Flory (INSA Lyon, France)

Publicity Chair: Selmin Nurcan (University of Paris 1 Panthéon Sorbonne, France)

Operating Committee Chair: Martine Collard (University of Antilles Guyane, France)

PROGRAM COMMITTEE

PROGRAM COMMITTEE CHAIR

Jean-Louis CAVARERO University of Nice-Sophia Antipolis FRANCE

PROGRAM COMMITTEE CO-CHAIR

Nadine TOURNOIS University of Nice-Sophia Antipolis FRANCE

PROGRAM COMMITTEE MEMBERS

Silvia ABRAHAO Technical University of Valencia SPAIN Fernanda ALENCAR Federal University of Pernambuco BRAZIL Eric ANDONOFF University of Toulouse FRANCE João ARAUJO New University of Lisbon PORTUGAL Adnen BEN FADHEL University Tunis-Manar TUNISIA Laila BENHLIMA Ecole Mohammadia d'Ingénieurs MOROCCO Laurent BRISSON TELECOM Bretagne FRANCE Dimitru BURDESCU University of Craiova ROMANIA Silvana CASTANO Universita' degli Studi di Milano ITALY Corine CAUVET University of Aix-Marseille FRANCE Lawrence CHUNG University Of Texas At Dallas USA Martine COLLARD INRIA Sophia Antipolis FRANCE Alex DELIS University of Athens GREECE Oscar DIESTE UPM Madrid SPAIN Eric DUBOIS Public Research Centre Henri Tudor LUXEMBOURG Amador DURAN TORO University of Seville SPAIN Armin EBERLEIN University of Calgary CANADA Mohammed EL MOHAJIR University of FES MOROCCO

Maria José ESCALONA CUARESMA University of Sevilla SPAIN

Bernard ESPINASSE University of Aix-Marseille FRANCE

Nicoletta FARCANE West University of Timisoara, Faculty of Economic Sciences ROMANIA

André FLORY INSA Lyon FRANCE Xavier FRANCH University of Barcelona SPAIN Agnes FRONT University of Grenoble FRANCE Jose Luis GARRIDO University of Granada SPAIN Marcela GENERO UCLM Ciudad Real SPAIN Laura GAILLARD GIORDANI Bocconi University ITALY

Martin GLINZ University of Zurich SWITZERLAND María Visitación HURTADO TORRES University of Granada SPAIN

Dimitris KARAGIANNIS University of Vienna AUSTRIA Evangelia KAVAKLI University of the Aegean GREECE Régine LALEAU University of Paris XII FRANCE Georg LAUSEN University of Freiburg GERMANY Julio LEITE PUC Rio de Janeiro BRAZIL Christoph LOFI University of Braunschweig GERMANY Kalle LYYTINEN Case Western Reserve USA Maryse MARTIN University of Nice-Sophia Antipolis FRANCE Paloma MARTINEZ FERNANDEZ University Carlos III, Madrid SPAIN

Bertrand MASQUEFA University of Nice-Sophia Antipolis FRANCE Shawna MILLIOT-GUINN University of Poitiers FRANCE

Irena MLYNKOVA Charles University, Prague CZECH REPUBLIC Faïza NAJJAR Ecole Nationale des Sciences de l'Informatique TUNISIA Martin NECASKY Charles University, Prague CZECH REPUBLIC Moira NORRIE ETH, Zurich SWITZERLAND Selmin NURCAN University of Paris 1 La Sorbonne FRANCE Mads NYGAARD University of Trondheim NORWAY Antoni OLIVE Universitat Politecnica De Catalunya SPAIN Aris OUKSEL University of Illinois USA Oscar PASTOR Technical University of Valencia SPAIN Vicente PELECHANO Technical University of Valencia SPAIN Barbara PERNICI Politecnico di Milano ITALY Anne PERSSON University of Skövde SWEDEN

Klaus POHL University of Duisburg-Essen GERMANY Jolita RALYTE University of Geneva SWITZERLAND Stella RAYTCHEVA Versailles Saint-Quentin-en-Yvelines University FRANCE William ROBINSON Georgia State University USA Colette ROLLAND University of Paris 1 La Sorbonne FRANCE Gustavo ROSSI National University of La PLATA ARGENTINA Ounsa ROUDIES Ecole Mohammadia d'Ingénieurs MOROCCO Motoshi SAEKI Tokyo Institute of Technology JAPAN Marian SCUTURICI INSA Lyon FRANCE Keng SIAU University of Nebraska-Lincoln USA Robert TELLER University of Nice-Sophia Antipolis FRANCE Pierre TELLER University of Nice-Sophia Antipolis FRANCE Ernest TENIENTE Universitat Politècnica de Catalunya SPAIN Juan Carlos TRUJILLO University of Alicante SPAIN Afrodite TSALGATIDOU National and Kapodistrian University of Athens GREECE Jesus TORRES VALDERRAMA University of Sevilla SPAIN

Costas VASSILAKIS University of Peloponese GREECE June VERNER University of New South Wales AUSTRALIA Carson WOO University of British Columbia CANADA Mudasser WYNE National University, San Diego USA

Additional Reviewers

Marc ORIOL Universitat Politècnica de Catalunya SPAIN Kawtar BENGHAZI Universitat of Granada SPAIN

343- Combining Agents and Wrapper Induction for Information Gathering on Restricted Web Domains Shereen Albitar, Bernard Espinasse, Sebastien Fournier, LSIS, Aix-Marseille University

INTELLIGENT AGENTS

353- An Organization-Oriented Methodological Framework for Agent-Based Supply Chain Simulation Karam Mustapha, Erwan Tranvouez, Bernard Espinasse, Alain Ferrarini, LSIS, Aix-Marseille University

365- A multiagent Decision Support System for scheduling repair - application to socio-technical organizations Sébastien Fournier, Alain Ferrarini, Erwan Tranvouez, LSIS Aix-Marseille University

375- An Uncoupled Approach Agents/Web Services to Support Uniform Access to Resources in Information Systems Leila Ouahrani, Zaia Alimazighi, University of Alger

BUSINESS PROCESS MODELLING

383- Specifying Business Methods with the Work Product Pool Approach Cesar Gonzalez-Perez, LaPa - CSIC Brian Henderson-Sellers, Department of Software Engineering, University of Technology, Sydney

391- Research issues in designing Services for Quality Giovanni Pignatelli, Gianmario Motta, Department of Informatics and Systems, University of Pavia Antonella Longo, Department of Engineering for Innovation, University of Salento

399- User-oriented business processes Giorgio Bruno, Dip. Automatica e Informatica, Politecnico di Torino

409- Representing Analysis Models For Alignment Naveen Prakash, Arun K. Chaturvedi, MRCE, Sector-43, Faridabad, Haryana INDIA

415- Towards an ontology for service oriented modeling supporting business processes Andrea Delgado, Francisco Ruiz, Ignacio García-Rodríguez de Guzmán, Mario Piattini, University of Castilla - La Mancha

Towards an ontology for service oriented modeling

supporting business processes

Andrea Delgado

Computer Science Institute, Faculty of Engineering,

University of the Republica

Montevideo, Uruguay

adelgado@fing.edu.uy

Francisco Ruiz, Ignacio García-Rodríguez de Guzmán,

Mario Piattini

Alarcos Research Group, Technology and IS Department

University of Castilla – La Mancha

Ciudad Real, Spain

{francisco.ruizg,ignacio.grodriguez,mario.piattini}@uclm.es

Abstract—The Service Oriented Computing (SOC) paradigm is

nowadays applied as the preferred way to implement business

processes. Services provide the support required by organizations

for organizational agility, helping in closing the gap between the

business and the systems areas by relating them while detaching

business process definition from its technical implementation.

Several existing standards gives different visions of the concepts

involved in service oriented development, making it difficult to

get a clear relation between services and business processes. In

this article an ontology proposal containing the most relevant

concepts for service oriented and business process modeling is

presented, along with a comparison analysis between the existing

standards for service orientation.

Keywords: Service Oriented Computing (SOC), business

processes, Business Process Management (BPM), ontology support

I. INTRODUCTION

The traditional vertical vision of software development without having a global business vision of the organization has required important efforts for the integration of systems and the subsequent incorporation of changes to them, in general without fulfilling the business area expectations, in which is known as business-systems gap. Another contributor to this gap is the high coupling that presents business process definitions with their implementation, mostly when they are implicitly defined in the software systems. To help in closing this gap, a key aspect is to separate the business process definition from its technical implementation, adding an intermediate layer of services to realize business process, in an horizontal vision allowing the required organizational agility. To support this horizontal vision, the paradigms Business Process Management (BPM) [1][2], Service Oriented Computing (SOC) [3][4][5] and Model Driven Development (MDD) [6][7][8] can be integrated. In this vision, business process are realized as sequence of services invocations, where these services are defined to realize business processes, and a model driven approach supports their automatic derivation.

MINERVA (Model drIveN & sErvice oRiented framework for the continuous business process improVement & relAted tools) [9] proposal integrates these three paradigms, with the main objective of supporting the business process lifecycle and its continuous improvement. It aims to provide a framework comprising a methodology, concepts and tools for the automated development of service oriented solutions from

business processes in organizations, combining the application of SOC and MDD paradigms to business process. It is defined to support the business process lifecycle as defined in [10], covering the four phases: Design and Analysis, Configuration, Enactment and Evaluation, and it is composed of three dimensions: conceptual, methodological and tools support.

The conceptual dimension is the basis on which rest the other dimensions, it is defined to unify terminology, concepts and relationships between the framework elements. In this dimension an ontology is defined, based on the business process lifecycle and its relationship with service oriented development, which is composed of seven sub-ontologies. An ontology defines relevant elements (concepts, relationships) in an area of interest [11][12]. For the business process lifecycle five sub-ontologies are defined for: business process modeling, simulating, execution, measuring and evaluation, for service oriented development two sub-ontologies are defined for: service oriented modeling and execution. In this article, the Service Oriented Modeling sub-Ontology (SOMsO) is presented, discussing the defined concepts and their relation with the Business Processes Modeling sub-Ontology (BPMsO).

The organization of the article is as follows: in section II the background relating the evaluated existing standards is presented, in section III a comparison analysis between the terms defined in each source is discussed, in section IV the sub-ontology proposal is introduced, and finally in section V the conclusions and future work are presented.

II. BACKGROUND

For the definition of the Service Oriented Modeling sub-ontology (SOMsO), several existing international standards defining ontologies, models and metamodels to describe services where evaluated. The most relevant ones are: Service Oriented Architecture Modeling Language (SoaML) [13] from Object Modeling Group (OMG) [14], SOA Reference Model (SOA RM) [15] and SOA Reference Architecture (SOA RA) [16] from the Organization for the Advancement of Structured Information Standards (OASIS) [17], SOA Ontology (SOA O) [18] from the Open Group [19] and the Web Services Architecture (WSA) [20] from the World Wide Web Consortium (W3C) [21]. The Web Service Modeling Ontology (WSMO) [22] from W3C was also checked but it has a higher level approach than ours so it was not evaluated.

415

In the following the selected standards are presented, denoting them as source Si where S means source and the index i goes from 1 to 7 numerating them incrementally. The index for the Service Oriented sources goes from 3 to 7, as the first two where used for the business process modeling sources: Business Process Definition Metamodel (BPDM) [23] and Business Process Modeling Notation (BPMN) [24] from OMG.

A. SoaML v.1.8 Draft Standard (2009/04/01) – S3

SoaML [13] provides a profile and a UML metamodel for designing SOA services. SoaML defines a Service is a value offer as one or more capabilities (apart from the ability to act and produce output and result). A service can have one or more interfaces and an associated contract. A Service Interface is defined by three main sections: interfaces provided and required, the interface class and the behavior protocol. A Service Contract defines terms, conditions, interface and choreography in which participants agree to use services. Participants are software components, organizations or systems that provide and use services, offering capabilities in ServicePoint and requiring them at RequestPoint, both specializing UMLPort. A Service Channel enables communication between suppliers and consumers, messages specifies the type of information exchanged and can have attachments. Services are performed by implementations that run in an environment (manual or automatic).

B. SOA RM v.1.0 Standard (2009/10/12) – S4

SOA-RM [15] defines services as a central concept, surrounded by: service description, interaction between services, visibility, execution context, contract and policies, and real-world effect. A service is defined as a mechanism to allow access to one or more capabilities, with defined interfaces, restrictions and policies set in the service description. A service is provided by a vendor and used by consumers, for which its implementation is hidden within the information for its invocation and use in the service description and interfaces. As a result of the invocation of a service effect/s in the real world are obtained: feedback, change of state of shared entities, or a combination of them. Policies and service contracts represent conditions for using a service: a policy defines restrictions while a contract is an agreement between the parties. The execution context of a service interaction is the infrastructure that defines a path between those with needs and those that provides capabilities.

C. SOA RA v.1.0 Draft Specification (2008/04/28) – S5

SOA RA [16] establishes requirements, objectives and critical aspects of SOA systems, supporting them through models arranged into three views: Business via Services, Realizing SOA, and Owning SOA, as defined in [25]. In the Business via Services viewpoint, four models are defined involving concepts such as participants and stakeholders, agents, resources, participant's abilities and needs, and roles and social structure. In the Realizing SOA view four models are also defined including the most important elements such as services, interfaces, reachability of services, functionality, policies and contracts, associated metrics, visibility of services. The services interaction model defines messages, activities,

events and effects in the real world while interacting with services, along with service choreography and orchestration. The Owning SOA viewpoint is integrated with the models of governance, security and services as manageable entities. The concepts defined are aligned with the SOA reference Model.

D. SOA O Draft Standard (2008/07/14) – S6

SOA O [18] establishes two main objectives: contribute to the understanding, and potentially be the basis for model driven implementations. A key concept is service defined as the logical representation of a repeatable business activity that has a specified output, is self-contained, can be composed of other services and is a "black box" for consumers. It has a provider, can have multiple consumers, and produces one or more valuable effects for them. Services are provided and consumed by actors, someone or something that does something (person, organization or piece of technology). Associated with a Service a Contract is defined in which consumers and providers take part, and policies defined by stakeholders. Contracts and policies have conditions expressed as rules and applied to services. Services exchange messages, which have a type, are input/output of the corresponding interface, and are composed of information items. Services are combined in compositions of services, which can be orchestration or choreography.

E. WSA (2004/02/11) – S7

WSA [20] proposes four interrelated architectural models: Service Oriented, Messages, Resources, and Policies. The Service Oriented model, defines a service as an abstract resource that performs one or more tasks, has a description, interface/s, semantics, an identifier, service roles and associated policies. It also has an owner, which may be an individual or an organization that provides it, is performed by a provider agent and invoked by a consumer agent, exchanging messages. The Message model focuses on messages, their structure and transport, agents that send and receive them, and mechanisms for shipment. The Resource model focuses on existing resources, which has owners, an universal identification of location (URI) and an associated representation. Policy model focuses on constraints that apply to the behavior of resources and services. It deals with resource policies that apply to agents attempting to access them , and are established by people with responsibilities for these resources. Additionally, aspects of security and use of WS, management and reliability, among others are also described.

III. COMPARISON ANALYSIS

A comparison analysis between terms in each evaluated source allowed us to understand the different meanings assigned to them, and choose the more appropriate for our purpose. The comparison analysis is presented here in three tables, following the levels defined in the Service Oriented Modeling sub-Ontology (SOMsO). Each table is indexed by its left column, which contains the term of the ontology being described. The second column shows the source standard where the term appears. The proposed definition of the concept represented by the term is shown in column three. The new terms of the SOMsO are not included in the comparison since they do not have definitions in the evaluated standards.

416

TABLE I. COMPARISON OF TERMS IN THE FIRST LEVELS OF SOMSO

Term Level Source Definition

Choreography 2

S3

Specification of what is transmitted and when it is transmitted between parties to enact a service exchange. It

specifies exchanges between the parties - the data, assets, and obligations that go between the parties. It defines what happens between provider and consumer participants without defining their internal processes - their internal

processes do have to be compatible with their ServiceContracts.

S4 Not explicitly defined.

S5 A technique used to characterize and to compose service-oriented business collaborations based on ordered

message exchanges between peer entities in order to achieve a common business goal.

S6 In a choreography, the component activities of the composition are autonomous but have a defined pattern of behavior with respect to each other.

S7

Defines the sequence and conditions under which multiple cooperating independent agents exchange messages in

order to perform a task to achieve a goal state.A choreography is a model of the sequence of operations, states, and conditions that control the interactions involved in the participating services. The interaction prescribed by a

choreography results in the completion of some useful function.

Orchestration 2

S3, S4 Not explicitly defined.

S5 A technique used to compose hierarchical and self-contained service-oriented business processes that are executed

and coordinated by a single agent acting in a “conductor” role.

S6 In an orchestration, there is one particular component activity of the composition that oversees and directs the other component activities.

S7 An orchestration defines the sequence and conditions in which one Web service invokes other Web services in

order to realize some useful function.

TABLE II. COMPARISON OF TERMS AROUND THE SERVICE TERM OF SOMSO

Term Level Source Definition

Service 3

S3 A resource that enables access to one or more capabilities. Here, the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. It is provided by a

entity-called the provider-for use by others, called the consumers which may not be known to the service provider.

S4 A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.

S5 Same as S4.

S6 A logical representation of a repeatable business activity that has a specified outcome (e.g. check customer credit). It is self-contained, may be composed of other services, and is a "black box" to its consumers. A service has a

provider, may have multiple consumers, and produces one or more effects (which have value to the consumers).

S7 A service is an abstract resource that represents a capability of performing tasks that represents a coherent functionality from the point of view of provider entities and requester entities. To be used, a service must be

realized by a concrete provider agent.

Interface 3

S3 Defines the interface to a Service or Request. A ServiceInterface (specializes UML Interface) defines the interface and responsibilities of a participant to provide or consume a service. It is used as the type of a Service or Request

port. A ServiceInterface is the means for specifying how to interact with a Service.

S4 The service interface is the means for interacting with a service. It includes the specific protocols, commands, and information exchange by which actions are initiated that result in the real world effects as specified through the

service functionality portion of the service description.

S5 Same as S4, and the interface will support an exchange of messages, where messages satisfies established criteria.

S6

An interface is a protocol by which actors can interact with and exchange information with an activity (service

being an specialization of activity). An activity (service) may have any number of interfaces. An interface can be composed of other interfaces. An interface of an activity enables actors to interact with the activity by means of

events, and to input information to the activity and receive information that is output by the activity.

S7

A service interface is the abstract boundary that a service exposes. It defines the types of messages and the

message exchange patterns that are involved in interacting with the service, together with any conditions implied by those messages.

Contract 3

S3

A ServiceContract is the formalization of a binding exchange of information, goods, or obligations between parties

defining a service. A ServiceContract is the specification of the agreement between providers and consumers of a service as to what information, products, assets, value and obligations will flow between the providers and

consumers of that service – it specifies the service without regard for realization or implementation.

S4 A ServiceContract represents an agreement between two or more participants. Contracts can cover a wide range of aspects of services: quality of service agreements, interface and choreography agreements and commercial

agreements. Is a measurable assertion that governs the requirements and expectations of two or more parties.

S5, S6 Same as S4.

S7

A service semantics is the contract between the provider entity and the requester entity concerning the effects and

requirements pertaining to the use of a service. The semantics of a service is the behavior expected when interacting with the service. The semantics expresses a contract (not necessarily a legal contract) between the

provider entity and the requester entity.

417

Term Level Source Definition

Port 3

S3

From UMLSuperstructure: A port is a property of a classifier that specifies a distinct interaction point between that

classifier and its environment or between the (behavior of the) classifier and its internal parts. A Port may specify the services a classifier provides (offers) to its environment as well as the services that a classifier expects

(requires) of its environment.

S4, S5,

S6, S7 Not explicitly defined.

RequestPoint 4

S3 Defines the port through wich a Participant makes requests and uses or consumes services.

S4, S5, S6, S7

Not explicitly defined.

ServicePoint 4

S3 Defines the connection point of interaction on a Participant where a service is actually provided or consumed

S4, S5, S6, S7

Not explicitly defined.

Operation 3

S3 A service Operation is any Operation of an Interface provided or required by a Service or Request Point. An

Operation has parameters defining its inputs and outputs, preconditions and post-conditions, may raise Exceptions

S4, S6,

S7 Not explicitly defined.

S5 The sequence of actions a service must perform in order to validly participate in a given joint action.

Message 3

S3

A MessageType is the specification of information exchanged between service consumers and providers.This

information consists of data passed into and/or returned from the invocation of an operation or event signal defined in a service interface. A MessageType is in the domain of service-specific content and does not include header or

other implementation or protocol-specific information.

S4 Not explicitly defined.

S5 Medium of interaction between service participants. Messages are exchanged that represent actions, and messages

are exchanged that represent the reporting of events.

S6 An information item that is sent by an actor to one or more other actors (the recipients of the message). In addition to information to be processed by the recipients (the message body), a message may include other information, for

example to identify the recipients or the sender, or to describe characteristics of the message such as its priority.

S7 Basic unit of data sent from one Web service agent to another in the context of WS. A message represents the data structure passed from its sender to its recipients. The structure of a message is defined in a service description. The

main parts of a message are its envelope, a set of zero or more headers, and the message body.

TABLE III. COMPARISON OF TERMS AROUND THE PARTICIPANT TERM OF SOMSO

Term Level Source Definition

Participant 3

S3 The type of a provider and/or consumer of services. In the business domain a participant may be a person,

organization or system. In the systems domain a participant may be a system, or component.

S4,S6,

S7 Not explicitly defined.

S5 Stakeholder that has the capability to act in the context of a SOA-based system.

Actor 4

S3, S4,

S5, S7 Not explicitly defined.

S6 Someone or something that does something. An actor can be a person or an organization or a piece of technology.

Agent 5

S3 A classification of autonomous entities that can adapt to and interact with their environment. It describes a set of

agent instances that have features, constraints, and semantics in common.

S4, S6 Not explicitly defined.

S5

Any entity that is capable of acting on behalf of a person or organization. In order for people to be able to offer,

consume and otherwise participate in services, they require the use of an agent capable of directly interacting with electronic communications – a service agent.

S7 Same as S5.

Consumer 6

S3, S7 Not explicitly defined.

S4 An entity which seeks to satisfy a particular need through the use capabilities offered by means of a service.

S5 A service consumer is a participant that interacts with a service in order to access a capability to address a need.

S6 A consumer of a service (or some other thing) is an actor that uses it. A service can have one or more consumers.

Provider 6

S3, S7 Not explicitly defined.

S4 An entity (person or organization) that offers the use of capabilities by means of a service.

S5 A service provider is a participant that offers a service that permits some capability to be used by other participants.

S6 A provider of an activity (service) is an actor that takes responsibility for it being carried out. Every service has a

provider.

418

As it can be seen in Table I, services can be composed as

orchestration or choreography of other services, being the most relevant difference between these concepts how the control of the business process flow is managed. All definitions agree in that when there is an entity that controls the business process flow the composition is an orchestration, on the other hand, in choreography the interaction sequence is agreed by all participants but no one is in charge of the process flow. The definition in S6 is specially clear to this respect, stating that it defines a pattern of behavior between participants, which are autonomous. Also in S3 other important concept is defined, stating that what it defines is what happens between provider and consumer without defining its internal processes, which have to be compatible with their services contracts that provides the agreement between participants.

In table II the most relevant concepts defined are: services, interface, contract, port, operation and message. Regarding the definitions of the Service concept which is the key one, most of the sources agree in that it represents or enable access to one or more capability, as an (abstract) resource or a mechanism. On the other hand, in S6 an important aspect of services is stated when defined as a logical representation of a repeatable business activity that has a specified outcome, relating clearly the significance of a service with their business content. This definition is the one we adopted since we believe that the strong relation between services and business functions or activities has to be taken into account as the most important one to define useful services. About elements surrounding the service concept, all sources agree in that a service interface represents the means for interacting with a service, defining the interaction protocol, messages to be exchanged, responsibilities of participants, among others. All sources agree in that services contracts represents an agreement between provider and consumer, defining elements including services interfaces and others such as quality of service agreements. In S7 it represents the service semantics defined as the behaviour expected when interacting with the service. It is worth mentioning that many of the sources do not define the term Operation, which in our point of view is an important one that must be included in the definition of service interfaces. We adopt the definition of S3 which states so, defining it as being part of the interface provided or consumed by ports. The concept of Port is only defined in S3 as UML Port and specialized in RequestPoint and ServicePoint for requesting and providing services respectively which we also adopted. The Message concept is agreed by all sources to represent information, data, and events being the medium of interaction between service participants.

In table III the relevant concepts around the Participant element are shown. It drew our attention the fact that this concepts were not defined in most of the sources, specially S3 does not define the concepts of Consumer and Provider, but defines Participant as the type of a provider/consumer of services, which we adopt and extend defining them by means of adopting the definitions for provider/consumer in S6. An actor is only defined in S6 as someone or something that does something, being a person or a piece of technology.We adopted this definition defining a hierarchy that begins in the concept of Actor,specializing it until reaching the provider/consumer ones.

IV. ONTOLOGY PROPOSAL

As previously mention in Section I, the conceptual dimension of MINERVA, is defined to unify terminology, concepts and relationships between the framework elements. The ontology proposal belongs to this dimension and it is composed of seven sub-ontologies based on the business process lifecycle and its relationship with service oriented development. So far the business processes and services modeling sub-ontologies have been detailed, including relevant concepts and relationships based on evaluated standards as presented in Section II. These sub-ontologies are the basis for the transformations we are defining to automate the derivation of services from business processes, providing the semantic information needed to understand the correspondences between elements. The main work was done in the analysis and evaluation of concepts regarding the service oriented paradigm, due to the heterogeneity of the set of concepts covered in the selected sources, along with it definitions, although they share a common core set of relevant concepts.

A. Service Oriented Modeling sub-Ontology (SOMsO)

In the following the Service Oriented Modeling sub-Ontology (SOMsO) is presented in three tables around the defined levels and main terms, including the New ones and the reference to the source from wich the term was either Adopted as is, or Adapted mainly merging definitions of more than one source, with our own vision of the concept.

TABLE IV. DEFINITION OF TERMS IN THE FIRST LEVELS OF SOMSO

Term Level Source Definition

Business

Process 1 New

Real process in the

organization

SOModel 2 New

Service oriented model to

implement a business process model that specifies a BP

SOModel

Notation 3 New

Valid notation to specify a

service oriented model

SOType 1 New Indicates the type of

services composition

Choreography 2 Adapted S3+S5+S6

Composition of services that are autonomous but have

defined pattern of behaviour

with respect to each other, in order to achieve a common

business goal. It defines what

happens between provider and consumer without

defining their internal

processes, which have to be compatible with their service

contracts.

Orchestration 2 Adapted S6+S7

Composition of services that defines the sequence and

conditions in which one

service invokes other services, directing and

controlling them, in order to

realize some useful business function.

SOModel

Element 2 New

Elements in a service

oriented model

419

Table IV presents the concepts defined in the first levels of the sub-ontology, around the element Service Oriented Model, which has a type that can be orchestration or choreography depending on the composition of services defined, it is specified by means of a valid notation, such as SoaML, and is composed of elements for service oriented modeling, which are presented next in table V.

TABLE V. DEFINITION OF TERMS AROUND SERVICE TERM OF SOMSO

Term Level Source Definition

Service 3 Adopted

S6 Refer to table II.

Interface 3 Adapted

S3+S7

Abstract boundary that a service exposes. It is

composed of operations that

defines the types of messages (including parameters,

exceptions, etc) involved in

interacting with the service. A ServiceInterface is the

means for specifying how to

interact with a Service.

Contract 3 Adopted

S7 Refer to table II.

Implementa-

tion 3 New

Software implementation of

a service in a specific technology (JEE, .NET, WS)

Port 3 Adopted

S3 Refer to table II.

RequestPoint 4 Adopted

S3 Refer to table II.

ServicePoint 4 Adopted S3

Refer to table II.

Operation 3 Adopted

S3 Refer to table II.

Message 3 Adapted

S3+S5

Medium of interaction between service participants.

A MessageType is the

specification of information exchanged between service

consumers and providers.

This information consists of data passed into and/or

returned from the invocation

of an operation or event signal defined in a service

interface.

Interaction 3 Adopted

UML

Behavioral unit focus in the observable information

exchange between elements.

Their most visible aspects are the messages between the

lifelines.

Sequence

Diagram 4

Adopted

UML

Describes an Interaction by focusing on the sequence of

Messages that are

exchanged, along with their Occurrence Specifications on

the Lifelines

Communica-

tion Diagram 4

Adopted

UML

Focus on the interaction between Lifelines where the

architecture of the internal

structure and how this corresponds with the

message passing is central.

The sequencing of Messages is given through a sequence

numbering scheme.

Table V presents the concepts defined around the Service element, which constitutes the main concept in service oriented modeling. A service is composed of and has associated several model elements, such as interface, contract, operations, implementation, among others. Service interface/s provides operations defined for the service, including type and format of messages to be exchanged. Contracts offer interfaces adding other elements for the agreement in the use of the service. Another important concept in service oriented modeling is the Participant one, which determines the services providers and consumers, and are described next in table VI.

TABLE VI. DEFINITION OF TERMS AROUND PARTICIPANT TERM OF SOMSO

Term Level Source Definition

Participant 3 Adopted S3

Refer to table III.

Actor 4 Adopted

S6 Refer to table III.

Agent 5 Adopted

S5 Refer to table III.

Consumer 6 Adopted S6

Refer to table III.

Provider 6 Adopted

S6 Refer to table III.

NoAgent 5 Adapted S6

Any other kind of actor that is not an Agent actor.

In table VI concepts related with the Participant element which offers and consumes services, are presented. Participant is specialized in several concepts such as Actor which can be an Agent or a NoAgent (person, organization), and where providers and consumers (as agents) offers them in points of Port type (Service and Request) associated with the service implementation.

B. Business Process Modeling sub-Ontology (BPMsO)

To define the relations required to support business processes by means of services, the most relevant elements for business process modeling must be also identified. The most important efforts in defining such elements are reflected in the OMG standards BPDM [23] and BPMN [24]. To briefly describe them, in BPDM both choreography and orchestration views of process are defined that can be mapped to the ones defined for services. It defines several models to group elements, being the most relevant one the activities model wich is the basis for the BPMN model. BPMN specifies one type of Business Process Diagram (BPD) and a set of core elements to model most of the required business process and complete set. The main four groups defined in the standard are: flow objects which are events, activities, decision/union nodes (split, join); connecting objects which are sequence, messages and association; swimlanes (pool, lanes) and artifacts (data, annotation, groups). As the concepts defined in these standards in our understanding, covers the relevant elements for business process modeling, we mainly adopted them directly. For this reason, we did not present the table of definitions from sources BPDM -S1 and BPMN -S2 in section II. Instead the adopted definitions are presented here. In the following the Business Process Modeling sub-Ontology (BPMsO) is presented in two tables around the levels defined in the sub-ontology.

420

TABLE VII. DEFINITION OF TERMS IN THE FIRST LEVELS OF BPMSO

Term Level Source Definition

Business

Process 1 New

Real process in the

organization

BPModel 2 New Business process model that specifies a real BP.

BPModel

Notation 3 New

Valid notation to specify a

business process model

BPType 3 New Indicates the type of

business process

Choreography 4 Adopted S1

Describes how semi-independent collaborating

entities work together in a

process, each of one has its own internal processes.

Captures in a given process

the roles interaction with well defined responsibilities.

Orchestration 4 Adopted S1

Sequence of activities that

produces results with branching and merging.

Describes what happens and

when ir order for a process to be managed under the

authority of an specific entity

BPModel

Element 3 New

Elements in a service

oriented model

In table VII the concepts defined in the first levels of the sub-ontology, around the element Business Process Model are shown. The BPModel has a type which can be orchestration or choreography, it is specify in a valid notation, such as BPMN, and it is composed of elements for business process modeling, which are shown next in table VIII.

TABLE VIII. DEFINITION OF TERMS BPMODELELEMENT OF BPMSO

Term Level Source Definition

Artifact 4 Adopted S2

Provides information support

about the process or their elements, withou affecting

the process flow

Data 5 Adopted

S2

provides information about what activities require to be

performed and what produce

Group 5 Adopted S2

Represents an activity group that are in the same category

Swimlane 4 Adopted

S2

Container to partition a set of

activities from others

Pool 5 Adopted S2

Represents a process participant that is a business

entity (enterprise, section) or a business role (seller, buyer)

that controls it.

Lane 5 Adopted

S2

A sub-partition of a Pool

used to organize and categorize activities

Connecting

Object 4

Adopted

S2

Object used to connect two

objects with each other showing how the flow goes

Sequence 5 Adopted

S2

Shows the order in which

process activities are performed, from start to end

Message 5 Adopted

S2

Shows the message flow

between two participants prepared to send and receive

Association 5 Adopted

S2

Associates information to

flow objects, could be text or graphical objects not of flow

Term Level Source Definition

FlowObject 4 Adopted

S2

Objects flow could be:

activities, events, gateways

Activity 5 Adopted S2

Generic term for the work that an organization performs

SubProcess 6 Adapted

S1+S2

Activity that is composed of

other activities, process included in another process.

Simple 6 Adopted

S1

Activity which is no

composed of other activities

Gateway 5 Adopted S2

Decision point used to

control the divergence and

convergence of process flow

Parallel

(AND) 6

Adopted

S2

Flows are performed concurrently instead of

sequentially, when diverging (fork) and converging (join)

Exclusive

(XOR) 6

Adopted

S2

Flow is restricted to only one

alternative from the possible

when diverging and combining (merging)

Inclusive (OR) 6 Adopted

S2

Branching where different

alternatives are evaluated and one, several or all of them

can be selected, and for

combining (synchronize)

Complex 6 Adopted

S2

An expression determines

which options are selected

when diverging and which are required when combining

(merge)

Event 4 Adopted S2

Something that happens in the course of a process

affecting its flow, and

generally has a cause (trigger) or an impact (result)

Flow

Dimension 5

Adopted

S2

Event that affects the process

flow, can be start, intermediate or end

Start 6 Adopted

S2

Event indicating where a

process begins

Intermediate 6 Adopted S2

Event that happens between a start and an end event

End 6 Adopted

S2

Event indicating where a

process ends

Type

Dimension 5

Adopted

S2

Type associated to the event,

can be message, time, error,

cancellation, conditional, signal, compensation, link,

termination or multiple

Actor 5 Adopted

S1

Entity responsible for the execution of tasks specified

by a realizing role .

Table VIII presents the concepts defined as business process elements BPModelElement, which allows representing business processes as models. The four groups defined in the BPMN standard are reflected and the elements that comprise each group, so there are Artifact, Swimlane, ConnectingObject and FlowObject. The elements defined in these groups are then related with the service oriented modeling elements, for example, activities that can be a sub-processes or simple ones, are realized by services, and sub-process flows are shown by means of interaction diagrams, along with gateways for alternatives. To illustrate graphically the defined concepts and relationships, an UML class diagram of BPMsO and SMOsO is presented in figure 1, and the relationships defined between their elements are described in table IX.

421

Figure 1. UML class diagram for Business Process and Service Oriented sub-Ontologies

TABLE IX. SUMMARY OF RELATIONSHIPS DEFINED BETWEEN BPMSO AND SOMSO

Name Concepts Definition

Corresponds-to BPMsO.Pool-

SOMsO.Participant A pool in a business process model determines a participant in the service oriented model

Corresponds-to BPMsO.Actor-

SOMsO.Actor

An actor in a business process model determines different types of actors in the service oriented

model to provide and consume services

Is-realized-with BPMsO.Activity-

SOMsO.Service

An activity in a business process model determines a service in the service oriented model, and

depending on the type of the activity (sub-process, simple) it will be an atomic service or one composed by others

Defines BPMsO.Sub-process-

SOMsO.Interaction

A sub-process in a business process, besides of determining a service in the service oriented model

also defines an interaction between the services that comprises it.

Shows-in BPMsO.Gateway-

SOMsO.Interaction

Gateways defining flows in a business process model, are shown in the flow of the services interaction

that comprises the sub-process or process modeled.

Are-included-in BPMsO.ConnectingObject-SOMsO.Interaction

The connecting objects in a business process are shown in the flow of the services interaction that comprises the sub-process or process modeled.

Corresponds-to BPMsO.Message-

SOMsO.Message

Messages in a business process determines in the service oriented model which are the needed

messages for services to exchange for their realization

Corresponds-to BPMsO.Orchestration-SOMsO.Orchestration

A business process model of type orchestration determines that the service oriented model will also be an orchestration of the associated services

Corresponds-to BPMsO.Choreography-

SOMsO.Choreography

A business process model of type choreography determines that the service oriented model will also

be a choreography of the associated services between the identified participants

Figure 1 shows the elements defined to describe business process at the top, the elements defined to describe services at the bottom, and how the different elements are related to each other. The defined relationships are described in Table IX,

where, for example, it can be seen that there is a correspondence between a pool in a business process model and a participant in a service oriented model, how the flow of sub-processes can be represented by interaction diagrams

422

including gateways and connecting objects, how the needed messages for services to interact can be obtained from messages defined in the business process model, and how the type of services composition (orchestration, choreography) is determined by the type of business process model and their participants. These relationships are defined accordingly to other dimensions of MINERVA, as the methodology for service oriented development from business processes [26] that defines the description of sub-process by means of UML interaction diagrams. Based on the concepts and relationships defined in the modeling sub-ontologies and the methodology for services development, we are able to define transformations between business processes to service oriented models.

V. CONCLUSIONS AND FUTURE WORK

The support of business processes implementation by services have increased in last years, as organizations are paying more attention to the management of their business processes and the technological support that better suits their needs. The advent of SOA standards, tools and ways to implement SOA systems, has also brought conflicts and misunderstandings that are preventing organizations to obtain the promised results. As it was presented here, the concepts around the service oriented paradigm are not totally agreed between different standards, also difficulting it adoption.

This article has presented an analysis between the most relevant standards for service oriented development, evaluating and comparing the definitions provided by each one. Based on this evaluation and in our own definitions, an ontology to support the service oriented modeling has been defined. To support the service definition from business processes, an ontology for business process modeling was also defined, based on the de facto standards for business process modeling: BPDM and BPMN, and clarifying the relationships between the elements defined to model both business process and services. We believe that this ontology contributes to the understanding of elements that have to be taken into account if we want to support the adoption of the service oriented paradigm to implement business processes in organizations.

The definition of these sub-ontologies is part of a larger work that comprises the definition of MINERVA framework to support the continuous business process improvement applying the SOC and MDD paradigms. Based on the defined sub-ontologies and their relationships, the models and metamodels used in other dimensions of MINERVA provide the basis for defining automatic transformations between a business process model specified in BPMN to obtain a service oriented model specified in SoaML using QVT [27], as much as possible. The definition of these transformations is part of our current and future work to incorporate them into the service development methodology defined in MINERVA.

ACKNOWLEDGMENT

This work has been partially funded by the Agencia Nacional de Investigación e Innovación (ANII) from Uruguay, ALTAMIRA project (Junta de Comunidades de Castilla-La Mancha, Fondo Social Europeo, PII2I09-0106-2463) and PEGASO/MAGO project (Ministerio de Ciencia e Innovación

MICINN and Fondo Europeo de Desarrollo Regional FEDER, TIN2009-13718-C02-01).

REFERENCES

[1] Business Process Management Initiative, <http://www.bpmi.org/>

[2] H. Smith, P. Fingar, “Business Process Management: The third wave”, Meghan-Kieffer, 2003

[3] M. Papazoglou, P. Traverso, S. Dustdar, F. Leymann, “Service-Oriented Computing: State of the Art and Research Challenge”, IEEE Computer Society, 2007

[4] D. Krafzig, K. Banke, D. Slama, “Enterprise SOA Service Oriented Architecture: Best Practices”, Prentice Hall, 2005

[5] T. Erl, “Service Oriented Architecture: Concepts, Technology, and Design”, Prentice Hall, 2005

[6] S. Mellor, A. Clark, T. Futagami, “Model Driven Development”, Guest editors introduction, IEEE Computer Society, September/October 2003.

[7] T. Stahl, M. Volter, et. al, “Model-Driven Software Development, Technology, Engineering, Management” John Wiley & Sons, Ltd., 2006

[8] Model Driven Architecture (MDA) version 1.0.1, OMG, junio 2003 <http://www.omg.org/mda/>

[9] A. Delgado, F. Ruiz, I. García - Rodríguez de Guzmán, M. Piattini, MINERVA: Model drIveN and sErvice oRiented framework for the continuous business processes improVement & relAted tools, In: 5th International Workshop on Engineering Service-Oriented Applications (WESOA 09), Stockholm, Sweden, November 2009.

[10] M. Weske, “Business Process Management Concepts, Languages, Architectures”, Springer, 2007

[11] T.R. Gruber, “A translation approach to portable ontology specifications”, Knowledge Acquisition, 5(2), 1993.

[12] T.R. Gruber, “Ontology Encyclopedia of Database Systems”, Springer-Verlag, 2007

[13] SOA Modeling Language (SoaML),versión1.8Beta1,april 2009, OMG, http://www.omg.org/spec/SoaML/1.0/Beta1/

[14] Object Management Group (OMG), http://www.omg.org/

[15] SOA Reference Model, OASIS, http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf

[16] SOA Reference Architecture, OASIS, http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.pdf

[17] Organization for Advancement of Structured Information Standards (OASIS), http://www.oasis-open.org/

[18] Soa Ontology, Open Group, http://www.opengroup.org/projects/soa-ontology/

[19] Open Group, http://www.opengroup.org/

[20] Web Services Architecture (WSA), W3C, http://www.w3.org/TR/ws-arch/

[21] World Wide Web Consortium (W3C), http://www.w3.org/

[22] Web Service Modeling Ontology (WSMO), W3C, http://www. w3.org/Submission/WSMO/

[23] Business Process Definition Metamodel (BPDM), versión 1.0, OMG, http://www.omg.org/spec/BPDM/1.0/

[24] Business Process Modeling Notation (BPMN) versión 1.2, OMG, http://www.omg.org/spec/BPMN/1.2

[25] IEEE std. 1471-2000, IEEE Recommended Practice for Architectural Description of Software Intensive System, 2000.

[26] A., Delgado, F. Ruiz, I. García - Rodríguez de Guzmán, M. Piattini, “Towards a Service-Oriented and Model-Driven framework with business processes as first-class citizens”, In: 2nd International Conference on Business Process and Services Computing (BPSC 09), Leipzig, Germany, March 2009.

[27] Query/Views/Transformations (QVT) v.1.0, OMG, 2008, http://www. omg. org/spec/QVT/1.0/>

423