Planned and Customisable Service-Oriented Architectures provide… · Web viewATHENA Project No 507849 ATHENA – Project Name Planned and Customisable Service-Oriented Architectures

Programme

Integrating and Strengthening the European ResearchStrategic Objective

Networked businesses and governmentsIntegrated Project / Programme Title

Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application

Acronym

ATHENAProject No

507849ATHENA – Project Name

Planned and Customisable Service-Oriented ArchitecturesATHENA – Project No

Deliverable Number:

Model and Specification ofService Descriptions and Usageas well as Advanced Concepts

Work Package – A5.2Leading Partner: SINTEF & DFKI

Security Classification: Project Participants (PP)

August 25th, 2005

Version 1.1

IP- Project ATHENA IP- Project - No 507849ATHENA - Project Planned and Customisable Service-Oriented Architectures ATHENA - Project Number A5Document Deliverable D.A5.2 Date 18.05.23

Versioning and contribution historyVersion Description Comments

0.10 Initial version based on ACE-GIS results. [SINTEF] May 19th, 2004

0.20 Restructured and updated version. Added sections on ontologies and QoS. [SINTEF]

September 29th, 2004

0.30 Added new annex about service specification. Formatting and feedback on structure. [SINTEF]

November 22nd, 2004

0.40 Revised version after internal review in Saarbruecken. Moved parts of the document contents to separate annexes. [SINTEF]

December 9th, 2004

0.50 New structure. Revised version with SOA and Web service additions [SINTEF]. New section on FIPA [DFKI]. Updated section on QoS [ESI].

February 24th, 2005

0.55 Updated SOA and Web service descriptions [SAP]. Updated descriptions on ontology support for Web services [FORMULA].

March 29th, 2005

0.60 Migration of WD.A5.3 to first version of D.A5.2. Some structural changes. [SINTEF]

May 9th, 2005

0.70 First consolidated version. [SINTEF] June 6th, 2005

0.80 Updated the sections on introduction, specification framework and conclusions [SAP, SINTEF]. Added section on e-contracts [SAP]. Added section on agents and Web services [DFKI]. Updated sections on semantic annotation of Web services [FORMULA].

July 5th, 2005

0.90 Updated section on WS composition. Updated introduction and conclusion [DFKI] Added conclusion on Semantic Annotation [FORMULA]. Added section on mapping FIPA <-> SOAP messages [DFKI].

July 8th, 2005

1.00 Updated taking into account comments by reviewers July 22nd, 2005

1.10 Final revision which incorporates Rainer Ruggaber’s (TC delegate) comments. Minor formatting issues.[SINTEF]

August 25th, 2005

List of contributorsNo Partner name Contributors (alphabetical order by surname)1 SAP Julien Vayssière

6 DFKI Klaus Fischer, Esteban León Soto, Ingo Zinnikus (editor)

8 ESI Leire Bastida, Gorka Benguria

9 FORMULA Lorenzo Pondrelli

15 SINTEF Arne-Jørgen Berre, Brian Elvesæter (editor)

document.doc CONFIDENTIAL Page ii / 216


Deliverable process schedule

No Process step Responsible Timing Comments

1

Initial planning of process including identification of individual contributors and peers. Detailed planning of timeline.

Owner -

2

Initial drafting of the Deliverable including structure, comments and first basic content to be sent to to-be-contributors.

Owner 09.052005

Absolute latest would leave only 4 days for contribution – only possible if subject / content sufficiently discussed prior to start Deliverable creation process

3

First round of contributions. Work package member and others to contribute first iteration to owner of the Deliverable

All WP contributors

31.052005

Four days for reply is minimum (see above)

4Owner to consolidate first round input and distribute to contributors

Owner 05.062005

At this step internal peers and AL needs to be involved/copied:

5 Final round of contributions to be sent to owner

All WP contributors

17.062005

Watch for timely responses in order not to delay the document at this stage.

6

Final consolidation of input and finalisation of “technical” document to be send to Quality check

Owner 08.072005 Ensure proper formatting of document.

7 Quality check – e.g. Peer Review

Quality assurance by selected peers

11.072005

Quality assurance by “internal peers” including cross reading by ATHENA external but partner company internal peers particularly in the beginning of the programme:Internal peers:Francesco Taglino, IASI-CNR.External peers:Marlon Dumas, which is a senior lecturer at Queensland University of Technology (QUT), and works closely with SAP Research in Brisbane.

8 Final editing Programme office

22.072005

Final editing particularly formatting and if necessary (particularly with important Deliverables) English mother tongue proofreading

9Final Approval from PCC Delegate and one member of the Technology Council

PCC Delegate and TC member

15.082005

Formal approval (Note: this is not another revision of the content of the document. As it is distributed in pdf-format, comments will be external to the document. Any substantive comments lead to a rejection of the document)PCC Delegate – Michele Missikoff (IASI-CNR)TC Member – Rainer Ruggaber (SAP)

10 Submission to Commission Programme Committee

31.082005 Final stage of process.

document.doc CONFIDENTIAL Page iii / 216


Table of contentsObjectives of the document.................................................................................................................1

Sources of the document.....................................................................................................................2

Executive summary.............................................................................................................................. 3

1 PART I: Introduction.......................................................................................................................41.1 Motivation and background..........................................................................................................41.2 Model-based specification framework..........................................................................................41.3 The structure of this report...........................................................................................................6

2 Service-oriented architectures, Web services and agents.........................................................72.1 What is a service-oriented architecture (SOA)?...........................................................................72.1.1 Service-oriented model.........................................................................................................72.1.2 Benefits of service-orientation...............................................................................................72.2 What is a Web service?................................................................................................................82.3 Agents and service-oriented architectures...................................................................................9

3 PART II: Specification framework for Web services..................................................................103.1 Introduction................................................................................................................................ 103.2 Web services models and metamodels......................................................................................103.3 ATHENA UML profile for Web services......................................................................................103.4 ATHENA baseline methodology for SOA...................................................................................113.5 ATHENA Integrated execution infrastructure.............................................................................12

4 Web service descriptions............................................................................................................144.1 Introduction................................................................................................................................ 144.2 WSDL......................................................................................................................................... 144.3 Representing WSDL using extended UML.................................................................................154.4 Representing Web services as a platform-independent model..................................................15

5 Web service compositions..........................................................................................................175.1 Introduction................................................................................................................................ 175.2 WS-BPEL................................................................................................................................... 175.3 ACE-GIS Web service composition in UML...............................................................................175.3.1 Example.............................................................................................................................. 185.4 BDI-agent based Web service composition................................................................................205.5 Web service composition using AI planning techniques.............................................................20

6 Semantic annotation of Web services........................................................................................236.1 Introduction................................................................................................................................ 236.2 Adding semantic support to the ACE-GIS models......................................................................236.2.1 Example: OWL information in UML.....................................................................................236.3 Related work: Ontologies in model-driven development............................................................256.4 Different ways to add semantics to Web services......................................................................266.4.1 WSDL-S.............................................................................................................................. 266.4.2 OWL-S................................................................................................................................ 266.5 Extending the ACE-GIS profile (ACE-GIS+)...............................................................................266.5.1 A simple example based on a theoretical CPD scenario.....................................................266.5.2 Representing description parameters.................................................................................276.5.3 Using the SINTEF UMT-QVT tool for the transformation....................................................28

document.doc CONFIDENTIAL Page iv / 216


6.5.4 ACE-GIS+ conversion rules................................................................................................32

7 QoS support for Web services....................................................................................................357.1 Introduction................................................................................................................................ 357.2 A methodology for integration of QoS based on aggregation.....................................................357.3 Web service composition modelling with QoS............................................................................367.3.1 UML modelling of QoS characteristics................................................................................367.3.2 UML modelling of QoS requirements..................................................................................367.3.3 UML modelling of QoS offered............................................................................................367.3.4 Example: QoS in the gas dispersion case...........................................................................367.4 Quality of service (QoS) and Web services................................................................................387.4.1 Quality criteria..................................................................................................................... 387.4.2 Non-functional requirements for Web services....................................................................397.4.3 Non-functional requirements for Web services provider......................................................42

8 E-contracts.................................................................................................................................... 458.1 Introduction................................................................................................................................ 458.2 What is an e-contract................................................................................................................. 458.3 Design-time model of e-contracts...............................................................................................458.4 Run-time model of e-contracts...................................................................................................468.5 Modelling the e-contract document............................................................................................47

9 Part III: Agents and Web services...............................................................................................499.1 Introduction................................................................................................................................ 499.2 Concepts.................................................................................................................................... 499.2.1 A weak notion of agency.....................................................................................................499.2.2 A strong notion of agency....................................................................................................499.2.3 Speech-act-based communication and protocols................................................................509.2.4 Agents and services: A comparison....................................................................................519.3 Architecture................................................................................................................................ 529.3.1 WS gateway........................................................................................................................ 529.3.2 BDI agent framework for Web services...............................................................................539.4 Conclusion................................................................................................................................. 56

10 FIPA infrastructure....................................................................................................................... 5710.1 Agent directory services.............................................................................................................5710.2 Message transport service and agent communication...............................................................5810.2.1 Message structure...............................................................................................................5810.2.2 Message transport..............................................................................................................5810.2.3 Interoperability..................................................................................................................... 5910.3 Architectural elements................................................................................................................5910.3.1 Agent................................................................................................................................... 5910.3.2 Services.............................................................................................................................. 5910.3.3 Agent communication language..........................................................................................5910.3.4 Content language................................................................................................................5910.3.5 Ontology.............................................................................................................................. 5910.4 Agent management reference model.........................................................................................6010.5 Mapping FIPA to WS-Addressing: A Proposal...........................................................................6010.5.1 FIPA agent communication specification.............................................................................6110.5.2 WS-Addressing................................................................................................................... 6210.5.3 FIPA conversation protocols realization using Web services..............................................6210.5.4 Envelope structure conceptual mapping.............................................................................6310.5.5 Comparison to other approaches........................................................................................6610.5.6 Conclusion.......................................................................................................................... 66

document.doc CONFIDENTIAL Page v / 216


11 PART IV: Conclusions.................................................................................................................. 6711.1 Web service models and metamodels........................................................................................6711.1.1 Web service compositions...................................................................................................6711.1.2 Semantic annotation of Web services.................................................................................6711.1.3 QoS support for Web services............................................................................................6811.1.4 E-contracts.......................................................................................................................... 6811.2 Agents and Web services...........................................................................................................6811.2.1 FIPA infrastructure..............................................................................................................6811.3 UML profile for Web services.....................................................................................................6811.4 Baseline methodology for Web services....................................................................................69

12 References..................................................................................................................................... 70

13 Annex 1...................................................................................................................................... 7414 Annex 2................................................................................................................................... 10915 Annex 3................................................................................................................................... 169

document.doc CONFIDENTIAL Page vi / 216


Table of figuresFigure 1......Overview of the ATHENA model-based specification framework for Web services...........5Figure 2......Report overview................................................................................................................. 6Figure 3......Service model.................................................................................................................... 7Figure 4......Full methodology overview...............................................................................................12Figure 5......Focus of methodology in A5.............................................................................................12Figure 6......Reference architecture for the integrated execution infrastructure...................................13Figure 7......WSDL 1.1 metamodel......................................................................................................14Figure 8......Example of a specific model for WSDL............................................................................15Figure 9......A Web service interface model.........................................................................................17Figure 10.. . .A preliminary composition................................................................................................18Figure 11.. . .UML model generated from WSDL..................................................................................18Figure 12.. . .Complete composition......................................................................................................19Figure 13.. . .OWL information in UML..................................................................................................24Figure 14.. . .OWL document................................................................................................................24Figure 15.. . .UML ontology profile........................................................................................................25Figure 16.. . .UML class diagram using ACE-GIS+ profile....................................................................27Figure 17.. . .Poseidon note properties window....................................................................................28Figure 18.. . .Poseidon note tag values window....................................................................................28Figure 19.. . .Add a new transformation in UMT-QVT tool.....................................................................29Figure 20.. . .Add transformation window in UMT-QVT tool..................................................................29Figure 21.. . .The results of the OWL-S transformation.........................................................................30Figure 22.. . .Method overview..............................................................................................................35Figure 23.. . .Web service composition model with QoS requirements.................................................37Figure 24.. . .QoS characteristics..........................................................................................................37Figure 25.. . .QoS offered for the service composition..........................................................................38Figure 26.. . .Design-time model of e-contracts.....................................................................................46Figure 27.. . .Runtime model of e-contracts..........................................................................................47Figure 28.. . .Model of an e-contract document.....................................................................................48Figure 29.. . .FIPA contract net interaction protocol..............................................................................51Figure 30.. . .Functional overview of the WSIGS architecture entities...................................................53Figure 31.. . .Extended JACK agent framework for Web service composition and execution...............55Figure 32.. . .A message becomes a transport message......................................................................58Figure 33.. . .Agent platform reference model.......................................................................................60Figure 34.. . .FIPA communication specification stack..........................................................................61Figure 35.. . .Realization of the FIPA communication stack using WS-Addressing as a grounding......63Figure 36.. . .FIPA – WS-Addressing concept mapping........................................................................64Figure 37.. . .Transformation example for both directions.....................................................................65

document.doc CONFIDENTIAL Page vii / 216


Objectives of the document

This document collects and presents the results from work package A5.2 “Models and Specifications for Service Descriptions (Functional and Non-Functional), Registry, Discovery and Usage” having the following general objectives [4]: “Define models and their associated specifications, applicable for the representation of service

descriptions, involving both functional and non-functional elements. Service registries will also be investigated for the collection and effective discovery of services

utilising functional and non-functional elements. Usage frameworks will be investigated and specified for a service-oriented environment that

focuses upon the planning and customisation of solutions.”These objectives are to be achieved in the general framework of Project A5 “Planned and

customizable Service-Oriented Architectures”, which has the following goals [4]: “To develop modelling and specification systems that accurately express services and service-

oriented architectures and particularly assist in the planning of solutions and the marking of intended customisations for the better deployment of a solution into a wide range of client environments;

To develop technologies that enable the easier composition of services and the brokering, mediation and ultimately the negotiation of pre-specified but customisable services;

To develop an execution framework for planned and customisable service-oriented architectures utilising user scenarios from the ATHENA community processes (Activity B4); and

To evaluate the developed technologies and execution framework in proto-typical implementations.”

document.doc CONFIDENTIAL Page 1 / 216


Sources of the document

Within ATHENA the following sources have influenced this deliverable (including the annexes): A5: Planned and customizable Service-Oriented Architectures

o ATHENA A5, "WD.A5.1: Perspectives in Service-Oriented Architectures and there Application in Environments that Require Solutions to be Planned and Customisable", ATHENA IP, Working document, 2005. [5]

o ATHENA A5, "WD.A5.2: Technical architecture and implementation of services and their concepts", ATHENA IP, Working document, 2005. [6]

o ATHENA A5, "WD.A5.3: Model of service descriptions and service usage", ATHENA IP, Working document, 2005. [7]

A6: Model-driven and Adaptive Interoperability Architectureso ATHENA A6, "D.A6.1: Specification of a Basic Architecture Reference Model", ATHENA IP,

Deliverable D.A6.1, 2005. [8]o ATHENA A6, "WD.A6.2.1: Enhanced Registry/Repository Infrastructure", ATHENA IP, Working

document WD.A6.2.1, 2005. [9]o ATHENA A6, "WD.A6.5.1: Model driven interoperability infrastructure", ATHENA IP, Working

document WD.A6.5.1, 2005.



Executive summary

This report introduces the ATHENA model-based specification framework for Web services. The framework aims at providing developers with guidelines on how to use the Web service specifications in a consistent way and defines a set of models to be developed in the specification of interoperable Web service solutions. The models prescribed by the framework relate to both design-time models of interoperable Web service solutions and to run-time models to be deployed on the ATHENA integrated execution infrastructure.

The ATHENA model-based specification framework for Web services consist of three main parts: A set of models and metamodels describing how interoperable Web services should be specified.

The framework covers models related to: Web service descriptions, Web service compositions, Web service addressing, Web service security, Web service registry, semantic annotation of Web services, quality of service (QoS) support for Web services, e-contracts, as well as how agent concepts apply and can be used for designing Web services. The specification models must be compliant with the ATHENA Web services metamodel/profile which defines a set of non-proprietary Web service specifications as formalized metamodels in MOF (Meta Object Facility). The definition of precise metamodels will ensure that modelling tools and execution frameworks will become more interoperable. Moreover, it enables support for model transformations according to Model Driven Architecture (MDA) approaches where transformations between models are defined on the metamodels level.

The specification models can be represented in UML using the ATHENA UML profile for Web services. A UML profile is an extension of the UML metamodel that represents a level of abstraction between the model and the implementation environment. A UML profile uses UML model elements that have been customized for a specific domain or purpose using extension mechanisms as stereotypes, tagged values and constraints. The UML profile supports the process from an idea to a Web services system and allows the analyst and the developer to work in an organised way.

In addition we have the ATHENA baseline methodology for SOA (Service Oriented Architectures) which provides guidelines for developing platform-independent SOA models (as defined in A6) and Web service specific models (as defined in A5) and how to map between these. In line with model-driven development principles, we use models to describe business concerns, user requirements, activities, information structures, components and component interactions. These models govern the system development in that they can be transformed to program code. ATHENA aims to develop tools to automate model transformations for providing specifications for the Web service platform and for composition support.



1 PART I: Introduction

1.1 Motivation and backgroundWhen it comes to choosing a technical platform for enacting a service-oriented architecture, a

wealth of technical options is at our disposal. The A5 project ended up choosing the Web services platform over other solutions such as ebXML [10] and CORBA. The reasons for that choices are explained in greater details in the state of the art document WD.A5.1 [5]. We will however give a summary of these reasons here.

When one looks at the differences between recent technologies geared at service-oriented platforms, such as Web services or ebXML, and previous-generation distributed objects technologies, such as CORBA or Java RMI, one may ask if the plethora of new technology is not indeed a reformulation of previous-generation technology using the XML language and the infrastructure of the World Wide Web. However, major differences exist in the underlying assumptions that architects make when designing service-oriented architectures.

The notion of explicit boundaries in distributed computing is probably the major conceptual breakthrough delivered by efforts such as ebXML and Web services. When companies want to do business together, many different types of boundaries may come in the way: administrative company boundaries of course, but also network boundaries or legal boundaries, such as that introduced by privacy regulations for example.

Many of the middleware platforms of the previous generation did not take the notion of boundary directly into account. The motto of the time was actually quite the reverse: programming at the scale of the network had to be as easy as programming at the scale of a single computer, and as a consequence distributed programming did not need to know any boundaries. Of course, boundaries eventually have to be crossed at execution time, a process which was often handled in a very ad-hoc manner and resulted in brittle and inefficient distributed software architectures.

Because the main focus of ATHENA is to provide interoperability between enterprises, we could not go for a technology that did not incorporate explicit enterprise boundaries in its conceptual model. When we looked at the product offerings and product roadmaps, we realized that the enterprise software industry was strongly leaning towards Web services. This is not to say that ebXML does not have its own technical merits. Quite the opposite, in many respects ebXML is a more mature technology than Web services, and has already achieved strong adoption in some very localized portions of the market.

Another argument in favour of Web services was that Web services only cover one layer of the technology stack necessary for building, deploying and running enterprise applications. It may sound odd to bring up this fact as an argument, but in the context of a research and development project such as ATHENA, the use of the Web services stack provided us with a lot more extensibility points on which to develop innovative approaches for interoperability than what was possible with ebXML.

In quite a sharp contrast with ebXML, the world of Web services is far from being one coherent set of interrelated specifications. The different specifications that make up the so-called WS-* stack arose out of a combination of loosely-coordinated ad-hoc industry efforts, regular standardization processes such as that of the W3C [11] or OASIS [12], and vendors competing by pushing for “their” specification to become a de-facto standard.

The total number of WS-* specifications proposed at some point or another in time is not far from a hundred. Some of these specifications have been superseded, abandoned or merged together since then, while others are still in the process of getting finalised. It will probably take a few more years for all parties to agree on a common set of specification. In the meantime, we have to do with a WS-* landscape that is a combination of mature and accepted specifications, such as XML, SOAP and WSDL, nearly-there specifications, such as WS-Addressing and WS-Security, and still-immature specifications, such as WS-ReliableMessaging.

1.2 Model-based specification frameworkThis report introduces the ATHENA model-based specification framework for Web services. The

framework aims to provide developers with guidelines on how to use the Web service specifications in a consistent way and defines a set of models to be developed in the specification of interoperable Web service solutions.



Figure 1. Overview of the ATHENA model-based specification framework for Web servicesFigure 1 depicts a class diagram that gives an overview of the main components of the

specification framework and how these components relate to each other. The four dashed boxes illustrate how the different parts of this deliverable (main document and annex 1-3) focus on different components of the framework.

The specification framework consists of three main parts: A set of models and metamodels1 describing how interoperable Web services should be

specified. The framework covers Web service models related to: Web service descriptions, Web service compositions, Web service addressing, Web service security, Web service registry, semantic annotation of Web services, quality of service (QoS) support for Web services, e-contracts, as well as how agent concepts apply and can be used for designing Web services. The specification models must be compliant with the ATHENA Web services metamodel/profile2 which defines a set of non-proprietary Web service specifications as formalized metamodels in MOF (WS-* metamodels).

The Web service specification models can be represented in UML using the ATHENA UML profile3 for Web services. One specification model may apply several WS-* UML extensions. The UML profile for Web services maps the concepts defined in the metamodels to UML elements, so that the specification models in question can be developed as UML models. (We could also envision support for other modelling language formalisms besides UML.)

In addition we have the ATHENA baseline methodology for SOA which provides guidelines for developing platform-independent SOA models (as defined in A6) and Web service specific models (as defined in A5) and how to map between these. (In Figure 1 we have only shown the scope of A5.)

1 In this deliverable we consider the set of Web service models and Web service metamodels to be one main part of the specification framework.2 The term Web services profile is used to designate a set of non-proprietary Web service standards and protocols.3 The term UML profile is used to designate a set of UML extensions for developing Web service specifications.



1.3 The structure of this reportThis report is structured in four parts, and contains three technical annexes:

Part I consists of chapter 1 and 2. Chapter 1 describes the purpose and structure of this report. Chapter 2 gives an introduction to service-oriented architecture (SOA) and the Web service architecture.

Part II consists of chapter 3 – 8. Chapter 3 gives an overview of the ATHENA model-based specification framework for Web services. Chapter 4 details models for Web service descriptions. Chapter 5 details models for Web service compositions. Chapter 6 discusses semantic annotation of Web services. Chapter 7 discusses quality of service (QoS) support for Web services. Chapter 8 introduces e-contracts.

Part III consists of chapters 9 – 10. Chapter 9 discusses how agent concepts and technologies can be used together with Web services. Chapter 10 describes the FIPA infrastructure and proposes a mapping between FIPA and SOAP messages.

Part IV consists of chapter 11 which concludes the report.The three annexes are:

Annex 1 describes the ATHENA baseline methodology for service-oriented architectures, which specifies the different model artefacts and provides guidelines for how to develop them.

Annex 2 describes the ATHENA Web services metamodel/profile, which provides the technical background for Part II. It covers the most relevant parts of the Web service standards in the context of the A5 project.

Annex 3 describes the ATHENA UML profile for Web services.The structure of this report is presented in Figure 2 which also serves as a reader’s guide to the

different parts of this report.

AnnexesPart I1. Introduction

2. SOA, Web services and agents

Part II

Part IV10. Conclusions

A1. Baseline methodology forservice-orientedarchitectures

A2. Web servicesmetamodel/profile

A3. UML profile forWeb services

3. Specification framework for Web services

4. Web service descriptions

6. Semantic annotation 7. QoS support

Part III9. Agents and Web services

10. FIPA infrastructure

5. Web service compositions

8. E-contracts

Figure 2. Report overview



2 Service-oriented architectures, Web services and agents

2.1 What is a service-oriented architecture (SOA)?According to W3C, a service-oriented architecture (SOA) specifies a set of components whose

interfaces can be described, published, discovered and invoked over a network. SOA aims to promote software development in a way that leverages the construction of dynamic systems which can easily adapt to volatile environments and be easily maintained as well. The decoupling of system constituent parts enables the re-configuration of system components according to the end-user’s needs and the system’s environment. Furthermore, the use of widely accepted standards and protocols that are based on XML and operate above internet standards (HTTP, SMTP, etc) enhances interoperability.

Service-oriented development emerged as an evolution of the component-based development and among its goals is to support the loose coupling of system parts in a far better way than existing component-based technologies. The ramifications of service-oriented development can be observed both at the system and the business level. Having systems composed of services offered by various service providers provides the basis for supporting new business models, such as “virtual organizations”.

2.1.1 Service-oriented modelA common service-oriented model contains three roles service provider, service requester and

service broker supporting the basic activities publish/unpublish/update, discover and invoke/bind. These roles and basic activities are illustrated in Figure 3. It should be noted that in many scenarios the distinction between these roles may be blurred since an entity can play multiple roles, and roles can be interchangeable within the same scenario.

Invoke/Bind

Service Provider

Service Broker Service Requester

Publish, Unpublish, Update

Discover

Figure 3. Service model Service provider: A service provider is the party that provides software applications for specific

needs as services. Service providers publish, unpublish and update their services so that they are available on the Internet. From a business perspective, this is the owner of the service. From an architectural perspective, this is the platform that holds the implementation of the service.

Service requester: A requester is the party that has a need that can be fulfilled by a service available on the Internet. From a business perspective, this is the business that requires certain function to be fulfilled. From an architectural perspective, this is the application that is looking for and invoking a service. A requester could be a human user accessing the service through a desktop or a wireless browser; it could be an application program; or it could be another service. A requester finds the required services via a service broker and binds to services via the service provider.

Service broker: A service broker provides a searchable repository of service descriptions where service providers publish their services and service requesters find services and obtain binding information for these services. It is like telephone yellow pages. Examples of service brokers are UDDI (Universal Description, Discovery, and Integration) and XMethods. In many cases the role of the service broker is not explicitly needed. Services can be discovered by marketing channels or by referrals (e.g. a service provider referring to another one, or even a service consumer referring a provider to another provider).

2.1.2 Benefits of service-orientationOne might ask why we should focus on services for architecting the enterprise and its ICT support.

What was wrong with object-orientation, component-based development, and business process



engineering? Two of the major benefits are:1) The service concept applies equally well to the business as it does to software applications. Add to

that industry-wide support for Web services standards and for the first time in history, the convergence of the skill sets of the business analyst and the application developer. The analyst is able to specify service interface definitions and business processes, which can be used directly by the application developer as input for the implementation definition. From the point of view of the developer, this approach is sometimes referred to as “the outside-in approach” because it consists in going from the outside representation of a service to its internal representation. The “inside-out approach”, which derives the public interface of a service from its already-existing implementation, is to be avoided since it very often results in polluting the external representation of a service with unnecessary implementation details.

2) Service orientation offers a level of flexibility far exceeding that of component-based development (CBD). A component is built or bought once and integrated into an organisation’s application architecture. Once integrated, the component “disappears” inside the application and becomes “frozen”, i.e. it does not have an existence on its own (cannot be lookup up or accessed directly) and cannot be easily updated. A service is invoked dynamically when required, allowing providers to continuously improve their service and users to select the best available service at any one time. The focus on business processes in business process engineering (BPE) may have given a sense of flexibility, but ICT systems were never process-oriented. A change in the business processes of an organisation could require months to implement in the ERP systems supporting those processes. Other benefits are listed below:

Services reduce complexity by encapsulation: a service may be the aggregation of a number of other services. What is important is the type of behaviour a service provides, not how it is implemented. Encapsulation is key to coping with complexity, flexibility, scalability, and extensibility.

Services provide the ‘units of business’ that represent value propositions within a value chain or within business processes; these services are a natural starting point for flexible outsourcing strategies. This is made possible because services are entirely self-describing and do not rely on any implicit or hidden assumption.

Services promote interoperability by minimizing the requirements for shared understanding: a service description and a protocol of collaboration and negotiation are the only requirements for shared understanding between a service provider and a service user.

Services enable interoperability of legacy applications: By allowing legacy applications to be exposed as services, a service-oriented architecture greatly facilitates a seamless integration between heterogeneous systems. New services can be created and dynamically published and discovered without disrupting the existing environment.

2.2 What is a Web service?The service-oriented model can be seen as a generic model which can be supported by many

different technical platforms. There is a trend towards convergence with respect to all of the different architectures and technologies discussed in this report. Web service technologies such as WSDL and XML are being positioned as the best way of integrating systems implemented using different technologies.

There are many definitions for what constitutes a Web service. In this report we adopt the definition given by the World Wide Web Consortium (W3C) [13]:

“A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.”

Service-oriented architectures can be said to describe an architectural style towards system design. The Web service stack is an enabling technology that supports the design of a service-oriented model. Web services can be designed to adhere to the set of roles and operations specified by the service-oriented model and they have also managed to establish a standardized protocol stack. SOAP, WSDL and UDDI are the most well-known standards used for the execution of the basic set of operations i.e. bind, publish and find.

Web services aim to support enterprise application integration (EAI). They enable the integration



and interoperability of heterogeneous systems and components which may be geographically dispersed.

In practise Web services have been regarded as web interfaces to components. However, Web services are not just interfaces to components. Web services intend to expose higher level business processes whereas components tend to expose lower level business objects and processes. Nevertheless, the level of granularity addressed by each technology is not the only difference among Web services and component technologies such as CORBA, EJBs and COM+.

2.3 Agents and service-oriented architecturesOne of the main common features of Web services and agents is that both offer services and, in

many cases, also consume services. Issues of service-oriented architectures have been already discussed in agent-related research, especially topics such as service publishing, service discovery and service composition. In this report, we will discuss the relation between agents and Web service more closely (chapter 9), present an agent-based framework for Web service composition (section 9.3.2), describe the FIPA abstract infrastructure specification for agent-based service publishing and discovery (chapter 10), and introduce a proposal for a mapping between FIPA and SOAP messages (section 10.5).

An agent is a computational entity such as a software program or a robot that can be viewed as perceiving and acting upon its environment and that is autonomous in that its behaviour at least partially depends on its own experience. As an intelligent entity, an agent operates flexibly and rationally in a variety of environmental circumstances given its perceptual and effectual equipment. Behavioural flexibility and rationality are achieved by an agent on the basis of key processes such as problem solving, planning, decision making, and learning. As an interacting entity, an agent can be affected in its activities by other agents and perhaps by humans.

‘Autonomous’ means that to some extent agents have control over their behaviour and can act without the intervention of humans and other systems. Agents pursue goals or carry out tasks in order to meet their design objectives, and in general these goals and tasks can be supplementary as well as conflicting. ‘Intelligent’ indicates that the agents pursue their goals and execute their tasks such that they optimize some given performance measures. To say that agents are intelligent does not mean that they are omniscient or omnipotent, nor does it mean that they never fail. Rather, it means that they operate flexibly and rationally in a variety of environmental circumstances, given the information they have and their perceptual and effectual capabilities. Agents have available a repertoire of actions that can be executed to modify the environment, which may appear to respond non-deterministically to the execution of these actions. An intelligent agent is capable of flexible autonomous action in order to meet its design objectives, where flexibility means three things [14]: reactivity: intelligent agents are able to perceive their environment, and respond in a timely

fashion to changes that occur in it in order to satisfy their design objectives; pro-activeness: intelligent agents are able to exhibit goal-directed behaviour by taking the

initiative in order to satisfy their design objectives; social ability: intelligent agents are capable of interacting with other agents (and possibly humans)

in order to satisfy their design objectives.These properties characterise a ‘weak’ notion of agency. A stronger notion of agency uses

mentalistic notions, such as knowledge, belief, intention, and obligation [15], e.g. the BDI-agent approach proposed by (see chapter 9). For a survey of agent-related topics within the ATHENA context, see .



3 PART II: Specification framework for Web services

3.1 IntroductionThis section gives an overview of the ATHENA model-based specification framework for Web

services. The framework aims to provide developers with guidelines on how to use the Web service specifications in a consistent way and defines a set of models to be developed in the development of interoperable Web service solutions. The models prescribed by the framework relate to both design-time models of interoperable Web service solutions and to run-time models to be deployed on the ATHENA integrated execution infrastructure described in Annex 4 of deliverable D.A6.1 [16].

3.2 Web services models and metamodelsThe world of Web services is far from being one coherent set of interrelated specifications. The

different specifications that make up the so-called WS-* stack arose out of a combination of loosely-coordinated ad-hoc industry efforts, regular standardization processes such as that of the W3C [11] or OASIS [12], and vendors competing by pushing for “their” specification to become a de-facto standard. The total number of WS-* specifications proposed at some point or another in time is not far from a hundred. Some of these specifications have since then been superseded, abandoned or merged together, while others are still in the process of getting finalised.

Furthermore, because of the different WS-* specifications are being promoted and implemented by different vendors we are today finding some inconsistencies and interoperability issues in WS-* specifications themselves. The Web Service Interoperability Organization (WS-I) [17] has been established to promote consistent use of the WS-* specifications as described in their basic WS profile version 1.1 [18].

In the ATHENA project we have started the work on defining what we call a Web service metamodel or Web service profile for the Web service specifications. The idea is to have the most relevant WS-* specifications formalized as MOF metamodels so that the specifications themselves can be more precisely and consistently related, and moreover to support model transformations according to Model Driven Architecture (MDA) approaches where transformations between models are defined using their metamodels. We believe that such an approach to Web service standardization should in fact be adopted by the standardization bodies. The definition of precise metamodels will ensure that modelling tools and execution frameworks will become more interoperable.

To develop a complete MOF metamodel for the WS-* specifications would be quite time-consuming, so we have focused on some of the most relevant and interesting specifications that we will investigate in the ATHENA project. We have based our selection on criteria such as maturity, adoption, and interoperability coverage of the different WS-* standards. In this work we have also tried to introduce agent concepts and technologies to extend the dynamic capabilities of the WS-* world.

The ATHENA model-based specification framework for Web services specifies models and metamodels for the following: Web service descriptions Web service compositions Web service addressing Web service security Web service registry Semantic annotation of Web services Quality of service (QoS) support for Web services E-contracts Agents and Web services FIPA infrastructure

The models and their corresponding metamodels are described in this report and in Annex [2].

3.3 ATHENA UML profile for Web servicesDue to many necessary interrelated specifications developed for Web services, it becomes a very

difficult task to model the use of these specifications along the different work products built during the development of the software solution. Because of this, a purchaser, a developer or other stakeholder of a Web services product can find hard to develop and build Web services, although the industry has the best intentions of making easier the use of this technology.

There already exists an approach that allows separating the business solution from the platform



specific solution. This approach is called Model Driven Architecture (MDA) [19]. MDA allows us to specify solutions precisely and in a technology-independent manner. It uses several models to go from the business logic to the platform specific solution. The business logic is represented in Platform Independent Model (PIM), that are transformed one or several times to reach the platform-specific solution. This platform-specific solution is represented in a Platform Specific Model (PSM).

Web services can be developed using MDA in order to improve programmer productivity and make services development easier. MDA sets the stage for automatic generation of technical details that the usage of Web services implies, such as WSDL [20] and SOAP [21] proxy, in the PSM. It also makes it easier that services can be retargeted to use others Web services implementation technologies and newer versions of existing ones when required.

Annex [3] describes the ATHENA UML profile for Web services. A UML profile is an extension of UML metamodel that represents a level of abstraction between the model and the implementation environment. A UML profile uses UML model elements that have been customized for a specific domain or purpose using extension mechanisms as stereotypes, tagged values and constraints. The UML profile supports the process from an idea to a Web services system and allows the analyst and the developer to work in organised way.

3.4 ATHENA baseline methodology for SOAThe ATHENA baseline methodology for SOA introduces a model-driven development (MDD)

approach to specifying interoperable service-oriented architectures realized as Web services. In model-driven development are used models to describe business concerns, user requirements, activities, information structures, components and component interactions. These models govern the system development in that they can be transformed to program code. We aim to develop tools to automate model transformations for service-oriented architectures. Hence, the term model-driven development in our context encompasses both the development of models, and tools for model transformation.

The models are expressed in UML, and supported by UML profiles for SOA and Web services. The baseline methodology provides guidelines for how to develop the different kinds of models recommended for SOA. Some of them lay the basis for automated code generation; all of them contribute to the understanding and specification of the system or services to be developed.

Figure 4 illustrates the full methodology, being developed as a joint effort in A6 and A5, which addresses a complete MDD approach supporting multiple execution platforms. The focus in A6 and A5 are on the following models, respectively: The Service-Oriented Architecture Model is a platform independent model (PIM) which

specifies services in a technology independent manner. Here we will describe business services according to a UML profile for SOA being developed in A6.

A Web Service Specification Model is a platform specific model (PSM) which refines a business service in the PIM and specifies it as a Web service using the UML Profile for Web Services. From this model we can generate a concrete Web Service Execution Model that can be deployed on a Web service platform in the Integrated Execution Infrastructure.



SemanticSpace

BusinessModel

RequirementsModel

Service-OrientedArchitecture Model

Web ServiceExecution Model

AgentExecution Model

BPELExecution Model

P2PExecution Model

Web ServiceSpecification Model

Agent SpecificationModel

BPEL SpecificationModel

P2P SpecificationModel

Model Transformation

UML Profile for Web ServicesUML Profile for AgentsUML Profile for BPELUML Profile for P2P

Model Transformation

Architecture Specification

A5 & A6 IntegratedExecution Infrastructure

RegistryRepository

Service Wrappers (Enterprise A)

Evaluation & Negotiation of Available Functionality

Enhanced Service Interconnection Bus

Cross-org.

Intra-org.

Exist ing Enterprise Applications

PublicInfrastructure Services

Service Wrappers(Enterprise X)

Service Wrappers(Enterprise Y)

InternalInfrastructure Services

Process Execution Platform(BPEL)

Goal-or ientedAdaptive ExecutionPlatform(Agents)

Goal-or ientedAdaptive ExecutionPlatform(Agents)

ActiveModel Platform(AKMii)


Legend

Message-OrientedPlatform(MQSeries)


Server-side Component Platform(. NET, J2EE)

Server-side Component Platform(. NET, J2EE)

ComposedWebServicePlatform(WebServices )

Business Process/Agent

Act ive (Business) Model

Web/Server Component

Middlewar e Process/Agent

Middlewar e Component

Adaptive Distributed Resource Mgt Plat form (P2P)

Deployment

UML Profile for SOA• Information• Service• Process• QoS

ReferenceOntology

annotated with

Business & Requirements Analysis

influences

PIM Specification to PSM Specification

SpecificationModel to

Execution Model

ReferenceOntology

ReferenceOntology

annotatedwith

annotatedwith

Figure 4. Full methodology overviewIn A5 we will focus the methodology primarily on the Web service specifications. However we will

also investigate how BDI agents can be used in service composition. We will also integrate with the Business Process Execution Language (WS-BPEL [22]) models being developed in A2. To support this integrated MDD approach we may need to define formal MOF metamodels and corresponding UML profiles for BDI agents and BPEL. Figure 5 focuses on the methodology area that we will investigate further in project A5.

Service-OrientedArchitecture Model

Web ServiceSpecification Model

MessageModel

InterfaceModel

ReferenceOntology

OntologyModel

annotatedwith

InformationModel

ServiceModel

ProcessModel

NFAModel

CompositionModel

Security, QoSModel

WSDLDocument

OWL-SDocument

annotatedwith

annotatedwith ?

?

Web ServiceExecution Model

PIM Specification to PSM Specification

BPELDocument

?

BDIModel

1

1..*

Figure 5. Focus of methodology in A5

3.5 ATHENA Integrated execution infrastructureDevelopment of the ATHENA Integrated Execution Infrastructure (see Figure 6) and

corresponding infrastructure services will be described in more details in deliverable D.A5.3 [23]. The



primary focus of A5 is on the service bus which consists of three main components:1) The service wrappers will provide a standardised way of accessing and using services. A first

version of the service wrapper will be based on Web service technology.2) The evaluation & negotiation of available functionality will evaluate and negotiate incoming service

requests, make use of underlying infrastructure services, and direct requests to the appropriate service deployed on one of the execution platforms (Model Execution Platform, Process Execution Platform, Goal-oriented Adaptive Execution Platform, Active Model Platform, Composed Web Service Platform).

3) The enhanced service interconnection bus provides middleware services for integrating the various execution platforms. The use of P2P technology will enhance the robustness of the service bus.A detailed technical description of the various execution platforms depicted in the integrated

execution infrastructure can be found in Annex 4 of deliverable D.A6.1 [16].

RegistryRepository

Service Wrappers (Enterprise A)

Evaluation & Negotiation of Available Functionality

Enhanced Service Interconnection Bus

Cross-org.

Intra-org.

Existing Enterprise Applications

PublicInfrastructure Services

Service Wrappers(Enterprise X)

Service Wrappers(Enterprise Y)

InternalInfrastructure Services

Process Execution Platform(BPEL)

Goal-orientedAdaptive ExecutionPlatform(Agents)

Goal-orientedAdaptive ExecutionPlatform(Agents)



Legend



Server-side Component Platform(.NET, J2EE)

Server-side Component Platform(.NET, J2EE)

ComposedWebServicePlatform(WebServices)

UML ModelBusiness Process/Agent

Active (Business) Model

Web/Server Component

Middleware Process/Agent

Middleware Component

Adaptive Distributed Resource Mgt Platform (P2P)

ModelExecutionPlatform(UML VM)

ModelExecutionPlatform(UML VM)

Figure 6. Reference architecture for the integrated execution infrastructure



4 Web service descriptions

4.1 IntroductionThe Web Services Description Language (WSDL) [20, 24] is one of the cornerstones of how Web

services are used in the industry today. WSDL provides a convenient way to group together all the different pieces of metadata that together describe a service from both a functional (operations, data types and faults) and a non-functional (specifications supported, policies with respect to non-functional aspects such as security or reliability) view.

4.2 WSDLWSDL 1.1 [20] is used today to describe and publish the public interfaces of Web services. WSDL

is an XML format for describing network services as a set of endpoints operating on messages. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services).

A WSDL document is simply a set of definitions. There is a definitions element at the root, and definitions inside. Services are defined using six major elements: Types, which provides data type definitions used to describe the messages exchanged. Message, which represents an abstract definition of the data being transmitted. A message

consists of logical parts, each of which is associated with a definition within some type system. Port type, which is a set of abstract operations. Each operation refers to an input message and

output messages. Binding, which specifies concrete protocol and data format specifications for the operations and

messages defined by a particular port type. Port, which specifies an address for a binding, thus defining a single communication endpoint. Service, which is used to aggregate a set of related ports.

Figure 7 depicts the WSDL 1.1 metamodel which shows the relationship between these elements. A detailed description of the metamodel is given in Annex [2]. The annex also gives a good insight into the metamodel of WSDL 2.0 [24] which will eventually replace WSDL 1.1.

Port+ Name

Operation+ Name

Part+ Name+ Type+ Element

Service+ Name

Binding+ Name

Port Type+ Name

Message+ Name

Import+ NameSpace+ Location

Include+ Location

Element+ Name+ BaseType+ MinOccurs+ MaxOccurs

Definition+ Name+ TargetNameSpace

Schema+ TargetNameSpace

Types

1..*

1

1..*

0..*

1..*

0..*

11

1

1

0..*

111

0..*+input

0..1

1..*

0..1+output

0..10..1+fault 0..10..1

0..*

0..*

0..*

0..*

0..* 0..*

0..*

0..*0..10..1

Figure 7. WSDL 1.1 metamodel



4.3 Representing WSDL using extended UMLThe specification framework described in this report promotes visual models such as UML to

describe Web services. When modeling Web services in such an approach a WSDL profile is defined with special constructions for the WSDL language. This is done by using the UML extension mechanisms to: define stereotypes for the specific WSDL and XML Schema types such as <<wsdl:portType>>,

<<wsdl:service>> and <<xs:complexType>>. define taggedValues for representing bindings and access URLs.

Examples of proposed UML extensions for WSDL are described in [25] and [26]. Figure 8 shows a WSDL-dependent UML model of the Google service according to the extensions described in [25]. The GoogleSearchService represents the Web service. It contains a GoogleSearchPort with access URL, which in turn refers to the concrete binding represented by GoogleSearchBinding. GoogleSearch-Binding defines the transport protocol to be used with its associated tagged values (binding, style and transport) and realizes the GoogleSearchPortType. The GoogleSearchPortType defines the three available operations. Note that each of these operations has exactly one input parameter and one output parameter that directly reflect the WSDL programming model of sending an input message and receiving an output message as answer. To retrieve the actual details of these messages, it is necessary to look at the <<wsdl:message>> stereotyped classes.

+doSpellingSuggestion( doSpellingSuggestion : doSpellingSuggestion ) : doSpellingSuggestionResponse

+doGetCachedPage( doGetCachedPage : doGetCachedPage ) : doGetCachedPageResponse+doGoogleSearch( doGoogleSearch : doGoogleSearch ) : doGoogleSearchResponse

GoogleSearchPortType<<wsdl:portType>>

{binding=soap:binding,style=rpc,

transport=http://schemas.xmlsoap.org/soap/http}

<<wsdl:binding>>GoogleSearchBinding

GoogleSearchResult<<xs:complexType>>

-directoryCategories : DirectoryCategoryArray

-resultElements : resultElementArray

-estimatedTotalResultsCount : int

-documentFiltering : boolean

-estimateIsExact : boolean

-searchComments : string

-searchTime : double-searchQuery : string

-searchTips : string-startIndex : int

-endIndex : int

{URI=http://api.google.com/search/beta2}

<<wsdl:port>>GoogleSearchPort

ResultElement<<xs:complexType>>

-directoryCategory : DirectoryCategory

-relatedInformationPresent : boolean

-directoryTitle : string

-cachedSize : string

-hostName : string

-summary : string-snippet : string

-URL : string-title : string

-safeSearch : boolean

-maxResults : int

-filter : boolean

-restrict : strict

-key : string

-oe : string

-ie : string

-q : string

-lr : string

-start : int

doGoogleSearch<<wsdl:message>>

doSpellingSuggestionResponse<<wsdl:message>>

-return : string

doGetCachedPageResponse<<wsdl:message>>

-return : base64BinarydoGoogleSearchResponse

<<wsdl:message>>

-return : GoogleSearchResult

-fullViewableName : string-specialEncoding : string

DirectoryCategory<<xs:complexType>>

doSpellingSuggestion<<wsdl:message>>

-phrase : string-key : string

GoogleSearchService<<wsdl:service>>

-key : string-url : string

doGetCachedPage<<wsdl:message>>

-binding1

Figure 8. Example of a specific model for WSDL

4.4 Representing Web services as a platform-independent modelYou could also envision a platform-independent modelling approach that abstracts from the details

of the Web services platform. There are two major advantages of using platform-independent UML models: The same model may be used as a basis for conversion to more than one platform.



The modeller is not disturbed by technical details when designing a conceptual model.Work on defining a platform-independent metamodels for software services is being investigated

in work package A6.5. The baseline methodology described in Annex [1] also discusses this topic.



5 Web service compositions

5.1 IntroductionWeb service composition can encompass a lot of different approaches. The evolution of the WS-*

stack favoured control flow-based approaches such as the use of business process engines for orchestrating service invocations. In the last years, the industry seems to have standardized on WS-BPEL [22] as the specification of choice for describing business processes that feature both humans and services. In addition to WS-BPEL we have also investigated the ACE-GIS Web service composition profile described in [27] and JACK BDI [28] as an agent-oriented approach to service composition. Lastly, service composition can also be done according to the planning from first principle approach.

5.2 WS-BPELThe Business Process Execution Language for Web Services (WS-BPEL4) [22] provides a

language for the formal specification of business processes and business interaction protocols. By doing so, it extends the Web services interaction model and enables it to support business transactions. WS-BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces.

The language covers interoperability through concepts for interaction with partners based on Web services, supporting conversations of process instances with partners, and specifying business protocols through the external behaviour of partners. Partner interaction is based on the notion of peer-to-peer interaction between Web services. WS-BPEL introduces concepts to express the peer-to-peer conversational relationships between services.

The use of WS-BPEL is heavily studied in project A2 and will be supported by process executions platforms as described in [16]. A short description of the WS-BPEL metamodel is given in Annex [2]. The WS-BPEL results from A2 will be integrated into the A5 approach.

5.3 ACE-GIS Web service composition in UMLThis section presents an example of how design-time compositions of Web services can be

expressed in UML according to the ACE-GIS profile [27].The ACE-GIS example is situated around a case where an emergency situation is caused by an

explosion in a chemical factory, with subsequent leakage of poisonous gas. In order to make efficient evacuation plans, the crisis management needs a forecast of the gas plume dispersion. Hence a Web service need to be designed which calculates the plume and displays it on a map. The design and implementation of this service should of course be done before the need arises, supplying the service ready at hand when needed.

First, the modeller has to design the new Web service's interface including its operations' signatures. The UML class diagram in Figure 9 depicts the Web service with the one operation needed in the example. The createGasDispersionMap operation takes a plant ID and an emission rate as input, and returns a raster image depicting the gas plume on a map.

+createGasDispersionMap( plantID : string, emissionRate : float ) : imageMap

GasDispersionWebService

+createGasDispersionMap( plantID : string, emissionRate : float ) : imageMap

GasDispersionWebService

Figure 9. A Web service interface modelThe next thing to do is to sketch the operation's activities in a UML activity model, see Figure 10.

In order to create a gas dispersion map, one first needs to know the location of the factory (Get Plant Location). Then the weather at this location should be found (Get Weather). The next activity is the Calculate Gas Dispersion Plume activity. It takes the gas emission rate, the wind direction and wind strength, and the location of the plant as input and calculates a plume polygon. Finally the Create Gas Dispersion Map portrays the plume polygon on top of a background map and returns the map image.

4 The specification was formerly known as BPEL4WS. WS-BPEL or BPEL for short is now the official abbreviation.



Calculate Gas Dispersion Plume

Create Gas Dispersion Map

Get Plant Location

Get Weather

Calculate Gas Dispersion Plume

Create Gas Dispersion Map

Get Plant Location

Get Weather

Figure 10. A preliminary compositionWith this preliminary activity model in mind, the modeller searches Web service registries for

existing Web services that can perform the operations modelled in by the different activities. Each registered service has a textual presentation, and an associated WDSL specification. On the basis of the textual description, the modeller decides whether the service is a good candidate. If so, he/she extracts its WDSL description to use in the next step. (This ends step 1 of the method.)

When using UML as integration platform, all models have to be expressed in UML. So, the modeller transforms the WDSL descriptions of basic services into UML class models using UMT [29] to inspect their operation names, signatures and message types. An example of a Web service which provides weather information is portrayed in Figure 11. The service is provided by CapeScience and it provides a number of operations. The getWind operation is a candidate for solving the Get Weather activity. Two levels of details are shown in the figure. The AirportWeather class shows the operations with traditional operation signatures. WSDL requires that an operation takes only one input message and returns one output message. Hence the figure shows the input and output messages for the getWind operation, called getWind and getWindResponse. Notice that the semantics of the getWind operation can be difficult to understand. The arg0 input parameter requires a 4 character international airport code.

+getWind( arg0 : string ) : string

+getSkyConditions()

+getTemperature()+getSummary()

+getPressure()

+getHumidity()+getLocation()

+getVisibility()

<<BusinessService>>AirportWeather

getWindResponse+return : string

getWind+arg0 : string

Figure 11. UML model generated from WSDLNow, the modeller can start designing the real composition, doing as follows:

1) For each activity in the activity model select candidate Web services and decide on the basic operation, transfer its name and I/O parameters to a Web service call activity in the activity model. Relevant WDSL information will then appear as stereotypes and tagged values in the activity model, and the input and output messages will appear as data objects. If more than one Web service can perform the operation in an activity this should be modelled as alternative service providers.

2) For the activities where no relevant Web services are found design and implement appropriate operations and establish it either in a new Web service, or as a procedure internal to the composition.

5.3.1 ExampleThe composition modelling may require several iterations, where new activities are identified.

Figure 12 shows the complete activity model, with all I/O and WSDL details added for both existing and new service operations. Some details are removed from the figure. Notice that the final model has several new activities compared to the preliminary model. The first activity now is a Web service call activity which returns the coordinates of the plant based on the plant ID. The Get Nearest Airport activity is new. This because no service was found that could return the weather at an arbitrary location. However a service that gave the weather at airports around the world, given the international airport code as input, was found. Thus we needed an activity that could give us the nearest airport.



Two such services were implemented: one provided by e-blana that gave the nearest airport based on the plant ID, and one provided by Ionicsoft that returned the nearest airport based on the plant's location. The two services are modeled as alternative service providers using the discriminator pattern. Hence the services are invoked in parallel and the first value returned is used in the next activity. Unfortunately the weather service from CapeScience did not return a structured data type, but gave the information in a natural language string. This forced us to implement an activity to parse the weather string information. The final two services were provided by Ionicsoft . A number of data mappings had to be defined so that the different Web services could get the appropriate input.

The final activity model, which is complete with respect to data flow and Web service details, is transformed to an executable specification – an XML document.

{provider=e-blana,wsdl=http://acegis.e-blana.com/PreEmergencyPlanService/PreEmergencyPlanService.asmx?WSDL,

operation=GetPlantLocation,service=PreEmergencyPlanService,

portType=PreEmergencyPlanServiceSoap}

Get Plant Location<<WebServiceCall>>

Get Nearest Airport<<AlternativeServiceProviders>>

: createGasDispersionMapResponsedispersionMap

{domainObject=ParseWindInformation}

<<ImediateStep>>Parse the wind information

{provider=CapeScience,operation=getWind}

<<WebServiceCall>>Get Wind Information

: createGasDispersionMapRequestplume

: GetPlantLocationSoapOutcoordinates

: calculatePlumeResponseplumeLayer

Calculate Gas Dispersion Plume<<WebServiceCall>>

: LeakageInformationleakageDetails

: GetPlantLocationSoapInplantID

: calculatePlumeRequestplumeInfo

Create Gas Dispersion Map<<WebServiceCall>>

: windInformationwindInformation

<<transformation>>plumeGML = calculatePlumeReturn;

<<WebServiceCall>>GetNearestAirportCode

{provider=IONIC}

: getWindResponsewindStr

<<transformation>>emissionRate = emissionRate;

<<WebServiceCall>>LocateNearestAirport

{provider=e-blana}: airportCodeairportCode1

airportCodeInfo: getWind

<<transformation>>windSpeed = speed;windDirection = toDirection;

: point_and_plantIdpp<<transformation>>point.x = xCoordinatepoint.y = yCoordinate

<<transformation>>PlantID = plantID;XCooriate := 0;YCooriate := 0;

<<transformation>>arg0 = icao;

<<transformation>>origin = point;

<<transformation>>plantId = plantID;

Figure 12. Complete compositionThe new service is now ready to be published in an appropriate registry, for the benefit of end

users. Such publication requires a WSDL description of the Web service. Therefore, the modeller completes the service interface model and transforms it automatically to a corresponding WSDL description. After being published, the service may be invoked and run on the execution engine for which it has been configured. The service can finally be made available to Web service consumers.



5.4 BDI-agent based Web service compositionService-oriented architectures have the potential to increase interoperability of ITC applications

significantly. However, business applications ask for planned and customizable services, which basically comes down to the requirement for a methodology to do service composition in a flexible and efficient manner. The flexible combination and usage of services in such a service-oriented environment is a key feature that can obviously be supported by agent technologies. Regarding service composition for an individual agent, we have two extreme options. On the one hand, we can try to adopt a general purpose planner and try to map service descriptions to individual actions which are then composed by the planner. In a naive approach, this will most likely result in a linear sequence of actions, i.e. service calls, that make up the newly composed service. Business Process Modellers are often reluctant when confronted with the idea of choosing services or even processes at run-time. Control of the actual services invoked and the concrete processes performed is preferred over the possibility of an unperceived program decision. On the other hand, we can of course program the composition of services directly in some object-oriented programming language. In this case we are not restricted regarding the structures which we want to use. However, almost every change to a system which adopts such an approach is likely to end-up in painstaking programming sessions.

Composition languages such as e.g. WS-BPEL address some of the problems arising from this approach, but still have limitations regarding flexibility and adaptability (especially during run-time). WS-BPEL does not prevent ways for choosing services at run-time, but a service endpoint discovered at run-time must adhere to e.g. a declared partner link and port type. Fault handlers allow the compensation of failures, but the concrete action to be performed in case of a failure has to be modelled in advance.

A planning from second principles approach which uses a predefined library of plans and instantiates and adapts these plans for the task at hand, when the system is at work, seems to bring together the best of two extreme approaches just described. The plan library can be maintained and incrementally updated and the agent will automatically take advantage of the knowledge which the plan library provides. How complex the plan structures in the plan library can be depends on the language which we use for specifying these plans (plans are covered in detail in , in section 9.3.2 and in forthcoming ATHENA A5 and A6 documents).

BDI agents have a built-in theory of a planning from second principles approach to problems solving. BDI agents seem to be an ideal means for flexible service composition. On the one hand, BDI reasoning offers to the agents a flexible way to use the knowledge that is specified in the plan library of an agent. On the other hand, BDI plans can be expressed with a modelling language which nicely fits into a model driven approach to the specification of how service composition should be achieved. Taking this approach, it is possible to compare BDI models with the models that other approaches use.

We decided to use the JACK Intelligent Agents development environment (JDE [28]) in the ATHENA project for designing agents in the context of a service-oriented architecture. A major advantage of JDE is that it allows using graphical models for the specification of agent behaviours. We consider these models as the Platform Specific Model (PSM) level for agent design. Important to note is that these PSM models are directly executable in the runtime environment of JDE. BDI agents support adaptive execution which is introduced by flexible plan choice, in which the current situation in the environment is taken into account. A BDI agent has the ability to react flexibly to failure in plan execution, where both features are directly built into the framework of BDI reasoning

An overview of the extended JACK agent framework for Web service composition is given in section 9.3.2. The MDA aspects of this approach are discussed and presented in the context of project A6, especially in and forthcoming documents.

5.5 Web service composition using AI planning techniquesA straightforward idea would be to apply a classical Strips-like planner to the problem of Web

service composition. For this scenario to work out, the client must know what messages the service expects and what replies it produces. Because services are detected dynamically, each service must expose its interface information in a formal notation so that agents can know what they expect. One obvious idea is that what the service exposes is a set of primitive actions and canned interaction plans, which the client views as a planning domain. It constructs a plan for interacting with the service, executes it, and then takes stock. If the plan has failed, the client has at least gained some information, which it can use in the next cycle of planning and execution .

The planning problems that will naturally occur are not classical, for the obvious reason that classical-planning domains assume complete information, and many of the actions an agent performs



on the Web are for the purpose of gaining information. However, in one respect the web service problem fits the classical Strips-style paradigm very nicely: actions have preconditions and effects that in many cases are expressible as propositions. That means that it is easy to compute the contribution an action would make toward a goal, i.e., whether it would achieve or undo a piece of it, and what prior condition would be necessary in order for it to have that effect. Given a representation of services as actions, one can exploit AI planning techniques for automatic service composition by treating service composition as a planning problem. Ideally, given a user’s objective and a set of Web services, a planner would find a collection of Web services requests that achieves the objective.

The OWL-S process ontology provides a vocabulary for describing the composition of Web Services. This ontology uses an “action” or “process” metaphor for describing Web service behaviour – that is, primitive and complex actions with preconditions and effects.

In the process ontology, each process has several properties, including, (optional) inputs, preconditions, (conditional) outputs and (conditional) effects. Preconditions specify things that must be true of the world in order for an agent to execute a service. Effects characterize the physical side-effects that execution of a Web service has on the world. Inputs and Outputs correspond to knowledge preconditions and effects. That is, necessary states of our knowledge base before execution and modifications to our knowledge base as a result of the execution. Note that not all services have significant side-effects, in particular, services that are strictly information-providing do not.

A logic-based DAML-S composition planner has been developed at the university of Baltimore . This planner uses STRIPS-style services to compose a plan, given the goal and set of basic services. It is implemented with JESS (Java Expert System Shell), and uses a set of JESS rules to translate DAML-S descriptions of atomic services into planning operations.

HTN (hierarchical task network) planning is especially promising in this context, because the concept of task decomposition in HTN planning is very similar to the concept of composite process decomposition in OWL-S process ontology. HTN planning is an AI planning methodology that creates plans by task decomposition. HTN planners differ from classical AI planners in what they plan for, and how they plan for it. The objective of an HTN planner is to produce a sequence of actions that perform some activity or task. The description of a planning domain includes a set of operators similar to those of classical planning, and also a set of methods, each of which is a prescription for how to decompose a task into subtasks. Planning proceeds by using methods to decompose tasks recursively into smaller and smaller subtasks, until the planner reaches primitive tasks that can be performed directly using the planning operators.

One of the currently most prominent service composition planners is Shop2 (Simple Hierarchical Ordered Planner 2) developed at the university of Maryland . It is a HTN planner well-suited for working with the hierarchically structured OWL-S process model. The authors proved the correspondence between the semantics of Shop2 and situation calculus semantics of the OWL-S process model. The implemented Shop2 soundly and completely plans over sets of OWL-S descriptions, and treats the output of a web service as effects that either change the planning agent’s knowledge, or the world state. Shop2, like HTN planner in general, replaces those elements of the provided methods (workflows) by special methods or atomic actions until the composition plan contains only atomic actions that correspond to available web services. During planning, web services are not executed, hence do not affect the world state.

HTN planners such as SHOP2 perform well in domains for which complete and detailed knowledge on at least partially hierarchically structured action execution patterns is available, such as, for example, in scenarios of rescue planning. In domains in which this is not the case, i.e., no concrete set of methods and decomposition rules are provided, action based planners would be a more appropriate choice.

An alternative approach is OWLS-Xplan . OWLS-Xplan converts OWL-S 1.1 services to problem and domain descriptions specified in the planning domain description language PDDL , and invokes an efficient composition planner Xplan to generate a service composition plan sequence that satisfies a given goal. Xplan extends an action based FastForward-planner with a HTN planning and re-planning component.

After the domain and problem definitions have been parsed, Xplan compiles the information into memory efficient data structures. A connectivity graph is then generated, which contains information about connections between facts and instantiated operators, as well as information about numerical expressions which can be connected to facts. This connectivity graph is maintained during the whole planning process and serves as a kind of efficient lookup table for the actual search. In case of a



replanning situation, the connectivity graph is adjusted according to the changed new world state.Xplan uses an enforced hill-climbing search method to prune the search space during planning,

and a modified version of relaxed graph-planning that allows to use (decomposition) information from hierarchical task networks during the efficient creation of the relaxed planning graph, if required, such as in partially hierarchical domains. Information on the quality of an action (service) is utilized by the local search to decide upon two or more steps that are equally weighted by the used heuristic.

Both Xplan and Shop2 are based on the closed world assumption, use PDDL for problem description, allow external (call-back) functions to be bounded to variables and executed during planning, and generate total ordered, instantiated plan sequences for a given initial state, goal and planning domain.

Among others, the main difference between Shop2 and Xplan is inherent to the individual planning processes. In essence, Shop2 plans are generated by use of given decomposition rules (methods), hence a solution to the planning problem is not always guaranteed to be found. In contrast, hybrid Xplan as part of OWLS-Xplan tries to plan by means of (a) method decomposition using only relevant parts of it, discarding useless actions, thereby reducing the plan size, and (b) if this is not successful, uses its relaxed graph plan algorithm to find a solution if it exists.



6 Semantic annotation of Web services

6.1 IntroductionWeb services, today, orbit around three main elements, WSDL for interface specifications, BPEL

for processes and UDDI registries (and obviously also SOAP as message protocol). WSDL and BPEL do not support semantic description of services and only UDDI version 3 provides a first semantic annotation based on storing and retrieving annotations on a service-by-service basis, so it is not possible to issue a query based purely on semantic annotations without mentioning explicitly which service it relates to. In this context the first necessary step is the understanding of the possible different levels of annotation required to achieve a complete semantic description of Web services. In order to give a complete semantic description it is necessary to consider three different levels of annotation: The first one is related to the business level, regarding non functional aspects and business

descriptions of the service itself, such as information concerning actors involved in the service, quality and so on. This annotation is useful to add a description of the meaning of the service and to specify at business level what a service accomplishes.

A second level of annotation considers the description of the objects and terms that each WSDL document specifies as service interface. Today these terms generate taxonomies related only to the single Web services, but to achieve interoperability it is necessary also to add a common understanding of these concepts in order to share common knowledge among different services.

The last level of semantic description concerns the specification of how a service can be used in a wider context, so how it is possible to integrate different services using composition and choreography. For doing that, annotations related to the scope of each single service, preconditions and effects are necessary elements, in order to allow run-time composition of complex business processes based on services.

It is not necessary to achieve always all these levels of annotation but it is possible to analyse case by case what could be useful. The most important thing is to understand that more accurate the annotation process is and more complete the description of the services will be.

The focus point of this chapter is to identify how it is possible to use modelling languages in order to add semantic support for Web services directly at PIM level, investigating the UML capabilities to describe semantic aspects and ontologies. Starting from these key points and from all the semantic research activities related to Web services, it is possible to identify some possible different contexts.

6.2 Adding semantic support to the ACE-GIS modelsThe UML models developed in ACE-GIS contain semantic and syntactic information. However the

semantics are not modelled explicitly. Precise semantic definitions can be added manually in an OWL file that describes the ontology for many of the syntactic elements in the model, such as the operations input parameter types. The OWL files relate to specific types within the WSDL files. The WSDL files have been generated by the UML models, while the OWL files are coded by hand and at the low-level of XML. It is useful to investigate if UML models are suitable for describing the same information provided in the OWL, but with higher-level graphical models, which are easier to understand. There are two main possibilities: Transforming OWL to UML Transforming UML to OWL

In both these cases it is essential to find out how the OWL information can be captured as UML models. There are two main things that need to be represented, the ontology itself and the references to the ontology concepts from all the types used in the component interface model. The ontology itself can be modelled as a new model with an OWL UML Profile. The component interface model needs to have some additions for registering references to the OWL concepts.

6.2.1 Example: OWL information in UMLIn ACE-GIS the WSDL elements have been extended with an additional attribute, semRef, to

provide a pointer to an ontology element within an Ontology Web Language (OWL) file. The figure below shows a second level annotation using UML for the ACE-GIS Web service Get Nearest Airport Code. The left side shows a package with the OWL classes and the right side shows a Web service interface model. The left side corresponds to one ore more OWL files and the right side corresponds to a WSDL file. Note that it is only a high-level view without going further into the details of how to model the OWL elements and not how to model the semantic references of the part attributes of the data



types, such as SRS, x and y of the Point class.

+g e tN e a re s tA irp o rtC o d e ( p o in t : P o in t ) : g e tN e a re s tA irp o rtC o d e R e s p o n s eG e tN e a re s tA irp o rtC o de

O W L O n to lo g y

<<O n tC la s s >>A irp o rtC o de

<<O n tC la s s >>G M _ P o in t

<<O n tC la s s >>G M _ P rim itive

<<O n tC la s s >>IC A O ge tN e a re s tA irpo rtC o d e R e s p o n s e

G e tN e a re s tA irp o rtC o de S e rvic eP o in t

-S R S : s tr in g

-y : d o u b le-x : d o u b le

s tr ing

- s e m R e f

-s e m R e f

Figure 13. OWL information in UMLThe OWL information represented in Figure 13 corresponds to the simplified OWL XML file

developed by the University of Münster (Figure 14). The different semRef links correspond to a simplified second level annotation.

<rdf:RDF ...> <owl:Ontology rdf:about=""> <owl:imports rdf:resource="http://musil.uni-muenster.de/onto/ACE/D_Met.owl"/> <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">This Application onbtology describes the GetNearestAirportCode Service provided by ionic. It takes a location (GML Point) as input and returns an four letter ICAO airport code (string) as output</rdfs:comment> <owl:imports rdf:resource="http://musil.uni-muenster.de/onto/ACE/D_SpaRep.owl"/> </owl:Ontology> <owl:Class rdf:ID="getNearestAirportCodeReturn"> <rdfs:subClassOf> <owl:Class rdf:ID="Operation"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="SRS"/> <owl:Class rdf:ID="Y"/> <owl:Class rdf:ID="ICAO"> <rdfs:subClassOf> <owl:Class rdf:about="#AirportCode"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="X"/> <owl:Class rdf:ID="Point"> <rdfs:subClassOf rdf:resource="http://musil.uni-muenster.de/onto/ACE/D_SpaRep.owl#GM_Point"/> </owl:Class> <owl:Class rdf:ID="AirportCode"> <rdfs:comment>not in WSDL yet ICAO code is used</rdfs:comment> <rdfs:subClassOf rdf:resource="http://musil.uni-muenster.de/onto/ACE/D_Loc.owl#GeographicIdentifier"/> </owl:Class> </rdf:RDF>

Figure 14. OWL documentThis example shows a simplified way to annotate Web service elements with ontologies. This is a

very important issue because it is the first step needed in order to add semantics to a SOA architecture and for allowing semantic searching, semantic composition and messages reconciliation of services. The ATHENA Action Line A3 should develop a complete framework of tools and best practices to include semantic features in the SOA context but obviously we need to integrate that work following a MDD approach.

In this context we there are two main challenges: Representing ontologies in UML Using these ontologies to add semantics to UML models with the annotation process



6.3 Related work: Ontologies in model-driven development One of the main goals of this chapter is to describe a semantic enhanced Web services

framework and, for doing that, it is needed to bind ontologies and Web services elements, in particular WSDL documents. A second goal is to achieve those results directly at PIM level, using models, in order to maintain a correct level of abstraction. In this context, it is simple to understand that one of the key points is the capability to represent ontologies using UML. This section, in particular, presents some works regarding how UML can be used to capture OWL information.

OMG has proposed a Request for Proposal regarding an Ontology Definition Metamodel (ODM) in order to achieve a final solution for using UML as common language to build ontologies. There is a semantic overlapping between UML and an ODM so it is possible to suppose a complete mapping between them in order to translate UML models directly to ODM models.

UserModel

public class Car {}

MOF

UML Ontology Profile

Ontology DefinitionMetamodel

Car

Realizations

LanguageMapping

<owl:Class rdf:ID=‘Car’/>

Mapping

Figure 15. UML ontology profileDuric presents an UML profile for modelling OWL called Ontology UML Profile (OUP). That

proposal describes how to represent the OWL statements, but does not show how to link this information to UML models, for instance to add references to OWL concepts for each type in WSDL documents using simply relations between WSDL elements and ontology concepts.

A different approach is taken by Rajasekaran et al. proposing WSDL-S, a simple extension of WSDL where the data types are expressed using OWL types from the Rosetta Net Ontology instead of XML Schema.

Gasevic et al. presents transformations among models using an Ontology UML Profile for OWL. Hart et al. compares UML 2.0 and OWL elements in order to identify the relevant common features. This information will be used to specify transformations between UML 2.0 and OWL. The reverse transformation, from OWL to UML 2.0 is not investigated in the article. Zhao et al. discusses the relationship between OWL and OCL and he proposes to use OCL as basis for a new Ontology Query Language (OQL).

In section 6.2.1 the annotation has been described as one of the most important aspects in order to solve integration problems following an MDD approach. Figure 15 shows a simple annotation between an ontology and some Web services, both represented using UML diagrams. Those PIM models could be transformed at PSM level in two different ways. With an embedded annotation process, including annotations directly into the document annotated, as proposed in the WSDL-S work, or with an attached annotation, using external links among resources annotated and annotations. That second method has the benefit to let the PSM level unchanged but it needs a system to manage, discover and use the external annotations. The main benefit of using a model-driven approach for the annotation procedure is to derive a common UML based method for the annotation that can be transformed at PSM level using both embedded and attached techniques at the same time.



6.4 Different ways to add semantics to Web servicesComing back to the three different aspects regarding annotation of Web services (section 6.1),

different methods are found for adding semantic to services. In particular some simple methodologies allow only annotations of the service interfaces (second level annotation), such as WSDL-S, instead of more complex procedures that cover all the three different aspects of annotation, such as OWL-S.

6.4.1 WSDL-SWSDL describes interfaces of Web services, each interface contains a set of operations and each

operation has a common structure which includes an operation name, input, output and exception messages. XML Schema Definition is the language used to specify the objects (Types) exchanged by these messages. In order to ensure more flexibility, in WSDL 2.0, Types are pushed more completely outside the standard, so it is possible to use different languages to define them, such as OWL and XMI. This flexibility creates the necessity of mappings among different specifications. WSDL-S, in particular, has chosen OWL to express input and output parameters using Rosetta Net as common Ontology.

6.4.2 OWL-SAn OWL-S document is composed of three main sections that explain different views in order to

give a complete description of a service, using a semantic language and ontologies to ensure a common computer comprehensive understanding of the information: Service Profile: It is used to describe information regarding organizations that provide the service,

a list of input/output parameters and pre/post conditions used by the description of the process in the Service Model and additional information about the service, including parameters related to the quality and the accuracy.

Service Model: It provides the fundamental information for the composition and interoperation of services.

Service Grounding: It specifies the details of how to access the service, in particular regarding protocol and message formats, serialization, transport, and addressing.

The Profile and the Model are abstract representations of a service and only the Grounding is related to the concrete level of specification. It is possible to suppose to use the structure of OWL-S as starting point to achieve a generic metamodel for describing all the three aspects mentioned before (business aspect annotation, interfaces annotation and service composition annotation).

6.5 Extending the ACE-GIS profile (ACE-GIS+)Following the OWL-S approach for the semantic enrichment of Web services it is easy to

understand that a service needs all the three different types of annotation. In particular, the annotation of the interface content and the annotation of business processes based on services could be done using the ACE-GIS standard for modelling Web services and adding semantic references between the structure of the service, such as methods and input/output parameters, and ontologies. The annotation of business and non functional aspects needs a standard way for adding semantic information related directly to the service components. Annotating the interfaces is more related to the message reconciliation while the semantic description of services permits semantic retrieval and semantic composition of Web services.

OWL-S manages both these different aspects of the services in order to achieve complete descriptions using semantic support. On this base, could be useful to include in the ACE-GIS profile new elements capable to add all these new concepts directly at PIM level. The ACE-GIS can be used to derive directly from the UML artefacts written using that profile, PSM elements such as WSDL documents and BPEL processes. Following this approach it will be possible to derive also OWL-S files starting from the same UML class diagrams, using for example the SINTEF UMT-QVT transformation tool [29]. The next chapters will describe an implementation of that transformation based on a plug-in for the UMT-QVT tool, in order to clarify a complete methodology for building semantic enhanced SOAs.

6.5.1 A simple example based on a theoretical CPD scenarioThe explanation of the ACE-GIS+ semantically enhanced profile and its PSM transformations will

be based on a simple example diagram that describes the implementation of some Web services related to a theoretical ATHENA CPD scenario.



Figure 16. UML class diagram using ACE-GIS+ profileIn this case there is the implementation of two different Web services. The first one is called

LeanSOR (the SOR is a Specification of Requirements document). It is published by the company that produces the finale product (Original Equipment Manufacturer), and realizes one interface, named SORservice, with two methods: GetSORfromPSI() that creates a SOR document from the PSI system (the system that stores all

the information regarding the product in development) with an input parameter which indicates the unique code of a single PSI project. The operation returns a single output parameter of type SOR. The SOR type is not a simple XML Schema type so a new class named SOR and stereotyped <<Concept>> should be defined, in order to explain the new complex type. In this manner it is possible to describe new complex types that will be mapped as also OWL concept using <<semRef>> relations. The new data type contains also a parameter of type SORcontent, so also this type has to be added in the same manner. In a real context, it will be necessary a more complete methodology for describing the schema of the concepts involved in the service, using UML profiles for XML Schema.

SendSORtoPU() which sends the SOR document created with the first procedure to the Purchase Unit. The input parameters are a SOR document and the URL of the PU web server. This procedure returns an integer parameter with the confirmation code of the transaction.

A second service is published by the Purchase Unit with the name ProcessActionPlan and realizes an interface, called ActionPlanservice, which includes a single method called makeActionPlan( ) that takes as input a SOR document and produces a new Action Plan.

Obviously, the services described above are only examples of possible real services needed in the CPD process.

6.5.2 Representing description parameters



In Figure 17 one can see also two UML notes that include the description of the two companies involved in the scenario. This is a proposal to achieve a complete methodology for describing the different parameters of the OWL-S Profile. The example includes the description of the actors involved in the scenario, linking each service to UML notes stereotyped with the name of the OWL-S Profile parameter described.

Figure 17. Poseidon note properties windowAs one can see in Figure 17, the example includes a note called OEMactor and stereotyped

<<contactInformation>>. Obviously, it is necessary to add also all the OWL-S parameters to each contact description, so the proposal is to add parameters as tagged values with the property name as tag name and the description as value (Figure 18).

Figure 18. Poseidon note tag values windowFinally, in the body of each UML note it is possible to add a text description of the content of the

note, in this case the statement “description of OEM”.The same procedure can be used to add <<serviceParameter>> and <<serviceCategory>>

elements with the related tagged values.

6.5.3 Using the SINTEF UMT-QVT tool for the transformationThe UMT is software that allows transformations among models. It is based on the OMG QVT

standard and realizes translations with XSL transformations. It uses the XMI Light language as interface between different XMI releases (1.0, 1.1 and 1.2) and target models. To deal with the previous example, following the methodology described in the section 6.5.2, a UMT plug-in has been developed to implement the transformation from an XMI document to an expanded version of XMI Light and finally to the OWL-S files.



To carry out this task, it has been necessary to add some new concepts to the basic XMI Light translation, in particular, some components require the related UML note elements. To connect the new OWL-S plug-in to the UMT tool, it is necessary to create a new transformation with the button “Transformations” in the menu “Settings”. In the “Editor Transformations” window you have to click with the right mouse button on the list in the left pane and select the “add” command (Figure 19).

Figure 19. Add a new transformation in UMT-QVT toolThen, it is necessary to select the “multifile” output type and the directory with the OWL-S XSLT

files as “implementation” (Figure 20).

Figure 20. Add transformation window in UMT-QVT toolAt the end of this process the new OWL-S transformation appears in the main “Transformations”

menu. Now, it is possible to open the example XMI file, from the main menu “File”, and the XMI Light code appears in the right “Model viewer” window, then you can apply the new transformation (Figure 21).



Figure 21. The results of the OWL-S transformationThe code below shows the XMI Light representation of our UML example.

<model xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://umt-qvt.sourceforge.net/XMI-Light.xsd"><package id="sm_b533b8_ff0c53233f_-7e6f" name="CPDpack" xmlns:UML1_1="UML1.1" xmlns:UML1_2="UML1.2"><class abstract="false" id="sm_b533b8_ff0c53233f_-7e97" name="LeanSOR" stereoType="BusinessService"> <implements id="sm_b533b8_ff0c53233f_-7e7f" name="SORservice" /> <documentation body="desription of OEM" docname="OEMactor" stereoType="contactInformation"> <tagNote tag="name" value="FIAT" /> <tagNote tag="webURL" value="some title" /> <tagNote tag="phone" value="+390232443223" /> <tagNote tag="fax" value="+390232441100" /> <tagNote tag="email" value="[email protected]" /> <tagNote tag="physicalAddress" value="Lingotto street, Torino, ITALY" /> <tagNote tag="webURL" value="www.fiat.it" /> </documentation></class><class abstract="false" id="sm_b533b8_ff0c53233f_-7e7d" name="ProcessActionPlan" stereoType="BusinessService"> <implements id="sm_b533b8_ff0c53233f_-7e78" name="ActionPlanservice" /> <documentation body="description of PU" docname="PUactor" stereoType="contactInformation"> <tagNote tag="name" value="PUname" /> <tagNote tag="webURL" value="www.PUwebsite.com" /> </documentation></class><class abstract="false" id="sm_b533b8_ff0c53233f_-7e73" name="SOR" stereoType="Concept"> <attribute cardinality="" id="sm_b533b8_ff0c53233f_-7e75" name="SORcode" type="sm_b533b8_ff0c53233f_-7ea0" /> <attribute cardinality="" id="sm_b533b8_ff0c53233f_-7e74" name="SORcont" type="sm_b533b8_ff0c53233f_-7e70" /> </class><class abstract="false" id="sm_b533b8_ff0c53233f_-7e70" name="SORcontent" stereoType="Concept"> <attribute cardinality="" id="sm_b533b8_ff0c53233f_-7e71" name="content" type="sm_b533b8_ff0c53233f_-7e9e" />



</class><class abstract="false" id="sm_b533b8_ff0c53233f_-7dea" name="ActionPlan" stereoType="Concept"> <attribute cardinality="" id="sm_b533b8_ff0c53233f_-7dc5" name="actionPlaneCont" type="sm_b533b8_ff0c53233f_-7e9e" /> </class><class abstract="false" id="sm_b533b8_ff0c53233f_-7e7f" name="SORservice" stereoType="Interface"><operation id="sm_b533b8_ff0c53233f_-7e88" name="getSORfromPSI" returnType="sm_b533b8_ff0c53233f_-7e73" visibility="public"> <parameter direction="in" name="PSIcode" type="sm_b533b8_ff0c53233f_-7ea0" /> </operation><operation id="sm_b533b8_ff0c53233f_-7e82" name="sendSORtoPU" returnType="sm_b533b8_ff0c53233f_-7ea0" visibility="public"> <parameter direction="in" name="sentSOR" type="sm_b533b8_ff0c53233f_-7e73" /> <parameter direction="in" name="urlPU" type="sm_b533b8_ff0c53233f_-7e9e"/> </operation></class><class abstract="false" id="sm_b533b8_ff0c53233f_-7e78" name="ActionPlanservice" stereoType="Interface"><operation id="sm_b533b8_ff0c53233f_-7e7b" name="makeActionPlan" returnType="sm_b533b8_ff0c53233f_-7dea" visibility="public"> <parameter direction="in" name="inSOR" type="sm_b533b8_ff0c53233f_-7e73"/> </operation></class><package id="sm_b533b8_ff0c53233f_-7e9c" name="java"> <package id="sm_b533b8_ff0c53233f_-7e9d" name="lang"> <class abstract="false" id="sm_b533b8_ff0c53233f_-7e9e" name="string" /> <datatype id="sm_b533b8_ff0c53233f_-7ea0" name="int" /> <datatype id="sm_b533b8_ff0c53233f_-7e9f" name="void" /> </package></package></package></model>

In the code below, the <<BusinessService>> classes include implementations and documentations. Each documentation has a name, a body with a description, a stereotype and a list of tags with name and value. This description has an XMI 1.2 representation as a stereotyped UML note with tagged values. <class abstract="false" id="…" name="LeanSOR" stereoType="BusinessService"> <implements id="…" name="SORservice" /> <documentation body="desription of OEM" docname="OEMactor" stereoType="contactInformation"> <tagNote tag="name" value="FIAT" /> <tagNote tag="webURL" value="some title" /> <tagNote tag="phone" value="+390232443223" /> <tagNote tag="fax" value="+390232441100" /> <tagNote tag="email" value="[email protected]" /> <tagNote tag="physicalAddress" value="Lingotto street, Torino, ITALY" /> <tagNote tag="webURL" value="www.fiat.it" /> </documentation></class>

For instance the code above is the XMI Light representation of the OWL-S description of the OEM actor, so it should be translated into the following OWL-S code.<profile:contactInformation> <actor:Actor rdf:ID="OEMactor"> <actor:name>FIAT</actor:name> <actor:webURL>some title</actor:webURL> <actor:phone>+390232443223</actor:phone> <actor:fax>+390232441100</actor:fax> <actor:email>[email protected]</actor:email> <actor:physicalAddress>Lingotto street, Torino, ITALY</actor:physicalAddress> <actor:webURL>www.fiat.it</actor:webURL> </actor:Actor></profile:contactInformation>

The OWL-S plug-in executes all these XSL transformations and it creates all the OWL-S and WSDL necessary files.

6.5.4 ACE-GIS+ conversion rulesThis section describes all the conversion rules from the UML class diagram to the OWL-S files.

The transformation tool uses the name of the UML package to create the names of all the OWL-S



documents. In the previous example (section 6.5.1) CPDpack is the name of the entire package that contains the UML class models.

<package id="…" name="CPDpack" … xmlns:UML1_2="UML1.2">This name is added automatically to every OWL-S documents obtained after the translation. In

that case: CPDpackService.owl CDPpackProfile.owl CPDpackProcess.owl CPDpackGrounding.owl LeanSOR-wsdl.wsdl ProcessActionPlan-wsdl.wsdl CPDpackConcepts.owl

Using an expanded version of the ACE-GIS description of Web services, it is possible to express a new service for each <<BusinessService>> class, with its related WSDL file too. Each service realizes interfaces that include the methods that represent the operations of each service. The methods could use different types of input and output parameters, including concepts related to a common ontology designed with the <<Concept>> stereotype

In the table below you can find the detailed conversion rules:

UML Construct Conversion to OWL-S

<<BusinessService>> stereotyped classes

Each such class will results in a separate WSDL-document file.

It is used to create the <profileHierarchy:service> tags in the OWL Profile document with an ID composed with a “profile_” string before the name of the service. Each such section defines also a <profile:serviceName> tag that shows the name of the service and includes the descriptions explained with the UML note diagrams

It is used to create a <process:ProcessModel> tag in the OWL Process file and the related <process:AtomicProcess>

It is used to create a <grounding:WsdlGrounding> tag in the OWL Grounding file

Interface The interfaces include the methods implemented by the service

<<contactInformation>> stereotyped notes

Each UML note with the stereotype <<contactInformation>> is used to create a <profile:contactInformation> tag related to a service in the OWL Profile file The tagged values of the UML note are used to create the Actor

detailso <name>o <title>o <phone>o <fax>o <email>o <physicalAddress>o webURL

<<serviceCategory>> stereotyped notes

Each UML note with the stereotype <<serviceCategory>> is used to create a <profile:serviceCategory> tag related to a service in the OWL Profile file The tag values of the UML note are used to create the Actor details

o <name>o <taxonomy>o <value>



UML Construct Conversion to OWL-So <code>

The ‘addParam’ and ‘addParmaID’ tagged values could be used to add a new reference to a particular category

<<serviceParameter>> stereotyped notes

Each UML note with the stereotype <<serviceParameter>> is used to create a <profile:serviceParameter> tag related to a service in the OWL Profile file The tag values of the UML note are used to create the Actor details

o <serviceParameterName>o <sParameter>

The ‘addParam’ and ‘addParmaID’ tagged values could be used to add a new reference to a particular parameter

Package Packages could be implemented as container of common ontologies

Class Classes that are not being used directly or indirectly by the realized set of operations for a <<BusinessService>>, are ignored. Every other class is mapped to an XML Schema

<xsd:complexType> within the <wsdl:types> part of the WSDL.

Attribute Each attribute is mapped to an <xsd:element> within the <xsd:complexType> corresponding to its owner class in the WSDL file.

Association Each association is mapped to an <xsd:element> within the <xsd:complexType> corresponding to the class on the non-navigable side. The <xsd:element> will have name equal to the association role name on the navigable side and type equal to the class on the navigable side. (The conversion rule requires that all associations are marked as navigable in one direction only.)

Cardinality Attribute and association cardinalities are converted to values of the minOccurs and maxOccurs attributes within the corresponding <xsd:element>. The UML cardinality “*” is converted to the xml value: unbounded.

Cardinalities could used to implement a specific range for a new ontology concept

Class Inheritance The <xsd:complexType> corresponding to the sub class gets an <xsd:extension> element with base attribute equal to the corresponding <xsd:complexType> of the super class.

Operations (Methods) Each operation is mapped to two <wsdl:message> elements. One for the request and one for the response. Each parameter is mapped to a <wsdl:part> element within the request <wsdl:message>. The response <wsdl:message> consists of one <wsdl:part> element with name=”return” and type equal to the UML return type name. Operations that do not belong to Interfaces are considered internal and will be ignored.

Each operation is mapped to an <process:AtomicProcess> statement in the OWL Process file The input parameters are used to insert the <process:hasInput>

elements The output parameters are used to include the

<process:hasOutput> elementsTo describe the types of each I/O parameters, the transformation includes also the description of <process:Input> and <process:UnConditionalOutput> statements with the description of the <process:parameterType> for each parameter used in every operations



UML Construct Conversion to OWL-S

The tags <process:hasInput> and <process:hasOutput> are added also in the OWL Profile file with the links to the related OWL Process file parameters

Each method is mapped to an

<<Concept>> stereotyped classes

Each class stereotyped with the term <<Concept>> is used to create a new semantic notion stored in the OWL Concepts document.The parameters included in each << Concept>> class are used to define <owl:DatatypeProperty> elements with the related <rdfs:domain> and <rdfs:range> tags. The range statement could be also used to link both XML Schema types and OWL semantic concepts

Other UML constructs Ignored.



7 QoS support for Web services

7.1 IntroductionIn order to support adaptability we have introduced the concept of AlternativeServiceProviders of

the Web service composition modelling described in ACE-GIS . This can be used when there are many alternative services delivering more or less the same service. This makes the composition more adaptable since one Web service may be unavailable and still the execution of the composition is possible with selecting one of the other alternative services. The simplest way to implement this is to execute all the alternative services in parallel and the first one to return an answer is used. The other results are ignored. The selection process can be further improved by taking Quality of Service (QoS) aspects into account. The modeller may identify the selection criteria based on data quality, price, security level etc. Such information can be utilized by QoS-aware brokers that do selection and optimization of which service to select and invoke. We may differentiate between static and dynamic QoS selection. Static QoS selection means that the service to be used is chosen based on QoS values prior to run-time. Dynamic QoS selection means that the service to be used is chosen based on QoS values provided or estimated at run-time. There are two different approaches to defining the QoS values for a given service. The first is to let the service providers themselves declare these values. The question is to what extent these values can be trusted and relied upon. An alternative is to let trusted third-parties calculate the QoS values either on-demand or based upon experience.

7.2 A methodology for integration of QoS based on aggregationThis section describes a preliminary methodology for how to integrate QoS aspects when

designing new Web service compositions. This methodology aligns well with the ACE-GIS Web service composition methodology. This QoS methodology requires more validation through practical experience since it has not yet been implemented and tested on a real scenario. Our main choices are to use UML for the modelling parts, a UML transformation tool to support model-driven development and an optimization component to optimize the QoS values for the composition. Step 1: Model the new Web service composition in UML. The Web service model contains a

service model, a workflow model and QoS requirements for the Web service composition as a whole. Then a search in a Web service registry is used to find candidate services to be used within the composition to fulfil the different tasks. It is assumed that these Web service descriptions go along with QoS values of each service.

Step 2: The list of candidate Web services with QoS values of each are sent to an optimization algorithm that picks the best suited collection of Web services that fulfil each task in the composition and that meets the compositions QoS requirements identified in step 1. The optimization algorithm will have to compute the aggregated QoS values for the composition as a whole.

Step 1 Step 2 Step 3

Web service registry w/

QoS


QoS

Search and discover

Extract

Publish

QoS describedcandidateservices

Modelcompositionw/ QoSrequirements

Internetserver

Web service consumers

Compositionmodel withindividualandaggregatedQoS values



QoSaggregationcomputation

and optimization

WSDL + QoS spec.

WSDL + QoS spec.

Selectedservices and aggregatedQos

Aggregated QoS

UpdateCompositionmodel

WSDL spec. ofnew service

WSDL spec. ofnew service

AggregatedQoS valuesAggregatedQoS values

Executablespec. (XML)

Executionengine


QoS


QoS

Export WSDL + QoS of composition

Export

Deploy

Configure

Figure 22. Method overview



Step 3: The selected services with QoS values and the aggregated QoS values are used to update the composition UML model. The QoS values are probably described in a proper XML format suitable to be published in a Web service registry. A model-driven tool can implement an automatic transformation that transforms the XML QoS documents and the original composition model into the updated UML model with the actual QoS values of each individual service as well as for the composition as a whole. The UML composition model is used as a basis for automatic generation of descriptions and code needed to register, implement and deploy the new Web service. An exported WSDL file describes the new composite service, an exported QoS file describes the QoS of the composite service, and an exported executable specification can be used to configure an execution engine. Finally the new composite Web service is deployed on an internet server and its WSDL and aggregated QoS values are registered in a Web service registry available for Web service consumers.

7.3 Web service composition modelling with QoSThis section shows how UML can be used to model QoS within service composition. The QoS

modelling is here divided into three main parts and the modelling builds upon the forthcoming OMG UML profile for QoS modelling .

7.3.1 UML modelling of QoS characteristicsAn ontology for possible QoS concepts is defined by QoS Characteristics. Each QoS

Characteristic contains a set of QoS Dimensions with a name, its allowed value domain, if higher or lower values are considered better and its relationship to other QoS Characteristics. All the QoS concepts to be used elsewhere shall be defined as a QoS Characteristic either within the model itself or as in imported model. The modelling of QoS Characteristics should be placed in a separate package or a separate model in order to simplify reuse.

7.3.2 UML modelling of QoS requirementsA QoS Requirement identifies restrictions on a service with respect to specific QoS Characteristics

that needs to be fulfilled in order to do a successful binding to a service. The requirements may apply to a single service or the service composition as a whole. We also propose to have the concept of QoS Interests to be the set of QoS Characteristics that are desirable to be optimized. It could be chosen that all the QoS Characteristics referred to by the requirements are implicitly part of the Interest set. In some cases it may not be necessary and any characteristic that one tries to optimize may worsen the optimization of other Characteristics, since optimization deals with trade-offs. We suggest explicitly modelling all Characteristics within the Interest set and leaving it for the selection and optimization brokers to make the choice. Furthermore we propose that the different Characteristics in the Interest set are weighted to indicate the relative importance of the interest.

7.3.3 UML modelling of QoS offeredQoS Offered indicate the actual, expected or average values of the different Characteristics for a

service. There may be assumptions on the environment to deliver such QoS values. This could be a maximum number of simultaneous users or a required bandwidth of the accessing client application.

7.3.4 Example: QoS in the gas dispersion caseThe following example illustrates how QoS can be used to enrich the ACE-GIS gas dispersion

case. We illustrate a possible UML modelling approach by relating to the steps of the method in Figure 22. In step 1 we model the service composition as suggested by the ACE-GIS Method and we enrich it with QoS Requirements such as shown in Figure 23.



<<Q o S - In te re s ts >><In te re s t n a m e ="E xe c u tio n T im e .w o rs tC a s e E xe c u tio n T im e " w e ig h t="0 .8 "/><In te re s t n a m e ="U s e rR a tin g .ra tin g " w e ig h t="0 .5 "/><In te re s t n a m e ="E n c ryp tio n L e ve l.le ve l" w e ig h t="0 .2 "/>

<<W e b S e rvic e C a ll>>C a lc u la te G a s D is p e rs io n P lu m e

<<W e b S e rvic e C a ll>>C re a te G a s D is p e rs io n M a p

<<Q o S - R e q u ire m e n ts >>{c o n te xt P ric e : p r ic e P e rC a ll <= 5 0 }{c o n te xt E xe c u tio n T im e : w o rs tC a s e E xe c u tio n T im e <= 2 0 } <<W e b S e rvic e C a ll>>

G e t N e a re s t A irp o r t

G e t W in d<<W e b S e rvic e C a ll>>

<<W e b S e rvic e C a ll>>G e t P la n t L o c a tio n

Figure 23. Web service composition model with QoS requirementsThe QoS Requirements in the example (top left note) apply to the composition as a whole, since

they are not attached to any the individual services (This is just a notational convention). The required price per invocation must be at most 50 Euros and the execution time must never exceed 20 seconds. In addition we specify QoS Interests (lower left note) indicating which QoS Characteristics we want optimized. Each of these interests has assigned a weight between 0 and 1, where 1 indicates highest importance. The QoS Characteristics used are defined by a separate UML package as shown in Figure 24.

Q o SC h a ra c te r is tic s

E x e c u tio n T im e<<Q o S C h a ra c te ris tic >>

<<Q o S D im e n s io n >>-w o rs tC a s e E xe c u tio n T im e : re a l{d ire c tio n =d e c re a s in g , u n it=s e c o n d s }<<Q o S D im e n s io n >>-a ve ra g e E xe c u tio n T im e : re a l{d ire c tio n =d e c re a s in g , u n it=s e c o n d s }

E n c ryp tio n L e ve l<<Q o S C h a ra c te ris tic >>

<<Q o S D im e n s io n >>- le ve l : e n u m {1 ,2 ,3 ,4 }{d ire c tio n =in c re a s in g }

U s e rR a tin g<<Q o S C h a ra c te ris tic >>

<<Q o S D im e n s io n >>- ra tin g : p o s itive In te g e r{u n it=1 ..1 0 , d ire c tio n =in c re a s in g }

P ric e<<Q o S C h a ra c te ris tic >>

<<Q o S D im e n s io n >>m o n th lyS u b s c rip tio n P ric e : re a l{d ire c tio n =d e c re a s in g , u n it=E u ro }<<Q o S D im e n s io n >>p ric e P e rC a l l : re a l{u n it=E u ro , d ire c tio n =d e c re a s in g }

Figure 24. QoS characteristicsThe direction of a characteristic is defined as either increasing or decreasing, where increasing

means that higher values are preferred. Next in step 1, we search for candidate services for each task in the composition and we assume that these have specified values for the relevant QoS Characteristics. These are manually inspected to see if they describe the same semantic service as needed. This manual step may be replaced by an automatic agent if all or many of the Web service descriptions have published proper ontology descriptions. In step 2 we use an optimization component that selects the services based on the requirements and interests. Ideally this ends up with a set of services (one for each task) that gives aggregated QoS Offered for the whole composition that satisfy the requirements, and that are optimized with respect to the interests defined. In Step 3 all the QoS Offered from the chosen services are used to produce a UML composition model (Figure 25) with these values attached to each service. The production of this UML model is preferably supported by



automatic reverse engineering in a transformation tool such as UMT. Then the Web service composition model with QoS Offered is a basis for code generation to WSDL, execution specification (e.g. BPEL) and a QoS XML document. Finally the Web service composition is deployed and published as WSDL and QoS values for the service composition as a whole.

<<Q o S O ffe re d >>{c o n te xt P ric e : p ric e P e rC a ll = 0 } {c o n te xt E xe c u tio n T im e w o rs tC a s e E xe c u tio n T im e = 0 .2 } {c o n te xt U s e rR a tin g : ra tin g = 6 } {c o n te xt E n c ryp tio n L e ve l : le ve l = 2 }

<<Q o S O ffe re d >>{c o n te xt P ric e : p ric e P e rC a ll = 1 0 } {c o n te xt E xe c u tio n T im e w o rs tC a s e E xe c u tio n T im e = 3 } {c o n te xt U s e rR a tin g : ra tin g = 8 } {c o n te xt E n c ryp tio n L e ve l : le ve l = 4 }

<<Q o S O ffe re d >>{c o n te xt P ric e : p ric e P e rC a ll = 9 } {c o n te xt E xe c u tio n T im e w o rs tC a s e E xe c u tio n T im e = 1 0 } {c o n te xt U s e rR a tin g : ra tin g = 4 } {c o n te xt E n c ryp tio n L e ve l : le ve l = 4 }

<<Q o S O ffe re d >>{c o n te xt P ric e : p ric e P e rC a ll = 0 } {c o n te xt E xe c u tio n T im e w o rs tC a s e E xe c u tio n T im e = 5 } {c o n te xt U s e rR a tin g : ra tin g = 2 } {c o n te xt E n c ryp tio n L e ve l : le ve l = 1 }

<<Q o S O ffe re d >>{c o n te xt P ric e : p ric e P e rC a ll = 1 } {c o n te xt E xe c u tio n T im e w o rs tC a s e E xe c u tio n T im e = 1 .8 } {c o n te xt U s e rR a tin g : ra tin g = 5 } {c o n te xt E n c ryp tio n L e ve l : le ve l = 3 }

{p ro vid e r=IO N IC }C a lc u la te G a s D is pe rs io n P lu m e

<<W e b S e rvic e C a ll>>

<<Q o S O ffe re d >>{c o n te xt P ric e : p ric e P e rC a ll = 3 0}{c o n te xt E xe c u tio n T im e : w o rs tC a s e E xe c u tio n T im e = 2 0 }{c o n te xt U s e rR a tin g : ra tin g = 4 .6 }{c o n te xt E n c ryp tio n L e ve l : le ve l = 1}

<<W e b S e rvic e C a ll>>C re a te G a s D is pe rs io n M a p

{p ro vid e r=IO N IC }

{p ro vid e r=C a p e S c ie n c e }

<<W e b S e rvic e C a ll>>G e t W in d

<<W e b S e rvic e C a ll>>G e t P la n t L o c a tio n

{p ro vid e r=e -b la n a }

<<W e b S e rvic e C a ll>>G e t N e a re s t A irpo rt

{p ro vid e r=e -b la n a }

Figure 25. QoS offered for the service composition

7.4 Quality of service (QoS) and Web servicesThis section aims to define a set of quality criteria that should be required for defining the quality

of the Web services in order to answer the questions of the integrator that evaluates the possibility of integrating a Web service within his current application. These questions will be the basic criteria for selecting Web services.

This section will provide the way of defining the non-functional aspects for Web services in order that a Web service integrator can easily find answers to questions such as: Will this Web service fit the required functionality that our organisation needs? What are the advantages and disadvantages of this Web service? Can I trust the company that develops the Web service? Can I trust the Web service provider? What are the quality characteristics of the Web service? Does anybody else use the Web service?

7.4.1 Quality criteriaThe requirements can be split into two groups:

The requirements about the Web service that include technological aspects. These requirements are generally oriented to assure that the Web service can solve a set of technical functionalities necessary for fitting the business aspects of the application.

The requirements about the provider that deals with the entity that provides the Web service. These requirements refer to the quality of the Web service and the assurance that the Web service doesn’t disappear.

The following table summarizes the quality aspects that Web service developers or providers explicitly define:

Requirements for Web services Requirements for Web Service ProviderAccessibility ContinuityAccuracy, Exception Handling and Robustness Customer Support

Configurability IdentificationInteroperability Quality assurancePerformance ReputationPrecision ScalabilityPricing Security system and policy



Requirements for Web services Requirements for Web Service ProviderReliabilitySecurityTestabilityTraceability and AuditabilityUsability

7.4.2 Non-functional requirements for Web services This section will describe different non-functional requirements related to Web services.

7.4.2.1 AccessibilityThe customer generally would want to use the Web service from anywhere, from any device and

at anytime. Accessibility defines whether a Web services is able to serve the client’s request. The technology used for developing Web services supports technologies such as the HTTP

protocol, which allows connecting to the internet from anywhere and any system. The only limitation for using Web services might be on the terminals, as it is possible to find some type of terminals that don’t support Web services.

7.4.2.2 Accuracy, Exception Handling and RobustnessThese criteria are classical requirements for any software development. Customers do not want to

have any problem with the services at run time. Normally, the Web service developers assure that their Web services are completely secure and perfectly tested.

According to [30]: Accuracy means that the number of errors that the service generates over a time interval should

be minimized. Exception handling is related to how to handle all the possible outcomes and alternatives of a

Web service that cannot be specified by the service designer. This means, how the service deals with exceptional situations.

Robustness means basically that a Web service should still work even if incomplete parameters are provided to the service request invocation.

The way of satisfying or improving these requirements is basically the same for any software development. Some guidelines are the following ones: Establish a regular checking of the Web service during the development and maintenance

phases, and also verify the requirements, design, architecture and so on. Formalize the way of developing the Web service. Automate the testing activities. Define the exploitation and maintenance activities and ensure that they are properly deployed.

In any case, for the development of Web services, some additional mechanisms have to be established in order to continually control the existence of errors or exceptions within the normal execution.

Recurrently carry out some automatic test cases on the service. These tests generally work by introducing some input and expecting some output in relationship with the input. These tests allow verifying if the logic of the Web service is working properly. Of course, there are some cases in which it will be difficult or impossible to do it so it is necessary to make these tests manually.Besides some mechanisms of configuration management can be developed that will allow establishing some recovery point within the system, in case new version containing errors are deployed. This will allow going back faster to the previous stable status.7.4.2.3 Configurability

In some cases it is possible that customers require that the Web service keeps the configuration they’ve set in order to avoid repetitive setting tasks for the customers.

The configurable features of the Web service are generally: Language Currency Location



7.4.2.4 InteroperabilityInteroperability [30] means that Web services should be interoperable between the different

development environments used to implement services so that developers using those services do not have to think about which programming language or operating system the services are hosted on.

Interoperability implies to use standard specifications for Web services but most of those specifications are defined under standards bodies and each vendor partly implements them in their products due to the competitive nature of the market so this results in poor interoperability.

7.4.2.5 PerformanceIn the context of Web services, this requirement is very important for assuring the success of the

Web service [31]. The performance of a Web service is measured in terms of throughput, latency, execution time, and transaction time. Throughput represents the number of Web services requests served in a given time period. Latency is the round-trip time between sending a request and receiving the response. Execution time is the time taken by a Web service to process its sequence of activities. Transaction time represents the period of time that passes while the Web service is completing

one complete transaction. Higher throughput, lower latency, lower execution and faster transaction times represent good

performing Web services.In order to improve the speed of the service, some technical actions can be considered:

The system should have enough data transmission and data processing capacity. This implies the optimization of the resource management.

The system should support the update of platform to improve the system performance. The system should support concepts such as replicated systems and charge distribution. During the development review activities could be included to evaluate the performance provided

by the Web service design.

7.4.2.6 PrecisionThe customers need that the Web service provides the functionalities described within the WSDL.

The customers need to clearly know what these functionalities are and how to use them. If the Web service does not provide precise information, the customer might feel disappointed and might stop using the service.

To avoid this situation it is important to: Take care about the service name and operations. Take care about the documentation provided together with the Web service. Take care about the language used to describe the Web service.

7.4.2.7 PricingWhen customers need to pay for the use the service, they should know precisely the terms of cost

for using this Web service. The customer should be warned about any change in the rate setting, and he should also receive a detailed and easy to understand invoice. Transparent mechanisms for pricing are needed.

7.4.2.8 ReliabilityReliability [31] is the overall measure of a Web service to maintain its service quality. The number

of failures per day, week, month, or year represents an overall measure of reliability for a Web service. Customers should be able to connect to the Web service at any time without being affected by any problem on the web. Reliability also refers to the assured and ordered delivery for messages being sent and received by service requestors and service providers.

7.4.2.9 SecurityThe security on the network communication such as Internet is one of the major concerns of the

customers. Web services should include security artefacts that depend on the type of Web service, on the data being transported, and also on the interests of the customer and the provider. In any case, independently from the nature of the Web service, the needs of the customer (and sometimes also the needs of the provider) may require that the following features are supported by the Web service: Authentication: The authentication consists on the recognition without mistake of users (or other

services) that can access service and data. There are many different ways in which to implement authentication. The most basic techniques for authenticating users include a username and



password, but one can also introduce physical artefacts (smartcards, one-time-password generators) or biometrics. Authenticating software artefacts usually relies on applications of public-key cryptography such as digital signatures. It is important to note that all that an authentication technique does is verify a request for authentication with a secret (password, private key, etc.). Authentication relies on the assumption that the owners of those secrets keep those secrets secret.

Authorisation/Access control: Access control builds on authentication. Access control is responsible for granting or refusing access to some resources or functionalities according to the credentials presented by the requester and some access control rules.

Integrity: It consists on assuring that data is not tampered with during transfer or storage. In the context of a data communication, the integrity mechanism assures that the data received is the same as the data sent. It therefore refers to both data and transaction integrity. Digital Signatures represent a way of dealing with this issue.

Confidentiality/Privacy: It consists on assuring that nobody outside the intended recipient of a message can read the data transferred. These mechanisms are generally based on techniques of encryption based on a combination of symmetric and asymmetric keys.

Non Repudiation: In some services there is a need for being sure that neither the customer nor the provider denies having used the service or received some information. In real life, a mechanism such as registered mail is an example of a system which offers a proof of non-repudiation.

Auditability: Some customers or providers might require all operations to be registered, in case it is needed for later audits.

To fit these requirements the provider should take into account two aspects: the first one is to provide support for the security mechanisms required by the customer, and the second one is to protect the Web service and the data that contain the authentication information.

7.4.2.10 TestabilityCustomers should be sure that the Web service provides the solution for their issues. The

possibility of testing the Web service should be implemented at two levels: The first level would allow the customer to test the functionalities provided by the Web service

and therefore know the use, the time of response, the output and so on. The second level would allow the customer the free test of extra charge the functionalities of the

Web service during the development and maintenance phases of its system.When implementing Web service testing mechanisms, the provider could also choose to provide

the customer with a default interface that would allow him to evaluate the Web service. Generally, the testing platform can be implemented on a specific server with a set of imaginary data.

Some existing development environments (e.g .Net) provide the way of automatically generating the testing interface. This interface allows to set the required input and to get as a result a SOAP file.

7.4.2.11 Traceability and auditability In some cases, there is an important need for monitoring and controlling the Web service. There

are different aspects that the customer might want to monitor: Use: The customer might want to know some information such as the use of the service until a

certain date, the number of uses of the Web service, the history of use… A customer with several users within might also ask for getting information on the use of the service by each user, the total use, some specific historic data…

Error log: The customer might want to know if some error, exception, crash or shutdown of the service has occurred during a certain period of time.

Actual status: If the service has a strange behaviour, the customer needs some alternative mechanisms that will allow him to know if the problem comes from the service, from the system or from the communication.

Number of users: If the Web service supports several users from the same customer, the customer might want to know, control, and set limits on the number of users authorized to use the service.

7.4.2.12 UsabilityThis requirement is focused on the easy usage, integration and management of Web services.

The usability of a Web service means different things depending on the development phase or use of the Web service.



The requirements of the customer for the Web service can change if the Web service is integrated, used or managed. So the Web service has to provide supporting mechanisms for the customer during each of the following steps:

Support for the integration: The customer should have facilities for integrating the Web service within its own application: A description of the interface available from the Web service (WDSL description). Examples of the use of the Web service in different platforms and in different languages (Java,

C++, VB, C#...) Examples of customers: It would be a very important advantage to get some examples of

integration of the Web service within other customers’ applications. It would be interesting to get information about the functionalities and the use of the Web service

directly within the development environment.

Support for the use: The customer should have the documentation that explicitly explains the errors that can occur

during the use of the Web service. If some pre-defined sequence exists for the use of the Web service, the customer should be able

to consult the documentation explaining such sequence, such as a user manual.

Support for the management: Documentation on how to use the mechanisms for managing the Web service in order to monitor

or to control the Web service. Notification service of any shutdown, error or exception of the system.

7.4.3 Non-functional requirements for Web services provider This section will describe different non-functional requirements related to Web services.

7.4.3.1 ContinuityWhat the customer needs from the Web service provider is to be assured that the Web service will

be available as long as the application in which the Web service is integrated is working.A customer will not buy any Web service from companies without being sure that the Web service

provider will maintain the web during the customer’s application life. A Web service customer will not integrate Web services from companies that do not have a healthy economical situation at a medium/long term.

At the end, the customer will establish a dependent relationship with the Web service providers. The customer might not really appreciate such dependency, and so the situation might be compensated with: Showing that providing Web service is an important part of the company business. Showing the economical situation of the Web service provider. Indicating the experiences and how long has the company been providing this kind of services or

applications.

Anyway, the best way of assuring the continuity of the Web services is to establish by contract that the code and the implementation of the Web service will be available for the customers if the provider stops providing it.7.4.3.2 Customer Support

The customer will appreciate to have access to a support service available any time of the day and the year (24x365). The customer will also value the promptness of the response from the support service.

The support should not be limited to the use of the Web service, but should be also capable of solving problems and issues about: The integration of the Web service within an application. The monitoring of the Web service. The management of the Web service and contracting aspects.

The availability of the support might not have a relevant influence when selecting a Web service, but should favour the decision of maintaining or not the choice of Web service. Moreover, providing a 24x365 support to customers would considerably improve the image of the company. This requirement can be completed with: The establishment of communication mechanisms between customers and companies.



The notification to the customers that a support service is available. The establishment of mechanisms and processes for dealing with questions from customers. The use of applications for managing the relationship between customers (CRM) that allow

registering the requests from the customers and assure the traceability until the end of the process.

Making the customers aware about events that can have some interest for them.

7.4.3.3 IdentificationBefore calling the Web service, the customer will need to be sure that the company providing the

Web service really exists. A customer will not trust a company only with the WDSL description of the Web service.

The identity of the company can be described: By using a web site in which the company information will be available. This information will

consist on the economical situation of the company, contact information, information about the use of the Web service, its way to work and so on…

By using an identity certification issued by a certifying organization. By showing some references from other company web sites that used the Web service.

7.4.3.4 Quality AssuranceThe customer might require some assurance about the way the company providing the Web

service works. For example, a customer wanting to integrate a Web service into an application for the military domain might require from the Web service provider a CMM® certification.

The customer will take into account the situation of the provider concerning the quality assurance of their Web services. A clear position of the provider in terms of quality assurance such as ISO 9000, CMM® or EFQM® will be seen positively by the customer.

7.4.3.5 ReputationOne of the requirements that most of the customers have for buying a Web service is that the

organisation providing the Web service must have some experience and presence in the domain. The experience refers both to the experience on the domain of application and to the experience

on the provision of the Web service. The presence is a feature that indicates the relevance of the provider in the domain of application of the Web service.

The reputation of a service measures how trustworthy it is. It mainly depends on user’s experiences in using the service or other services previously provided. It is mostly a Quality of Experience metric.

Related with this, [32] propose another QoS metric for selecting a Web service and a Web service provider: Verity, which mainly refers to the reputation of a Web service, but not only according to the user perception. It refers also to how trustworthy the provider has been in complying with the agreed levels in Service Level Agreements.

7.4.3.6 ScalabilityAlthough this may not be considered as a critical requirement, high scalability [30] should be

considered for a Web service provider. It means basically that a provider should be able to increase the capacity of its computer system and its system’s ability to process more users’ requests, operations or transactions in a given time interval.

7.4.3.7 Security System and PolicyIn some cases, the customer can see positively that the Web service provider has some security

mechanism ensuring that the data and information exchanged with the Web service will not be used for anything not related with the execution of the Web service. The Web service provider may apply different approaches and levels of providing security policy depending on the service requestor.

This can be assured: Through the certification of having the procedures, processes and installations that guarantee the

security both inside and outside the company. By establishing an engagement in the contract about the security of the data. By respecting the laws about the treatment of the personal information. By using infrastructures and systems such as firewalls or antivirus that prevent non-authorized

people from having access to the data.



8 E-contracts

8.1 IntroductionThe object of the present chapter is to present a modeling of the concepts found in the general

field of e-contracts. The state of the art document WD.A5.1 [5] presented a detailed study of a number of proposed technologies that can be referred to as e-contract technologies. Among these are WSLA (Web Services Level Agreement), WS-Agreement, WSML (Web Services Management Language), the CrossFlow European Project, WSOL (Web Services Offering Language), SNAP (Service Negotiation and Acquisition Protocol) and ebXML.

In this chapter, we focus on providing a model of e-contracts which could be transformed “down” into any of the technologies listed above that rely on the Web Services stack. Obviously, we do not expect such a transformation to be fully automated; neither do we require that such a transformation is performed without any extra input. Our goal is thus to propose a model of e-contracts that allows architects of Service-Oriented Architectures to specify the use of e-contract mechanisms, identify the main actors and the scope of the agreement, all that without having to tie that description to a particular technological approach.

We have chosen to present separately the design-time and the runtime models of e-contracts. The first category of models is concerned with the establishment of a contract, while the second one is concerned with the enforcement of the contract when the service is actually consumed.

8.2 What is an e-contractBy using the term ‘e-contract’ we intend to refer loosely to all the mechanisms that may exist, both

at design time and at runtime, to negotiate how to communicate between two services after the service consumer has discovered and selected the service provider. The scope of such a contract may include technical details, such as data encryption, reliability or the transactional context used. It may also include negotiations on which data format to use or on how to restrict the conversation to a specific business context. Little has been proposed for standardization of e-contracts so far in the world of Web services. This has to be contrasted with the approach taken by ebXML, which has an entire framework dedicated to negotiation and e-contracts. The only specification that may play a role in that field is WS-Policy, which defines a framework for exchanging information on requirements with respect to other specifications. Ws-Policy only defines how to exchange information and introduces a simple scheme for computing the intersection of two policy declarations, but is still far from proposing a real framework for e-contract negotiation.

8.3 Design-time model of e-contractsBy abstracting over the different e-contract technologies that we have documented in D.A5.1, we

came up with the following design-time model presented in the figure below.The main entities in this model are as follows.

Service consumer and service provider. We chose to use the more abstract concepts of service providers and consumers, as opposed to the more frequently used concepts of clients and servers. This is because we want to abstract away from the technological realization of the exchange of data between entities in a service-oriented architecture. While in most cases service consumers are clients and service providers are servers, there exist some technological realizations, such as publish-subscribe middleware technologies or peer-to-peer overlay networks, where the roles can be reversed, or even where the distinction between the notion of client and server is difficult to establish. The service consumer is therefore defined as the entity that initiates the negotiation of an e-contract with the service provider, which eventually results in the provision of the service from the service provider to the service consumer according to the terms of the e-contract.

Negotiation Protocol. Obviously, reaching an agreement between the service consumer and the service provider over the terms of the e-contract requires a negotiation phase. This negotiation phase is conducted according to a negotiation protocol. This protocol is known and agreed on by both parties. For the sake of simplicity and clarity, we assume here that there is no mismatch between the negotiation protocols in use by both parties. We believe that taking into account this problematic case would not add much value to our modeling work and would result in undue complexity of the models. This property is reflected in the cardinality of one of the associations between the service consumer and the negotiation protocol. The same applies to the association between the service provider and the negotiation protocol. It is also understood here that the



description of the protocol is outside of the scope of the e-contracts modeling work. It may very well be that there is actually no actual model for the negotiation protocol beyond a specification text in plain natural language and possibly a reference implementation.

Service Description. This is a description of the services offered for consumption by the service provider. This is nothing specific to the work on e-contracts. It is actually a good thing that we can keep a clear separation of concerns between the service description and the e-contract. The dependency is clearly from the e-contract to the service description, which means two things: services can be used without e-contracts, and more than one e-contract may govern the consumption of a service. The last point is obvious is one considers the fact (modeled by the *-1 association between a service consumer and a service provider) that many service consumers may access the same service provider, each of them potentially requesting different terms of the e-contract.

E-contract Document. This is the document that contains the terms that govern the consumption of the service offered by the service provider by the service consumer. We will see in more details later what this document may contain. The only component of an e-contract which is made visible here is its link to the service description. There is a unique e-contract document for any given pair of service consumer and service provider. While it is not theoretically impossible for a given pair of service consumer and service provider to have more than one e-contract that govern their interactions, we do not see much value in modeling this case, since the set of contracts can always be replaced by a contract which is the intersection or the union of them. We deliberately do not consider this case, since it is indeed a marginal case that adds little value to our modeling work and introduces significant difficulties when trying to model the runtime aspects (monitoring and enforcement) of e-contracts.

Figure 26. Design-time model of e-contracts

8.4 Run-time model of e-contractsNow that we have a model of how e-contracts are created as the result of a negotiation between

the service provider and the service consumer, let’s have a look at how e-contracts are monitored and enforced at runtime.



Figure 27. Runtime model of e-contractsThe following elements are of interest. The elements not described in the list below are described

above in the design-time view of e-contracts. Message. A message is an abstraction for any piece of data that can be exchanged between the

service provider and the provider and that falls within the scope of the enforcement of the e-contract. In practice, the message will most likely be concretized as an actual message, for example a SOAP message, a JMS message, the payload of an HTTP POST request, the content of an email, etc. However, there are situations when a message can be defined implicitly. For example, in the case of a network communication involving regular POSIX sockets, the act of abruptly closing the socket on one end of the communication can be treated as a message, and should definitely be taken into account when assessing the quality of service provided and the compliance with the terms of the e-contract.

Enforcement. The enforcement mechanism view the operation of the system through the set of messages collected, and monitors if the exchange of messages is in accordance or in violation with the terms of the e-contract. The structure of an e-contract document is detailed in the next section.

Service Consumer Owner and Service Provider Owner. Here we tried to follow the approach proposed by the Web Services Architecture document from the W3C and explicitly introduced the notion of an owner of a service. This is made necessary by the fact that e-contract are not pure technical artefacts, but are strongly linked to the legal side of operating networked services. This is why, for example, if a violation of one of the obligations set forth in the e-contract document is detected, it is necessary to escalate the issue to a human being who will decide how to act on the matter, since the matter is now outside of the technical real.

8.5 Modelling the e-contract documentThe e-contract document itself is probably the most important aspect of an e-contract framework.

The main reason for that is that it is the e-contract document that acts as the link between the design-time and the runtime aspect of an e-contract framework. Figure 28 contains the model of an e-contract document.



Figure 28. Model of an e-contract documentLet us walk now walk through the different elements of the model.

Party. An e-contract document is a binding agreement between a number of parties. The different parties do not all play the same role in the agreement, but there is however some features common to all parties which we choose to group in class Party. The most important common feature is that all parties need to be authenticated. This is because an e-contract does not exist in isolation: it only exists because there is a surrounding legal environment that makes it possible to enforce the conditions described in the e-contract document, and provides non-technical means of escalation, such as a prosecution, if the conditions are repeatedly broken.

Authentication Credential. This class is meant to represent any kind of mechanism that allows for authentication of the party. It is important to note here that an implementation of this class does not have to use the regular cryptography-based techniques for authentication. Even if it is quite likely that, for example, digital signatures will be used here, it is also absolutely conceivable that authentication is achieved in an implicit manner.

Human-readable description. This is a description in natural language of the content of the e-contract. The text could either have been written by a human being, or could be generated programmatically from the information contained in the rest of the document.

Service Provider, Service Consumer and Third Party. The first two classes are rather self-explanatory but the last one, Third Party, deserves a word. In a large-scale service-oriented architecture, it is quite unlikely that the collection of data and the enforcement of the contract will be performed directly by the service provider or the service consumer. A first reason is that contract enforcement is, by nature, a very orthogonal concern and therefore is a very good candidate for outsourcing. Moreover, it is a feature of quite a technical nature; hence it is best left to a specialised party. Finally, and this is probably the strongest argument in favour of outsourcing, it is difficult from a legal point of view to have one of the contractual party also play the role of the enforcement party. The value of any conclusion reached by that party would very likely be challenged by the other party if a conflicting situation arises. This is why this feature is best left to a third party trusted by both the service provider and the service consumer.

Obligations. This is the real core of an e-contract document. The obligations describe the actual terms of the contract, i.e. they describe in a non-ambiguous and machine-processable manner all the constraints that the parties have to comply with in the process of providing and consuming the service. Given that the particulars of the description of obligations vary a lot between the different e-contract systems that we have studied, we made the decision not to drill down any further in what actually an obligation is composed of.

Metric. The only exception to the rule state right above is that all the different implementation of the notion of obligation have one thing in common: they are all expressed in term of metrics, i.e. a way to obtain a reading of a measurable quantity that is used in the expression of one of the obligations.



9 Part III: Agents and Web services

9.1 IntroductionIn [33] a Web service is defined as

“a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.”

The authors continue:“A Web service is an abstract notion that must be implemented by a concrete agent. The

agent is the concrete piece of software or hardware that sends and receives messages, while the service is the resource characterized by the abstract set of functionality that is provided. To illustrate this distinction, you might implement a particular Web service using one agent one day (perhaps written in one programming language), and a different agent the next day (perhaps written in a different programming language) with the same functionality. Although the agent may have changed, the Web service remains the same.”

These definitions and explanations suggest that the concept of an agent is already customary in the Web Service context and the relation between Web services and agents is clear. However, the term, as it is used here, does not or only partially reflect the full features of agents and multiagent systems (MAS) as they are conceived in current ambitious agent theories. It will become clear that the term agent refers not (only) to the concrete instance behind a service but to a conceptual and design aspect of the architecture behind the service, as well as to a means for modelling the interactions between entities. Furthermore, agent platforms such as the JACK agent framework offer ways for modelling and flexible execution of business processes and Web service composition, i.e. they offer services which themselves consist of processes consuming and composing Web services. Agents act on both sides of a service interface, as service providers as well as service consumers, comparable to a BPEL4WS process. But unlike a BPEL4WS process, an agent-based approach provides inherent flexibility and adaptability even while executing a process.

9.2 ConceptsAgent theories provide support to the conceptual and programmatic encapsulation of autonomous,

goal-driven behaviour for a wide variety of applications and software solutions.In the literature about agents, two concepts of agency are prevailing, a “weak” notion, and a

stronger notion which is based on concepts that are more usually applied to humans.

9.2.1 A weak notion of agencyPerhaps the most general way in which the term agent is used is to denote a hardware or (more

usually) software-based computer system that enjoys the following properties [14]: autonomy: agents operate without the direct intervention of humans or others, and have some

kind of control over their actions and internal state [34]; social ability: agents interact with other agents (and possibly humans) via some kind of agent-

communication language [35]; reactivity: agents perceive their environment, (which may be the physical world, a user via a

graphical user interface, a collection of other agents, the Internet, or perhaps all of these combined), and respond in a timely fashion to changes that occur in it;

pro-activeness: agents do not simply act in response to their environment, they are able to exhibit goal-directed behaviour by taking the initiative.

A simple way of conceptualising an agent is thus as a kind of UNIX-like software process, that exhibits the properties listed above. This weak notion of agency has found currency with a surprisingly wide range of researchers. For example, in mainstream computer science, the notion of an agent as a self-contained, concurrently executing software process, that encapsulates some state and is able to communicate with other agents via message passing, is seen as a natural development of the object-based concurrent programming paradigm [36, 37].

9.2.2 A strong notion of agencyA more ambitious notion characterises an agent using mentalistic notions, such as knowledge,

belief, intention, and obligation [15]. The most commonly studied architecture for deliberative agents is



the belief-desire-intention (BDI) model [38]. Since this is, at its core, a model founded on a view of practical reasoning, it is well suited to be the basis of a robust implementation.

The use of explicit mental attitudes, it has been argued, allows the agent to manage its internal structures and external environment, and so achieve a balance between optimal behaviour and resource limitations. A common choice of foundational mental attitudes is the set belief, desire, and intention [38]. BDI agents have been extensively studied in the agent literature, and have attracted both formal logical characterisations [39] and (rather fewer) practical implementations and re-usable tools (e.g. [40]). For more details, see section 9.3.2 and Annex 10 of working document WD.A5.1 [5].

9.2.3 Speech-act-based communication and protocolsSocial ability is one of the standard properties attributed to agents. In order to allow for agents

engaging in dialogues like people, e.g. replacing or supporting people in auctions, they need to be able to express their intentions in a way, such that other agents are able to differentiate the contents of the message from the overall goal of the message. Here is where speech act theory comes into play [41]. This theory distinguishes between the pure content of a message and its intended meaning or the effect it should have. Basically a speech act is intended to trigger actions, or changes of internal states of the addressee. Most agent-based system’s communications have their roots in the speech act theory.

For participating in communication, agent may use actions or communicative acts, which are basically pragmatic applications of speech acts: they are intended to perform some action by virtue of being sent. The two major collections of such speech-act-based communication actions that have evolved during the last years are KQML, as an academic effort, and FIPA-ACL, as a more industrially inspired development. Both were aiming at standardizing speech-act-based message exchange for agents in open, networked environments. Today they have been joined and the main result is FIPA-ACL, which basically provides agent-system designers with a standardized collection of speech acts for message exchange. Still, the content of such messages needs to comply with a problem-specific domain ontology.

In KQML these messages were called performatives, whereas FIPA-ACL denotes them as communicative acts. The following example shows the main structural characteristics for the messages:

(ask

:sender agent customer

:receiver agent bookshop

:content (<price> 059035342X </price>)

:language (XML)

:ontology bookshop)The message is structured with brackets. The first line denotes the type of speech act, or rather

the performative/communicative act. The next two lines denote the sender and the receiver of the message, such information may be more complex than the example and thus used for routing and message delivery. The content field contains the actual information for the receiver. The language field denotes the language in which the context is given. In our example we chose XML, however, FIPA has specified several more specific content languages in order to allow for flexibility and interoperability (FIPA-CLL). The meaning is given in the ontology slot, which helps the receiver to interpret it. The message as a whole describes the question for the price of a book, denoted by the ISBN.

The major advantage of speech act based communication can easily be seen from this example: this is a standard syntactic wrapper for the contents to be communicated.



Figure 29. FIPA contract net interaction protocolSpeech-act-based communicative acts are used in order to perform structured conversations

between agents. These conversations are called protocols and many of them are now commonly used in a large variety of agent applications. The most prominent among these is the Contract Net Protocol [42]. Figure 29 shows a sequence diagram of the protocol, which is used to announce a task to different qualified cooperation partners. In this protocol, agents can either act as manager (announcing a task) or as bidders (competing for the respective task). The manager announces the task to a set of possibly qualified agents able to fulfil it. These compute a bid and send it back in an answer, which is evaluated by the original announcer of the task, the manager of the respective protocol. The manager collects all bids and evaluates them according to its preferred means of measure. This can be a kind of utility or the cheapest price, the level of service promised etc. Then, the manager sends out a grant message to the agent with the preferred bid, while the others receive reject messages. There are many variants of this protocol, including e.g. time limits for the collection of bids.

9.2.4 Agents and services: A comparison Similar to Web services, agents can also be used to encapsulate some business or application

logic, but differ in that they do not simply expose functionality as methods over a fixed protocol. Rather, agents can offer multiple services, or behaviours, that can be processed concurrently and activated by specifying goals. A goal, instead of identifying a particular method to be invoked, states an abstract objective to be achieved using whatever resources the agent has available, including knowledge and action behaviours. By these means an agent is capable of making proactive and autonomous decisions about how to act in a given situation

Services are loosely coupled, self-contained, autonomous entities with support for description, publishing, deployment, discovery and invocation. The encoding and protocol stack typically used for creating and publishing Web services includes the following technologies: WSDL, SOAP and UDDI. WSDL is the standard means for expressing Web service descriptions. SOAP is a protocol defining the



exchange of messages containing Web service requests and responses. UDDI is the directory services schema commonly used to register and discover Web services.

Applying the weak notion of agency, agents and services have common properties, especially autonomy. However, characterising agent systems with the stronger notion of agency distinguishes them from services [43]: A service knows only about itself, but not about its users, clients or customers. Agents are often

self-aware at a metalevel, and through learning and model building gain awareness of other agents and their capabilities as interactions among the agents occur.

Services, unlike agents, are not designed to use and reconcile ontologies. If a client and the provider of a service happen to use different ontologies, then the result of invoking the Web service would be incomprehensible to the client. Agents can mediate such differences.

Agents are inherently communicative (see section 9.2.3), whereas services are passive until invoked. As new information becomes available, agents can provide alerts and updates. Current standards and protocols make no provision for different interaction patterns, such as subscribing to a service to receive periodic updates.

For services to apply naturally in open environments, they should be modelled as being autonomous. Autonomy is a natural characteristic of agents, and it is also characteristic of many envisioned Internet-based services. Among agents, autonomy generally refers to social autonomy, where an agent is aware of its colleagues and is sociable, but nevertheless exercises its in dependence in certain circumstances. Autonomy is in natural tension with coordination or with the higher-level notion of commitment. To be coordinated with other agents or keep its commitments, an agent must relinquish some of its autonomy. However, an agent that is sociable and responsible can still be autonomous. It would attempt to coordinate with others where appropriate and to keep its commitments as much as possible, but it would exercise its autonomy in entering into these commitments in the first place.

Agents are cooperative, and by forming teams and coalitions can provide higher-level and more comprehensive services. Current standards for Web services provide limited support for composing functionalities.

It becomes apparent from this discussion that the capabilities of agents go beyond those of services. The term agent refers to the way an entity is conceived, modelled or designed, whereas the term service refers to a way an entity is used in a specific context. Especially in the context of Service-oriented architectures, the aim is to abstract from the way a service is implemented and to expose the interface of the service only, wrapping the underlying system. Agents and multiagent systems chiefly address these aspects of a design and modelling perspective which is usually hidden in a service-oriented view. From an external point of view, an agent offers a service similar to a Web service. From an internal point of view, an agent is more than just a service.

9.3 ArchitectureAlthough agents and services are – considered on an internal, conceptual level – different, when

regarding the architectural and technical level (the external view), Web services and agent architectures are two approaches for distributed programming. In section 10, we describe the FIPA abstract architecture in detail, as well as a mapping between FIPA and SOAP messages. Considered as architectures, agents and Web services can be technically combined to interoperate with each other.

In fact, there are several approaches to glue agent platforms and Web services together, e.g. Whitestein’s Gateway architecture for enabling transparent, automatic connectivity between Web services and agent services (WSIGS, [44]).

9.3.1 WS gatewayWSIGS is a stand alone, encapsulated service that provides transparent, bidirectional

transformations between FIPA compliant agent services and Web services that use the standard Web Service stack (WSDL, SOAP and UDDI), implemented using the JADE agent platform [45].

The following assumptions were made when designing the WSIGS architecture: All agents are assumed to be FIPA compliant and capable of communicating with FIPA-ACL

encoded messages. All Web services operate using the standard Web service stack consisting of WSDL for service

descriptions, SOAP for message encoding and UDDI for directory services. The WSIGS is designed as a platform service accessible to both agents running on and external

to JADE platforms, and Web service clients operating from any accessible network locations.



The WSIGS is registered as an agent service in FIPA Directory Facilitators and as a Web service endpoint in UDDI directories.

All interactions between the WSIGS and agents use ACL encoded FIPA-Request and FIPA-Inform performatives [46]. These simplify the operation of the WSIGS and are essentially all that is needed to invoke basic request-response Web services.

All ontologies used by agents are published and available to the WSIGS in a machine readable form.

As illustrated in Figure 30, the WSIGS contains several operational components, including a FIPA compliant Directory Facilitator (DF) and a Web service stack compliant UDDI repository. These internal registries are at the heart of the WSIGS, maintaining records of all agent and Web service descriptions that have been registered with, and can be invoked via, the Gateway.

Figure 30. Functional overview of the WSIGS architecture entitiesAccess to these registries is provided to both agents and Web service clients by exposing

appropriate interfaces providing the standard operations: Registration of a new service description. Deregistration of an existing service description. Modification of an existing service description. Searching for a registered service description.

The main problem with the WSIGS approach is the decision to choose the JADE agent platform as underlying infrastructure. While JADE is supporting communication between agents, it provides only basic structures for modelling the processes an agent participates in and executes (i.e. JADE only provides support for the weak notion of agency). For applying agents in a business process context, a different approach is therefore necessary.

9.3.2 BDI agent framework for Web servicesThe aim of the extended JACK agent framework for Web services is to provide a goal-oriented

business service composition and execution module within a service-oriented architecture.Following the Belief Desire Intention (BDI) model agents are autonomous software components

that have explicit goals to achieve or events to handle (desires). To describe how they should go about achieving these desires, these agents are programmed with a set of plans. Each plan describes how to achieve a goal under varying circumstances. Set to work, the agent pursues its given goals (desires), adopting the appropriate plans (intentions) according to its current set of data (beliefs) about the state of the world. This combination of desires and beliefs initiating context-sensitive intended behaviour is part of what characterises a BDI agent.

A BDI agent is a software component that can exhibit reasoning behaviour under both pro-active



(goal directed) and reactive (event driven) stimuli. Each agent has: a set of beliefs about the world (its data set); a set of events that it will respond to; a set of goals that it may desire to achieve (either at the request of an external agent, as a

consequence of an event, or when one or more of its beliefs change); and a set of plans that describe how it can handle the goals or events that may arise.

When an agent is instantiated in a system, it will wait until it is given a goal to achieve or experiences an event that it must respond to. When such a goal or event arises, it determines what course of action it will take. If the agent already believes that the goal or event has been handled (as may happen when it is asked to do something that it believes has already been achieved), it does nothing. Otherwise, it looks through its plans to find those that are relevant to the request and applicable to the situation. If it has any problems executing this plan, it looks for others that might apply and keeps cycling through its alternatives until it succeeds or all alternatives are exhausted.

Thus, an agent can be thought of as a person with access to a Procedures Manual. The Procedures Manual (set of plans) describes the steps that the agent should take when a certain event arises or when it wants to achieve a certain outcome. At first glance, this may seem like ordinary Expert System behaviour-with all the limitations that this implies. However, the crucial difference in agent-oriented systems is that the agent is able to be programmed to execute these plans just as a rational person would. In particular, it is able to exhibit the following properties associated with rational behaviour: Goal-directed focus: the agent focuses on the objective and not the method chosen to achieve it. Real-time context sensitivity: the agent will keep track of which options are applicable at each

given moment, and make decisions about what to try and retry based on present conditions. Real-time validation of approach: the agent will ensure that a chosen course of action is pursued

only for as long as certain maintenance conditions continue to be true. Concurrency: the agent system is multi-threaded. If new goals and events arise, the agent will be

able to prioritise between them and multi-task as required.Applications which deploy agent technologies are usually comprised of a possibly large number of

individual agents. Systems in which at least two instances of individual agents are active are normally referred to with the term multiagent systems.

Coming back to the design of individual agents, there are several tools to design BDI agents available (e.g. [28, 40]). Although most of the concepts discussed in this section are available in most of these tools in one way or another. However, the ways to deal with specific concepts varies between different development tools. We therefore decided to use the Jack™ Intelligent Agents development environment (JDE [28]) for designing agents in the context of the ATHENA programme. A major advantage of JDE is that it allows using graphical models for the specification of agent behaviours. We consider these models as the PSM level for agent design. Important to note is that these PSM models are directly executable in the runtime environment of JDE.

BDI agents support adaptive execution which is introduced by flexible plan choice, in which the current situation in the environment is taken into account. A BDI agent has the ability to react flexibly to failure in plan execution, where both features are directly built into the framework of BDI reasoning.



BDIPlan/WorkflowLibrary

JACKAgentFrame-work

JACKAgentFrame-work

specify use

OntologyOntology

Services

Service Composition

Planner

MediationSupport

Tool

Design Time WS Service Composition Run-time

ExecutionPlan

Dynamic Service Selection

Services

KnowledgeBase

ParameterMapping

Parameter Mediation

Annotation

use

Design TimeService SelectionSupport

Figure 31. Extended JACK agent framework for Web service composition and executionFigure 31 shows an overview of the extended JACK architecture for Web service composition and

execution. It contains as its core the JACK agent framework with plan library and knowledge base. Distinguishing design time and run-time phase, Web service composition and plan execution is supported by the extended JACK agent framework. Following the MDA approach, a modeller specifies during design time a set of plans (PSM level) that constitute the workflow library of the agents. For atomic Web service calls, a design time support for selection and call integration will be provided. Atomic calls are integrated as steps into plans. Composing internal and external services during design time, fixed service calls can be integrated into executable plans. JACK allows to model workflows graphically, and supports most of the common workflow patterns. The details of adaptive workflow modelling with JACK, especially regarding the MDA approach, are explored in the context of ATHENA project A6.

As a trade-off between fully fixed Web service composition (e.g. WS-BPEL) and online planning, the extended JACK agent framework takes the middle course. The BDI agent Web service composition framework allows specifying a library of plans. During execution, plans are selected according to their ability to help accomplishing a given goal. If a plan fails (e.g. due to a failed service call), another plan is checked which might eventually achieve the envisioned goal. Thus, adaptability and flexibility is accomplished, and the possibility of a failure is reflected in the conceptual framework which makes it natural to cope with failures.

However, it might be the case that a modeller wants to allow a certain degree of freedom for several plan steps. In this case the extended JACK framework contains an online planning component which allows composing services at run-time. The online composition planer takes a description of the initial state and the goal state as input and generates a plan which leads from the initial state to the goal by using the available services as steps towards the goal.

At run-time, services are either used according to the specification at design time, or bound and invoked dynamically. In the latter case, while the type of service required is fixed at design time, the concrete service endpoint invoked is discovered using a registry. The main problem with using services dynamically is to know how to map the values of input and output parameters of a service. Therefore, the inclusion of semantically described services into the workflow is supported in a twofold way. Annotation is needed on both sides, the agent knowledge/beliefs about the world, and the services invoked during run-time. We assume the services to be described using e.g. OWL-S (see section 6.4.2) with a grounding to WSDL descriptions. In general it will not be the case that there is exactly one ontology which is used to formulate the agent's beliefs and the service descriptions. In this case the agent's beliefs must contain translations between the ontologies used in a scenario.



For a service to be admissible for an agent A for each concept C in a service description there must be a concept D in the agent's ontology such that the agent believes that D translates to C. Furthermore for an admissible service to be invokable at time t there has to be an x such that agent A believes at time t that C(x) for each C pertaining to an input parameter of the service.

In order to map input and output values properly, the agent’s ontology is annotated by refering to a shared ontology (in case the shared ontology is already known when designing the agent’s ontology this step is omitted; for a discussion of the problems involved see ). While executing, an agent updates its belief set using the semantic annotation entered at design time. When an invokable service conforming to a specified requirement is discovered, the input and output values are mapped according to the annotation.

The composition framework acts itself as a service and is published as a Web service to be used in the context of a service-oriented architecture. A call to the framework specifies a goal (e.g. “product ready for shipping”) which the framework tries to achieve.

9.4 Conclusion In this chapter, we compared the concepts behind Web services and agent architectures.

Whereas services can be characterised by some of the “weak” notions usually attributed to agents, the stronger notion of agency goes beyond the standard concept of a service. We described the WSIGS Web service agent integration gateway. The gateway is based on the JADE agent middleware; the drawback is that it hardly supports the stronger notion of agency needed for process modelling. We presented an overview of the extended JACK agent framework for Web service composition and execution which is based on the BDI agent model.



10 FIPA infrastructure

As discussed in the previous chapter, agents offer and consume services. In the agent research area, the three roles characterising a service oriented architecture discussed in section 2.1 were already seen rather early as a central theme, and the most influential approach for defining an architecture for service publishing, discovery and usage is the FIPA Abstract Architecture [47]. It defines at an abstract level how two agents can locate and communicate with each other by registering themselves and exchanging messages. This section will describe the elements of this architecture and the relationship between them.

The architecture defines a basic services-model that includes the following services: Agent-Directory-Service Service-Directory-Service Message-Transport-Services

On start-up an agent must be provided with a service-root. Typically the provider of the service-root will be a service-directory-service which will supply a set of service-locators for available agent lifecycle support services, such as message-transport-services, agent-directory-services and service-directory-services. In general, a service-root will provide sufficient entries to either describe all of the services available within the environment directly, or it will provide pointers to further services which will describe these services. 10.1 Agent directory services

The basic role of the agent-directory-service is to provide a location where agents register their descriptions as agent-directory-entries. Other agents can search the agent-directory-entries to find agents with which they wish to interact.

The agent-directory-entry is a key-value-tuple consisting of at least the following two key-value-pairs:

Agent-name A globally unique name for the agent

Agent-locatorOne or more transport-descriptions, each of which is a self describing structure containing a transport-type, a transport-specific-address and zero or more transport-specific-properties used to communicate with the agent

In addition the agent-directory-entry may contain other descriptive attributes, such as the services offered by the agent, cost associated with using the agent, restrictions on using the agent, etc.

10.1.1.1 Service directory servicesThe basic role of the service-directory-service is to provide a consistent means by which agents

and services can discover services. Operationally, the service-directory-service provides a location where services can register their service descriptions as service-directory-entries. Also, agents and services can search the service-directory-service to locate services appropriate to their needs.

The service-directory-service is analogous to but different to the agent-directory-services; the latter are oriented towards discovering agents whereas the former is oriented to discovering services. In practice also, the two kinds of directories may have radically different reifications. For example, on some systems a service-directory-service may be modelled simply as a fixed table of a small size whereas the agent-directory-service may be modelled using LDAP or other distributed directory technologies.

The entries in a service-directory-service are service descriptions consisting of a tuple containing a service-name, service-type, a service-locator and a set of optional service-attributes. The service-locator is a typed structure that may be used by services and agents to access the service.

Service-directory-entry:

Service-name A globally unique name for the serviceService-type The categorized type of the serviceService-locator One of more key-value tuples containing a signature type, service signature and

service address eachAdditional service-attributes may be included that contain other descriptive properties of the

service, such as the cost associated with using the service, restrictions on using the service, etc.As a foundation for bootstrapping, each realization of the service-directory-service will provide



agents with a service-root, which will take the form of a set of service-locators including at least one service-directory-service (pointing to itself).

10.2 Message transport service and agent communicationIn FIPA agents communicate with one another by sending messages. Three fundamental aspects

of message communication between agents are the message structure, message representation and message transport.

10.2.1 Message structureThe structure of a message [48] is a key-value-tuple and is written in an agent-communication-

language, such as FIPA ACL. The content of the message is expressed in a content-language, such as KIF or SL.

Messages contain the sender and receiver names, expressed as agent-names. Every message has one sender and zero or more receivers. The case of zero receivers enables broadcasting of messages such as in ad-hoc wireless networks.

Content expressions can be grounded by ontologies referenced within the ontology key-value-tuple.

10.2.2 Message transport When a message is sent it is encoded into a payload, and included in a transport-message. The

payload is encoded using the encoding-representation appropriate for the transport. For example, if the message is going to be sent over a low bandwidth transport (such a wireless connection) a bit efficient representation may be used instead of a string representation to allow more efficient transmission.

Transport-messages are composed of a payload and an envelope. The envelope includes the sender and receiver transport-descriptions. The transport-descriptions contain the information about how to send the message (via what transport, to what address, with details about how to utilize the transport). The envelope can also contain additional information, such as the encoding-representation, data related security, and other realization specific data that needs be visible to the transport or recipient(s).

Figure 32. A message becomes a transport message

In the above diagram, a message is encoded into a payload suitable for transport over the selected message-transport. It should be noted that payload adds nothing to the message, but only encodes it into another representation. An appropriate envelope is created that has sender and receiver information that uses the transport-description data appropriate to the transport selected. There may be additional envelope data also included. The combination of the payload and envelope is termed as a transport-message.

A directory entry for communicating with a desired agent is shown next, along with a usage example of such an entry and how it is to be interpreted:

For an arbitrary agent with name ABC:

Directory entry for ABC



Agent-name: ABC

Agent Locator:

Transport-type Transport-specific-address Transport-specific-propertyHTTP http://www.whiz.net/abcEndpoint (none)SMTP [email protected] (none)

Agent-attributes:

Attrib-1: yes

Attrib-2: yellow

Language: French, German, English

Preferred negotiation: contract-net

Another agent can communicate with agent “ABC” using either transport-description, and thereby know which agent it is communicating with. In fact, the second agent can even change transports and can continue its communication. Because the second agent knows the agent-name, it can retain any reasoning it may be doing about the other agent, without loss of continuity.

10.2.3 InteroperabilityFIPA Abstract Architecture makes provision for interoperability in two ways:

Transport: contains information necessary for a particular transport to send a message to the corresponding agent

Message Representation: Encoding used for representing the message structure and contentsThe semantics of agent communication require that an agent’s name be preserved throughout its

lifetime, regardless of what transports may be used to communicate with it, in order to ensure continuous communication.

10.3 Architectural elements10.3.1 Agent

An agent is a computational process that implements the autonomous, communicating functionality of an application. Typically, agents communicate using an Agent Communication Language.

10.3.2 ServicesThere are two kinds of services: the ones that conform the FIPA Infrastructure and the ones

agents provide. A service is defined in terms of a set of actions that it supports. Each action defines an interaction between the service and the agent using the service.

10.3.3 Agent communication languageAgent-communication-language (ACL) is a language in which communicative acts can be

expressed and hence messages constructed.

10.3.4 Content languageA content-language is a language used to express the content of a communication between

agents. FIPA allows considerable flexibility in the choice, form and encoding of a content language. However, content languages are required to be able to represent propositions, actions and terms (names of individual entities) if they are to make full use of the standard FIPA performatives. Examples of performatives or speech acts are [49]: Request, response, cfp (call for proposals), accept, reject, query_if, not_undertstood, etc.

10.3.5 OntologyAn ontology provides a vocabulary for representing and communicating knowledge about some



topic and a set of relationships and properties that hold for the entities denoted by that vocabulary.

10.4 Agent management reference modelAgent management provides the concrete normative framework within which FIPA agents exist

and operate. It establishes the logical reference model for the creation, registration, location, communication, migration and retirement of agents. Implementation details of individual Agent Platforms (AP) and agents are the design choices of the individual agent system developers.

Figure 33. Agent platform reference modelThe agent management reference model consists of the following logical components [50], each

representing a capability set (these can be combined in physical implementations of APs): An agent is a computational process that implements the autonomous, communicating

functionality of an application. Agents communicate using an Agent Communication Language. An Agent is the fundamental actor on an AP which combines one or more service capabilities, as published in a service description, into a unified and integrated execution model. An agent must have at least one owner, for example, based on organisational affiliation or human user ownership, and an agent must support at least one notion of identity. This notion of identity is the Agent Identifier (AID) that labels an agent so that it may be distinguished unambiguously within the Agent Universe. An agent may be registered at a number of transport addresses at which it can be contacted.

A Directory Facilitator (DF) is an optional component of the AP, but if it is present, it must be implemented as a DF service. The DF provides yellow pages services to other agents. Agents may register their services with the DF or query the DF to find out what services are offered by other agents. Multiple DFs may exist within an AP and may be federated. The DF is a reification of the Agent Directory Service in [47].

An Agent Management System (AMS) is a mandatory component of the AP. The AMS exerts supervisory control over access to and use of the AP. Only one AMS will exist in a single AP. The AMS maintains a directory of AIDs which contain transport addresses (amongst other things) for agents registered with the AP. The AMS offers white pages services to other agents. Each agent must register with an AMS in order to get a valid AID. The AMS is a reification of the Agent Directory Service in [47].

An Message Transport Service (MTS) is the default communication method between agents on different APs [46].

An Agent Platform (AP) provides the physical infrastructure in which agents can be deployed. The AP consists of the machine(s), operating system, agent support software, FIPA agent management components (DF, AMS and MTS) and agents.

10.5 Mapping FIPA to WS-Addressing: A ProposalIn this section we present a new way of representing FIPA Agent communication language (ACL)

messages using the first results reported by WS-Addressing. Since this problem actually requires the mapping of many aspects between FIPA and Web Services, like description of services provided this way by agents, the ontologies involved, specially those related to domain specific concepts, among



others, the present work will focus specifically in the case of translating the domain independent contents of Web Services messages complying WS-Addressing to FIPA ACL messages and vice versa. For this purpose we will provide a mapping of contents of FIPA and WS-Addressing envelopes. In the case of WS-Addressing we will map to the contents in an End Point Reference (EPR).

The proposal states that once a representation of FIPA ACL messages is specified using WS-Addressing, the rest of FIPA specifications that construct on top of it can be used to create the same agent oriented structure and architecture within a WS-Addressing compliant environment and hence building the fundament for porting FIPA contributions to Service Oriented Computing based on Web Services.

In the next two sections a brief overview of the concepts involved in the presented work will be exposed, in section 10.5.1 those of FIPA and in section 10.5.2 those of WS-Addressing. Next, in section 10.5.3 the way FIPA Conversation Patterns can be realized using WS-Addressing will be exposed at an abstract level. Section 10.5.4 is the concept mapping between these two technologies.

10.5.1 FIPA agent communication specificationFIPA is an organization focused on the specification of several aspects related to agents. It has

provided over 90 specification documents all of them focused on interoperability of agent implementations. One important part of these specifications are about communication between agents and how this communication can be implemented in a way that is interoperable but at the same time covers all necessary aspects that allow reasoning and autonomy of agents. Agents are one of the preferred way for implementing systems with a higher level of complexity and where communication, autonomy play an important role . The importance of using FIPA specifications relies on the wide acceptance and usage they have in the Multiagents Systems (MAS) community. The majority of investigations about agent communication are based on top of these specifications, some of them very relevant to the SOA community, especially those about dynamic planning of services (composition of services), conversations patterns and protocols or autonomous negotiation.

Figure 34 shows how communication specifications in FIPA are built one on top of another.

Figure 34. FIPA communication specification stackLooking at it from the bottom up, implementations of communication are grounded on a specific

way of representing messages. First of all the representation of the message envelope is specified, which contains transport specific information required in every single message, independently of their context. A way of representing the contents is also specified in a similar manner. These concrete representations can be based on any appropriate representation technique, like bit efficient, Strings following a specific syntax, XML, etc. Message contents and envelope form together a Transport message which is the realization of a FIPA ACL Message. The FIPA ACL Message is one of the fundamental elements in this Stack. It is the description of a Message in an abstract level and specifies all the information that has to be present in every message and how contents is to be organized and interpreted [46]. This specification is used both for making the grounding of messages and also as the basic structure on which the rest of the Stack is built. Using the structure and guideline for FIPA ACL messages, the different kinds of messages are declared, first as primitive speech acts and then as combination of them: composite speech acts. There are certain well known situations in which a specific sequence of speech acts are expected. These situations are called protocols and they are a pre-agreed way of how these message exchanges should be preformed. Interaction protocols are a very important concept in FIPA and based on these many agent-based solutions are implemented. These protocols can be very helpful in the business-process scenario.

We propose a concept mapping between message properties used in WS-Addressing (shown in the next section) and those specified by FIPA. For this purpose, the basic structure of a FIPA Envelope is laid out:

A FIPA message envelope is composed of : Sender: Agent Identifier (AID) of the sender of the message Receiver: AID of the intended receiver of the message



Communicative-act: The speech-act the message is Language: The language used for the content Encoding: Encoding used for the content Ontology: Ontologies used in the content Protocol: The protocol(s) this message is part of Reply-With: A token to use in a reply for message correlation In-Reply-To: The token identifying the message being replied Reply-By: Time constraint for the reply Reply-To: Instructions about where to send the reply to Conversation-ID: The ID of the conversation this is part of User-Defined: Extra fields left for user specific purposes Content: The content of the message It is important also to remark that an AID is composed of three parts: name: The unique identifier of the agent address: The different addresses the agent provides to be contacted The addresses of different directories where the agent can be found.

Based on these properties all FIPA compliant messages are generated and interpreted. Even though there is still a lot of freedom left for further structuring of the messages, these properties cover the most relevant context independent ones. FIPA messaging framework is based on top of this structure.

10.5.2 WS-AddressingWeb Services Addressing (WS-Addressing) [51] (see also Annex DA5.2 [2]) provides a transport

neutral mechanism to address messages in a Web Services environment. It is based on a specification of properties each message should have in order to facilitate the end-to-end addressing of endpoints in messages. These properties are organized within a structure called Endpoint Reference.

An EPR is a construct designed to support: Dynamic generation and customization of service endpoint descriptions. Referencing and description of service instances that are created as a result of stateful

interactions. Exchange of endpoint information in tightly coupled environments where participants share a set

of common assumptions about specific policies or protocols used during the interaction.Following is a brief summary of what an EPR is and how it is structured. For further details please

see [51]. This description only highlights the aspects relevant to this paper. An EPR is composed of (All elements are optional unless otherwise specified): Address: Mandatory, the address of the EPR Reference Parameters: A set of parameters associated with the EPR Metadata: Behaviour, policies and capabilities of the EPR Additional abstract properties: Destination: IRI representing the address of the intended receiver Source Endpoint: Reference to the Endpoint from which the message was originated Reply Endpoint: EPR for the receiver of replies to the message Fault Endpoint: EPR for the receiver of faults related to the message Action: Mandatory, an IRI that identifies the semantics implied by the message Message-ID: An IRI that uniquely identifies the message Relationship: A relationship – message-id pair which indicate how this message relates to

another message, both values in the pair are of type IRI.

10.5.3 FIPA conversation protocols realization using Web servicesIn order to use the paradigm of Speech Acts (SA) in Web Services, the basics for these have to be

ported to Web Services. The objective is to make Web Services the communication platform to use by agents. In order to achieve that, there must be a specification of how information present in each message envelope will be represented in the other.

As shown in section 10.5.1, the speech act library and conversation patterns are based on top of the FIPA Message Envelope . FIPA specifications rely on representations of the envelope for grounding the rest of specifications at a low level. The Speech Act library for instance, is based on this and refers to the fields in the envelope in an abstract manner, hence it ensures freedom in choosing how an implementation will be grounded. This means that once a concept mapping between envelopes for FIPA and WS-Addressing is completed, several speech act based frameworks, like



conversation patterns will be easier to develop using Web Services. Figure 35 illustrates how the FIPA Stack would be placed on top of WS-Addressing.

Figure 35. Realization of the FIPA communication stack using WS-Addressing as a groundingThe key part of the integration is the mapping of envelope information. How this mapping is to be

performed and what properties it must have will be shown in the next sections.The clear benefit of this approach is that the complete FIPA messaging techniques will be ported

to Web Services taking advantage of the way these FIPA specifications are made on top of the abstract FIPA ACL message. Using this mapping, these specifications can then be translated to a WS-Addressing realization, making the same abstractions that were done on top of the FIPA representations, but this time using WS-Addressing specifications for this purpose. With this conceptual mapping a direct realization, or in other words, a FIPA Message Representation using WS-Addressing is possible and is actually one of the main goals in the present work.

10.5.4 Envelope structure conceptual mappingEnvelopes as used in FIPA and WS-Addressing share a lot of similarities which is not surprising,

since these serve the same purpose. Still there are some concepts which differ in some degree. Properties that share the same purpose must be linked together, properties that follow a very similar concept will be also associated, but with some extra information of how the small difference is to be covered. There are concepts that definitely will not be present in the other paradigm, in this case the mapping is to provide a way of how to represent it in the other schema and any extra processing required to overcome the gap. Therefore a mapping can be specified between some single elements and other single elements or between single elements and composed elements on the other side. This means that a property in WS-Addressing or in the FIPA specification is not necessarily an element in the domain or codomain, since there are some elements in the domain or codomain that are actually composed of two or more properties. This has relevant implications in the way some properties are to be handled in this mapping, in order to ensure the functionality of it.

The most important property of such a mapping is that it has to be bijective: it has to be injective on one side and surjective on the other. It has to be injective in that linked elements in the codomain are linked with a single concept in the domain. It has to be surjective in that all elements in the codomain are to be linked to a property in the domain. If the mapping complies with these two properties, it will be bijective: it will be possible to map concepts from one domain to the other and vice versa. It also means that each translation done in one direction has to lead to the original message when translated back.

Figure 36 shows the complete mapping relations, properties belonging to FIPA specs on the left side, those belonging to WS-Addressing to the right and arrows linking them together. These arrows can be continuous or dotted if they represent strict relations or relations that are somehow optional respectively. Details about each option will be seen later.



Figure 36. FIPA – WS-Addressing concept mappingAs mentioned previously, some properties on one side can be linked to several on the other side,

binding these mapped-to properties as a single element in the codomain. This raises one discrepancy between the FIPA-Model and the one proposed by WS-A: The lack of standardization in the FIPA model of handling of exceptional cases. The reason might be that in MAS the way faults are handled is basically left free to each platform implementation. This means that a specific platform would have to extend the presented mapping in order to fit its fault management situation framework. In the presented mapping, FIPA’s Reply-to is linked to reply and fault-endpoints in WS-A, which in this case is interpreted as mapping the information in the Reply-to property to the reply and fault-endpoint and in the inverse case, the fault-endpoint is to be overwritten by the reply-endpoint information. A better option would be to extend FIPA’s properties with one carrying fault-to information, but this option is not used in the current paper, in order not to constraint any AP-specific framework for the management of faults. Another special case is the AID handling: AIDs are structured and some times they are used as a whole, some others just specific fields are used. In the first case a link is made to the curly bracket grouping the AID, in the second the flag goes on directly to the specific field. In the rest of this section each relation will be explained and discussed in the order as they appear on the left side.

The first three fields are the parties involved in the interaction: the receiver, sender and a reply to. These concepts are well defined in each of the paradigms: AIDs on behave of FIPA and EPRs on behave of WS-Addressing. In the case of WS-Addressing the targeted EPR, the one that corresponds to the destination of the message is actually the complete EPR on the right side. In the case of sender and reply-to, the EPR is the one present inside the corresponding element of the EPR of the message. In order not to loose the details inside the AID, a special extra element called AID is added in order to add the complete AID as provided by FIPA as annotation for later use. One interesting detail about the mapping is the actual link established between the speech act field and the action in the EPR. In both cases this property carries the semantic meaning of the message, independently of the perspective the message is seen from. Reply-With is an identifier provided by the sender of the message for it to be used in the In-Reply-To in the corresponding reply of the message. These properties share the same semantics as message-id and relationship in an EPR. The only difference one might notice is the lack of typification of In-Reply-To when compared to relationship. Relationships carry always the type of relation, for instance a direct reply, a fault, an agreement of disapproval, etc. This meaning is normally inferred by the receiving agent, based on the contents or the act property. The rest of the properties are annotated in the EPR since these are properties relative to the contents. In this section it is assumed that a description of the participant services was provided in which these contents-specific issues are clearly specified.

10.5.4.1 Example of a bidirectional mappingThe following example shows how the proposed mapping could be put to practice. The proposal

consists of a translation module that uses the concept mapping as a set of rules for translating and generating the contents of messages. In this specific case it is supposed that FIPA agents are communicating using the FIPA XML Message Envelope Representation . The example scenario consists of a call for proposal (cfp) message sent from a BidManager agent to a specific bidder. The module would get messages from one party represented as an XML document and translate it to the



other XML representation using an XSLT transformation rules document. Another XSLT document is available for the inverse process. There are several efficiency issues and implementation details open with such a simple example, even though these will be obviated in order to keep the example simple and independent of any specific implementation platform.

<fipa-message act="cfp"><receiver><agent-identifier><name id="bidder1"/><addresses>

<url>http://example.org/bidder1</url>

</addresses></agent-identifier>

</receiver><sender>...</sender>...

<protocol>contract net</protocol><reply-with>

BidManager1:cfp#12421312</reply-with><in-reply-to>

http://selector.net/request#1/J12314</in-reply-to>...

<reply-to>...</reply-to><conversation-id>

contract_net#1</conversation-id><content>...</content>

</fipa-message>

<soap:Envelope xmlns:fipa=“…"

xmlns:soap=“…"xmlns:wsa=“…"><soap:Header><wsa:Action>

http://www.fipa.org/speech-acts/cfp</wsa:Action>

<wsa:To>http://example.org/bidder1</wsa:To><agent-identifier>

<name id="bidder1"/><addresses>

<url>http://example.org/bidder1</url></addresses>

</agent-identifier><wsa:From>…</wsa:From>…

<protocol> contract net </protocol><wsa:message_id>

BidManager1:cfp#12421312</wsa:message_id><wsa:RelatesTo type="fipa:reply">

http://selector.net/request#1/J12314</wsa:RelatesTo>…

<wsa:ReplyTo>…</wsa:ReplyTo></soap:Header><soap:Body> …</soap:Body>

</soap:Envelope>

<xsl:stylesheet xmlns: …><xsl:template match="/">

<soap:Envelope><soap:Header>

<xsl:element name="wsa:Action"><xsl:choose><xsl:when

test="/@act='cfp'">http://www.fipa.org/speech-acts/cfp</xsl:when><xsl:otherwise>…</xsl:otherwise></xsl:choose> </xsl:element> …

<xsl:template match="receiver"><xsl:element name="wsa:To"><xsl:value-of select="agent-

identifier/addresses/url"/></xsl:element> <xsl:copy-of select="agent-identifier"/>

</xsl:template> …<xsl:template match="conversation-id"><xsl:element name ="wsa:message_id">

<xsl:choose><xsl:when test="../reply-with">

<xsl:value-of select="../reply-with"/></xsl:when>

<xsl:otherwise> …</xsl:otherwise>< /xsl:choose>

</xsl:element></xsl:template>

…<xsl:template match="in-reply-to"><xsl:element name="wsa:RelatesTo">

<xsl:attribute name="type">fipa:reply</xsl:attribute>

<xsl:value-of select="."/></xsl:element>

</xsl:template>…<xsl:template

match="language|encoding|ontologies|protocol|reply-by">

<xsl:copy-of select="."/></xsl:template></xsl:stylesheet>

<xsl:stylesheet xmlns:…><xsl:template match="/">

<fipa-message><xsl:template match="/soap:Envelope/

soap:Header/wsa:Actio"><xsl:attribute name="act"><xsl:choose><xsl:when

test="/soap:Envelope/soap:Header/wsa:Action='http://www.fipa.org/speech-acts/cfp'">cfp</xsl:when>

<xsl:otherwise>Request</xsl:otherwise></xsl:choose> </xsl:attribute>

</xsl:template> <xsl:apply-templates

select="/soap:Envelope/soap:Header" /><xsl:apply-templates

select="/soap:Envelope/soap:Body" /></fipa-message>

</xsl:template><xsl:template match="/soap:Envelope/soap:Header">

<xsl:apply-templates select="./wsa:To" /><xsl:apply-templates select="./wsa:From"

/><xsl:apply-templates

select="./wsa:ReplyTo" /><xsl:apply-templates

select="./wsa:message_id"/><xsl:apply-templates

select="./wsa:RelatesTo"/><xsl:copy-of

select="protocol|language|ontologies|reply-by" />

</xsl:template><xsl:template match=“…wsa:To">

<xsl:element name="receiver"><xsl:copy-of select="../agent-identifier"/>

</xsl:element> </xsl:template> …

<xsl:template match="wsa:message_id"><xsl:element name="reply-with"><xsl:value-of select="."/>

</xsl:element> </xsl:template>

<xsl:template match="wsa:RelatesTo"><xsl:element name="in-reply-to"><xsl:value-of select="."/>

</xsl:element> </xsl:template>

…</xsl:stylesheet>

Figure 37. Transformation example for both directionsFigure 37 shows on the left side the message in FIPA XML representation, on the very right the



same message in SOAP. In the middle the two XSLT documents are shown, one for translating from FIPA to SOAP and the other one for the inverse, as the arrows behind each document illustrate. The four XML documents have been pruned, and only the most important highlights are shown. The complete example can be found here . The first detail to show is the translation of speech act (act) and action. The message shows the specification of the receiver, the other parties are done the same way, only inside the corresponding elements in the SOAP headers. It also shows how the transformation of the message and conversation identifiers are done, following the guideline exposed in the conceptual mapping.

10.5.5 Comparison to other approachesThe way the integration of the messaging framework is done in the present document is also

following the idea of wrappers as mentioned by . Also mentions the idea of creating wrappers for integration of different technologies, like in this case FIPA and Web Services.

The proposal shows how the two paradigms, FIPA Agents and Web Services, specifically WS-Addressing, can be merged in a single framework for communication. This merge manages to take advantage of the various features in each of the frameworks, extending them with the information necessary to comply with the other one.

Other approaches have adapted agent interactions to simple Web services request-responses like proposed in [44], , [43] and some of the proposals given by Agentcities . These approaches are based on placing a gateway between the agent platform and the Web Services environment. These, as also mentioned in the cited contributions, do not enable the implementation of complex conversation patterns. Instead of introducing the independent, asynchronous and flexible manner for messaging used by agents, communication is reduced to request-reponse services. Therefore the contribution for the growing Web Services community is very little. The present work proposes a more comprehensive integration which provides new resources, like the FIPA specifications, to the Web Services community.

There are other approaches like in , where the integration is brought closer by proposing a conversation model which allows complex conversations managed completely by the server. The server provides the possible answers to each interaction for the client to choose. Still Web Services are not expressive enough to define conversations including more than two turns, unless the services are orchestrated by a single management entity. The state of the conversation is maintained by the server hindering the autonomy of the participating agents. A final difference is the blur separation between domain-specific and domain-independent contents. The complete message payload has to carry both kinds of information. The present proposal overcomes these issues.

10.5.6 ConclusionThe present section provided a solution in two levels of abstraction. One conceptual and a

concrete one creating an adapter around the agent platforms based on a mapping of concepts present in FIPA messaging specifications and WS-Addressing specifications. The conceptual mapping allows the direct grounding of the FIPA Messaging using a WS-Addressing representation. This integration of FIPA specifications in Web Services opens the door for the realization of messaging as done in Multiagent Systems: by specifying speech-acts which are then combined to produce conversation protocols. These conversation protocols are a very interesting tool for the SOA community for the implementation of business process for example.

A lot of research in Multiagent Systems has provided new frameworks for implementation of autonomous and flexible systems, where several independent agents work together (or concurrently) to solve problems and achieve specific goals. In this context, automatic negotiation systems, workflow modelling and dynamic planning are among the most interesting contributions that could be implemented in Web Services using the present proposal.

A very important issue is the description of the services, since this should take into account the user of the services. Very frequently it will be the case that the client is one which a lot of reasoning could not be expected from. In that case the description should simplify the tasks as much as possible, but still not hindering autonomy of the participants. Enriching the mapping with extra reasoning for supporting these kinds of clients is also an option.



11 PART IV: Conclusions

This section concludes the report and summarises some major results achieved in work package A5.2. The results are reported in the following order: Web service models and metamodels, which summarises the model specification and

metamodels specification for Web services. Agents and Web services, which summarises the relationships between agents and Web

services. UML profile for Web services, which summarises the work on defining UML extensions

supporting Web service models. Baseline methodology for SOA, which summarises the work related to the baseline methodology.

11.1 Web service models and metamodelsIn the ATHENA project we have started the work on defining what we call a Web services

metamodel or Web services profile for the Web service specifications. The idea is to have the most relevant WS-* specifications formalized as MOF metamodels so that the specifications themselves can be more precisely and consistently related, and moreover to support model transformations according to MDA approaches where transformations between models are defined using their metamodels.

The ATHENA model-based specification framework for Web services specifies a set of models for how interoperable Web services should be specified. The models cover: Web service descriptions Web service compositions Web service addressing Web service security Web service registry Semantic annotation of Web services Quality of service (QoS) support for Web services E-contracts Agents and Web services

The specification models must be compliant with the ATHENA Web services metamodel/profile which defines a set of non-proprietary Web service specifications as formalized metamodels in MOF. The definition of precise metamodels will ensure that modelling tools and execution frameworks will become more interoperable. Moreover, it enables support for model transformations according to MDA approaches where transformations between models are defined on the metamodels level.

To develop a complete MOF metamodel for the WS-* specifications would be quite time-consuming, so we have focused on some of the most relevant and interesting specifications that we will investigate in the ATHENA project. We believe that such an approach to Web service standardization should in fact be adopted by the standardization bodies.

11.1.1 Web service compositionsWe have discussed four different approaches to Web service compositions: WS-BPEL [22], ACE-

GIS Web service composition [27], JACK BDI agents [28] and composition planning. Based on the discussions we provide the following input to work package A5.4 which deals with Web service composition: The WS-BPEL approach to service composition will be supported in A2 and needs to be

integrated into the A5 infrastructure. The ACE-GIS approach provides us with a UML profile for describing service composition in

design-time. This profile could be included as an extension to the UML profile for Web services, and transformations could be developed that maps ACE-GIS composition models to WS-BPEL.

The JACK BDI agents needs to be studied more closely in A5.4, and should be integrated into the A5 infrastructure as a flexible alternative of doing Web service compositions.

Web service composition using AI planning techniques is a currently debated research area. There are already several experimental planners available which were discussed in section 5.5. Work package A5.4 should however focus on integrating WS-BPEL and JACK BDI as these are more closely related to work being done in project A2 and project A6.

11.1.2 Semantic annotation of Web servicesThe document shows how it is possible to combine semantic and Web services technologies

directly at PIM level, in order to support service description and run-time composition. There still is not



a single clear methodology to achieve those results so different approaches are proposed in order to understand the different aspects of annotations that can be applied in the semantic description process of Web services. In addition, the development of MOF metamodels regarding semantic annotation aspects has allowed the definition of general concepts useful for including semantic concepts and ontology elements into SOAs.

The following are recommendations for research work in A5 in the area of semantic annotation of Web services: Define how semantic information can be expressed in UML by integrating with results and tools

coming out from the A3 project. Define how OWL files can be generated from Semantic enhanced UML models and how

Semantic enhanced UML models can be generated from OWL files.

11.1.3 QoS support for Web servicesThe proposed QoS requirements should give Web service consumers some confidence about the

quality of the discovered Web services. The metrics for such quality aspects need to be clearly defined, although some of these criteria are not quantitative but qualitative. Our QoS should deal with the following criteria: Requirements for the Web service: Accessibility, Accuracy, Exception Handling and

Robustness, Configurability, Interoperability, Performance, Precision, Pricing, Reliability, Security, Testability, Traceability and Auditability and Usability.

Requirements for the Provider: Continuity, Customer Support, Identification, Quality assurance, Reputation, Scalability and Security system and policy.

11.1.4 E-contractsIn chapter 8 of this report we have tried to extract the commonalities between the different e-

contract systems that we have studied as part of out state-of-the-art review. We report that the different technologies considered can all be modelled using a model that gives us hope that interoperability could be achieved between the different technologies proposed, both in an industrial and an academic setting, for specifying and enforcing e-contracts. However, because e-contracts touch on a lot of other domains, such as federated authentication and managed services, interoperability of e-contracts will remain dependent on interoperability advances in these other domains.

11.2 Agents and Web servicesIn this section, we discussed shared as well as distinguishing properties of agents and Web

services. We presented a framework for model driven Web service composition using BDI agents in a service-oriented context. BDI agents provide a framework for both aspects by employing a planning from second principles approach, which uses a predefined library of plans and instantiates and adapts these plans. From this perspective, plans are design-time models for agent task execution and for Web Service composition. JACK’s [28] BDI plans can model most of the standard workflow patterns in a clean and fairly straightforward manner. We also presented the extension of JACK agents for dynamic Web service composition and invocation. The BDI agent approach improves flexibility by allowing a try-and-error strategy, where alternative paths are modelled implicitly.

11.2.1 FIPA infrastructureThe FIPA abstract architecture offers an alternative infrastructure for service creation, description,

registration, location and usage. It defines a basic services-model that includes an Agent-Directory-Service and a Service-Directory-Service. Furthermore, since FIPA agents communicate with one another by sending messages, the FIPA architecture defines message structure, message representation and message transport.

A mapping of the FIPA message standard to the SOAP standard (and vice versa) has been proposed. The conceptual mapping allows the direct grounding of the FIPA Messaging using a WS-Addressing representation. This integration of FIPA specifications in Web Services opens the door for the realization of messaging as done in Multiagent Systems: by specifying speech-acts which are then combined to produce conversation protocols. These conversation protocols are a very interesting tool for the SOA community for the implementation of business process for example.

11.3 UML profile for Web servicesConclusions on the ATHENA UML profile for Web services are derived from Annex [3]:



There are several specifications interrelated for Web services that specify how to define and develop Web services keeping in mind some concepts such as security. The great amount of specifications makes a difficult task for developers, purchasers and stakeholders to use of Web services technology.

A barrier for developing a Web services solution is not only to address the specifications but also to deal with the different vendor-specific implementations of the Web services technology stack. This is why it is necessary to provide an environment in which it could be possible to produce individual Web services in a way that is vendor-independent and interoperable across different vendor-specific execution environments.

To apply MDA it is necessary to develop the metamodels that will be used in Platform Independent Model (PIM) and Platform Specific Model (PSM) and the transformations between those models.

In order to define the Web services metamodel, we have used UML profile because it provides easy and flexibility way to implement extensions to CASE tools in order to support the use of the metamodel. Besides, it allows to combine the profile elements with UML standard elements and other profiles to obtain more expressive models. Additionally, the mapping from UML to Web services technology permits a Model-Driven development approach in which some information can be automatically generated from UML models, such as WSDL.

We have defined a basic metamodel for Web services that covers those basic aspects that all Web services have to fulfil, and two extended metamodels that extend the basic specification with important concepts for Web services technology, such as faults and security. Starting from these metamodels, we have defined three different UML profiles that try to make easy the specification and development of Web services.

The basic UML profile for Web services could need further refinements to include different aspects that will be important as far as Web services technology advances because Web services are an expanding technology. Currently we have a UML profile for WSDL and a UML profile for XSD available.

11.4 Baseline methodology for Web servicesThe ATHENA baseline methodology for SOA provides a baseline methodology identifying a set of

models that are usable at different stages of the model-driven development in the ATHENA A6 and A5 projects. The purpose is not to prescribe a complete methodology. Rather, it presents the expected outcome of the modelling activities in the project. Some of the models are basically intended for capturing requirements, stakeholders and resources and shall be communicated with the end users.

The current methodology as described in Annex [1] should be regarded as a baseline. During the course of the A5 project we will continue to evolve this methodology to better cater for service-oriented architectures and concepts. Furthermore, we will also develop this methodology in cooperation with the A6 project.

During the next 6 months of the project we will improve the methodology on the following areas: Needs to be closer linked to the work being done in A6.5 on defining a platform-independent

metamodels for SOAo We will develop transformation between the SOA metamodels and the Web services

metamodels, in particular focusing on WSDL.o The component model of the methodology will be updated with how A6 perceives platform-

independent modelling of software services should be specified according to the ATHENA UML profile for SOA being developed in A6.5.

Needs to be closer linked to the work being done in A2 on service composition.o We will integrate with the collaboration metamodels and BPEL realisations being investigated in

A2. Guidelines for how to apply a UML profile for BPEL will possibly be described in the methodology.

o The business model of the methodology will also need to be updated with the business models, primarily focusing on cross-collaborative processes, specified in A2.

The methodology also needs to be better linked with the ATHENA UML profile for Web services and the usage of agent models, e.g. by introducing a UML profile for BDI agents.

Lastly, the model examples of the methodology should be updated with examples from the user scenarios of B4 and B5. In particular we will look into the INTRACOM PPM scenario and also an extended CRF e-Procurement/CPD scenario.



12 References

Documents

Planned and Customisable Service-Oriented Architectures provide… · Web viewATHENA Project No 507849 ATHENA – Project Name Planned and Customisable Service-Oriented Architectures