Service UPMS Agents Variability SoaML - STI Innsbruck · APPENDIX B: UPM FOR AGENTS 65 B.1.1 Agent...

Copyright SHAPE Consortium 2007-2010

Service and Software Architectures, Infrastructures and EngineeringSmall or Medium-scale Focused Research Project

Semantically-enabled Heterogeneous Service Architecture andPlatforms Engineering

AcronymSHAPEProject No216408

UPMSSoaML

Agents

Semantic WebServices

ServiceVariability

WebServices

P2P

FlexibleBusiness Models

HeterogeneousPlatforms

Grid

UPMSSoaML

Agents


ServiceVariability

WebServices

P2P



Grid

UPMSSoaML

Agents


ServiceVariability

WebServices

P2P



Grid

UPMSSoaML

Agents


ServiceVariability

WebServices

P2P



Grid

Deliverable D3.1

Consolidation of Common Basis forMetamodels and Languages for SHA

Work Package: 3

Leading partner: ESI

Editor: Gorka Benguria

Author(s): SOFTEAM, SINTEF, DFKI, ESI ,UIBK

Dissemination level: Public

Date: 19/9/2008

Version: 1.0 – final version

Public

Copyright SHAPE Consortium 2007-2010 / 140

Versioning and contribution history

Version Description Comments

0.1 Gathering of previous material SOFTEAM, SINTEF, DFKI, ESI,UIBK

0.2 Minor Updates From DFKI DFKI

0.3 Minor Updates From ESI ESI

0.4 Minor Updates From SINTEF SINTEF

0.5 Final editing Prior to Peer Review ESI

0.6 Peer Review SOFTEAM

1.0 Final editing after peer review ESI

Public


Executive SummaryThis report presents Deliverable 3.1 "Consolidation of Common Basis for Metamodels andLanguages for SHA” of the SHAPE project, containing results of tasks T3.1 and T3.2 as defined inthe Description of Work.

The system development has experienced during the last years a paradigm shift from the componentbased development to the service based development. Systems are more and more dependent fromother external systems, and the way in which they collaborate is through the exchange of services.Therefore, the services are becoming a key aspect in the lifecycle of the current and upcomingsystems.

In the same way that the introduction of the object oriented paradigm or the component paradigm hasrequired the development of new technologies (such as compilers, languages, notations or platforms)to support their usage in the real world; the service orientation will require new technologies to supporttheir application throughout the development and maintenance lifecycle.

Some of these technologies and standards are already in place, such as the web servicetechnologies, but others are still in development. One of the areas which is still in development is theservice design support. In the same way that system design languages such as UML can be used tomodel objects and components, the design community needs design notations to model the servicesin their systems.

Several projects have included activities to define languages for the specification of service basedsystems. These projects have been leaded by tool vendors, by universities, by research institutes, orby individuals. In summary, the current situation is quite similar to the scenario that was in placebefore the development of the UML modelling language.

There is a clear new of new modelling elements that make it possible to design service based systemsusing a common language. The resulting language should be able to support all the differentmodelling scenarios that can arise when developing service based systems.

With the aim to standardise, or to get to an agreement on the way to model services, some of theOMG members issued a RFP for a UML profile and metamodel for services. In that line the objectiveof this document will be to analyzed previous work on the definition of conceptual models for servicesand use it as input for the definition of the new metamodel.

This new metamodel will be developed taking in mind the scenarios of the SHAPE project to ensure itsapplicability in the reality and it will also take into account the requirements in the RFP for a UMLprofile and metamodel for services issued by the OMG to promote the standardisation of the resultinglanguage.

Public


Table of ContentsEXECUTIVE SUMMARY 3

TABLE OF CONTENTS 4

LIST OF FIGURES 7

1 INTRODUCTION 10

1.1 DOCUMENT STRUCTURE 11

2 EXECUTIVE OVERVIEW – UPMS - FOR HETEROGENEOUS ARCHITECTURES 12

2.1.1 Target Audience and Use 142.2 OTHER COMMON BENEFITS 15

2.2.1 Evolution 152.2.2 Services architecture -Understanding 15

2.3 CONCEPTS SUPPORTED 15

3 METAMODEL SPECIFICATION 16

3.1 OVERVIEW 163.2 ELEMENT SPECIFICATION 18

3.2.1 Behaviour 183.2.2 CollaborationUse 193.2.3 Event 203.2.4 Exception 213.2.5 InteractionPoint 223.2.6 Message 233.2.7 Operation 243.2.8 Participation 263.2.9 Partition 273.2.10 Service 283.2.11 ServiceBinding 293.2.12 ServiceChannel 303.2.13 ServiceComponent 313.2.14 Service Contract 333.2.15 ServiceContractInstance 353.2.16 ServiceInterface 353.2.17 ServiceInterfaceSpecification 373.2.18 ServiceSpecification 38

4 RESPONSES TO SHAPE SCENARIOS 40

4.1 STATOILHYDRO USE CASE SCENARIOS 414.1.1 StatoilHydro: Production and Process Optimization 414.1.2 StatoilHydro: “Collecting drilling data” – for “Semantic Enabled SOA” 424.1.3 StatoilHydro: “Scheduling product cargos” for “SOA and MAS” 424.1.4 StatoilHydro: “SOA and variability in data intensive systems” 424.1.5 StatoilHydro: Integrated Operations – Reference architecture 43

4.2 SAARSTAHL USE CASE SCENARIOS 434.2.1 Saarstahl: Manufacturing planning and control system 434.2.2 Saarstahl: “Creation and Optimization of Heats and Sequences” 434.2.3 Saarstahl: Coordination between Rolling Mills and Steelworks 444.2.4 Saarstahl: Capacity planning of Annealing Furnaces 444.2.5 Saarstahl: Cross-plant order coordination from steel works’ point of view 444.2.6 Saarstahl: Concrete Requirement Specification “Creation and Optimization of Heats andSequences” 45

5 RESPONSES TO RFP REQUIREMENTS 46

5.1 MANDATORY REQUIREMENTS 46

Public


5.2 OPTIONAL REQUIREMENTS 535.3 ISSUES TO BE DISCUSSED 545.4 EVALUATION CRITERIA 55

6 REFERENCES 57

APPENDIX A: PIM4SOA 58

A.1.1 Introduction 58A.1.2 The Challenge 58A.1.3 Solution Overview 59A.1.4 PIM4SOA Metamodel 59A.1.5 Information Aspect 60A.1.6 Process Aspect 60A.1.7 Service Aspect 60A.1.8 Quality of Service Aspect 61A.1.9 e-Procurement Scenario, a sample use of the metamodel 61A.1.10 Model Input 61A.1.11 PIM4SOA Model 62A.1.12 Model output 62A.1.13 Discussion of solution 63A.1.14 Relationship to UPMS-HA 63A.1.15 References 63

APPENDIX B: UPM FOR AGENTS 65

B.1.1 Agent Modelling 65B.1.2 Agent UML 65B.1.3 PIM4Agents 66B.1.4 Agent UML versus PIM4Agents 69B.1.5 Relation to the UPMS-HA proposal 69B.1.6 Similarities between the UPMS-HA core and the PIM4Agents 69B.1.7 Feasible extensions on the UPMS-HA core 70B.1.8 Feasible extensions on the PIM4Agents 70B.1.9 References 71

APPENDIX C: UPM FOR P2P, GRID AND WEB SERVICES 72

C.1.1 Core Layer of GeSMO 73C.1.2 Abstract View 73C.1.3 Basic View 74C.1.4 Description View 74C.1.5 Structure View 75C.1.6 Semantics & QoS View 75C.1.7 Communication View 76C.1.8 Message Structure View 76C.1.9 Extensions Layer of GeSMO 77C.1.10 Web Service Type 77C.1.11 Grid Service Type 77C.1.12 P2P Service Type 78

APPENDIX D: UPM FOR EVENT MODELLING 80

D.1.1 Event-based Business Models 80D.1.2 Event-based Agent Models 83D.1.3 References 83

APPENDIX E: A SERVICE MODELLING LANGUAGE FOR MID INNOVATORAOX 84

E.1.1 Description of the profile’s elements 84E.1.2 Services & Collaborations 84E.1.3 Service provider & implementation 85E.1.4 Data types, operations, messages and interfaces 85E.1.5 Ports & Bindings 86

Public


E.1.6 Behaviour 88E.1.7 Defining the UML-Profile 90E.1.8 The UML-Profile visualized as a metamodel 93E.1.9 Example: Modelling with the SOA UML-Profile 96E.1.10 Documents, messages and interfaces 96E.1.11 ServiceProvider and ServiceCollaboration 99E.1.12 Process flow 99E.1.13 Service provider implementation 103E.1.14 Binding 104E.1.15 References 105

APPENDIX F: COLLABORATIVE SERVICES THROUGH SEMANTIC INTERFACES 106

F.1.1 SIMS at a glance 107F.1.2 The virtual meeting place 108F.1.3 Collaborative services 109F.1.4 Service engineering in the telecom domain 109

F.1.4.1 Domain concepts 109F.1.4.2 Formal modelling 110F.1.4.3 The concept of service 110F.1.4.4 System architecture 111F.1.4.5 Computing platforms 111

F.1.5 Mixed initiatives and conflict resolution 111F.1.5.1 Conflict resolution 112F.1.5.2 Early detection of errors 112

F.1.6 SIMS service engineering approach 112F.1.7 Modelling services 113F.1.8 Relationship to the UML Profile and Metamodel for Services 116F.1.9 Further work 116F.1.10 References 116

APPENDIX G: INTEGRATING UPMS-HA AND SEMANTIC WEB SERVICES 118

G.1.1 Extending UPMS-HA to a Semantic Web Service Metamodel 118G.1.2 Using ontology concepts in UPMS-HA 118G.1.3 Extending Service Specifications of UPMS-HA 119G.1.4 Aligning the Semantic Web Service Metamodel with existing Semantic Web Service standards

120G.1.5 OWL-S: Semantic Markup for Web Services 121G.1.6 WSMO: Web Service Modelling Ontology 124G.1.7 WSDL-S: Web Service Semantics 127G.1.8 SWSF: Semantic Web Services Framework 129G.1.9 References 131

APPENDIX H: SEA – SOA BASED ENTERPRISE ARCHITECTURE 133

H.1.1 The Praxeme approach 133H.1.2 The SEA « logical » profile 135H.1.3 Description 136H.1.4 Examples 138

Public


List of FiguresFigure 1 UPMS (core) and UPMS-HA...................................................................................................... 12

Figure 2 - Service Metamodel - Contract related elements ........................................................................ 16

Figure 3 - Service Metamodel - ServiceSpecification related elements ........................................................ 17

Figure 4 - Service Metamodel - ServiceInterfaceSpecification related elements............................................ 17

Figure 5 - Service Metamodel - ServiceComponent related elements .......................................................... 17

Figure 6 –Behaviour............................................................................................................................. 18

Figure 7 –Behaviour link to external metamodel ...................................................................................... 18

Figure 8 – Notation: Complex Contract ................................................................................................... 20

Figure 9 – Events ................................................................................................................................ 21

Figure 10 – Notation: Events................................................................................................................. 21

Figure 11 – Operation Exception ............................................................................................................ 21

Figure 12 – Notation: Operation Exception.............................................................................................. 22

Figure 13 – Service InteractionPoint....................................................................................................... 22

Figure 14 –Message link to external metamodel ...................................................................................... 23

Figure 15 – Service Operation ............................................................................................................... 25

Figure 16 – Notation: AirConditioner ...................................................................................................... 26

Figure 17 – Partition ............................................................................................................................ 27

Figure 18 – Notation: Partition .............................................................................................................. 28

Figure 19 – Notation: Simple Contract.................................................................................................... 29

Figure 20 – Notation: Complex Contract ................................................................................................. 30


Figure 22 – Notation: Service Channel ................................................................................................... 31

Figure 23 – ServiceComponent .............................................................................................................. 32


Figure 25 – Notation: ServiceComponent to ServiceSpecification ............................................................... 33

Figure 26 – Service Contract ................................................................................................................. 33



Figure 29 – ServiceInterface ................................................................................................................. 36

Figure 30 – Notation: Operation getTemperature..................................................................................... 37

Figure 31 – ServiceSpecification ............................................................................................................ 38

Figure 32 – Notation: Operation getTemperature..................................................................................... 39

Figure 33 – Notation: Use Case Realization ............................................................................................. 47

Figure 34 – ServiceSpecification with no Contract .................................................................................... 48

Figure 35 – Abstract AirConditioner Composite Structure.......................................................................... 52

Figure 36 – The special configuration of the AirConditioner ....................................................................... 52

Figure 37. PIM and PSM levels............................................................................................................... 59

Figure 38. The information aspect of the PIM4SOA metamodel .................................................................. 60

Figure 39. The process aspect ............................................................................................................... 60

Figure 40. The service oriented aspect ................................................................................................... 61

Figure 41. The QoS aspect .................................................................................................................... 61

Public


Figure 42. Partial view of the PIM4SOA model for e-Procurement............................................................... 62

Figure 43: The overall picture: From a particular application domain (e.g. a PIM metamodel for SOA) to a PIM

metamodel for agents to miscellaneous agent-oriented execution platforms like Jack and Jade................ 67

Figure 44: The partial agent aspect of the PIM4Agents. ............................................................................ 67

Figure 45: The partial behavioural aspect of the PIM4Agents..................................................................... 68

Figure 46: The partial interaction aspect of the PIM4Agents ...................................................................... 69

Figure 47: How to extend the core of the PIM4Agents to deal with SOA...................................................... 71

Figure 48. Layered architecture of the Generic Service Model .................................................................... 72

Figure 49. The GeSMO conceptual views refine the concept of Service........................................................ 73

Figure 50. Abstract View of Service........................................................................................................ 74

Figure 51. Basic view of Service ............................................................................................................ 74

Figure 52 Description view of Service ..................................................................................................... 75

Figure 53. Structure view of Service....................................................................................................... 75

Figure 54. Semantics & QoS view of Service ........................................................................................... 76

Figure 55. Communication view of Service .............................................................................................. 76

Figure 56. Message Structure view of Service.......................................................................................... 77

Figure 57. The Web service type............................................................................................................ 77

Figure 58. The Grid service type ............................................................................................................ 78

Figure 59. The P2P service type............................................................................................................. 79

Figure 60: Complete Metamodel for Event-based Business Models ............................................................. 82

Figure 61: The partial metamodel for Jack. ............................................................................................. 83

Figure 62: Metamodel – collaborations ................................................................................................... 84

Figure 63: Metamodel – service provider ................................................................................................ 85

Figure 64: Metamodel – message exchange............................................................................................ 85

Figure 65: Metamodel – service provider realization................................................................................. 86

Figure 66: Metamodel – binding ............................................................................................................ 87

Figure 67: Metamodel – SOAP-binding ................................................................................................... 87

Figure 68: Metamodel – behaviour basics ............................................................................................... 88

Figure 69: Metamodel – dependency between Swimlane and Role ............................................................. 88

Figure 70: Metamodel – kinds of ProcessFlow.......................................................................................... 88

Figure 71: Metamodel – structured Nodes............................................................................................... 89

Figure 72: Metamodel – control nodes.................................................................................................... 89

Figure 73: Metamodel – input and output of actions................................................................................. 89

Figure 74: Metamodel – concrete actions................................................................................................ 90

Figure 75: Metamodel – variables .......................................................................................................... 90

Figure 76: Example diagram for data types............................................................................................. 97

Figure 77: Example diagram for messages.............................................................................................. 98

Figure 78: Example diagram for interfaces.............................................................................................. 98

Figure 79: Example diagram for the description of service provider and their roles ...................................... 99

Figure 80: Example diagrams for service collaboration ............................................................................. 99

Figure 81: Example diagram for process flow ........................................................................................ 101

Figure 82: Example diagram for ExceptionFlow and CompensationFlow .................................................... 102

Figure 83: Example diagram for service provider implementation ............................................................ 103

Public


Figure 84: Example diagram for SOAP-Binding ...................................................................................... 104

Figure 85: Example diagram for binding of ports to a service collaboration ............................................... 105

Figure 86 - Exploiting semantic interfaces at design time and runtime...................................................... 108

Figure 87 - Example of a Meeting place ................................................................................................ 109

Figure 88 - The concept of collaborative service..................................................................................... 111

Figure 89 - Mixed initiatives involving three service components ............................................................. 112

Figure 90 - Meta model for the basic concepts and definitions in SIMS ..................................................... 113

Figure 91 - Modelling a service with two roles using UML 2.0................................................................... 114

Figure 92 - Expressing the binding between service roles and the service components that play these roles

using UML 2.0.............................................................................................................................. 114

Figure 93 - Elementary collaboration and a pair of semantic interfaces..................................................... 114

Figure 94 - Interface behaviour for semantic interfaces (with goals)......................................................... 115

Figure 95 - Multi-role composite service composed of elementary collaborations........................................ 115

Figure 96: Extending UPMS-HA with ontology concepts .......................................................................... 118

Figure 97: Extending UPMS-HA Operations with ontology concepts .......................................................... 119

Figure 98: Extending UPMS-HA Tasks with Preconditions and Effects........................................................ 119

Figure 99: SWS extension of UPMS-HA for additional semantic properties................................................. 120

Figure 100: SWS extension of UPMS-HA for additional semantic properties ............................................... 120

Figure 101: Semantic Web Service languages ....................................................................................... 121

Figure 102: OWL-S meta-model: Service.............................................................................................. 121

Figure 103: OWL-S meta-model: Service Model..................................................................................... 122

Figure 104: OWL-S meta-model: Service Profile .................................................................................... 122

Figure 105: OWL-S meta-model: Service Grounding .............................................................................. 123

Figure 106: WSMO top level elements .................................................................................................. 125

Figure 107: WSMO ontology................................................................................................................ 125

Figure 108: WSMO web service ........................................................................................................... 126

Figure 109: WSMO goals .................................................................................................................... 126

Figure 110: WSDL-S meta-model ........................................................................................................ 128

Figure 111: SWSF Meta-model: FLOWS Core ........................................................................................ 130

Figure 112: SWSF meta-model: Other Constraints................................................................................. 130

Figure 113 – Topology of the aspects (view-point) from Praxeme ............................................................ 135

Figure 114 – UML extensions supporting the SEA logical profile ............................................................... 136

Figure 115 – Example of Business component providing three services..................................................... 138

Figure 116 – Traceability between Software process, Use Cases and Services ........................................... 138

Figure 117 – Assembly of service components, identification of their interaction with actors ....................... 139

Figure 118 – Service, with a set of service operations ............................................................................ 139

Figure 119 – Habilitation diagram : who can access to a given service ..................................................... 139

Figure 120 – Example of a service data model....................................................................................... 140

Public


1 IntroductionSeveral projects have included activities to define languages for the specification of service basedsystems. Some of them have provided means to model services architectures from a platformindependent point of view, such as the PIM4SOA (see Appendix A:) (Platform-Independent Model forService-Oriented Architectures) developed within the ATHENA project. Others have provided meansto model specific kinds of services architectures such as the PIM4Agents (see Appendix B:) (Platform-Independent Model for Agents based services architectures).

The objective of this document is to gather information from the different Metamodels for serviceoriented architectures available in the consortium and use them as the basis for the development of anintegrated proposal for service modelling. This new metamodel will be developed taking in mind thescenarios of the SHAPE project to ensure its applicability in the reality and it will also take into accountthe requirements in the RFP [1] for a UML profile and metamodel for services issued by the OMG topromote the standardisation

The objective of this service modelling language is to support a broad range of service modellingneeds, such as service specification, service realisation, services architecture modelling, serviceoriented. Besides, another requirement of the language is to be flexible and extensible enough todefine services for their deployment in different platforms such as Web Services, Agents, P2P,Semantic Web Services, and Grid environments.

These are the service modelling languages considered for the development of the service modellingproposal.

PIM4SOA: Platform-Independent Model for Service-Oriented Architectures developed withinthe ATHENA project. It covers four dimensions related with the services architecturemodelling. These dimensions are services, processes, information and non-functionalrequirements (see Appendix A:).PIM4Agents: it defines a core metamodel that covers several important aspects to modelmulti-agent systems. Aspects like: the cooperation between agents; the processesimplemented by the agents, how the messages are sent between roles (see Appendix B:).GeSMO: Generic service model developed by the National & Kapodistrian university of Athenswithin the context of the SODIUM project. The specification of GeSMO was driven by thenecessity to conceptually describe commonalities and differences of Web, P2P, and Gridservices (see Appendix C:).Event based Metamodels: in this category two disciplines were considered event-basedbusiness models and event-based agent models (see Appendix D:)Service Modelling Language For MID INNOVATORAOX: This is a profile developed incollaboration by the MID GmbH, Nuremberg, Germany and the Programming distributedSystems lab of the University of Augsburg, Germany in a local project. The profile focuses inthe generation of the modelling of services and enables the generation of BPELWS 1.1 as wellas WSDL code (see Appendix E:).Semantic Web Services: In this area several Metamodels were analysed, including: WSMO(Web Service Modelling Ontology), OWL-S (Web Ontology Language for Services), WSDL-Sand SWSF (see Appendix F: and Appendix G:).SOA Enterprise Architecture: SOFTEAM has worked within an open consortium in France todefine model based methodologies for SOA, and has set up a methodology called SEA thatsupports system modelling from the first vision and goal definition stages until theimplementation. SEA separates the models into aspects covering the main areas or concern,one (the logical aspect) being entirely devoted to SOA (seeAppendix H:).CIM4SOA: Different Business modelling languages were analysed, among them EPC andBPMN (see Fehler! Verweisquelle konnte nicht gefunden werden.). These languages willbe the starting point for the flexible business model support with the use of the servicemetamodel.

Public


1.1 Document StructureThe report is organized into the following sections:

Section 2, Overview—provides a general understanding of the specification (normative).Section 3, Metamodel specification—details of the metamodel specification (normative).Section 4, Responses to SHAPE scenarios.Section 5, Responses to specific RFP requirements.

The appendices contain information on the related metamodels, namely:

A – PIM4SOAB – UPM for AgentsC – UPM for P2P, Grid, and Web ServicesD – UPM for Event ModellingE – A Service Modelling Language for MID innovatorF – Collaborative Services through Semantic Web ServicesG – Integrating UPMS-HA and Semantic Web ServicesH – SEA: SOA based Enterprise ArchitectureI – CIM4SOA.

Public


2 Executive Overview – UPMS - for HeterogeneousArchitecturesDuring the last years service orientation has gained popularity in the developer community veryrapidly. Service orientation has very interesting qualities in contrast to other previous approaches thatbecome it very attractive for the development of open systems: Clear system boundaries,standardized interfaces, standardized communication mechanisms, and open architectural principles.We see that a broad service-oriented approach can be an encompassing architectural approach thatcan be further refined for various specific architectural styles and technologies such as web services,service component architectures, P2P, Grid, Agents, Event driven architectures and the furthersupport of semantics, as in semantic web services and semantically-enabled services architectures.To support this we envision that this metamodel an profile can have a core part which is a commonbasis for a number of architectural styles and technologies, and a service-specific parts which isaddressing specific aspects of service technologies for generic services architectures such as SCA(Service Component Architecture) and Web Services architectures (WSA), as shown in the illustrationbelow. For brevity, we will refer to the core metamodel and profile as UPMS (UML Profile andMetamodel for Services) following the style of the RFP, and we will refer to the metamodel and profileswith service-specific parts which is addressing specific aspects of service technologies as UPMS-HA(UML Profile and Metamodel for Services-for Heterogeneous Architectures)

UPMS (core)Service Variabilityand Configuration

UPMSWSA/SCA

UPM forSWS/SESA

UPM forAgents

UPM for P2P/Grid/EDA/Components

UPMS-HA

WS, WSMO, OWL-S, JACK, JADE, JXTA, OGSA, J2EE, CORBA

J2EE, SCA, .Net ,…

BPMN BPDM BMM SBVR

PIMs for differentArchitecturalStyles

RealisationTechnologies

PSMModels

CIMBusinessModels

PIMModelsUPMS (core)

Service Variabilityand Configuration

UPMSWSA/SCA

UPM forSWS/SESA

UPM forAgents

UPM for P2P/Grid/EDA/Components

UPMS-HA

WS, WSMO, OWL-S, JACK, JADE, JXTA, OGSA, J2EE, CORBA

J2EE, SCA, .Net ,…

BPMN BPDM BMM SBVR

PIMs for differentArchitecturalStyles

RealisationTechnologies

PSMModels

CIMBusinessModels

PIMModels

Figure 1 UPMS (core) and UPMS-HA

The intention of UMPS-HA is to analyze metamodels for a number of architectural styles in order toidentify a common core basis for these, so that it is possible to specify large and complex systemsusing a common modelling approach. We assume that later RFPs will address the more specificdetails for these architectural styles, i.e. through a UPM for EDA/CEP (Event Driven Architectures andComplex Event Processing), a UPM for Agents, a UPM for Semantic services, a UPM for P2P andGrid, etc.) but it is already possible to identify a number of common concepts for these through ananalysis of existing approaches and experiences.

The UPMS-HA submission has analyzed a number of available results in these areas, with respect toextracting the common concepts into a core UPMS-HA model.

The approach for this has been to ensure that UPMS core is a suitable basis for

Public


UPM for Web services architecturesUPM for SCA/SDO1 (Service Component Architecture and Service Data Objects), now alsoOpen CSA2 (Open Composite Services Architecture)UPM for Semantic (web) servicesUPM for AgentsUPM for Event modelling and EDA/CEPUPM for P2PUPM for GridUPM for Components

The basis for the UPMS-HA submission have been the results and experiences from research anddevelopment projects and products from the submitting partners, in particular related to set of recentlyfinished European IST projects in the European 6th Framework programme, and also national French,Norwegian and German projects, as well as partner products from MID and SOFTTEAM in particular.Some of these baseline results have also been further documented in Appendixes in the submission,as follows:

Appendix A: PIM4SOA (service,process,information,QoS) from partners ESI and SINTEF -ATHENA project3Appendix B: PIM4Agents and AgentUML - from DFKI/SINTEF and Univ. Augsburg, and OSLOSoftware and Rhysome - INTEROP project4Appendix C: GeSMO (Generic Service Model)for WS/P2P/Grid from NKUA and SINTEF -SODIUM project5Appendix D: Event modelling derived from UML for EDOC and concepts for Agent modellingAppendix E: Service Modelling Language for the product MID InnovatorAOX, and from MIDand University of Augsburg from the German project Business Processes to Web Services(BP2WS).Appendix F: Semantic Interfaces – from SINTEF Norwegian national project and the SIMSproject6Appendix G: Semantic web services (WSMO, OWL-S etc.) from MID and Univ. Augsburgand DERI – DIP7 and SUPER projectsAppendix H: SEA – from SOFTTEAM and the French Praxeme project

Some aspects have also been derived from work in the recent "UML for ODP" ISO DIS standard fromISO/IEC JTC1/SC7/WG19, ISO/IEC 19793, but due to copyright policies of ISO, this work can not bereferenced in for an appendix here.

Service orientation promotes the definition of clear system boundaries, the developer decides what willbe available to other systems and it encapsulates that functionality in a service hiding the rest of thesystem.

Standardized interfaces allow the automatic interpretation of the service interface. This makes easierits use because the development environments are capable of interpretation those descriptions anddevelop a class structure for that service that makes easier its use.

As services uses a set of know communication mechanisms, the development environment is capableof developing the necessary code to decode and encode the messages for their transmission throughdifferent communications protocols.

Besides, service orientation is supported by a huge set of standards (supported by the key players ofthe software industry) covering several aspects of the service consumption like: security, transactions,serialization, and so on.

1 www.osoa.org2 See www.oasis-opencsa.org3 www.athena-ip.org4 www.interop-noe,org5 www.atc.gr/sodium/6 www.ist-sims.org7 dip.semanticweb.org

http://www.osoa.org/

http://www.oasis-opencsa.org/

http://www.athena-ip.org/

http://www.atc.gr/sodium/

http://www.ist-sims.org/

Public


Currently SOA solutions are too focused on the specific platforms where services are implemented(WebServices, JavaRMI, etc). As a consequence, information technology architectures become verysensitive to the technical and business evolution. Additionally, these architectures can be affected bythe evolution of the current development and deployment platforms. In summary, a change in any ofthese domains (technical, business, development or deployment) will require the entire system to berebuilt.

A possible solution to this situation could be to provide modelling languages, as abstractionmechanisms to split the logical solution from its technical implementation, that enables the definition ofservices architectures independently from the used specific platforms. A modelling language raisingthe level of abstraction allows us to share models and provides a capability to generate platformsspecific assets (Models, code, standard documents). Unfortunately nowadays, there are no modellinglanguages based on service aspects, and able to set aside technical concerns in this way.

There exists general purpose modelling languages such as UML (Unified Modelling Language). UMLis a standard for software system modelling. It is able to represent any kind of software system, fromembedded software to enterprise applications. To allow this flexibility UML provides a set of generalelements applicable to any situation such as classes or relationships. When we try to model an SOA,we could find ourselves in a situation where everything is a class, a provider is a class, a service is aclass, a registry is a class, etc, this could make the models difficult to understand and use.

The UPMS-HA (UML Profile and Metamodel for Services – for Heterogeneous Architectures) isaddressing the requirements of the OMG UPMS RFP to achieve the following:

A common vocabulary and metamodel to unify the diverse service definitions that exist in theindustry.Clarify UML semantics concerning services modelling and establish modelling best practices.Complement existing UML metamodel by defining an extension to UML to ensure completeand consistent service specifications and implementations.Integrate with and complement standards developed by other organisations such as W3C andOASIS to facilitate collaborations between service consumer and providers.Support a service contract describing the collaboration between participating serviceconsumers and service providers using mechanisms that clearly separate servicerequirements and specification from realization.Enable traceability between contracts specifying services requirements, service specificationsthat fulfil those requirements and service providers that realize service specifications.Facilitate the adoption of Service Oriented Architectures through more abstract and platformindependent services models to speed service development, decouple service design fromevolving implementation, deployment and runtime technologies, and enable generation ofplatform specific artefacts.The ability to exchange services models between tools using XMI.

2.1.1 Target Audience and UseThe target Audience is system/software architects willing to define a services architecture for theirsystems or for their organisations. A services architecture which is independent from the concreteservice platforms that will support the system now and in the future.

They will use the UPMS-HA for modelling/modifying/extending their services architecture and tointeractively deploy this services architecture to the best suited platform technologies (web services,agent, grid, p2p, …).

One of the objectives of the UPMS-HA is to establish the basis for the modelling and integratingservices that will be executed in different platforms and with different technologies, not necessarily in ahomogeneous architecture.

Public


2.2 Other Common Benefits

2.2.1 EvolutionThe UPMS-HA based models will support the evolution of the platform technologies along the time.The evolution of the underlying architecture is not expected to change the services provided and theowned behaviours. The UPMS-HA is expected to easily support the total/partial migration of theservices architecture to new platforms.

2.2.2 Services architecture -UnderstandingThe UPMS-HA provides the elements to completely represent a services architecture. Thisrepresentation could be easily extended to include additional services and behaviours. Besides, itcould be used to evaluate the impact that the withdrawal of a service could have in the overall servicesarchitecture.

2.3 Concepts supportedServiceComponent: ServiceComponents represent computing entities realizing services. AComponent is a representation of an autonomous business concept or business process. Itimplements provided services, defines the services it requests for its behaviour. They can beintegrated into other components to constitute larger systems. Service components could bestructured and classified based on their nature (such as Entity, Process, Utility, etc.).

The service metamodel supports the establishment of relationships between the service componentsat three coupling levels:

ServiceContract: Is the higher coupling level between services, for each service entity itenforce the fulfilment of a service specification, where the messages should be exchangedfollowing some behavioural rules.ServiceSpecification: Is the intermediate coupling level between ServiceComponent, itenforces the provision of one or several interfaces. In some cases it could also provideindication about the communication mechanisms allowed for the different services.ServiceInterfaceSpecification: Is the lowest coupling level between ServiceComponent, itonly enforces to provide the operations contained in that ServiceInterfaceSpecification.

Public


3 Metamodel SpecificationThis section presents the specification

3.1 OverviewIn this section we sketch out the main components of the UPMS-HA metamodel. The UPMSmetamodel is centred in the specification of services delegating other aspects of the service modellingto existing Metamodels such as Metamodels for information modelling, for behaviour modelling, forQoS modelling, and so on.

The service oriented metamodel has the objective of describing services architectures as proposed bythe W3C or OASIS. These architectures represent functionalities provided by a system or a set ofsystems to achieve a shared goal. These functionalities could be represented as a service or as a setof services. In this work we emphasize the concept of collaborations to address the different levels ofservice description.

Figure 2 represents partially the service metamodel. It is focused in the ServiceContract aspects thatwill be described latter. Figure 3 is focused in the ServiceSpecification aspects of the metamodel.Figure 4 is focused in the ServiceInterfaceSpecification aspect of the metamodel. Finally, Figure 5 isfocused in the ServiceComponent aspect of the metamodel. These four aspects ServiceContract,ServiceSpecification, ServiceInterfaceSpecification and ServiceComponent are the main elements ofthe service metamodel.

Figure 2 - Service Metamodel - Contract related elements

Public


Figure 3 - Service Metamodel - ServiceSpecification related elements

Figure 4 - Service Metamodel - ServiceInterfaceSpecification related elements

Figure 5 - Service Metamodel - ServiceComponent related elements

Public


3.2 Element SpecificationThe following specifies the elements the detail.

3.2.1 BehaviourDescription:The behaviour element is used to describe the realization of the ServiceContract and theServiceOperations along the time. In this sense the objective of this element is similar to the objectiveof the UML Behaviour element. This element is open to the usage of any UML behaviour specificationelements such as activities, states, etc.

Figure 6 –BehaviourAs needed we can establish relationships with other metamodels to allow the usage of their behaviourdescription languages. Clearly, this will affect the way in which platform assets are derived from thisPIM, it is not the same to generate a BPEL file from a BPDM process model or to do the same form anUML state machine.

Figure 7 –Behaviour link to external metamodelNamespace:UPMS-HA.Services

isAbstract:Yes

Generalization:None.

Attributes:None.

Associations:None.

Public


Constraints:To be defined.

Semantics:To be defined.

UML Element Extended:Behaviour

RFP Requirement:6.5.5.1 g. Behavioural rules for how the roles interact.

6.5.7.1 f. Behaviours as methods of operations provided by the service specification indication thebehavioural semantics that must be supported by any realizing service provider.

Notation:Not applicable

Presentation Options:Not applicable

3.2.2 CollaborationUseDescription:CollaborationUse element represents the usage of a ServiceContract in the context of anotherServiceContract (see Figure 2). It allows the definition of complex ServiceContracts that includes thefulfillment of other ServiceContracts.

Namespace:UPMS-HA.Services

isAbstract:No


Attributes:None.

Associations:+ serviceContract it points to the serviceContract realized by the collaborationUse

+ bindings it points to the serviceBindings between the services contained in the serviceContractpointed through the serviceContract association and the serviceContract that contains thecollaborationUse.



UML Element Extended:CollaborationOcurrence

RFP Requirement:6.5.5.1 a. the ability to specify bi-directional, complex, long-lived and asynchronous interactionsbetween service consumers and providers.

6.5.15 Composing Services from other Services

Notation:The example bellow shows a complex serviceContract “AirConditioning” that involves five serviceentities and three inner serviceContracts.

Public


Figure 8 – Notation: Complex ContractPresentation Options:Not applicable

3.2.3 EventDescription:It represents an event provided by a ServiceInterfaceSpecification. The event could be subscribed byServiceSpecification and ServiceComponent. These two ways of subscription are provided in order tosupport different levels of coupling between ServiceComponent and the providedEvents: a morecoupled one through ServiceSpecification and a less coupled one through a direct event subscription.

Public


Figure 9 – Events


isAbstract:No


Attributes:None.

Associations:+message it points to the message attached to the event in case it exists.



UML Element Extended:Class

RFP Requirement:6.5.10 Service Event Handling and Generation

Notation:

Figure 10 – Notation: Events


3.2.4 ExceptionDescription:It describes an unexpected behaviour during the operation execution. In case an exception occursduring the execution of an operation instead of sending the OutputMessage the ServiceComponentwill sent a exception message following the standardized format of the concrete platform.

Figure 11 – Operation Exception

Public



isAbstract:No


Attributes:None.

Associations:None.




RFP Requirement:6.5.7.1 c Operations pre and post conditions, parameters and exceptions

Notation:

Figure 12 – Notation: Operation Exception


3.2.5 InteractionPointDescription:Service interactionPoints represent points through which service interfaces are provided and required.A serviceSpecification could provide each of its service interfaces through a different set ofcommunication channels and protocols. This element supports the representation of that fact.

Figure 13 – Service InteractionPoint


isAbstract:

Public


No


Attributes:To be defined.

Associations:None.




RFP Requirement:6.5.8.1 Submission shall provide a means of indicating structured service data or informationexchanged between service consumers and services providers.

Notation:In UML the interactionPoints are represented through stereotyped classes. They are associated to theInterfaces through the serviceInterface element which is represented through a port. This informationis contained and it will be represented using dependencies from the port to the classes that representthe different set of communication channels and protocols.


3.2.6 MessageDescription:Messages represent the information exchanged between the service entities. A service can have inputand/or output messages. The data structure of the messages is addressed by the external datadefinition metamodels.

Figure 14 –Message link to external metamodel

Public



isAbstract:No



Associations:None.




RFP Requirement:6.5.7.1 e. Service interaction points through which service interfaces are provided and required inorder to decouple consumers and providers.

6.5.13.2 Service providers shall provide and require services only through service interaction points.Service providers shall not directly realize or use service interfaces other than realize servicespecifications This ensures isolation and decoupling between consumers and providers.

Notation:In UML the messages are represented with classes, and the information contained in those messagesfollow the representation introduced in the information package.


3.2.7 OperationDescription:Operations are behavioural elements of the services. They describe the inputs received and theoutputs returned, besides they could have an associated behavioural description of the way in which itinternally operates.

Public


Figure 15 – Service Operation


isAbstract:No



Associations:+Constraint It links the operation with the description or description of its behaviours

+precondition Conditions that should be meet prior to call the service

+postCondition Conditions that should be meet after calling the service

+InputMessages Information required by the service

+OuputMessages Information provided by the service



UML Element Extended:Operation

RFP Requirement:6.5.5.1 b The functions specified by the contract.

Public


6.5.7.2 b. Service operations in services interfaces.

6.5.7.2 c. Operation pre and post conditions, parameters and exceptions.

Notation:Operations are represented using the UML2 notation for operations.


3.2.8 ParticipationDescription:Participation element represents the relationship of a ServiceComponent with a Service in a givenserviceContractInstance. In other words, it represents the role (service) that ServiceComponent isplaying in a ServiceContract instance.


isAbstract:No



Associations:+serviceComponent It points to the serviceComponent that participates

+Service It points to the Service in the ServiceContract participated by the serviceComponent.



UML Element Extended:RoleBinding

RFP Requirement:

Notation:

Figure 16 – Notation: AirConditioner


Public


3.2.9 PartitionDescription:Partition is an auxiliary element that helps to organise the ServiceSpecifications andServiceComponents in categories. It also allows to define constraints to those categories.

Figure 17 – PartitionNamespace:UPMS-HA.Services

isAbstract:No



Associations:+serviceComponent It points to the contained serviceComponent

+constrain It points to the constrains applicable to the elements contained by the partition

+ServiceSpecification It points to the contained serviceSpecification.



UML Element Extended:Package

RFP Requirement:

Notation:

Public


Figure 18 – Notation: PartitionPresentation Options:Not applicable

3.2.10 ServiceDescription:Service element represent a service computing entity in a serviceContract, it could be a serviceprovider, a service consumer or both.


isAbstract:No



Associations:+specification It points to the serviceSpecification which describes the serviceInterfaces providedand required by the service entity.



UML Element Extended:Part

RFP Requirement:6.5.5.1 a The ability to specify bi-directional, complex, long-lived and asynchronous interactionsbetween service consumers and providers.

Notation:The figure bellow shows a simple contract “GetTemperature” between a consumer Service entity anda Sensor Service entity.

Public


Figure 19 – Notation: Simple Contract


3.2.11 ServiceBindingDescription:It represents the relationships between the service entities of a serviceContract and the serviceentities of the serviceContract contained in that serviceContract.


isAbstract:No



Associations:+service It points to the service of the Containing ServiceContract that is linked with a low levelservice entity

+boundservice It points to the Service in the low level ServiceContract participated by the Service.



UML Element Extended:RoleBinding



Notation:

Public


Figure 20 – Notation: Complex ContractPresentation Options:Not applicable

3.2.12 ServiceChannelDescription:Represents the interaction channel between services in a serviceContract.

Public


Figure 21 – Notation: Complex Contract


isAbstract:No



Associations:+Service It points to the Services that use that service channel.



UML Element Extended:Connector

RFP Requirement:6.5.16.1 Submission shall support serviceChannels for connections between usages of serviceconsumers and service providers in the internal structure of some containing element.

Notation:To be defined.

Presentation Options:

Figure 22 – Notation: Service Channel

3.2.13 ServiceComponentDescription:ServiceComponents represent computing entities realizing services. A ServiceComponent is asoftware representation of an autonomous business concept or business process. It implementsprovided services, defines the services it requests for it behaviour. They can be integrated in othercomponents to constitute larger systems. Service components could be structured and classifiedbased on their nature (such as Entity, Process, Utility, etc.).

Public


Figure 23 – ServiceComponentNamespace:UPMS-HA.Services

isAbstract:No

Generalization:No

Attributes:

No

Associations.+serviceContractInstances It points to the serviceContract Realized by the serviceComponent

+serviceSpecification It points to the serviceSpecifications realized by the serviceComponent.

+providedInterfaces It points to the ServiceInterfaces realized by the serviceComponent.

+requiredInterfaces It points to the ServiceInterfaces required by the serviceComponent.

Constraints.To be defined

Semantics:To be defined

UML Element Extended:Component

RFP Requirement:6.5.5.1 d The participants in the contract and the roles they play.

Notation:

Public



Figure 25 – Notation: ServiceComponent to ServiceSpecification

Presentation OptionsTo be defined

3.2.14 Service ContractDescription:Service contract represents a message exchange pattern between a set of services providers andconsumers. It can be as simple as one operation between two service roles (provider and partner)(see Figure 19), or a complex interaction involving several service roles and containing inner servicecontracts (see Figure 8).

Figure 26 – Service Contract

Namespace:UPMS-HA.Service

isAbstract:

Public


No

Generalization:No

Attributes:

No

Associations.+services It points to the service entities that take part in the contract

+constraints It points to the behaviour element describing the internal interactions in the contract.

Constraints.To be defined

Semantics:To be defined

UML Element Extended:Collaboration

RFP Requirement:6.5.5.1 a Submission shall provide a means of specifying contracts (i.e. requirements) that must e metby service specifications or realizations.

Notation:

Figure 27 – Notation: Complex ContractPresentation OptionsTo be defined

Public


3.2.15 ServiceContractInstanceDescription:It represents a concrete instance of the service contract where the service entities are associated toconcrete serviceComponents.


isAbstract:No



Associations:+serviceContract It points to the serviceContract realized by this serviceContractOcurrence

+Participation It contains the participation elements associated to that serviceContractOcurrence.



UML Element Extended:Collaboration use

RFP Requirement:

Notation:



3.2.16 ServiceInterfaceDescription:It represents a serviceInterface that could be provided through an interactionPoint is aServiceSpecification. Different ServiceSpecification can implement the sameServiceInterfaceSpecification using the same or different interationPoints (protocols, channels,…). Inorder to to decouple the ServiceInterfaceSpecification from the ServiceSpecification theServiceInterface element is introduced, it works as an interaction port who provides or consumes theoperations defined by a given ServiceInterfaceSpecification. This element is also used to identify theconsumers and providers of the different ServiceInterface in the context of a ServiceSpecification.

Public


Figure 29 – ServiceInterface


isAbstract:No



Associations:+InteractionPoint It points to the InteractionPoints used by pointed interface specification.

+ServiceInterfaceSpecifcation It points interfaceSpecification, a interfaceSpecification could be pointthrough several service interface.



UML Element Extended:Port


6.5.7.2 b. Service operations in service interfaces.

Notation:

Public


Figure 30 – Notation: Operation getTemperature


3.2.17 ServiceInterfaceSpecificationDescription:It describes the service interface, their operations and the messages it exchanges.


isAbstract:No



Associations:+Operations It points to the operations provided by the service



UML Element Extended:Interface



Notation:

Public


The ServiceInterfaceSpecification are modeled as UML2 interfaces using theServiceInterfaceSpecification stereotype.


3.2.18 ServiceSpecificationDescription:A Service can be a very simple feature of a system who is able to provide a set of operation toexternal system. But, on the other hand, it can be a complex exchange of information between aservice provider and a service consumer. The ServiceSpecification describes the service, and it pointsto the ServiceInterfaces which are provided and required to fulfil the objectives of the service..

Figure 31 – ServiceSpecification


isAbstract:No



Associations:+ProvidedInterfaces It points to the ServiceInterfaces Provided by the service.

+RequiredInterfaces It points to the ServiceInterfaces Required by the service.



UML Element Extended:

Public


Component



Notation:

Figure 32 – Notation: Operation getTemperaturePresentation Options:Not applicable

Public


4 Responses to SHAPE ScenariosAll the case studies from the project require in one way, or another, the availability of a commonlanguage to describe their services architectures. This language should be able to cope with theneeds of the project use cases. A summary table of the needs extracted from the use cases areshown bellow. This table also describes the way in which the metamodel and the profile address thoseneeds.

Requirement Resolution

Represent the different stakeholders whoprovide and consume services.

This is supported by the serviceComponentconcept of the metamodel.

A service must be usable in the realization ofother services

A ServiceSpecification can be realized byseveral serviceComponents and it can be usedby different contracts.

Capability to model service orchestration andchoreography

The metamodel allow the description of theprocesses that represent the internal behaviourof the service entities with any behaviourmodelling notation.

describe services in such manner that they canbe used by different stakeholders forimplementation

The ServiceSpecifications are used or providedby the serviceComponents.

Split the Logical and the Technical view The metamodel does not allow to modelplatform aspects of the service based system.It is focused in the modelling of the logicalaspects of the service interaction. Latterly, themodel can be deployed in any service capableinfrastructure.

Architecture modelling The metamodel is capable to representarchitectures using serviceComponents andServiceContracts.

Interaction pattern modelling ServiceContracts can be used to modelinteraction patterns, that can be applied indifferent parts of the system.

Service modelling The metamodel provides a full support forservice modelling.

Parts identification The metamodel supports the modelling of thedifferent parts of the system with theserviceComponent element.

Support the modeling of loosely coupledservices that are interacting with theenvironment through ports

The metamodel supports different levels ofcoupling between service ServiceComponents.These levels relay in the usage of Service andrequest ports, ServiceInterfaces andServiceContracts.

Data modelling Information is modelled using UML2 elements,and these data structures are used for theserviceInterfaces descriptions.

Table 1 Case Study Requirements

Public


The following subsections provide a cross-reference between the needs extracted from the individualSHAPE scenarios [2] and the corresponding responses provided by this metamodel and profile.

4.1 StatoilHydro Use Case Scenarios

4.1.1 StatoilHydro: Production and Process OptimizationThe main objective of the metamodel in the context of this case scenario is to support the modellingfor production and process optimization taking into account that this optimisation is highly dependentin the services provided by the different production facilities and the way in which those services areorchestrated.


Capability to model the different entities thatprovide and require services such as thesurface and the topside facilities.

This is supported by the serviceComponentconcept of the metamodel. Both surface andtopside facilities can be modelled asserviceComponents that provide and requireservices from other serviceComponents.

To have a set of consistent, updated andintegrated models of the subsurface andtopside facilities as a basis for real-timeproduction optimization.

The metamodel supports the description of theinteraction among the types ofserviceComponents and also among concreteserviceComponents.

Each process will change over time, and therewill be several processes using the sameservices simultaneously

A ServiceSpecification can be realized byseveral serviceComponents and it can be usedby different contracts. Accordingly the differentprocesses within the serviceComponents andthe contracts can make use of the sameServiceSpecification playing the role ofproviders or consumers.

simplify the orchestration by using processmodelling and services

The metamodel allow the description of theprocesses that represent the internal behaviourof the service entities with any behaviourmodelling notation. For example the processthat model the interaction of the servicesprovide and used by a serviceComponent canbe modelled using any of the behaviourdescription UML diagrams such as activitydiagrams, sequence diagrams and so on.

create adaptable workflows (businessprocesses) based on semantics

The metamodel is open to any behaviouralrepresentation notation, especially those fromthe UML2 metamodel. This allows therepresentation of workflows to define the way inwhich the processes interact together.

describe the services consumed by theprocesses

The metamodel supports the modelling ofservice through the ServiceSpecificationelement. This interface can be latterly realizeby serviceComponents or used in contracts.

describe services in such manner that they canbe used by different stakeholders forimplementation

The ServiceSpecifications are used or providedby the serviceComponents.

Public


4.1.2 StatoilHydro: “Collecting drilling data” – for “Semantic EnabledSOA”

The main objective of the metamodel in the context of this case scenario is to support the modelling ofsystems being compatible with WITSML.


model the services in WITSML It is not objective of this deliverable todemonstrate who the metamodel support themodelling of WITSML system.

Anyhow, the metamodel relays in UML2 formthe representation of data structures, andUML2 should be capable to represent theWITSML format.

4.1.3 StatoilHydro: “Scheduling product cargos” for “SOA and MAS”The main objective of the metamodel in the context of this case scenario is to support the modelling ofagent based service systems.


model the problem domain components asagents

The metamodel provide the ServiceComponentelement that can be extended to representagents.

Model the algorithms The metamodel supports the usage of differentnotations to model behaviour: UML2 activitydiagrams, sequence diagrams, etc.

4.1.4 StatoilHydro: “SOA and variability in data intensive systems”The main objective of the metamodel in the context of this case scenario is to support the modelling ofagent based service systems.


Information ownership and external access The metamodel does not cover the modellingof the ownership and rights over theinformation, this should be covered using otherstandards and Metamodels.

Provided and required associations areinteraction point between differentserviceComponents. Therefore, they allow torepresent external access.

Split the logical and the technical view The metamodel does not allow to modelplatform aspects of the service based system.It is focused in the modelling of the logicalaspects of the service interaction. Latterly, themodel can be deployed in any service capableinfrastructure.

Public


4.1.5 StatoilHydro: Integrated Operations – Reference architectureThe main objective of the metamodel in the context of this case scenario is to support the modelling ofthe reference architecture of the different StatoilHydro systems.


Architecture modelling The metamodel is capable to representarchitectures using serviceComponents andServiceContracts.

Interaction pattern modelling ServiceContracts can be used to modelinteraction patterns, that can be applied indifferent parts of the system.

Semantic model The semantic model can be partially modelledusing the UML2 data modelling capabilities andthe behaviour description capabilities. Inupcoming deliverables this metamodel will beextended to better support the semanticmodelling.

Service Modelling The metamodel provides a full support forservice modelling.

4.2 Saarstahl Use Case Scenarios

4.2.1 Saarstahl: Manufacturing planning and control systemThe main objective of the metamodel in the context of this case scenario is to support therepresentation of the business model in the platform independent view for its deployment in specificplatforms.


Mappings from Business These mappings are not covered in thisdeliverable. They will be addressed in otherSHAPE deliverables.

Mappings to platforms These mappings are not covered in thisdeliverable They will be addressed in otherSHAPE deliverables.

Agents support The metamodel provides agent support throughthe ServiceComponent element.

4.2.2 Saarstahl: “Creation and Optimization of Heats and Sequences”The main objective of the metamodel in the context of this case scenario is to support the modelling ofservice based system for the creation and optimization of heats and sequences.

Public



Parts identification The metamodel supports the modelling of thedifferent parts of the system with theserviceComponent element.

Process modelling The metamodel uses any of the UML2behavioural diagrams to represent processes

Service modelling The metamodel provides all the elementsrequired to describe the services and link themto the serviceComponents that realize themand to represent the way in which theseservices are used in the processes

4.2.3 Saarstahl: Coordination between Rolling Mills and SteelworksThe main objective of the metamodel in the context of this case scenario is to support the modelling ofservice based system for the Coordination between Rolling Mills and Steelworks.


service interaction patterns should be used andhow can those be modelled

The metamodel includes the ServiceContractelement to model interaction patterns amongdifferent serviceComponents

How to formulate business requirements on theCIM level that can then be easily translated intoa running system

This is not covered in this deliverable. Therepresentation of the business requirementsand the rationale of their transformation into theservice model will be addressed in latterdeliverables.

4.2.4 Saarstahl: Capacity planning of Annealing FurnacesThe main objective of the metamodel in the context of this case scenario is to support the modelling ofservice based system for the Capacity planning of Annealing Furnaces.


Services architecture The metamodel is able to model servicesarchitectures using ServiceComponents andServiceContracts

choreography Choreographies can be modelled with activitydiagrams, sequence diagrams, or ay otherUML2 behaviour diagram.

4.2.5 Saarstahl: Cross-plant order coordination from steel works’point of view

The main objective of the metamodel in the context of this case scenario is to support the modelling ofservice based system for the Cross-plant order coordination from steel works’ point of view.

Public



Support the modeling of loosely coupledservices that are interacting with theenvironment through ports

The metamodel supports different levels ofcoupling between service ServiceComponents.These levels relay in the usage of Service andrequest ports, ServiceInterfaces andServiceContracts.

4.2.6 Saarstahl: Concrete Requirement Specification “Creation andOptimization of Heats and Sequences”

The main objective of the metamodel in the context of this case scenario is to support the ConcreteRequirement Specification specifically in the “Creation and Optimization of Heats and Sequences”.


Participants and features At requirements phase the participants can bemodelled as UML usecase actors that could belatter realized by participants. The features ofthe system are modelled using usecases,usecases can be latter modelled usingServiceSpecifications and ServiceContracts.

Data modelling Information is modelled using UML2 elements,and these data structures are used for theserviceInterfaces descriptions.

Public


5 Responses to RFP RequirementsThe following tables provide a cross-reference between the requirements as stated in the Request forProposals [1] and the corresponding responses provided by this submission.

5.1 Mandatory RequirementsRequirement Resolution

6.5.1 Required Profile

6.5.1.1 Submissions to this RFP shall provide aMOF metamodel and equivalent Profileextending UML for Services Modelling asspecified in other mandatory requirementsspecified in this RFP.

The metamodel is provided in the section (2) andthe profile is introduced in the notation section ofeach of the elements of the metamodel.

6.5.2 UML Compatibility

6.5.2.1 These metamodel and profileextensions can extend, but not conflict withexisting UML semantics for extendedmetaclasses.

No conflicts were detected.

6.5.3 Notation

6.5.3.1 Submissions shall specify icons forstereotype extensions to UML in order toextend the UML notation for servicesmodelling.

To be defined.

6.5.4 Platform Independent

6.5.4.1 Submissions shall express the intent ofservices models rather than any specificmeans by which that intent may be realized bysome runtime platform.

The metamodel supports the definition of a servicemodel that could be deployed in different runtimeplatforms (Web service, agent, grid, p2p, …).

6.5.4.2 Submissions shall include a non-normative mapping from the Services Profile toWeb Services (XSD, WSDL, BPEL, etc.) inorder to demonstrate the completeness andapplicability of the submission.

To be defined

6.5.5 Specification of Service Contracts

6.5.5.1 Submissions shall provide a means ofspecifying contracts (i.e., requirements) thatmust be met by service specifications orrealizations. Service contracts shall include:

a. The ability to specify bi-directional, complex,long-lived and asynchronous interactionsbetween service consumers and providers

b. The functions specified by the contract.

c. The ability to realize UseCases that capturecontract requirements.

d. The participants in the contract and the rolesthey play.

e. The responsibilities of those roles in thecontext of the contract. It shall be possible to

Collaborations are the containers used to specifyservice contracts in UML. Therefore ServiceContract is a specialization of Collaboration.

a) Via its CollaborationUse and ServiceBindingtogether with behaviour element bi-directional,complex, long-lived and asynchronous interactionscould be specified (see Figure 19 and Figure 8).

b) Functions are described through the operationscontained in the service descriptions associated tothe services of the service contract (Figure 15).

c) Service contract Is stereotyped from UMLcollaboration, therefore it is possible to representrealization between use-case and service contract(see Figure 33).

Public


specify these responsibilities using serviceinterfaces, service specifications, or particularservice providers (see Section 6.5.13).

f. Connectors indicating possible interactionsbetween roles.

g. Behavioural rules for how the roles interact.

h. Constraints or objectives that must be met.

Figure 33 – Notation: Use Case Realizationd) The participants in the contract are the servicecomponents and they are linked to the servicecontract Through ServiceContractInstances andParticipation binding between theserviceComponent and the Services contained inthe ServiceContract. The Role consumer orProvider are bound to the Service elementsthrough the ServiceSpecification and their interfaceprovided and required associations. (see Figure 21and Figure 24) .

e) ServiceSpecification could be used to specifyconcrete operations to be provided and required bythe different service entities.

f) Roles and ServiceChannels between the roles.

g) Constraining behaviour of the ServiceContract(see Figure 6).

h) pre and post conditions are included foroperations (see Figure 15).

6.5.5.2 Service contracts shall be consistentwith the upcoming BPDM choreography andcollaborations.

The current proposal does not elaborate ametamodel for the behaviour specification. Itdelegates the specification of the behaviourelements to existing Metamodels for choreography,collaboration, process, activity, state machines,etc..

6.5.6 Service Contract Fulfillment

6.5.6.1 Service specifications and/or providersshall have a means to indicate the servicecontracts they fulfill and how they provide forthe roles in the contract.

This is possible via the collaboration uses fromserviceComponent to the serviceContract (seeFigure 24). For service specifications therelationship starts from the ServiceContract whichpoints to the concrete serviceSpecification of theircontained Services

6.5.6.2 Submissions shall specify a means forsupporting both strict and loose contractfulfilment.

a. Strict contract fulfilment shall mean that aservice specification or service provider mustbe conformant with the service contracts itfulfils. Submissions shall provide a completedefinition of conformance which includes, but isnot limited to type, behaviour, and constraintconformance with the constraints,

Loose contract fulfilment will be covered throughthe introduction of loose coupling aspectsintroduced by the Appendix F: - Collaborativeservices through Semantic Interfaces

Public


responsibilities and rules for the role in thecontract.

b. Loose contract fulfilment shall mean themodeller warrants the service consumers andproviders are capable of playing the indicatedroles, but this is not validated by themetamodel, nor do all roles in the contracthave to be filled by the service specification orprovider.

6.5.6.3 The use of service contracts in anyservices model shall be optional. Servicescontracts also need not be fulfilled by anyservice provider (although tools would beencouraged to report on such contracts).

The metamodel allows representingServiceSpecifications without ServiceContract.These ServiceSpecification can be directly pointedby the serviceComponents realizing thoseServiceSpecification (see Figure 34).

Figure 34 – ServiceSpecification with noContract

6.5.7 Service Specification

6.5.7.1 Submissions shall provide a means ofspecifying service specifications independentlyof how those services are provided orimplemented. Such service specifications shallinclude:

a. Specification of possibly many ServiceInterfaces where all operations are consideredavailable in distributed, concurrent systemswith no assumptions about globalsynchronization, control or shared addressspaces. (Service interface definition inGlossary B.2)

b. Service Operations in Service Interfaces

c. Operation pre and post conditions,parameters and exceptions

d. Constraints service providers are expectedto honour

e. Service interaction points through whichservice interfaces are provided and required inorder to decouple consumers and providers

f. Behaviours as methods of operationsprovided by the Service Specification indicatingthe behavioural semantics that must besupported by any realizing service provider.

Service specification does not contain details onhow they are provided or implemented.

a) ServiceSpecification can contain one or moreprovided and required interfaces.

b) Service interfaces contain operations

c) pre and pos conditions are provided

d) to be defined

e) Port (service) as a single interaction point.

f) Operations could be described with behaviourelements

6.5.7.2 The use of service specifications in anyservices model shall be optional and areprovided for additional decoupling betweenservice consumers and service providers.Developers decide the degree of coupling that

It is also possible to only useServiceInterfaceSpecifications

Public


is tolerable for their solutions.

6.5.8 Specification of Service Data

6.5.8.1 Submissions shall provide a means ofindicating structured service data or informationexchanged between service consumers andservices providers.

Message could be define with any service modeldescription metamodel xsd, edoc, etc.

6.5.8.2 Submissions shall provide a means ofindicating components of service datarepresenting attachments containing opaqueinformation exchanged between consumersand providers. Such attachments shall providefor an indication of the type of the opaque datasuch as MIME type where applicable, or maybe represented by extensions to UML primitivetypes.

6.5.8.3 The usage semantics of service datashall make no assumptions with regard toglobal synchronization, control or sharedaddress spaces.

It does not

6.5.9 Synchronous and Asynchronous ServiceInvocations

6.5.9.1 Submissions shall support synchronousand asynchronous service invocation.

They are supported. Operations can have input andoutputs, or only one of those.

6.5.9.2 Synchronicity shall be a property of theinvocation of a service operation, not itsspecification in a service interface or itsimplementation in a service provider. That is, aservice provider may expect a service to beinvoked a certain way, but it is up to clientsusing the service to determine how the serviceis to be used. In particular, a service that hasoutput or return parameters may be calledsynchronously or asynchronously. It is up tothe client invoking the service to determine ifthe output is needed or not.

Part of the Behaviour specification in theserviceComponent.

6.5.10 Service Event Handling and Generation

6.5.10.1 Submissions shall provide a means ofdesignating the ability of a service specificationor provider to receive an event.

The metamodel includes the provision associationbetween ServiceInterfaces and events (see Figure9)

6.5.10.2 Submissions shall provide a means ofgenerating events targeted at a specific serviceprovider or broadcast to interested providers.

The metamodel includes the subscribe associationbetween events and ServiceSpecification andServiceComponents

6.5.10.3 Service operations that respond toevents shall not have outputs, are alwaysinvoked asynchronously, and may raiseexceptions.

Events do not require return messages; they onlydefine messages attached to the event itself.

6.5.11 Service Parameters

6.5.11.1 All parameter types of all operationsprovided by a service specification or serviceprovider shall be either primitive types orservice data in order to minimize coupling

Solved through separate information model.Connection only through messages.

Public


between service consumers and serviceproviders.

6.5.12 Service Consumers

6.5.12.1 Submissions shall provide a means ofdesignating a consumer which requiresservices provided by other service providers.

A consumer is a serviceComponent which requiresa relationship from its associatedserviceSpecification or to the service interface.

6.5.13 Service Providers

6.5.13.1 Submissions shall provide a means ofdesignating a service provider.

Service provider is a serviceComponent whichprovides a relationship from its associatedserviceSpecification or to the service interface.

6.5.13.2 Service providers shall provide andrequire services only through serviceinteraction points. Service providers shall notdirectly realize or use service interfaces otherthan realize service specifications. Thisensures isolation and decoupling betweenconsumers and providers.

ServiceComponents are linked tointerfaceSpecification through serviceInterface thatpoints to the interactionPoints allowed for eachserviceInterfaceSpecification

6.5.13.3 A service provider shall be able torealize zero or more service specifications.

A service provider can realize more than oneservice specification.

6.5.13.4 A service provider must be conformantto all service specifications it realizes.Submissions shall provide a complete definitionof conformance which includes, but is notlimited to type, behaviour, and constraintconformance. Such conformance rules shall beconsistent with the conformance rules forfulfilling service contracts.

Service specifications are used by servicecontracts and service components. We will have tofurther specify the conformance. See also 6.5.6.2.

6.5.13.5 An interaction point of a serviceprovider shall be able to provide and/or requireat least one service interface.

A service specification has to have at least oneinterface.

6.5.13.6 A service provider shall be able tospecify binding information applicable to all itsinteraction points for use in connecting toservice consumers.

To be defined

6.5.13.7 A service interaction point shall beable to restrict and/or extend the bindingsavailable through that interaction pointoverriding the binding information of itscontaining service provider.

To be defined

6.5.14 Service Realizations

6.5.14.1 Submissions shall provide a means ofspecifying the realizations of provided serviceoperations through owned behaviours of theservice provider.

Service component as an implementation of aservice can have its own Behaviour (how theservices provided by the service component arecomposed). Further more one can think ofrealizations of a service component through otherclassifiers like in UML.

6.5.14.2 Submissions shall provide multiplestyles for specifying behaviour implementationsincluding but not limited to UML activities,interactions, state machines, protocol statemachines, and/or opaque behaviours. These

Most of the process profiles inherit from thebehavioural elements. This metamodel uses theUML behavioural document, therefore it will beready to use any behaviour implementations (see

Public


may differ from the means used for the sameoperation in any realized service specification.

Figure 7).

6.5.15 Composing Services from otherServices

6.5.15.1 Submissions shall specify howservices are composed from other services.

Service component as an implementation of aservice can have its own Behaviour. This can beused to specify service compositions.

6.5.15.2 Submissions shall make noassumptions about or constraints on thenumber of levels of composed services, orimpose arbitrary distinctions between specificcomposition levels.

It does not, serviceContract can be nested asneeded with no restrictions.

6.5.16 Connecting Service Consumers withService Providers

6.5.16.1 Submissions shall support servicechannels for connections between usages ofservice consumers and service providers in theinternal structure of some containing element.

Service channels are contained inServiceContracts/Collaborations.

6.5.16.2 Submissions shall support differentdegrees of coupling between connectedservice consumers and providers by allowingservice providers to be specified by any of thefollowing:

a. A service interface (supports minimalcoupling by allowing connections to any serviceproviding that service interface)

b. A service specification (supports moderatecoupling by allowing connections to any serviceprovider realizing the service specification)

c. A service provider (provides direct couplingto a specific service provider)

a) Possible, since ServiceContract can only specifyroles and interfaces

b) Possible, since the ServiceContract can specifyspecifications of arbitrary complexity

c) Possible, since ServiceComponent can establishprovide and require relationships toserviceInterfaces.

6.5.16.3 Submissions shall provide a way forservice channels to specify a binding frompossible bindings specified on the connectedinteraction point of the service provider andbindings expected by the interaction point ofthe connected service consumer.

The constraints in the model should address thatissue.

6.5.17 Customizing and Extending Services

6.5.17.1 Submissions shall specify a means ofcustomizing and extending services that shallinclude, but not be limited to, the followingfacilities (as specified by UML):

a. Service specification or provider propertiesthat can be configured by setting values duringservice development, or deferred to servicedeployment or runtime.

b. Refinement and redefinition throughgeneralization/specialization.

c. Pattern or template specification and

Services and the structures on which they applyare defined in this submission as collaborationsand components. Both of these may be specializedand thereby add properties. However,customization and extending normally goes beyondadding properties.

Based on the works published by Haugen andMøller-Pedersen in [3] we explain here through theAirConditioner example some of the variability thatour submission handles.

The AirConditioner composite structure shown inFigure 35 is the composite structure of an abstractinstallation. As such it may also serve as the

Public


instantiation. composite structure of the complex service contractshown in Figure 8.

Figure 35 – Abstract AirConditioner CompositeStructure

We would like to define a service contract thatdescribes a specialization of the general one. Inthis specialization we would like to express that thepart set mySensor consists of one sensor for theliving room and between 1 and 4 sensors onsleeping rooms. We would like to be able to identifythese specific subsets by names such thatautomatic coding, constraints etc. may refer directlyto these new names without losing the fact thatthese sets are subsets of the general mySensor setand must comply to the constraints defined for thatset. This is shown in Figure 36.

Figure 36 – The special configuration of theAirConditioner

We have applied the role syntax where the newpart name is followed by a slash before the old partname. This is readable and easily understoodunlike using a subsets-constraint which would havebeen possible in standard UML 2.

Another feature with such configurations would beto define that the sensor of the sleeping roomsmust be of a special brand or quality while the onesin the living room may be of the default type. Thiscan easily be done by redefining the type of thesleepingroom part to be a specialization of Sensor.

Furthermore we could specialize the compositestructure further by adding properties to one of themySensor subsets and not the other. E.g. we coulddefine that the sleeping room sensors (of thespecialized type SleepSensor) are all connectedtogether.

As for the services themselves, they are defined as

Public


collaborations and as such the configurationdescriptions of composite structures shown aboveapply also to them. Thus we may define hierarchiesof services representing different service variants,and as we showed above we may define servicecontext hierarchies to represent serviceconfigurations.

For even more general approach to servicevariability please refer to the metamodel andexamples shown by Bayer et al. in [4]

6.5.18 Service Partitions

6.5.18.1 Submissions shall provide a means oforganizing service specifications and/orproviders into partitions for organisation andmanagement purposes.

The metamodel includes a partition element thatgroups ServiceComponents andServiceSpecifications.

6.5.18.2 Submissions shall provide a means ofspecifying constraints on the connectionsbetween service partitions.

Partition are associated to the constraint element

6.5.19 Service Model Interchange

6.5.19.1 The resulting metamodel and profileshall be made available as an XMI documentbased on the UML and MOF to XMI mappingspecifications and the UML rules forexchanging profiles using XMI.

Implicit

6.5.19.2 Instances of the service metamodelshall be exchanged using XMI as specified inthe MOF to XMI mapping specification.Instances of services models created using theequivalent UML profile shall be exchangedusing XMI as specified by the UML rules forexchanging instances of UML models withapplied profiles. Submissions shall defineinterchange compliance levels for each forthese XMI document formats.

Implicit

5.2 Optional RequirementsRequirement Resolution

6.6.1 Proposals may provide additionalmappings to existing platforms and languagesfor service specification and execution.

To be defined

6.6.2 Submissions may provide a means forspecifying the preferred encoding for servicedata exchange in order to maximizeinteroperability between service consumersand providers.

To be defined

6.6.3 Submissions may provide a means forspecifying a binding metamodel for capturingstructured binding information rather thansimple strings.

To be defined

Public


5.3 Issues to be DiscussedIssue to be discussed Resolution

6.7.1 Relationship to existing UML metamodel

Proposals shall discuss the relationship ofsubmission model elements and UML2modelling to demonstrate consistency with theUML metamodel. In particular, the followingareas shall be discussed:

Relationship to UML2 componentmodellingRelationship between servicespecifications and UML2«specification» ComponentClarification concerning options forwhere serviceschoreographies/communicationprotocols could be captured:

In a delegate part of a component

In an owned behaviour or a component

In a collaboration between parts ofanother assembly component

In the contract of a connector

In a port class (the type of a Port)

Using nested classes

Additional constraints needed foreffective services modellingFormalizing SOA modelling bestpracticesRelationship between service contractsand UML2 Collaborations andCollaborationUses as indicators ofcontract fulfillmentThe relationship between services andUML2 Ports and classes used to typeports.The use of UML2 Behaviours (Activity,Interaction, StateMachine,ProtocolStateMachine, and/orOpaqueBehaviour) in servicespecifications and realizations.Relationship between service data andpossible domain data used in serviceimplementations.

Not covered

6.7.2 Consistency Checks and ModelValidation

Submissions shall discuss how thespecification supports automated consistencychecks for model validation particularlybetween service contracts, servicespecifications, and service realizations.

Not covered

6.7.3 Applicability to Enterprise Service Bus Not covered

Public


Runtime Architectures

Submission shall discuss how the specificationrelates to or supports usage of EnterpriseService Bus (ESB) architectures.

6.7.4 Relationship to UDDI.

Submissions shall discuss how instances ofservices model may be used to captureinformation necessary to populate UDDIrepositories with information necessary forservice discovery and use.

These issues will be considered duringsubmission evaluation. They should not be partof the proposed normative specification. (Placethem in Part I of the submission.)

Not covered

5.4 Evaluation CriteriaEvaluation Criteria Resolution

6.8.1 Submissions will be evaluated on thedegree of formality used to express servicemodels and their semantics and balancebetween the concerns of understandability,completeness, precision, simplicity, andeconomy.

Formality is guaranteed by the metamodel.Understability is supported by the usage ofUML as the basis of the metamodel. Thecompleteness and precision are covered by the

6.8.1.1 Submissions that establish UML as thefoundation for services modelling and extend(i.e., define a new capability of) UML will bepreferred.

The Metamodel is build on top of UML, and itextends it only when necessary.

6.8.2 Submissions that specify semantics ofmodel element extensions using formalmethods such as OCL will be preferred.

OCL usage is possible as the metamodelextends UML2

6.8.3 Although the mapping from the servicesprofile to Web Services is nonnormative,submissions will be evaluated against thecompleteness of the mapping and the use ofOMG MDA principles and related work such asMOF QVT and IMM (for XML Schemas).

This will be implemented in latter stages of theSHAPE project

6.8.4 Evaluation will be based on the ability totranslate from one SOA platform to anotherusing the services profile as an intermediateform.

This will be implemented in latter stages of theSHAPE project

6.8.5 Clarity of the proposed specification forthe purpose of implementing conforming toolsfor modelling services and ease of reviewingfor correctness.

During the project several tools will bedeveloped that will guaranty this requirement

6.8.6 The precision, completeness,compactness, and clarity of the servicesmetamodel.

During the project several tools will bedeveloped that will guaranty this requirement

6.8.7 The ability of services models to betranslated to existing runtime platforms in

Transformation will be provided in otherSHAPE deliverables

Public


common use.

6.8.8 Clear layering of concepts in the servicesmetamodel required for modelling functionalbehaviour from those that specify optional non-functional properties such as performance orusability.

The definition of non-functional requirementswill be addressed using the extensionmechanisms of this metamodel

6.8.9 Consistency with existing UML2 notation.The ability to easily draw notation elements byhand and use them in collaborative modellingsessions.

The metamodel is build on top of UML2

6.8.10 The ability to support different views ofthe same model elements with different levelsof detail and different layout organisations inorder to facilitate comprehension by differentstakeholders.

Different levels of coupling are allowed by themetamodel

Public


6 References1 UML Profile and Metamodel for Services (UPMS) - Request For Proposal, OMG Document:

soa/2006-09-09. Available in http://www.omg.org/cgi-bin/doc?soa/2006-09-09

2 Case study scenario descriptions and requirements specifications. Deliverable D1.1. SHAPE.

3 Haugen, O. and Møller-Pedersen, B. Configurations by UML. in EWSA 2006 - European

Workshop on Software Architecture. 2006. Nantes, France: Springer LNCS 4344 ISBN 978-3-

540-69271-3 p 98 - 113

4 Bayer, J., Gerard, S., Haugen, Ø., Mansell, J., Møller-Pedersen, B., Oldevik, J., Tessier, P.,

Thibault, J.-P., and Widen, T., Consolidated Product Line Variability Modeling, in Software

Product Lines. Research Issues in Engineering and Management, Käkölä, T. and Dueñas,

J.C., Editors. 2006, Springer: Berlin Heidelberg New York. 3-540-33252-9 p. 195-241.

http://www.omg.org/cgi-bin/doc?soa/2006-09-09

Public


Appendix A: PIM4SOAA.1.1 IntroductionThere is an industrial interest in getting infrastructures that enable us to develop long termarchitectures for supporting inter and intra enterprise interoperability. Such an infrastructure must dealwith several issues from business level to the supporting software systems. Service orientedarchitectures (SOAs) provide solutions to several of those issues at the information technology level.For example, they address the integration of heterogeneous systems and the consumption offunctionalities from other enterprises.

Currently SOA solutions are too focused on the specific platforms where services are implemented. Asa consequence, information technology architectures become very sensitive to the technical andbusiness evolution. Additionally, these architectures can be affected by the evolution of the currentdevelopment and deployment platforms. In summary, a change in any of these domains (technical,business, development or deployment) will require the entire system to be rebuilt.

A possible solution to this situation could be to provide modelling languages, as abstractionmechanisms to split the logical solution from its technical implementation, which enables the definitionof services architectures independently from the used specific platforms. A modelling language raisingthe level of abstraction allows us to share models and provides a capability to generate platformsspecific assets (Models, code, standard documents). Unfortunately nowadays, there are no modellinglanguages based on service aspects, and able to set aside technical concerns in this way.

There are existing general purpose modelling languages such as UML [1] (Unified ModellingLanguage). UML is a standard for software system modelling. It is able to represent any kind ofsoftware system, from embedded software to enterprise applications. To allow this flexibility UMLprovides a set of general elements applicable to any situation such as classes or relationships. Whenwe try to model a SOA, we could find ourselves in a situation where everything is a class, a provider isa class, a service is a class, a registry is a class, etc, this could make the models difficult tounderstand and use.

In addition UML provides facilities to specialize UML for a specific domain as so-called UML profiles.But frequently, these mechanisms are not able to represent the semantics behind the domainconcepts.

In the context of ATHENA project a metamodel for SOA was developed. This metamodel allows todefine a platform independent model (PIM). This metamodel consists of a set of essential aspects forSOA. These aspects are service, process, information and quality of service.

A.1.2 The ChallengeAs described in the introduction the focus of SOA has mostly been on the platform. The advantages ofthe service oriented approach are really not platform dependent, but arise from the conceptualarchitecture of more or less loosely coupled services. The goal of creating the PIM4SOA metamodelwas to define a language that could be used to describe SOAs at a platform independent level.

The following summarizes a set of requirements and goals for the PIM4SOA metamodel:

The PIM4SOA metamodel should bridge the gap between the business analysts and the ITdevelopers and support mapping and alignment between enterprise and IT models.The PIM4SOA metamodel should define a platform neutral abstraction that can be used tointegrate and define mappings to web services architecture (WSA), business process, agentand peer to peer (P2P) execution platforms.

In order to validate the metamodel, an instance of the model should be created that describes a non-trivial SOA. Based on this instance, artefacts are to be generated for SOA platforms using model totext transformations. Specifically the following will be done: a PIM4SOA model will be generated froman enterprise model; based on the Modelling tool we will generate a complete PIM4SOA model; finally,web service artefacts are to be generated from the model.

Public


A.1.3 Solution OverviewTo solve the challenge we will use an MDA [2] approach in the implementation of the PIM4SOA.Applying a MDA approach allows the separation of concerns between the business solutions, thelogical solutions and the technologies used, avoiding organisations having to reinvent the wheel whenthere are changes at the logical or technical layer. Besides, using an MDA approach makes it possiblefor us to implement the same system functionality on different or combined platforms. For example,Web services technology could be used with P2P and agents technologies to provide new dynamicand flexible solutions.

To implement the MDA approach we first need to identify the platform independent metamodel to beused to represent the logical solution; and second we need to identify candidate platform specificmetamodels that will be used to generate the platform assets. Besides this, we require appropriatetransformations between both abstraction levels, and possibly transformations to the new metamodelfrom higher abstraction metamodels. We already have platform specific metamodels for SOA,metamodels such as WSDL, BPEL and XSD [3]; and business specific metamodels such as POP*; butwe lack platform independent metamodels for SOA and appropriate transformations to the platformspecific metamodels and from the business metamodels.

The PIM4SOA metamodel identifies four aspects where specific concerns can be addressed:

Information: In the context of virtual enterprises information represents one of the mostimportant elements that need to be described. In fact the other aspects manage or are basedon information elements.Service: Our main intention is to be able to describe SOA independently from the technologyused. Service represents business accessible functionality.Process: Processes describe a set of interactions amongst services in terms of messagesexchange.Quality of service (QoS): A suitable feature is the description and the modelling of non-functional aspects related with the services described.

Figure 37 represents our approach where we have identified a metamodel for each of the aspectsrequired. This set of metamodels is placed at the top layer of this figure. Once we have defined aPIM4SOA model, platform specific artefacts can be derived from it.

Platform IndependentModel for Service OrientedArchitecture metamodel

WSDLModel

XSDModel

InformationModel

ServiceModel

ProcessModel

QoSModel

BPELModel

Security, QoSModel

PIM Specification to PSM Specification

Platform Specific Model

Figure 37. PIM and PSM levelsFor the implementation of the metamodel we have used the EMF[ 5] tooling available in Eclipse [6],which allows us to define ecore metamodels using the EMOF (Essential Meta Object Facility) meta-metamodel. EMOF is a subset of MOF[7] (MOF is the meta-metamodel used to define UML). Thismeta-metamodel allows us to describe metamodels and then to be able to define models complaintwith the defined metamodel.

Besides, we have included another component to the solution to visualize and to create the PIM4SOAmodels. We have decided to use the UML profiling mechanism. For the implementation of the UMLprofile, we will use the UML 2.0 Framework available in Eclipse. This is a vendor independentimplementation of the UML 2.0 specification, which can be imported from some commonly, usedmodelling tools such as IBM Rational Software Modeller or Omondo.

A.1.4 PIM4SOA MetamodelAs we already have mentioned the PIM4SOA metamodel is based on four (information, service,process and QoS) aspects. Currently there are standardization initiatives for some of these aspects.

Public


Our intention is not to reinvent the wheel so we promote the usage of these already well-defined andstandardized metamodels for the definition of the aspects.

A.1.5 Information AspectThe metamodel for the information aspect is inspired by the UML for EDOC standard [8] and the Classrelated parts of the UML metamodel. It has been a design goal to keep the metamodel as simple aspossible, but still providing the needed expressive power. This means that a lot of the features in theUML 2.0 metamodel have not been replicated. An overview of the metamodel is shown in Figure 38.

The metamodel concept ItemType represents what is often referred to as simple types, such as string,integer and boolean. The simple types are the basic building blocks for information models. It hasbeen chosen not to include a set of standard types in the metamodel, but rather allow users to definetheir own set of basic types.

Figure 38. The information aspect of the PIM4SOA metamodelComplex types, similar to UML classes without operations, are represented by the Entity element.Entities can contain a set of attributes and can have associations between them. Attributes are typedeither by an ItemType or by an Entity.

A.1.6 Process AspectThe process metamodel is founded on work still in progress [9] for the BPDM [10] RFP from the OMG,with some modifications to allow integration with cross business process models and the otherPIM4SOA packages. An overview of the metamodel is shown in Fig. 3.

Figure 39. The process aspectThe process aspect is closely linked to the Service aspect, the primary link being an abstract classScope that can be instantiated as a Process belonging to a ServiceProvider from that aspect. Bothabstract and executable Processes may be modelled, according to this property of theServiceProvider.

The process contains a set of Steps (generally Tasks), representing actions carried out by theProcess. These essentially fall into two categories, interactions with other service providers, orspecialized actions requiring implementation beyond the scope of this model. The Process alsocontains a set of Flows between these actions, which may be specialized (ItemFlow) to indicate thetransfer of specific data.

A.1.7 Service AspectThe service aspect has the objective of describing services architectures, as proposed by the W3C[11]; these architectures are composed of functions provided by a system or a set of systems toachieve a shared goal. Its scope ranges from the description of a simple service to the description of a

Public


set of services provided by different systems to achieve a given objective. The Collaborationsapproach used addresses both of these levels of service description rather than tying to a specificviewpoint.

Figure 40. The service oriented aspectFigure 40 illustrates the service oriented metamodel composed essentially of:

Collaboration: a service is viewed as a collaboration of a set of rolesCollaborationUse: represents the usage of collaborationRole: A Role represents a part involved in a service.Behaviour: is an abstract class for the specification of the Process.

A.1.8 Quality of Service AspectAs starting point this part of the metamodel is based on the quality of service OMG standard calledUML Profile for Modelling Quality of Service and Fault Tolerance Characteristics and Mechanisms[12]. Therefore we have extracted a set of elements needed from this standard to describe QoSelements (see Figure 41).

Figure 41. The QoS aspect

A.1.9 e-Procurement Scenario, a sample use of the metamodelWith the purpose of testing the metamodel, to know how it addresses the challenges identified at thebeginning of the project, we decided to apply the proposed solution to a real scenario. The scenarioselected was the modelling and implementation of an e-procurement process over a SOA. Theprocurement process, traditionally, covers the activities that one organisation should perform to derivethe material to be purchased from the providers to build the products requested by the customer. Thee-procurement process aims to implement the same functionality using information andcommunication technologies. This e-procurement process has been extracted from documentsdescribing current practice in the furniture sector.

In this section, we present the input used to create the PIM4SOA model for the e-procurementscenario, the PIM4SOA model generated, and the output artefacts generated from this model.

A.1.10 Model InputThe input for the generation of the PIM4SOA model can come from several sources, but we will focuson two of them. We can use as input models with higher level of abstraction, or we can use models atthe same level of abstraction.

An enterprise model, such as POP*, is an example of a model with higher level of abstraction fromwhich we could derive a PIM4SOA. The POP* model, among other information, includes the process,organisation, products and infrastructure details of a business scenario. Using an enterprise model asinput has the advantage of translating the business requirements to the infrastructure requirements ina formal way.

Public


An UML profile, such as the PIM4SOA Profile, is an example of a model with the same level ofabstraction. As we already have mentioned, we use the PIM4SOA profile for graphically visualize anddraw PIM4SOA models. But even if they manage the same concepts they are not physically the same.The PIM4SOA Profile, physically, is a UML model that uses stereotypes representing the concepts ofthe PIM4SOA metamodel, while the PIM4SOA Model, physically, is a XMI file that uses elementsproper of the PIM4SOA metamodel.

The usage of the UML profile, allow us to get profit from the current state of the practice UMLmodelling tools to model our PIM4SOA solutions. Later we can transform the generated UML model toa PIM4SOA model that can be used to generate platform specific assets.

In the e-Procurement example we decided to start from a higher level of abstraction level, in our casea POP* model developed by business experts. The objective was to generate a SOA solution, thatunambiguously reflects the POP* model provided by the business experts.

In order to transform from the POP* Input file to the PIM4SOA metamodel we implemented atransformation using MTF [13]. MTF stands for Model Transformation Framework, it is a preliminaryimplementation of the QVT[14] incoming standard implemented by IBM. QVT (Query, View andTransformation), is a specialized language that is being developed under the OMG. One of thepurposes of this language is to allow the transformation between models.

A.1.11 PIM4SOA ModelAs a result of the transformation of the POP* model we will obtain the following PIM4SOA model, seeFigure 42 (Figure 42 shows the generated model using a simple PIM4SOA treeview editor, that isautomatically generated by EMF for the PIM4SOA metamodel).

Figure 42. Partial view of the PIM4SOA model for e-ProcurementThis model implements all the requirements stated by the business expert, but it does not contain allthe information needed to generate the platform specific artefacts. For example, the information aboutthe specific format of the messages exchanged is not defined at business level. Therefore, thisinformation must be defined at this point.

For the completion of the PIM4SOA model we have used the PIM4SOA Profile that allow us to modelin a graphical tool which is easier than using the treeview based editor provided by EMF.

Once the PIM4SOA model is completed we can proceed to the generation of the different platformspecific artefacts. We have developed specific transformations to derive the platform specific artefactsfrom the PIM4SOA model. More concretely, we have developed transformation for deriving XSD,WSDL, and BPEL documents from the PIM4SOA metamodel.

A.1.12 Model outputIn this example we decided to generate artefacts for the WSA, more concretely we have generated theWSDL, the XSD and the BPEL documents required to support the PIM4SOA model using thetransformations that we developed.

A transformation from PIM4SOA to WSDL was developed using Java and the implementation of aWSDL metamodel provided by the Eclipse Webtools project[15]. This implementation providesautomatic serialization and deserialisation of WSDL models to WSDL files.

The WSDL concepts that are generated from the transformation are PortTypes with Operations,Messages and PartnerLinkTypes. The PartnerLinkTypes are created in order to provide a tie-in for the

Public


BPEL. The source for the WSDL transformation is mainly the Service aspect of the PIM4SOA, withelements from the Information aspect in order to handle messages. The target of the transformation isWSDL 1.1.

Finally, the BPEL is mainly generated from the process perspective of the PIM4SOA metamodel. Aparticular ServiceProvider from the PIM is transformed with reference to the collaborations (BPELpartnerlinks) defined in the Service aspect, and the process generated from the list of tasks defined forthe ServiceProvider’s behaviour.

A.1.13 Discussion of solutionAs presented in the previous chapters the high level goals of creating an instance of a PIM4SOAmodel and generating Web Service artefacts was achieved. PIM4SOA model instances have beencreated from the enterprise modelling language POP*, proving that the PIM4SOA metamodel can actas a “meeting point” for different tools.

In writing the PIM to PSM transformation to the Web Service artefacts it took some effort to map thePIM concepts to PSM elements. This was a challenge at the conceptual level, since the metamodelhas abstracted a lot of specifics from the PSM. Especially the mapping from PIM Collaborations toPSM PartnerLinks, PortTypes and Operations was hard. In addition a concept that would naturallymap to the WSDL concept of Service is missing.

A.1.14 Relationship to UPMS-HAThe PIM4SOA is heavily related to the UPMS-HA. In order to define the PIM4SOA as an extension ofthe UPMS-HA for business translation to webservices, four changes will be required.

Replace the service dimension of the PIM4SOA with the service dimension if the UPMS-HA.extend the UPMS-HA message element with the information dimension of the PIM4SOA.extend the behaviour of the UPMS-HA with the process dimension of the PIM4SOA.extend the ServiceSpecification element with NFA

A.1.15 References1. Object Management Group, UML 2.0 Superstructure Specification. 2003, Object ManagementGroup.

2. Object Management Group, MDA Guide Version 1.0.1, J. Miller and J. Mukerji, Editors. 2003,Object Management Group.

3. World Wide Web Consortium, XML Schema Part 0: Primer Second Edition. 2004, World WideWeb Consortium. http://www.w3.org/TR/xmlschema-0/.

4. Object Management Group, XML Metadata Interchange. 2003, Object Management Group.http://www.omg.org/cgi-bin/apps/doc?formal/03-05-02.pdf.

5. Eclipse Foundation, Eclipse Modelling Framework. 2005. http://www.eclipse.org/emf.

6. Eclipse Foundation, Eclipse platform. 2005. http://www.eclipse.org.

7. Object Management Group, Meta Object Facility 2.0. 2003, Object Management Group.http://www.omg.org/docs/ptc/03-10-04.pdf.

8. Object Management Group, UML Profile for Enterprise Distributed Object ComputingSpecification. 2002, Object Management Group.http://www.omg.org/technology/documents/formal/edoc.htm.

9. IBM, et al., Business Process Definition Metamodel - Revised submission. 2004, ObjectManagement Group. http://www.bpmn.org/Documents/BPDM/OMG-BPD-2004-01-12-Revision.pdf.

10. Object Management Group, Business Process Definition Metamodel - Request For Proposal.2003, Object Management Group. http://www.omg.org/docs/bei/03-01-06.pdf.

11. World Wide Web Consortium, Web Services Architecture. 2004, World Wide Web Consortium.http://www.w3.org/TR/ws-arch/.

http://www.w3.org/TR/xmlschema-0/.

http://www.omg.org/cgi-bin/apps/doc?formal/03-05-02.pdf.

http://www.eclipse.org/emf.

http://www.eclipse.org./

http://www.omg.org/docs/ptc/03-10-04.pdf.

http://www.omg.org/technology/documents/formal/edoc.htm.

http://www.bpmn.org/Documents/BPDM/OMG-BPD-2004-01-12-Revision.pdf.

http://www.omg.org/docs/bei/03-01-06.pdf.

http://www.w3.org/TR/ws-arch/.

Public


12. Object Management Group, UML™ Profile for Modelling Quality of Service and FaultTolerance Characteristics and Mechanisms. 2004, Object Management Group.http://www.omg.org/docs/ptc/04-09-01.pdf.

13. IBM Alphaworks, Model Transformation Framework. 2005.http://alphaworks.ibm.com/tech/mtf.

14. Object Management Group, Request For Proposal: MOF 2.0/QVT. 2004, Object ManagementGroup.

15. Eclipse Foundation, The Eclipse Webtools project. http://www.eclipse.org/webtools.

http://www.omg.org/docs/ptc/04-09-01.pdf.

http://alphaworks.ibm.com/tech/mtf.

http://www.eclipse.org/webtools.

Public


Appendix B: UPM for AgentsThe similarities between agent architectures and SOAs have already been recognized [1]. In fact, thestrong correspondence between the platform-independent model for SOA (PIM4SOA) [2] and themetamodel for BDI agents (JackMM) confirms this observation. Hahn et al (2006) (see [3]), showedhow to translate the metamodel of the PIM4SOA and its concepts into adaptive and executable BDI-agents [4].

B.1.1 Agent ModellingAgent-oriented software engineering (AOSE) is rapidly emerging in response to urgent needs in bothsoftware engineering and agent-based computing. While these two disciplines co-existed withoutremarkable interaction until some years ago, today there is rich and fruitful interaction among themand various approaches are available that bring together techniques, concepts and ideas from bothsides. One good example is the work which is done within the OMG Agent Platform Special InterestGroup that aims to leverage and interoperate with OMG specifications in the agent area.

Other examples are the Agent Modelling Language [5] (AML) that is a semi-formal visual modellinglanguage for specifying, modelling and documenting systems that incorporate features drawn frommulti-agent systems theory. It is specified as an extension to UML 2.0 in accordance to OMG's majormodelling frameworks (e.g. UML). The ultimate objective of AML is to provide software engineers witha ready-to-use, complete and highly expressive modelling language suitable for the development ofcommercial software solutions based on multiagent technologies.

B.1.2 Agent UMLAgent UML is an extension of the Unified Modelling Language (UML) to overcome the limitations ofUML with respect to MAS development. Agent UML results from the cooperation between the ObjectManagement Group (OMG) and the Foundation of Intelligent Physical Agents8 (FIPA), aiming toincrease acceptance of agent technology in industry.

The main parts of the Agent-UML modelling language are the agent class diagram and agentinteraction protocol diagram that bases on UML2.0 sequence diagrams.

An agent class diagram is an extension of the UML class diagram. Agents are specified using UMLstereotyped classes. They have three characteristics: An identifier uniquely identifies each agent in theMAS. A role defines the behaviour of an agent within the society, for instance, Seller or Buyer. Agentscan have multiple roles in the MAS or they can change from role to role during the execution of theMAS. Agents evolving in MAS belong to one or several organisations. These organisations define theagent roles and the relationships between these roles. Organisations correspond generally to humanor animal organisations such as hierarchies, markets, groups of interest or herds. Furthermore,concepts exist that model capabilities, services and protocols. Each of them has also their owncharacteristics (such as input, output for services, type, ontology for services, etc.).

An interaction protocol diagram combines the notation of the sequence diagram and the state diagramfor the specification of interaction protocols. They have the following characteristics: In UML, the roleconcept is an instance focused term. In Agent UML a role defines a set of agents satisfyingdistinguished properties, interfaces, service descriptions or having a distinguished behaviour. Agentscan perform various roles within one interaction protocol. The agent lifeline in protocol diagramsdefines the time period during which an agent exists, represented by dotted vertical lines. The lifelinestarts when the agent of a given role is created and ends when the interaction of one role with theother terminates in the interaction protocol. A lifeline may split up into several lifelines to indicate thedifferent branches in the message flow. A lifeline's split can be realized by different connector types(e.g. XOR, OR, AND) that split again the thread of interaction. Each thread defines how an incomingmessage is processed and which messages are sent as response. As interaction protocols can becodified as recognizable patterns of agent interaction, they become reusable modules of processingthat can be treated as first-class notions. Thus, Agent UML allows to nest interaction protocols.

8 FIPA is a non-profit organization aimed at producing standards for the interoperation of heterogeneous software agents.

Public


B.1.3 PIM4AgentsHowever, the transition from laboratories to deployed industrial applications is still considered as bigchallenge as many of the agent-oriented methodologies do not provide a straightforward interface forimplementation. Even if existing methodologies have different advantages when applied to particularproblems, it seems to be widely accepted that a unique methodology cannot be applied to eachproblem without some (minor) level of customization.

The model-driven architecture (MDA) proposed by the Object Management Group (OMG) is a recentdevelopment in the area of software engineering. It is interesting to see that some of the concepts thatwere already developed in the area of agent technologies and MAS nicely match with the ideas ofMDA. Our aim is to translate the basic ideas of MDA into methodologies for the design of agent-basedsystems and in doing so to contribute to bridging the gap between traditional software engineering andagent-based system design. To take this one step further, we not only need to integrate MDA into themethodologies of agent-based system design but also demonstrate how such methodologies can beutilized in practical development frameworks for agent-based system design. At this step some basicquestions arise:

Agent-oriented methodologies often do not rely on existing agent-based development tools, i.e. theydo not provide a straightforward interface for implementation..

Even if existing methodologies have different advantages when applied to particular problems, usuallya unique methodology cannot be applied to each problem without some (minor) level of customization.

MAS implementation requires deep knowledge regarding technical details of agent architectures,multiagent development tools, and agent concepts.

The question how to fill the gap between agent methodologies and agent-based development toolsleads to the development of a framework that (i) simplifies the design and implementation of agentsystems and (ii) allows to integrate already existing agent frameworks into a single tool box in order toincrease the degree of utilization in practice.

In our ongoing work, we offer a proposal on how to exploit the MDA ideas and techniques in AOSE.Beside the general benefit to improve (i) quality by allowing to reuse models and mappings betweenmodels and (ii) software maintainability by favoring a better consistency between models and code, weare especially interested in exploring a framework that (i) establishes interoperability among variousagent systems and other information technologies, and (ii) identifies a core metamodel that unifies themost common agent-oriented concepts to increase the efficiency in developing agent-based softwareapplications. To increase the interoperability among agent methodologies we follow the approachillustrated in Figure 43. Starting with a metamodel at the PIM level that defines the requirements of aparticular application domain in which agent-oriented computing should be applied, we transformconcepts required by the domain to various agent specific metamodels on the PSM level.

Public


Figure 43: The overall picture: From a particular application domain (e.g. a PIM metamodel forSOA) to a PIM metamodel for agents to miscellaneous agent-oriented execution platforms like

Jack and Jade.The work on a platform independent model for agents (PIM4Agents [6]) is a first step to overcome thislimitation. Basing on the ideas of MDA, the PIM4Agents that has been developed at the GermanResearch Center for Artificial Intelligence (DFKI) links domain-specific architectures (e.g. SOA) withexisting agent-oriented platforms like JACK and JADE and thus supports the developer in using anappropriate and intuitive modelling language and methodology that can be used to transform modelsto executable code. One challenge in defining the platform-independent model for agents – like forevery metamodel on the PIM level - is to decide which concepts to include and abstract from the targetexecution platforms (PSMs) that support the architectural style of agent-based systems.

In order to support an evolution of the PIM4Agents metamodel, it is structured around a small core thatcould be possibly enriched by adding smaller extensions, each focusing on either specific aspects ofan agent system or particular domain-specific aspects. Grouping modelling concepts in this mannerallows the metamodel evolution by adding (i) new modelling concepts for particular aspects, (ii)extending existing modelling concepts, or (iii) defining new modelling concepts for describingadditional aspects of agent systems (e.g. security).

The PIM4Agents defines a core metamodel that covers several important aspects to model MAS like.

The agent aspect allows to model the cooperation between agents, either as loose collaboration or asa form of organisation. It further defines the relationship between agents and roles they play in acooperation. Additionally, this metamodel defines to which resources (from its surroundingenvironment) and to which capabilities – a concept that groups behaviours – an agent has access to.The agent metamodel is depicted in Figure 44.

Figure 44: The partial agent aspect of the PIM4Agents. Cooperation represents the interaction between agents performing the required set of roles. Thedetailed realization of this interaction is described by a Protocol that indicates the messages to be

Public


expected from each of the roles at each point in time. The protocol aspect is discussed in theinteraction aspect in more detail. Organisation illustrates the social structure agents can take part in.The Organisation is a special kind of cooperation that also has the same characteristics of an agent.Therefore, the Organisation can perform roles and have capabilities which can be performed by itsmembers, be it agents or suborganisations. The multiple inheritance of the Organisation, from theagent and the cooperation, also allows it to have its own internal protocol that specifies how theOrganisation coordinates its members.

The behaviour aspect defines how an agent's process could be modelled. In general, the behaviour iscomposed by several plans that are connected via an information flow. A Plan is again composed bycontrol structures (e.g. split, parallel, loops, decision, etc.) that are again a specialization of a plan andatomic activities like sending or receiving a message. Additionally, atomic activities are a specializationof a plan. The process metamodel is depicted in Figure 45. A Flow distinguishes between ControlFlowand InformationFlow as specialization. The ControlFlow describes in which order plans, scopes andtasks are executed. The InformationFlow describes the order in which information flow between plans,scopes and tasks. Each Flow connects exactly two plans. The concepts Plan, Scopes and Task arespecializations of the Step concept. The atomic activities ReceiveMessage and SendMessage refer toMessages that are defined in the agent interaction protocol. Messages could be sent and receivedeither in a synchronous or asynchronous manner.

Figure 45: The partial behavioural aspect of the PIM4AgentsThe interaction aspect defines how messages are sent between roles from a centralized point of view.The order in which messages are sent between roles is specified by a message flow. A role is ideallyperformed by several agents, thus n to m relationships are supported. How a message flow isimplemented is specified by a plan, i.e. the plan handles incoming messages in an event-basedmanner and specifies which message are sent accordingly. Thus, the interaction aspect is stronglyconnected to the behaviour aspect. The interaction metamodel is depicted in Figure 46. A Protocolrefers to a set of roles (e.g. Initiator and Participant) that interact within the protocol. Furthermore, itrefers to a set of behaviours that are executed by the roles. In order to define the messagesequencing, the Protocol refers to a MessageFlow. A MessageFlow defines the sequence in whichmessages are sent within the protocol.

Other viewpoints of PIM4Agents are for instance the role, environment, and organisational aspects. Acomplete description of the syntax of the PIM4Agents is given in [7]

Public


Figure 46: The partial interaction aspect of the PIM4Agents

B.1.4 Agent UML versus PIM4AgentsBoth, Agent UML as well as the PIM4Agents are languages to model agent systems on an abstractlevel. Both provide means to model agent interactions using protocols which are an essentialcomponent to illustrate how agents cooperate in MAS. Furthermore, both languages provide a linkbetween interaction and the processes that are needed to interact (e.g. sending and receivingmessages) and thus combine an agent’s internal point of view with the centralized point of view that isdefined by the interaction protocols. However, the ability to transform models that conform to thePIM4Agents metamodel to executable code basing on Jack or Jade presents one of the maindifferences.

B.1.5 Relation to the UPMS-HA proposalIn the following, we will briefly relate the PIM4Agents to the proposed UPMS-HA proposal byillustrating the similarities between both metamodels and how the UPMS-HA core could be extendedwith agent-based concepts.

B.1.6 Similarities between the UPMS-HA core and the PIM4AgentsProcess aspects

The process aspect of the UPMS-HA nicely corresponds to the approach we are following in thePIM4Agents process metamodel. In fact, the process concepts of the UPMS-HA present a subset ofthe concepts used in the PIM4Agents. The remaining features of the PIM4Agents process aspects areused (i) to execute processes in a concurrent manner and (ii) to support an event-driven execution.

Service contract and agent-based cooperation/organisation

The information on a service contract which refers to behaviours and services could nicely betransformed to a cooperation of agents that perform a required role that provides the particular service.The behaviour could be transformed to the partners’ (those that participate in the service contract)behaviour.

Public


B.1.7 Feasible extensions on the UPMS-HA coreInteractions between service consumers and service providers defined from a centralizedpoint of view

Interaction protocols as they were defined in Agent UML and the PIM4Agents could be consideredto further extend the UPMS-HA core in order to describe service choreographies. The protocolshould refer to the behaviour that finally implements the interaction protocol. This may include (i)how and when messages are sent and received, (ii) whether these messages are exchangedsynchronously or asynchronously and (ii) how the workflow between receiving and sendingmessages is defined. Furthermore, the interaction metamodel should refer to the service channeland conform to the upcoming BPDM choreography and collaboration description.

Connecting service consumers with service providersIn order to compare an agent-based approach with other standards for service composition, thedistinction [8] between fixed, semi-fixed, and explorative composition is useful. Fixed compositioncan be modelled with the PIM4SOA, but also by applying the PIM4Agents. Semi-fixed compositionmight also be modelled with the PIM4Agents: the agents that perform the role of the serviceprovider are defined at design time, the binding (i.e. selecting the most adequate agent) is done atrun-time. In contrast, the current version of the UPMS-HA core does not support role bindingsduring run-time. Rather, they have to be defined at design-time. Explorative composition is beyondof what the UPMS-HA and the PIM4Agents approach offer (at least if they are used in a ’normal’way). To enable explorative composition, a general purpose planner [9] might be applied whichdynamically generates, based on the service descriptions stored in a registry, a plan which tries toachieve the objective specified by the consumer. A further important question is how theavailability of a partner service is detected. This might be checked only by actually calling theservice. If the service is not available or does not return the expected output, an exception will beraised. This could for instance be compensated if the metamodel supports that (i) several entitiesperform the same role at design time but (ii) the final binding between service provider and entitiesis done at run-time. In this case, is a service is not available, the next best service provider ischosen until one of the service providers provides the requested outputs.

Service event handling and generationThe PIM4Agents supports an event-based plan execution. In the case of an incoming message,all feasible plans that could in principle handle the incoming request are evaluated with respect totheir adequacy under the particular circumstances. The most adequate plan is then finally chosenin accordance to the agent's meta-level reasoning process. The PIM4Agents supports thisadaptive behaviour in a natural way, whereas the UPMS-HA process specification which attemptsto provide the same behaviour would require awkward coding such as nested fault handlers etc.Furthermore, events or messages (in the PIM4Agents case) are sent in plans that are againhandled by the recipient that then triggers the responsible plan(s). Furthermore, messages caneither be sent synchronously or asynchronously in plans. Since it is in many cases not possible tofully specify all necessary details on the PIM level, a system engineer must add these details onthe PSM level. Hence, customizing the composition is facilitated since the different plans clearlystructure the alternatives of possible actions. Since the control structure is implicit, changes in aplan do not have impact on the control structure, reducing the danger of errors in the code.Another advantage is that extending the behaviour by adding alternative plans for a specific taskcan be straightforward modelled with the PIM4Agents.

Composing services from other servicesThe structuring of organisations as it is done in the PIM4Agents could be a feasible input for theUPMS proposal. An organisation acts to the outside as an atomic agent, but it can be in fact againcomposed of several agents and/or organisations that provide a particular service that could becomposed inside the organisation to a more complex service. The number of levels needed tocompose this more complex service is not recognizable to the outside (e.g. service consumer).

B.1.8 Feasible extensions on the PIM4AgentsFigure 47 depicts feasible extensions for the PIM4Agents core in order to deal with services andservice descriptions. Therefore, we introduced the concept of Agent Service that is a specialization ofService from the UPMS-HA core.

Public


Figure 47: How to extend the core of the PIM4Agents to deal with SOA

B.1.9 References1. Singh, M., Huhns, M. (2005): Service Oriented Computing: Semantics, Processes, Agents. John Wiley &Sons, Chichster, West Sussex, UK (2005).

2. G. Benguria, X. Larrucea, B. Elvester, T. Neple, A. Beardsmore, and M. Friess. A platformindependent model for service oriented architectures. In Proceedings of I-ESA Conference, 2006

3 Hahn, C., Madrigal-Mora, C., Fischer, K., Elvesæter,, B., Berre, A.J., Zinnikus, I. (2006): Meta-models, Models, and Model Transformations: Towards Interoperable Agents. MATES 2006

4 Rao, A. S. and M. P. George. BDI-agents: from theory to practice. In V. Lesser, editor,Proceedings of the First Intl. Conference on Multiagent Systems, pages 312-319, San Francisco,1995. AAAI Press/The MIT Press.

5 Trencansky, I., Cervenka, R.: Agent modelling language (AML): A comprehensive approach tomodelling MAS. Informatica 29(4) (2005) 391-400

6 Hahn, C., Madrigal-Mora, C. und Fischer, K. (2007). Interoperability through a platform-independent model for agents, In: Proceedings of the 3rd International Conference on Interoperabilityfor Enterprise Applications and Software7 Hahn,C (2008): A Platform Independent Agent-based Modelling Language. Padgham, Parkes,Mueller and Parsons (eds.): Proceedings of AAMAS 2008, Estoril, May, 12-16., 2008, Portugal.

8 Yang, J., Heuvel, W., Papazoglou, M. (2002): Tackling the Challenges of Service Compositionin e-Marketplaces. 12th International Workshop on Research Issues on Data Engineering: EngineeringE-Commerce/E-Business Systems (RIDE-2EC 2002).

9 Sirin, E., Parsia, B., Wu, D., Hendler, J.A., Nau, D.S. (2004): HTN planning for Web Servicecomposition using SHOP2. J. Web Sem. 1 (2004) 377–396

Public


Appendix C: UPM for P2P, Grid and web servicesThis appendix provides a short description of the Generic Service Model (GeSMO), which wasdeveloped by the National & Kapodistrian University of Athens within the context of the SODIUMproject (IST-FP6-004559). The specification of GeSMO was driven by the need to conceptuallydescribe the commonalities and differences of Web, P2P, and Grid services. Thus, GeSMO has beenbased on the results of a thorough investigation of the state-of-the-art in Web, P2P, and Grid servicetechnologies, which was conducted during the SODIUM project. Moreover, GeSMO was used as abasis for the development of the SODIUM languages and middleware that address unified discoveryand composition of Web, P2P, and Grid services.

Specifically, GeSMO contributes to the UPMS-HA meta-model in the following ways:

The Description element that is provided by the Description view of GeSMO is ageneralization of the ServiceSpecification that is defined by the UPMS-HA meta-model.The Message Structure view of GeSMO provides a refinement of the Message element in theUPMS-HA meta-model.The GridService and P2PService elements defined by the GeSMO extensions layer aregeneralizations of the Service element of the UPMS-HA meta-model and exemplify how thelatter can seamlessly accommodate various types of services.

In general, GeSMO is characterised by the following properties:

Generality: The model is generic enough so as to support the modelling of all types ofservices and not just web, p2p and grid services.Abstraction: The model incorporates abstractions of all common concepts of the addressedtypes of services, which can be instantiated to the concepts supported by each specific type ofservice.Extensibility: The model can be easily extended with new features and properties, as well aswith new service types.Modularity: The model is constructed in a modular manner, thus allowing the easymodification or extension of specific information parts.Expressiveness: The model is expressive enough to accommodate several service activitiessuch as discovery and composition.Simplicity: The generic service model is simple enough to be easily used by a variety ofusers and tools which can be built on top of it.

CoreConcepts

Web Services

Grid Services P2P Services

Trust and Security

Management

Quality of ServiceSemantics

Figure 48. Layered architecture of the Generic Service ModelAs it is shown in Figure 48, GeSMO has adopted a layered architecture as follows:

The Core Layer which models all common concepts among the investigated service types, i.e.Web, P2P, and Grid servicesThe Extensions Layer which sits on top of the Core one and caters for the distinct features ofeach service type, i.e. Web, P2P, and Grid servicesA number of layers, orthogonal to the Core and Extensions layers, which model additionalcross-cutting features, such as semantics, quality-of-service, trust & security, andmanagement

Public


C.1.1 Core Layer of GeSMOThis section describes the core layer of the Generic Service Model (GeSMO). The fundamentalconcept of this layer which binds together all the other elements is the Service. The combination ofconcepts met in each of the aforementioned layers allows for modelling the Service concept frommultiple points of view.Figure 49 depicts the Service concept along with some of the views that wereused for its refinement.

Figure 49. The GeSMO conceptual views refine the concept of ServiceThe set of additional elements that stem from the multi-view evaluation of the Service concept can begrouped into sets of related elements which address a service aspect. The set of views that have beenused within this investigation are:

Abstract: This view looks into the service concept from an abstract point of view and tries toidentify its relationships with elements of the software engineering fieldBasic: This view pinpoints the minimal set of elements that need to be provided. Theelements that are identified within this view may be further analyzed in other sub-views.Description: This view focuses on the elements that are related to the service descriptionStructure: The structure view identifies the structural elements that a service may compriseSemantics & QoS: This view identifies the elements of the service model that may havesemantics and QoS annotationsMessage Structure: This view provides a look into the structure and the elements ofmessages that are exchanged among a service and its clientsCommunication: The communication view identifies the elements that are related to theunderlying network communication details i.e. communication protocols that are used, networkaddress, message wire format, etc.

In the following paragraphs, we briefly present each one of the GeSMO service views.

C.1.2 Abstract ViewThe Abstract View depicts a service and its related elements as they have been identified from anabstract point of view. Specifically, it tries to relate the service notion with a set of fundamentalconcepts that are pertinent in the description of a software system.

Public


Figure 50. Abstract View of Service

C.1.3 Basic ViewThe Basic View depicts a minimal set of concepts and their respective relationships that define theconcept of service. This set of constructs suffices for the invocation of a service, but they need to befurther annotated so as to facilitate the whole set of operations that are supported by the servicemodel i.e. publication, discovery, invocation, composition, etc.

Figure 51. Basic view of Service

C.1.4 Description ViewThe Description View provides a detailed specification of the information that a description documentmay convey. A description document may provide descriptions or links to other documents for thewhole or for parts of the information that is depicted in the following figure (Figure 52).

Public


Figure 52 Description view of Service

C.1.5 Structure ViewThe Structure View defines the set of structural elements that a service may be broken down into. Thestructural elements that have been identified are depicted in Figure 53:

Figure 53. Structure view of Service

C.1.6 Semantics & QoS ViewThe Semantics & QoS View specifies which of the structural elements of a service may have semanticor QoS annotations. The semantic annotations that are associated with a service or its constituentelements may be described in one or more description documents. Within our model, the set ofcomponents that may have semantic or QoS attributes attached are depicted in the following figure(Figure 54):

Public


Figure 54. Semantics & QoS view of Service

C.1.7 Communication ViewThe Communication View describes the elements and their respective associations that are used inthe description of the communication channels among a service and its clients. The following figureillustrates the elements that are going to be used within our model.

Figure 55. Communication view of Service

C.1.8 Message Structure ViewThe Message Structure View specifies the components of messages along with their associations.The figure below illustrates the integral components of a message that is exchanged among a serviceand its respective clients.

Public


Figure 56. Message Structure view of Service

C.1.9 Extensions Layer of GeSMOThis section provides a description of the Extensions Layer that has been built upon the Core Layer ofGeSMO. Specifically, this layer uses the concepts of the Core Layer as a basis and providesappropriate extensions for the concepts that are missing, for each one of the addressed service types(i.e. Web, P2P, and Grid services).

The concepts of the Extensions Layer have been grouped into three modules that are addressing theWeb, Grid and P2P service types respectively. In the following we present the elements that havebeen introduced for the aforementioned service types.

C.1.10 Web Service TypeThe set of protocols that is commonly used as a basis for the specification of Web Services consists ofWSDL, SOAP and UDDI. Thus the elements that are provided abide by these standards.

The description of the missing concepts for the web service type is a straightforward process. This isbecause most of the needed elements have been already described in the Core Layer. Therefore,through some simple extensions that are depicted below, we are able to provide the missing concepts.

Figure 57. The Web service type

C.1.11 Grid Service TypeThe Grid Service type that has been defined by the extensions layer of GeSMO is primarily influencedby the WS-RF specifications. Figure 58 depicts the relationship between WS-Resource, Resource,WebService and WSDL.

Public


Figure 58. The Grid service typeA WS-Resource is a stateful resource loosely coupled with a web service which defines standardizedways to access the resource. The scope of what a resource can be is broad. It can be any hardware orsoftware entity which has a state and whose state is also accessible by means of software. Aninstance of WS-Resource is defined as a web service as well as an identifier for a specific view on theresource. A client, which instantiates a WS-Resource gets back an identifier defining its view on theresource. It is however a misconception that the resource gets instantiated as this may not be alwaystrue.

A Resource has properties which are described / defined within the WSDL document throughResource Properties Definitions. In case the resource is a hard disk, a property may for instance bethe number of sectors whereas in case the resource is an implementation of a counter, the currentvalue may be a property. These Resource Properties are mapped to the actual Properties of theResource. The web service provides the necessary operations to access/modify the properties. It issolely up to the web service to implement how the resource properties are accessed. At no time theproperties of the resource are directly modified by a client.

The web service must also provide other standardized/defined operations for resource management,lifecycle management and notifications. These operations are defined in the WS-Notification, WS-ResourceProperties, WS-ResourceLifetime, WS-Addressing standards.

C.1.12 P2P Service TypeThe most prominent platform that explicitly defines and provides P2P services is JXTA. Therefore, theproposed P2P service type is based on concepts defined by this specific technology. Yet, theestablished elements and their respective associations may easily satisfy the needs of other types ofp2p platforms and/or architectures as well.

Public


The incorporation of the JXTA model though isn’t a straightforward process. Due to its lenientapproach and the freedom that a developer is provided with many of the specified concepts andcomponents can be easily bypassed. Such an example is the communication mechanisms that maybe used for the interaction among two endpoints. Although JXTA describes a communicationmechanism based on the use of the Pipe element, it doesn’t strictly enforce its use. Rather than that,developers are able to use any kind of communication mechanism and infrastructure they like. Thisopen approach and the freedom that JXTA provides to its users render the specification of a servicemodel and the provision of supporting tools a complicated task. Therefore, as far as GeSMO isconcerned, we use the invocation approach which is based on pipes for the exchange of messagesamong services and their consumers. This decision nonetheless, doesn’t hinder the applicability orthe extensibility of the P2P service type. Extensions may be provided so as to accommodateadditional communication mechanisms or schemes.

Figure 59. The P2P service typeA PSDL document provides a description on what a P2P service does and how it can be invoked. APSDL document is a specialized description that extends the existing P2P service advertisements.The PSDL descriptions do not aim to replace the existing service descriptions, but rather to enhancethem with concepts of the Core Layer of GeSMO, which are currently missing. For instance, theservice model that is supported by the JXTA framework suppresses concepts such as the serviceinterface or operation. These concepts however are crucial concepts that are supported by all othertypes of services. Furthermore, PSDL descriptions aim to support the development of enhanced andmore automated service binding and invocation tools.

Public


Appendix D: UPM for Event ModellingTo model Event-Driven Architectures (EDA) some concepts are required that are discussed in thefollowing in more detail. We distinguish between two disciplines: Event-based business models andevent-based agent models. The material presented in this section bases on [1] and [2]

D.1.1 Event-based Business ModelsAn event-driven system is a system in which actions result from business events. Whenever abusiness event happens anywhere in the enterprise, some person or thing, somewhere, may react to itby taking some action.

Business rules determine what event leads to what action. Usually the action is a business activity thatchanges the state of one or more business entities. Any state change to a business entity mayconstitute a new business event, to which, in turn, some other person or thing, somewhere else, mayreact by taking some action. The purpose of the Event Model is to define the use of the concepts inthe CCA, Entity and Event models, and to extend them in order to support the design of event-drivenbusiness systems.

The main concepts in event driven business models are the business entity, business event, businessprocess, business activity, and business rule. So the basic building blocks are the business processand the business entity. The two are ‘wired together’ by a flow of actions from process to entity, and bya flow of events from entity to process. In a component framework, therefore, business processeshave event inflow and action outflow, and entities have action inflow and event outflow. This meansthat CCA business process components and CCA business entity components can be created bymodelling:

A business process as a set of rules of the type notification/condition/activity (This is theevent-driven equivalent of the commonly known event/condition/action rule).A business entity as set of operation/state/event causalities.

The connection from business process to business entity is a configurable mapping of activity tooperation. The connection from business entity to business process is a configurable set ofsubscriptions.

With these building blocks it is possible to model a number of event-based interactions. Furthermore,by reconfiguring the activity to operation mapping and/or the subscriptions, it is possible to re-engineerthe business process and its execution in the system. However, neither the business world, nor thecomputing world applies only one paradigm to their problem space. Businesses use a combination ofloosely coupled and tightly coupled processes and computing solutions deploy a combination ofloosely coupled and tightly coupled styles of communication and interaction between distributedcomponents. Consequently, while the Events model is defined to support the event-driven flavour ofloosely coupled business and systems models, it allows such models to co-habit with more tightlycoupled models.

Event driven computing is becoming the preferred distributed computing paradigm in many enterprisesand in many collaborations between enterprises. Event driven computing combines two kinds ofloosely coupled architectures. The first one is loosely coupled, distributed components thatcommunicate with each other through asynchronous messaging.

The other one is loosely coupled business process execution. Here enterprises collaborate under anoverall long term contract, but do not execute their day to day interaction in traditional workflow, orrequest/response style interaction.

In event driven computing the most important aspect of a process is the events that happen during itsexecution, and the most important part of the component-to-component communication is thenotification of such events from the party that made them happen to all the parties that need to react tothem.

The event model defines the integration of systems and components using events to drive theprocessing. Events may be published or received by entities and processes. Events may be forwardedsynchronously or asynchronously. Synchronous events typically will be delivered within the context ofthe current transaction. Asynchronous events generally will be stored and delivered in the context of a

Public


new transaction. The use of events for integration reduces coupling and improves the ease by which asystem may be adapted or extended.

The entities model recognizes the publish and subscribe ports as elements that may be attached toentity components. In addition, it defines the Data Probe port to generate events requested on an adhoc basis. Event driven computing is a computing paradigm where interaction among components isbased on notification of what happened, as opposed to instructions of what should happen.

The “what happened” is reflected as events. The communication that the event happened is reflectedas notifications. The reaction to the notification (or indirectly to the event) is reflected as activities. Twoimportant layers provide loose coupling between event, notification, and activity. The events aredecoupled from the act of notification by configurable subscriptions. The act of notification isdecoupled from the activity by configurable notification rules. Event driven computing is a very flexible,yet powerful architecture for enterprise distributed object computing. The main architectural principle isthat individual components are kept as autonomous as possible, and that the loose coupling andconfigurability enable rapid reconfiguration of the system to meet changing business modelrequirements such as mergers, outsourcing, and business re-engineering. Under event drivenenterprise computing all business entities are self-contained, and typically do not directly change eachother’s state.

Event driven business computing executes business processes by capturing events that happen in theenterprise, notifying the appropriate other parties in the enterprise or outside the enterprise, andreacting to such notifications. Business processes are configured with a set of subscriptions, and a setof notification rules that determine what activity to start (or end) based on each notification. BusinessEntities are the people, products, and other business resources and artefacts that business activitiesoperate on. When actions are performed on Business Entities, Business Events happen. All BusinessEntities are capable of notifying the world of events that happen to them. Business Processes that arecapable of subscribing to such event notifications are called EventBasedProcesses. They assignnotifications to activities based on a set of Notification Rules. The complete event metamodel isdepicted in Figure 60.

In a Publish and Subscribe information distribution model, publishers publish information, andsubscribers subscribe to information. Publishing simply means make the information openly availablefor consumption. Subscribing simply means expressing an interest in the information and consuming itwhen it gets delivered. The information is transferred from Publisher to Subscriber ‘automatically,’usually through the use of asynchronous message middleware. Publishers do not know whichsubscribers will receive their data, and subscribers do not know where the information comes from.The information, however, describes the state of a process or an entity that is of interest to bothpublisher and subscriber, and both parties share the information model that describes these states(and state changes).

The concept EventBasedProcesses is an identifiable series of activities that change states of businessentities, thereby causing business events. For example, the activities in the Shipping process maycause allocation events against the Inventory Entity, and pick, pack, and ship events against theShipment Entity.

Business Entities are representations of entities of significance to the business, identifiable by an ID,operated on during business process execution, and characterized by having a lifecycle expressed asa set of entity states. Examples are Customer,

Purchase Order, Product, and Payment. In the Events model, we use the supertype of Entity,DataManager as the managers of the data behind an Entity. An EventBasedDataManager is capableof publishing information about all changes to the data it manages. Because anEventBasedDataManager is a kind of EventBasedProcess, it can also publish information about statechanges in its internal process.

BusinessEvents are state changes whose occurrence is of significance to the execution of businessprocesses. Typically business events reflect state changes in Business Entities. These can be thoughtof as entity events. Examples are the approval of a Purchase Order, or Receipt of a Payment. A moreindirect type of business event is a state change to a business process or to a collaboration betweentwo business processes. These are called ProcessEvents.

Public


A notification is a triggered dataflow between two roles, or between two components. The trigger thatcauses the notification can be ‘manual,’ or timed, or it can be due to the fact that an event hashappened. When triggered by an event, it is called an event notification. Event notification, too, is justa concept, and not modelled explicitly. The notification is always one-way only. The source of thenotification is usually an Entity, but can also be an EventBasedProcess. The destination is usually anEventBasedProcess. A notification can be thought of as the delivery of a set of data from a publisherto a subscriber. The data delivered is a PubSubNotice. A PubSubNotice is just a set of data, it isimmutable, and it does not have any behaviour of its own. There is no implication in the PubSubNoticeas to what the recipient is going to do when it receives the PubSubNotice.An EventNotice is a specialkind of PubSubNotice. All business events are associated with an EventNotice and the correspondingnotification will take place whenever the business event happens successfully. Similarly, when abusiness event is supposed to have happened but didn’t, ‘failure’ notifications will take place. AnEventNotice always conveys the following information:

EventBasedProcess or entity the event happened against, trigger that caused it, identification of thebefore state, after state, change between the two states.

A publisher is a component that provides PubSubNotices. A subscriber is a role or component thatholds subscriptions to one or more PubSubNotices.

A subscription establishes a flow of PubSubNotices to the subscriber. A subscription identifies the typeof EventNotice (e.g., the kind of event you want to be notified about). A subscription may additionallyhave a SubscriptionClause associated. The SubscriptionClause functions as a filter much like awhere-clause on the content of the notification.

NotificationRules are rules that govern the execution of (part of) an EventBasedProcess. ANotificationRule is a mapping from a BusinessNotification to an activity, optionally guarded by anEventCondition. An EventCondition is a dependency on the receipt of additional, relatedPubSubNotices.

Figure 60: Complete Metamodel for Event-based Business Models

Public


D.1.2 Event-based Agent ModelsThe term event is also very common in agent-oriented modelling. A very good example is the agentplatform JACK Intelligent Agents that provides programming constructs and concepts for developingcomplex agent-oriented applications. It bases on the Beliefs, Desires and Intentions model andprevious practical implementations of such systems. The BDI agent model is an event-drivenexecution model providing both reactive and proactive behaviour. In this model, an agent has certainbeliefs about the environment, desires to achieve, and plans describing how to achieve certainactivated goals. The BDI architecture is recognized as one of more successfully implementedarchitecture for developing complex systems in dynamic and error-prone environments. If an agent isinstantiated, it will wait until it is given a goal to achieve or experiences an event that it must respondto. When such a goal or event arises, it determines what course of action it will take. An event presetsthe type of stimuli a team, role, or team plan reacts to or posts. Jack distinguishes between (i) internalstimuli that are events the agent/team sends to itself, (ii) external stimuli that are messages from otheragents, and (iii) motivations such as goals the agent/team may have. The plan models proceduraldescriptions of what an agent does to handle a given event. All the actions that an agent takes isprescribed and described by the agent's plans. The metamodel of Jack (JackMM) is depicted in Figure61.

Figure 61: The partial metamodel for Jack.

D.1.3 References1. Enterprise Collaboration Architecture (ECA) Specification. Available at:http://www.omg.org/docs/formal/04-02-01.pdf

2. Hahn, C, Madrigal-Mora, C., Fischer, K., Elvesaeter, B., Berre, A.-J. and I. Zinnikus. (2006):Meta-models, models, and model transformations: Towards interoperable agents. In Fischer, K; Timm,J.; André, M. and Zhong, N.: Proceedings of the 4th German Conference on Multiagent SystemTechnologies (MATES 2006). Lecture Notes in Computer Science 4196.

http://www.omg.org/docs/formal/04-02-01.pdf

Public


Appendix E: A Service Modelling Language for MIDinnovatorAOX

This annex describes a service profile that has been created as a collaboration by the MID GmbH,Nuremberg, Germany and the Programming distributed Systems lab of the University of Augsburg,Germany in a local project. It focuses the modelling of services and enables the generation ofBPEL4WS 1.1 [1] as well as WSDL [2] code. The transformation rules between this profile have beenspecified using the openArchitectureWare language XP [3] and both, the profile and the transformationrules, have been implemented into the UML CASE tool MID Innovator AOX eXcellence 2007.

E.1.1 Description of the profile’s elementsThis section describes the elements used in the UML-Profile as concepts part of a language forservice modelling.

E.1.2 Services & CollaborationsA service constitutes the ability to fulfill requirements of persons and companies so that they can reachtheir goals. Collaborations are behaviour patterns between roles of services. Collaborations define theinvolved roles and their tasks in a collaboration. The order of collaborations can be detailed withprotocol descriptions.

Figure 62: Metamodel – collaborationsServices are collaborations between exactly two roles: the service provider and the service requester(binary collaboration). They are realized as ServiceCollaborations (see Figure 62). Roles define howpartners participate in and contribute to collaborations. Partner can offer services in the role of aservice provider or request services as a service requestor. A collaboration references theparticipating roles. ServiceChannels define between which roles messages are exchanged in thecollaboration.

Services can be defined through the combination of other services. Elementary, not composedcollaborations (in most cases these are binary collaborations) are the fundamental parts of composedcollaborations. Composed collaborations can be specified through CollaborationUse. A composedcollaboration refers with CollaborationUse to the behavioural patterns, which are used to compose thecollaboration. Thus, complex services can be composed from elementary services. The mapping fromroles (+role) of elementary collaborations to the roles (+boundRole) of composed collaborations isdefined by a RoleBinding.

Public


E.1.3 Service provider & implementation

Figure 63: Metamodel – service providerA ServiceProvider is an entity that offers services and defines conditions for the usage of theseservices. A service provider contains Roles (Role), with whom it can participate in collaborations. Forinstance, it can offer and request services in collaborations through these roles.

Some ServiceProviders include a behavioural description (Behaviour). This describes the activitiesthat need to be executed in order to realize the functionality offered by the service provider.

A ServiceProvider is an abstract description of a service provider, which defines its structure andvisible behaviour. ServiceProviderImplementations are concrete service components that contain anexecutable behaviour description. A service provider is a generalization of aServiceProviderImplementation, because one service could be realized using differentimplementations.

We distinguish between three kinds of behaviour descriptions:

Collaborative process: Defines the interaction protocol of a collaboration from the view of anexternal observer.Abstract process: Describes the public behaviour of a service component, i.e. the expectedbehaviour in a collaboration and not its implementation (ServiceProvider).Executable process: Describes the concrete realization of the behaviour of a processcomponent (ServiceProviderImplementation)

E.1.4 Data types, operations, messages and interfacesA service requestor can use the services of a service provider throughout its interfaces. To ensure acorrect invocation the possible operations of the interface, the exchanged messages and used datatypes need to be exactly specified.

Figure 64: Metamodel – message exchangeIn the UML-Profile an interface (Interface) can provide one or more operations (Operation). Anoperation is an abstract description of an action that is supported by service provider that implements

Public


the interface. Operations refer to Messages, which can be exchanged between several actions thatare described in the operation. An operation can send and receive zero or one message and sendvarious fault messages. The type of an operation (OperationType) defines in which order themessages are send or received.

A message is an abstract description of exchanged data and contains of one or more logical parts.Each message part has a type. Messages are bound to concrete message structures using a so calledMessageBinding. A message specifies and arranges the parameter of a service.

A message contains one or more documents (Document) whereas each document can contain otherdocuments using its attributes (Attributes).

Besides documents our meta-model also distinguishes another sort of information: the Entities. Anentity (Entity) is a container for a set of business data. It has an identity, a behaviour and an own stateand is often seen as an own expression from an economic point of view.

A document is a view of an entity. Documents can be used to exchange parameters between differentprocesses. Documents have no identity in contrast to entities; they don’t have identity, behaviour ortheir own state. For different states of an entity one should create different documents which can bedistinguished by the attributes that they provide for a concrete state of the entity.

With the differentiation of entities and documents the UML-Profile follows the idea of a step-to-steprefinement of models during the development process. Entities are mainly part of the business viewand can be refined with documents in the technical view. The technical view is then amended withdocuments which are snapshots of entities in a specific state. Documents always point to the entitiesthat they represent.

E.1.5 Ports & BindingsAs described above a ServiceProvider is an abstract description that defines the structure and visiblebehaviour of a service provider. A ServiceProviderImplementation is a concrete service componentthat implements the abstract services and offers them to the outside world.

Figure 65: Metamodel – service provider realizationA service provider has roles (Role) with which it participates in collaborations. A role has exactly onemandatory interface that it provides (+provided) and one optionally interface that it requires(+required).

A service provider implementation realizes the roles of a service provider via ports (Port). The attributeendpointAddress defines the concrete address of a port where the service component offers theservice. A service provider implementation has to realize each role of the implementedServiceProvider with at least one port. It is also possible to realize the same role with multiple portsand therefore offer services at different endpoints. For the different ports different bindings(WSDLBinding) might be used.

A binding (WSDLBinding) defines the message format and protocol details for the operation andmessages. A binding for an interface consists of OperationBindings for the offered operations. An

Public


OperationBinding in turn has several MessageBindings for the messages that are exchanged usingthis operation. The roles participating in a collaboration need to use the same message format toexchange messages. Therefore, WSDLBinding points to ServiceCollaboration. A binding defines themessage formats for the operations, which are realized by ports that reference the binding.

A WSDLBinding references the interface for which it defines the message format and anOperationBinding references the operation for which it defines the message format. AMessageBinding can define the message format for the whole message (+messsage) or only for partsof a message (+part).

Figure 66: Metamodel – bindingWSDLBinding, OperationBinding and MessageBinding are abstract concepts for different kinds ofbindings that can be extended. In this document we describe the SOAP-Binding as one example forthe binding.

A SOAPBinding is subclass of a WSDLBinding. The attribute style defines the type of operationswhich can be ‘rpc’ for remote procedure calls or ‘document’ for message-oriented communications.The attribute transport configures the transport protocol that shall be used. This might be http, smtp,ftp, etc. and is referenced with a URI (e.g. http://schemas.xmlsoap.org/soap/http).

A SOAPOperationBinding inherits from OperationBinding. Similar to the SOAPBinding the style can be‘rpc’ or ‘document’. The attribute soapAction defines the value for a SoapAction-Header of thisoperation and should only be used for http.

SOAPBody and SOAPHeader are MessageBindings and arrange where the messages and messageparts are in the SOAP header and body.

Figure 67: Metamodel – SOAP-binding

http://schemas.xmlsoap.org/soap/http).

Public


E.1.6 Behaviour

Figure 68: Metamodel – behaviour basicsThe Behaviour of a ServiceProvider is described with a ProcessFlow. A ProcessFlow contains thecomplete flow of a process and describes all actions and their sequence. A ProcessFlow containsNodes and their Connections. A Node is an abstract concept, which serves as a placeholder for moreconcrete concepts in a process flow description like specific actions. A Node can have severaloutgoing and incoming edges (Connection) whereas one edge always connects two nodes. Nodesand edges can be grouped in Swimlanes. These groups structure parts of the process flow that belongtogether and in which it is communicated with the same partner. This is described though adependency between Swimlane and Role whereas each Swimlane points to the role of thecorresponding partner (+partnerRole).

Figure 69: Metamodel – dependency between Swimlane and Role

Figure 70: Metamodel – kinds of ProcessFlowTwo specializations of a process flow exist: an ExceptionFlow describes a process that is executedwhen an exception occurs. Therefore, several areas can be defined (so-called Catch-Blocks) that areconcerned with the treatment of different exceptions. The name of the Catch-block is identical to thename of the exception that should be handled. A CompensationFlow on the other hand is a processflow that is executed when a process needs an undo and is called by a CompensateAction (seebelow).

Public


Figure 71: Metamodel – structured NodesA special kind of node is the StructuredNode. It groups other nodes and exists in three forms: Whiledescribes an area that is executed several times as long as the condition of the while-block holds.Catch describes the compartments in an ExceptionFlow that are responsible for exception handling. AScope depicts a set of actions that belong together in a process flow, i.e. they use the same variables,have the same event handlers, etc. StructuredNodes can be nested and can contain any other nodes(+containedNode).

Figure 72: Metamodel – control nodesFigure 72 depicts the nodes that are used to control the control flow. These control nodes specify thebeginning of a process (InitialNode) or its end (FlowFinalNode which ends the current thread orProcessFinalNode for termination of the whole process). Parallel flows can be created using aForkNode and synchronized again (JoinNode). Alternative flows can be modelled usingDecisionNodes and their combination via MergeNodes.

Figure 73: Metamodel – input and output of actionsThe most important specialization of nodes are actions (Action). An action is an abstract class thatdefines common properties and behaviour for its subclasses and represents exactly one executedstep in the process. Each action might need input values (Input) for their invocation or return outputvalues (Output).

Public


Figure 74: Metamodel – concrete actionsThere are several kinds of an action: Using Assign one can copy variables and messages but alsospecify programming instructions. With Invoke, Reply and Receive the communication with otherservices is possible. Invoke calls another operation that has been defined using the Interface of theServiceProvider. Reply sends the answer to an invocation that happened before. With Receive onecan wait for the invocation through another service provider. With the usage of Throw andFaultHandler the handling of exceptions is possible. An exception is raised calling the Throw action(the name of the Throw-action is the name of the exception). The FaultHandler defines a work list (aprogram) for all kind of exceptions either in the whole process flow or in the current scope. AFaultHandler calls therefore a predefined ExceptionFlow-behaviour that is responsible for theexception handling (the Compensate and CompensateHandler mechanism works similarly). The Wait-action enables the delay of a specified time, before the execution of the process is continued. Thedetails of time are specified in a trigger of a timer event.

Figure 75: Metamodel – variablesThe whole process flow as well as each Scope can contain any number of variables. Variables arebound to their scope and can only be used by actions in the same scope.

These variables have a type (either a primitive type like String or Integer or complex message types)and are referenced by the input and output of an action. Each input and output has a dependency to avariable that either contains the invocation parameter or the result after its execution.

E.1.7 Defining the UML-ProfileSOA UML-Profile:

Stereotype UML Element Description

«ServiceCollaboration» Collaboration ServiceCollaboration is a collaboration whereservices are offered. An atomic collaboration hasexactly two roles, whereby composite collaborationscan include more than two roles.

«CollaborationUse» CollaborationUse like in UML

«ServiceChannel» Connector A ServiceChannel describes the channels for thecommunication in a ServiceCollaboration.

Public


«RoleBinding» Dependency A RoleBinding is similar to a dependency in UMLthat is used as a role binding.

«Role» Port A Role is an abstract description of an interactionendpoint which can be used from ServiceProvidersto collaborate in ServiceCollaborations.

«ServiceProvider» Component A ServiceProvider is an abstract description of aninstitution/organisation/etc. that offers a service andthat defines the structure and visible behaviour ofthis provider.

«ServiceProviderImplementation»

Component A concrete ServiceProviderImplementationimplements an abstract ServiceProvider andcontains an executable behaviour description.

«Interface» Interface An interface describes (similar to UML) the visiblebehaviour resp. endpoints of a role

«Operation» Operation like in UML

«Message» Class A Message is an abstract description of data that areexchanged between services.

«Document» Class A view of an entity. In contrast to entities havedocuments no identity, no behaviour or own state.

«Entity» Class An Entity is a container for a set of business data.This includes an identity, behaviour and an ownstate.

«Attribute» Property Documents and Entities can include otherdocuments and entities with the help of attributes.

«Port» Port A port describes a concrete interaction endpoint thatprovides a service to other service components.

«WSDLBinding» Class WSDLBinding defines the message format and theprotocol details for operations and messages.

«OperationBinding» Class Defines the message format and protocol details foroperations and is part of a WSDLBinding.

«MessageBinding» Class Defines the message format and protocol details forthe message and is part of an OperationBinding.

«SOAPBinding» Class Subclass of WSDLBinding. Defines a binding forSOAP.

«SOAPOperationBinding»

Class Subclass of OperationBinding and defines a bindingfor SOAP operations.

«SOAPHeader» Class Subclass of MessageBinding. Defines a binding forthe message part SOAP header.

«SOAPBody» Class Subclass of MessageBinding. Defines a binding forthe message part SOAP body.

«Behaviour» Behaviour like in UML

«ProcessFlow» Activity Describes the behaviour or a ServiceProvider andspecifies in which order the actions are executed. Aprocess flow contains all nodes and connections.

«CompensationFlow» Activity A CompensationFlow describes a special behaviourwhich is executed when the compensation of anactivity is necessary due to abortion of its execution.

Public


Therefore, it might be necessary to use variables ofthe compensating scope. This is possible due todependencies of the input and output to variables(«VariableUse»).

«ExceptionFlow» Activity An ExceptionFlow describes the behaviour which isexecuted when an error occurred.

«Node» ActivityNode Each element of the process flow which is either anexecutable node or a control node.

«Connection» ActivityEdge Connects different nodes in the process flow.

«Action» Action like in UML

«StructuredNode» StructuredActivityNode

A StructuredNode includes a set of nodes andconnections and offers the possibility to model ownvariables, an exception or compensation handling forthis set.

«Swimlane» ActivityPartition A swimlane describes a group of elements that areall executed by the same role. An ActivityPartition isrepresented in UML normally with a swimlane, that’swhy this name has been used here.

«Input» InputPin Input describes the data that an action needs for itsexecution.

«Output» OutputPin Output describes the data that are returned after theexecution of an action.

«InitialNode» InitialNode like in UML

«ProcessFinalNode» ActivityFinalNode A ProcessFinalNode describes the end of a processand is similar to an ActivityFinalNode in UML.

«FlowFinalNode» FlowFinalNode like in UML

«ForkNode» ForkNode like in UML

«JoinNode» JoinNode like in UML

«DecisionNode» DecisionNode like in UML

«MergeNode» MergeNode like in UML

«Invoke» CallOperationAction Invoke starts a collaboration with another serviceprovider and sends the specified input values.

«Reply» CallOperationAction Reply answers to an invocation that has happenedbefore.

«Receive» AcceptCallAction Receive waits for the invocation through aServiceProvider (defined as a Trigger) and stores theparameters of this invocation in the output data.

«Assign» OpaqueAction Copies values from one element to another. Thesevalues can be part of a message or simply variables.

«Throw» OpaqueAction Throw creates an exception and finishes the currentprocess flow.

«Compensate» OpaqueAction Starts the modelled compensation flow in order toundo the last activities.

«FaultHandler» CallBehaviourAction Calls an ExceptionFlow as behaviour in order to reactto an error that has been thrown before. AFaultHandler is bound to a Scope similar to an UML2

Public


ExceptionHandler.

«CompensationHandler» CallBehaviourAction Calls a Compensation Flow if the compensation ofprevious actions is necessary (the Compensate-Action has been invoked). A CompensationHandler isbound to a Scope similar to an UML 2ExceptionHandler.

«Wait» AcceptEventAction Waits for a certain time or until a certain time whichhas been defined with a TimerEvent.

«While» StructuredActivityNode

A while-group describes a set of nodes that arelooped until a condition (in the name of the while-block) is not guilty anymore.

«Catch» StructuredActivityNode

A Catch-block describes a set of actions that areexecuted when an error occured which is identical tothe name of the catch-block. A catch-block is onlyallowed in an ExceptionFlow.

«Scope» StructuredActivityNode

Each ProcessFlow can be structured through scopesthat can be nested. Each scope can contain a sum orvariables (only valid inside the scope), an ownExceptionHandler and CompensationHandler whichthemselves can invoke an ExceptionFlow resp.CompensationFlow.

«Variable» Variable like in UML

E.1.8 The UML-Profile visualized as a metamodelIn this section we show the complete meta-model in two figures, so it is easier to get an overviewabout the concepts and their relationships.

Public


Public


E.1.9 Example: Modelling with the SOA UML-ProfileThis section provides an overview over the connections between the profile’s elements and thediagrams implemented in Innovator AOX eXcellence 2007 [4]. We explain the modelling with thehelp of an example.

The example describes bank transfers. A banking customer wishes to transfer money. Therefore firsthe logs in at his online banking account. Then he enters the relevant data for the transfer (amount ofmoney, etc.). The transfer service checks the data and prepares the data for the transfer execution.The customer has to confirm the data with a TAN before the transfer transaction is executed by thebanking server.

The process describes a collaboration between different persons and organisations: the bankingcustomer, the transfer manager, and a banking server. To be able to exchange messages, we firsthave to model message types, documents and interfaces.

E.1.10 Documents, messages and interfacesThe exchanged document are derived from the entity classes modelled during the analysis phase andare further refined with attributes. For the bank account entity for example three documents areconstructed with partially different properties. The property overdraft_limit is not relevant for theAccountLogindata document.

Public


Figure 76: Example diagram for data typesOn the basis of these data types messages can be modelled. For each message has to be definedwhich documents are to be exchanged. The login request message (LoginReq) contains documentsabout the account and customer login data.

Public


Figure 77: Example diagram for messagesThe interfaces are modelled after the messages have been specified. Interface specification containsall necessary operations as well as messages that are exchanged in the case of operation invocations.

Figure 78: Example diagram for interfaces

Public


E.1.11 ServiceProvider and ServiceCollaborationNow the collaborating service providers and roles can be modelled. Figure 79 depicts the serviceproviders and the roles they take up in the collaboration. For example, the TransferManager takes upthe Role TansferService, via which it provides the transfer service.

Figure 79: Example diagram for the description of service provider and their rolesAfter the service providers and the roles have been modelled, one can introduce the servicecollaborations. Service collaborations are modelled as connections between roles. ASeriveCollaboration represents the collaboration between two or more service providers.

Figure 80: Example diagrams for service collaboration

E.1.12 Process flowFor each service provider and service provider implementation it is possible to specify behaviour witha process flow. Figure 81 depicts the transfer process of our example. Swimlanes represent the rolesthe partners take up (TransferRequestor, TransferTransactionService) in the collaboration and the role

Public


via the ‘process’ offer the service (TransferService). The process is described through a sequence ofactions. Scopes (Execute_transaction) can group actions and define their own variables (Confirmation,etc.). Furthermore ExceptionHandlers and CompensationHandlers, which reference ExceptionFlowand CompensationFlow descriptions, can be added to scopes.

Public


Figure 81: Example diagram for process flow

Public


Figure 82: Example diagram for ExceptionFlow and CompensationFlow

Public


E.1.13 Service provider implementationFor each abstract service provider multiple implementations can exist. AServiceProviderImplementation has to realize each role the ServiceProvider offers with at least onePort. In Figure 83 we can find an OnlineBank_Bank1 which implements the TransferManager serviceprovider.

Figure 83: Example diagram for service provider implementation

Public


E.1.14 BindingFinally, the binding of the ports of the respective service provider implementations to the servicecollaborations and interfaces has to be conducted.

Figure 84: Example diagram for SOAP-Binding

Public


Figure 85: Example diagram for binding of ports to a service collaboration

E.1.15 References1 OASIS: „Business Process Execution Language for Web Services, Version 1.1” (2003), onlineverfügbar unter http://www-128.ibm.com/developerworks/library/specification/ws-bpel/

2 W3C: “Web Service Description Language (WSDL) 1.1” (2001), online verfügbar unterhttp://www.w3.org/TR/2001/NOTE-wsdl-20010315

3 openArchitectureWare: „XPand Language Reference“ (2006),http://www.eclipse.org/gmt/oaw/doc/r20_xPandReference.pdf

4 MID Enterprise Software Solutions GmbH: innovatorAOX 2006. http://www.mid.de

http://www-128.ibm.com/developerworks/library/specification/ws-bpel/

http://www.w3.org/TR/2001/NOTE-wsdl-20010315

http://www.eclipse.org/gmt/oaw/doc/r20_xPandReference.pdf

http://www.mid.de/

Public


Appendix F: Collaborative services through SemanticInterfaces

This appendix provides a short description of the work on Semantic Interfaces, - which is beingdeveloped by SINTEF within the context of the SIMS project (IST-FP6-004559), Semantic Interfacefor Mobile Services9 .

One of the core challenges of service engineering is to find practical ways to model services andservice features (partial functionalities) independently of each other, such that services may becomposed into well functioning application systems satisfying requirements. Service composition ingeneral involves static composition at design time as well as dynamic linking and binding at runtime.The new UML 2 collaboration concept [1] provides a structured way to define partial functionalities interms of collaborating roles and therefore it provides a promising basis for service modelling. It allowsservice parts to be modelled as collaboration roles, and service behaviour to be specified usinginteractions, activity diagrams and state machines as explained in [2-5]. Moreover it provides means todecompose/compose services using collaboration uses and to bind roles to classifiers defining systemcomponents. In this way, UML 2 collaborations directly support service modelling and servicecomposition at design time. In addition they provide a framework to define so-called semanticinterfaces as explained in [6] that can be utilized to ensure compatibility among interactingcomponents both at design time and runtime. Collaborations enable services to be precisely specified,composed, simulated and analyzed for errors so that correctness can be ensured at a very earlystage.

Another challenge is to define services architectures and service delivery platforms suitable for theapplication domain in question and able to support incremental deployment and dynamic discoveryand composition. The Service Oriented Architecture paradigm (SOA) is increasingly gainingacceptance influencing the way people understand and define services. However, one should beaware of the fundamental limitation of SOA as it is currently understood. In SOA, services are providedby a service provider to a service consumer. This service provider is normally a “passive object” in thesense that it never takes any initiatives towards a service user. It merely awaits requests and respondsto them.

Collaborative services on the other hand are performed by objects that may take initiatives towards theservice users. This is typical for telecom services, but also for many new services such as attentiveservices, context aware services, notification services and ambient intelligence. Such services ingeneral entail a collaboration among several active objects, and therefore we call them collaborativeservices. For this kind of service, a services architecture and delivery platform is needed that supportsloosely-coupled autonomous service components.

Most service engineering approaches and technologies, among them SOA, fail to considercollaborative services. The SIMS project [7] addresses this gap and proposes a model-drivenapproach focusing on precise modelling, analysis and composition of collaborative services.Implementations may then be automatically generated for a range of different platforms. SIMS alsodevelops a middleware platform for the discovery of service components and the composition ofservices at runtime. Semantic interfaces are central concepts in the approach and are exploited tocompose services at design time and runtime and to ensure compatibility between components.

In the following, we first introduce a short introduction to the overall SIMS approach. Then weintroduce a collaborative service example, the virtual meeting place. We exploit this service exampleto illustrate the proposed solutions. Further we describe the main characteristics of collaborativeservices and identify the problems to be solved. We draw the main lines of development approach thathas been traditionally applied in the telecom domain and that form a basis for our work in SIMS. Weintroduce the SIMS approach gradually: we present how techniques are used to model simplecollaborations and then the more complex case of composite collaboration. Finally we relate SIMS tothe current UPMS-HA submission.

9 http://www.ist-sims.org/


Public


F.1.1 SIMS at a glanceThe emerging all-IP broadband connectivity for fixed and wireless networks is bringing along adisruptive change taking us a step forward towards convergence of information and communicationservices as well as fixed-mobile convergence. It enables the development of novel collaborativeservices that combine traditional communication services with information services, where servicelogic can be performed outside of the telecom networks, possibly even on user devices. To make themost of these technological advances one needs to require rethink the service value chain, fromservice delivery platforms and service creation to the kind of service that can be provided [8].

SIMS concentrates on the problem of service creation and deployment for mobile collaborativeservices. The objective is to enable services to be developed rapidly in a modular fashion, anddeployed in ways that enable automatic discovery of service opportunities at runtime, as well asdynamic service composition - but without sacrificing reliability. This calls for an approach to serviceengineering where service components are independently developed and then validated on the flywith respect to their possible collaboration. In short, it requires a concept for service components withprecise interface specifications that enable runtime discovery, composition, feature selection, andcompatibility validation. It should enable interoperable service components to be developed bydifferent service providers, and offered across terminal, network and provider boundaries.

The overall SIMS approach is illustrated in Figure 86. Services are first specified as collaborations atan abstract level using UML 2 [1]. Focus is set on the interfaces to services components that wedescribe as semantic interfaces [5, 9]. A semantic interface defines the goals and the interfacebehaviour of a service component in a service collaboration. Semantic interfaces and collaborationssupport incremental service specification. Semantic interfaces and collaboration are partial servicecomponent behaviours and interactions that can be used to form service features (i.e. partialcollaboration behaviours) and to compose services. Further they enable safety and liveness propertiesto be checked effectively. In addition to UML models that define the behavioural semantics ofinterfaces and collaborations, ontologies are used and provide a common and precise vocabulary andlanguage for describing related to semantic interfaces artefacts. Artefacts defined using ontologiesfocus on the meaning and purpose of services and service components. They are less detailed thanUML models and therefore easier to understand by a developer or a service user.

Note that service sessions are explicitly represented in SIMS. A service specification describes aservice session, and the entity types that are modelled in a specification represent instances in asession. This contrasts with SOA approaches where service sessions are not represented. Multiplesessions may be handle trough one interface, but session management is hidden. The explicitrepresentation of sessions facilitates the understanding of concurrent session behaviours andenforces a precise definition of the interfaces.

Following service specification, service roles involved in collaborations are mapped to servicescomponents. A service component is a design time and/or runtime entity capable of playing one ormore service roles. A service component may participate in several services. It owns a thread ofcontrol and can initiate control activity. Service components communicate asynchronously with otherservice components. Semantic interfaces are associated to components providing a means for servicediscovery and service composition at runtime with compatibility guarantees.

Public


Component collaboration

Featureselection

User Agent BUser Agent A

Open networksOpen networks

Deployed components

Design time

Runtime

Middleware support forservice discovery, composition

and runtime validationUser BUser A

Dynamiccomposition ofapplication SW

Semantic interface

Developers

Service specificationand validation

Component design

Semantic interfaceService collaboration

Component collaboration

Featureselection

User Agent BUser Agent A

Open networksOpen networksOpen networksOpen networks

Deployed components

Design time

Runtime


and runtime validation


and runtime validationUser BUser A User BUser BUser AUser A

Dynamiccomposition ofapplication SW

Semantic interface

Developers

Service specificationand validation

Component design

Semantic interfaceService collaboration

Figure 86 - Exploiting semantic interfaces at design time and runtime

F.1.2 The virtual meeting placeThe virtual meeting place exemplifies the kind of collaborative services we address in SIMS. Itcombines well-known Internet features, e.g. chat rooms and file sharing, with telecom services such asvoice conferences and media streaming.

Virtual meeting places are typically owned and configured by a person for some purpose, andindividuals are invited to participate or may request to participate. Participation requires the use ofsome device, i.e. a computer or a mobile phone, in a session with the meeting place. What featuresare offered by the meeting place is determined by the combination of its configuration, and by whatinitiatives the participants take at any particular time. The configuration should combine a set ofservice features that suits the purpose of the individual needs of each meeting place.

The individual service features include the following:

Establishing and configuring meeting places, which includes defining access rights toparticipants, what service features should be offered.Discovering meeting places. Users browse for meeting places, typically based on interest in atopic, on what Meeting places they are invited into, or on some other context information suchas geographical position and status.Joining meeting places. Users join meeting places using a device of their choice. Thisestablishes a user session between the device and the meeting place.Initiating features of the meeting place. Users access the features enabled for the meetingplace, which can typically include:

Uploading or downloading digital content shared in the meeting place

Chatting on message boards, or instant messaging to other joined users

Voting on issues, for instance on candidate participants

Engaging in two-way calls or multi-way conference calls with joined users

For such services to be appealing, the users should not need to worry about what software is requiredon their devices. Provided devices have the necessary capabilities, the underlying infrastructure

Public


should ensure that the appropriate applications are deployed for participation in the services availablein a meeting place.

In the following we will consider a scenario where Richard creates the Meeting place “MIT forum”, andinvites Jackie, Jarek and Rolv to participate. Rolv has a restricted access to the meeting place and canonly contribute with content. This is illustrated in Figure 87.

Jackie(Participant)

Jackie(Participant)

Rolv(Observer)

Rolv(Observer)

Jarek(Participant)

Jarek(Participant)

Meeting place: “MIT Forum”

Enabled features:

•Content sharing

•Instant messaging

Richard(Coordinator)Richard

(Coordinator)

Figure 87 - Example of a Meeting placeThe example indicates that different devices and different user roles are supported, and that aselection of features has been enabled in the Meeting place.

F.1.3 Collaborative servicesWe are familiar with collaborative services from the telecom domain: voice communication serviceslike phone conferences involve the participation of several entities representing users where theseentities may take independent initiatives. Collaborative services are not restricted to the telecomdomain though. Emerging research areas, such as ubiquitous computing and ambient intelligence,also require collaborations between autonomous entities that may behave in a proactive manner. Theengineering of collaborative services is complex and requires support for multi-party, loose-couplingand concurrency concepts. Complexity increases further as we move toward open environmentswhere anyone can wrap existing functionalities or create new ones, or as we move to dynamicenvironments where services can adapt dynamically to changing contexts.

Our experience is that collaborative services and corresponding engineering solutions are not well-understood outside the telecom domain. Telecom and general software engineers have traditionallyused fundamentally different approaches for the development of services and applications. This is notsurprising as the problems they have to solved are of different nature. We propose to survey the mainlines of service engineering in the telecom domain as a starting point.

F.1.4 Service engineering in the telecom domainThe participants of a telecommunication service are distributed and behave independently. Therefore,distribution, concurrency and peer-to-peer communication among users are inherent properties of theapplication domain, and not just implementation issues. The characteristics of the domain haveinfluenced the engineering approach [10]. In the following we summarize this relationship.

F.1.4.1 Domain conceptsThe telecom domain may be characterized as follows:

Active objects with concurrent behaviour. The telecom domain is characterized by realobjects, like users, that behave concurrently and need to interact and to be servedconcurrently. These are active objects executing their own behaviours and possibly takinginitiatives independently of each other (without requiring invocation). Concurrency andcommunication among concurrent objects is at the heart of telecom applications.Asynchronous communication. It follows from the nature of active objects with concurrentbehaviour that they cannot well communicate by control transfer. Communication by

Public


invocation, i.e. communication based on procedure or method call, is tied to a transfer ofcontrol from the calling entity to the called entity. The calling entity is blocked until control isreturned from the called entity. Active objects in the telecom domain are in general, looselycoupled and autonomous. Asynchronous communication based on signal sending is thereforethe preferred approach in the telecom domain.Symmetrical or peer-to-peer interactions. One cannot in general assume that the activeobjects take on asymmetrical roles, but must allow objects to communicate on an equal basis,with few restrictions. Asymmetrical communication imposing asymmetric initiating role andresponding roles on interacting objects, e.g. client and server, is not appropriate.Asynchronous communication is the most general communication paradigm and may be usedto realize any meaningful communication pattern. It is therefore suited to implementsymmetrical interactions. Communication between two active objects may generally flow inboth directions and concurrently. Initiatives may be taken independently and simultaneouslyand lead to conflicts that must be resolved.

F.1.4.2 Formal modellingAbstract and formal modelling has gained a strong position in the telecom domain. Formal models ofapplication functionality that can be understood and analyzed independently from implementationsand then automatically translated into efficient implementations have been developed. A conceptualabstraction that promotes human understanding and enables formal analysis of the correctness ofcomplex behaviours has helped considerably to reduce the number of errors and hence increase thequality of systems. For example, SDL [11] is widely used in the telecom industry and a number ofsuccessful experiences have been reported [12-17].

Systems and service engineering is strongly biased by the concepts we use to model, communicateand reason about a problem domain and its design solutions. Therefore modelling concepts must becarefully chosen to reflect the domain they are intended for. Since the perspective and the conceptsused in the models strongly influence the way we understand and deal with the topic domain,unsuitable modelling concepts may well lead to unsuitable system solutions. Modelling concepts suchas active objects, asynchronous communication and symmetrical interactions with multi-way initiatives,directly reflect the concepts in the telecom domain. In addition other modelling concepts are beingused:

Two-way interfaces and protocols. Normally signals may flow both ways across an interface,and the ordering may be defined by a protocol. This means that interface definitions normallylist the signals going both ways and possibly also specify the protocol.Explicit states. Interactions between active objects may be complex and is often stateful.Therefore some form of state machine is useful to represent the object behaviours. Objectsmay be involved in several interactions (i.e. interact with multiple objects), possibly in aconcurrent manner.General network structure. The overall system structure may form a network without anystructural limitations.

F.1.4.3 The concept of serviceA telecom service is a functionality usually provided to a group of users. A service results from thecollaboration between several active objects where several of these objects represent users. Eventhough each service user may access the service through one interface, there may be several usersand interfaces involved in a service. Even though each service user may access the service throughone interface, there may be several users and interfaces involved in a service. The meeting placeservice is a typical case in point. It entails collaboration between the parties taking part in the meetingplace, and cannot be understood simply as an interface.

Another particularity is that different service instances may contend for the same domain objects andresources. There is typically an n:m relationship between services and objects providing the services.

Public


(a) direct collaboration between user agents (a) collaboration through a server node

active entity

peer-to-peer interaction

(a) direct collaboration between user agents (a) collaboration through a server node

active entity


active entity


Figure 88 - The concept of collaborative service

F.1.4.4 System architectureAs opposed to functional decomposition which is often applied in server oriented architecture, telecomsystems have traditionally been decomposed according to the active environment they serve. Thisdecomposition approach is sometimes called mirroring [18] and results in an agent orientedarchitecture.

Agent oriented architectures set focus on users and other entities in the environment needing to berepresented and served. Components (agents) are chosen to reflect these entities. The responsibilityof an agent is to represent a user or other entity and perform services on its behalf. Agents may beused to represent virtual entities such as virtual meeting places as well as physical entities like usersand terminals. Services are performed by parts inside, or closely associated with an agent. Users mayaccess all services in a service provider domain through one agent and user data may be integrated inone user agent.

F.1.4.5 Computing platformsFollowing from the differences outlined above, the computing platforms developed for the telecomdomain are predominantly peer-to-peer oriented and based on asynchronous communication bymessaging. Middleware platforms based on communication by remote invocation such as CORBA,DCOM and Java-RMI are seldom used. Dealing with concurrency and two-way initiatives on suchplatforms requires careful attention to multithreading and synchronization of invocations. This ishowever is often not well-understood by application programmers and often a source of error (“Threadprogramming can be tricky” [19].

Note that asynchronous communication is always required at the lower level of a distributed system.Communication by invocation in a distributed system needs to be layered on top of asynchronouscommunication by messaging. From a performance point of view, asynchronous communication bymessaging will be the most efficient when it comes to networking.

F.1.5 Mixed initiatives and conflict resolutionSpecifying concurrent behaviours is complex. In particular, mixed initiatives should be identified andpotential conflicts resolved. Mixed initiatives occur when interacting components simultaneously takethe initiative to perform some handlings that involve each other. Mixed initiatives should be properlyhandled in order to avoid safety problems such as deadlocks. In the following, we provide a simplecase illustrating the occurrence of mixed initiatives and problems related to those. Other cases arepresented in SIMS D2.1 [20].

Figure 89 illustrates a mixed initiative involving three service components: two user agentsrepresenting users and a service session agent responsible for the management of a service session.The two users Jackie and Jarek simultaneously decide to initiate distinct service features and expect

Public


some setup from the session agent before further interaction with the other user agent. We observe aconflict and here a potential case of deadlock. A deadlock denotes a situation where two or moreservice components are unable to proceed because they wait endlessly for signals from each other. InFigure 89, each user agent may wait endlessly for an answer to their request from the session agent.The mixed initiative should be detected. Both the session agent and the user agent of Joe are able todetect it.

Jackie’suser

agent

Jarek’suseragent

1a. selectfeature X

2a. requestfeature X

1b. selectfeature Y

sessionagent

processing X - not Y

2b. requestfeature Y

3. setup forfeature X

waiting for processing of Y – not Xwaiting for processing of X

Jackie Jarek

Notation convention: Events are represented by arrows and the numberingindicates the ordering in which the events occur. Identical numbers, e.g.“2a” and “2b”, are used for simultaneous events

Jackie’suser

agent

Jarek’suseragent

1a. selectfeature X1a. selectfeature X

2a. requestfeature X

1b. selectfeature Y

sessionagent

processing X - not Y



3. setup forfeature X

waiting for processing of Y – not Xwaiting for processing of X

Jackie Jarek

Notation convention: Events are represented by arrows and the numberingindicates the ordering in which the events occur. Identical numbers, e.g.“2a” and “2b”, are used for simultaneous events

Figure 89 - Mixed initiatives involving three service components

F.1.5.1 Conflict resolutionConflicts occur when two or more service components take simultaneously the initiative to divergentbehaviours. This is a case in Figure 89 where Jackie and Jarek select different service features. Thecomponents should be able to identify when conflicts occur and to resolve them, i.e. to decide on acommon agreement. This problem is sometimes referred to as non-local choice [21]. Several conflictresolution patterns are defined in [9]. Resolution may involve negotiation at run-time. More simply acoordinator role may be assigned at design-role.

Note that a mixed initiative does not necessarily lead to a conflict: two components may also select thesame behaviour simultaneously.

F.1.5.2 Early detection of errorsFormal modelling enables the validation of systems and detection of errors. The aim of validation is toverify the system’s logical consistency and completeness. Validation techniques are usually appliedafter the design phase. When the system has been designed, it is analyzed. If errors are found, thesystem has to be re-designed, re-analyzed, etc., until no new errors can be detected. Differently, SIMSexploits techniques that can be applied at design time [22]. Using these techniques, critical behaviourpatterns, such mixed as initiatives, can be detected early during service design, resulting in ashortened development process. Furthermore, design rules are proposed that enable the designer toavoid making certain dynamic errors and to develop well-formed behaviours.

F.1.6 SIMS service engineering approachIn SIMS we suggest a more general definition of services compared to that used by others. In SIMSservices are viewed as collaboration between services components that deliver functionality to the"end user - which can be a human or a machine. With this definition, both collaborative services of thetelecoms domain as well as two-party services of the client-server type can be supported. Note thatcollaborative services can involve several (i.e. more than two) collaborating objects playing differentservice roles, as exemplified by the Meeting place service.

Public


The compositional units that play service roles we call Service components, and these can becomposed both horizontally to form services, and vertically to form applications that run as softwareapplications on devices. Composite services can be composed from more elementary services andmodelled using UML 2.0 Collaborations.

The concepts used by SIMS are defined in the meta-model presented in Figure 90.

2..*involvesinvolves1..*

1..*

1..*

playsplays

performs inperforms in Service roleService role SemanticinterfaceSemanticinterface Role goalRole goal

Servicecomponent

Servicecomponent

ServiceService

can be played bycan be played by

is compliant withis compliant with1..*

definesdefines

1..*

Collaborationgoal sequenceCollaboration

goal sequenceCollaboration

goalCollaboration

goal

CompositecollaborationComposite

collaborationElementary

collaborationElementary

collaboration

is defined inis defined incontainscontains

1..*

2

containscontains

containscontains

hashas

2..*

1..*

1..*is used inis used in1..*

hashas

is modelled byis modelled by is used inis used in

1..*

definesdefines

Figure 90 - Meta model for the basic concepts and definitions in SIMSA service comprises at least two service components, for instance in order to play the service role ofthe client and of the server in a client-server service. This implies that applications wishing to performservices meet two aspects of service discovery:

Finding (discovering or learning) service components that they can use in their (static ordynamic) composition to play their role in the service. E.g. a client object has to have thecapability of playing the client role; the client role can be encapsulated in a servicecomponent.Finding (discovering) a complementary service component with which to interact to perform aservice. E.g. a client (component) needs to find a server (component).

This applies regardless of whether the service is of a client-server or a collaborative type.

F.1.7 Modelling servicesIn SIMS services are modelled in UML 2.0 using Collaborations in Composite structure diagrams, as inFigure 91. Here an octagonal stereotype is used for the collaboration role classifier.

Public


P:Participant C:Coordinator

Invite2MeetingPlace

Service nameService role

name

Service roletype

session

UML 2.0Collaboration

UML 2.0connector

UML 2.0collaboration role

and role type

Figure 91 - Modelling a service with two roles using UML 2.0The binding of service role types (service components) to service components (at design time or run-time) can also be expressed in UML 2.0 Collaboration uses:

Participant Controller1 1Invite2MeetingPlaceP C

:UserAgent :UserAgent: Invite2MeetingPlaceP C

plays plays

Service nameService role type

Role player(service

component)

role binding

UML 2.0Collaboration use

UML 2.0 object

Figure 92 - Expressing the binding between service roles and the service components that playthese roles using UML 2.0

Note that it is the bottom half of Figure 92 that is the Collaboration Use; the “plays” relationshipreferring to the Collaboration defining the service (the top half) is included to explain to the reader whatthe Collaboration Use means.

In SIMS, we base our compositional approach on the simplest form of a service, which is close to thetype of service of the client-server (web services) viewpoint; we call this a elementary collaboration,which defines exactly two roles (e.g. a client and a server role), see Figure 93.

Invite

inviter:Inviter 1 invitee:Invitee 1

{def: goal : Boolean = inviter.goal and invitee.goal}Collaboration goal

Semantic interface Role name

Elementarycollaboration

Role typeFigure 93 - Elementary collaboration and a pair of semantic interfaces

We call the role types defined by an elementary collaboration semantic interfaces; these are describedby state machines (actually extended protocol state machines in UML), and define service goals forthe components, see Figure 94.

Public


invitinginviting

Accept

Inviter {xprotocol}

Reject

Invite

accepted{goal == True}

invitedinvited

Invitee {xprotocol}

Accept

joined{goal == True}

Reject

Invite

progress:Invite_Responding

goal:=False

goal:=True

goal:=False

goal:=TrueGoalvariable

Progress labelmarks anevent goal

Goalassertion

Figure 94 - Interface behaviour for semantic interfaces (with goals)Service goals (collaboration goals and role goals) are used during validation (at design time and/orrun-time) to check if components can collaborate usefully; that they can collaborate safely is aprerequisite that also is checked. This is detailed in the section on validation below.

SIMS uses ontologies to describe the intensions of service components and semantic interfaces. Thisaids the designer when formulating goals, and when searching for semantic interfaces and servicecomponents in the design phase as an aid to reuse. Characterizing components and interfaces withgoals supported by ontologies also aids the validation process, in that one can select candidates forcomplementary roles based on their defined intensions.

Elementary collaborations are used to compose more complex services; again, this can be modelledusing UML2 collaborations.

MeetingPlaceWithInstantMessaging

C:CoordinatorC:Coordinator 1 P1:Participant1

P2:ParticipantP2:Participant

im1:IM

talker talker

inv_1:Invite

inviter

inv_1:Invite

invitee

inv_1:Invite

inviter

inv_1:Invite

invitee

talk_2:Talkim2:IM

talker

talker

talk_2:Talkim2:IM

talker

talker

invitee

inviterinv_2:Invite

talk_3:Talk

talker

talker

im3:IM

talker

talker

talk_3:Talk

talker

talker

im3:IM

talker

talker1

Figure 95 - Multi-role composite service composed of elementary collaborationsFigure 95 indicates how collaborations can express composite behaviour; in this case a compositeservice reuses the elementary collaboration Invite defined in Figure 93, as well as an elementarycollaboration for instant messaging called IM that is not defined here. Detailed goal relationships canbe expressed in goal sequence diagrams.

Public


F.1.8 Relationship to the UML Profile and Metamodel for ServicesThe above discussion presents the main concepts and contribution to the modelling of services withsemantic interfaces. SIMS identifies the following relationships to the UPMS-HA metamodel

SIMS provides a service model capable of supporting loosely coupled interfaces;SIMS defines behavioural interfaces on ports of components, using (extended) protocol statemachines – the extension consists of specifying output (in addition to input);SIMS relates goals to interfaces (see Figure 90):

SIMS in addition relates goals to collaborations, to express composite goals

SIMS related goals to interaction overview diagrams to express goal sequences

F.1.9 Further workThe foundation of this work is found in a recently published PhD thesis by Sanders [23].

Further work in this area is ongoing in the SIMS project, http://www.ist-sims.org/

F.1.10 References1. OMG. UML 2.0 Superstructure Specification, Revised Final Adopted Specification, ptc/04-10-02, Object Management Group, Needham (MA), USA, Oct. 8, 2004. 2004.

2. Kraemer, F.A. and P. Herrmann. Service Specification by Composition of Collaborations--AnExample. In proceedings of Web Intelligence and International Agent Technology Workshops, 2006.2006. Hong Kong, China. IEEE. p. 129-133.

3. Castejón, H.N. and R. Bræk. Formalizing Collaboration Goal Sequences for ServiceChoreography. In proceedings of Formal Techniques for Networked and Distributed Systems - FORTE2006. 2006. Paris, France. Springer Berlin / Heidelberg. p. 275-291.

4. Kraemer, F.A., P. Herrmann, and R. Bræk. Aligning UML 2.0 State Machines and TemporalLogic for the Efficient Execution of Services. In proceedings of On the Move to Meaningful InternetSystems 2006: CoopIS, DOA, GADA, and ODBASE. 2006. Montpellier, France. Springer Berlin /Heidelberg. p. 1613-1632.

5. Sanders, R.T., et al. Using UML 2.0 Collaborations for Compositional Service Specification. Inproceedings of Model Driven Engineering Languages and Systems, 8th International Conference,MoDELS 2005. 2005. Montego Bay, Jamaica. Springer Berlin / Heidelberg. p. 460-475.

6. Sanders, R.T., et al. Service discovery and component reuse with semantic interfaces. Inproceedings of SDL 2005: Model Driven Systems Design: 12th International SDL Forum, Grimstad,Norway, June 20-23, 2005. 2005. Grimstad, Norway. Springer-Verlag GmbH. p. 85-102.

7. The SIMS project - Semantic Interfaces for Mobile Services. Available from: http://www.ist-sims.org/

8. eMobility, the European Mobile and Wireless Communications and Technology Platform.Available from: http://www.emobility.eu.org/ [accessed: March 2007

9. Floch, J. Towards Plug-and-Play Services: Design and Validation using Roles. thesis.Norwegian University of Science and Technology (NTNU). 2003.

10. Floch, J. and R. Bræk. ICT Convergence: Modelling Issues, in System Analysis and Modelling:4th International SDL and MSC Workshop, SAM 2004, Ottawa, Canada, June 1-4, 2004, RevisedSelected Papers, D. Amyot and A.W. Williams, Editors. 2005, Springer-Verlag GmbH. p. 237-256.

11. ITU-T. Recommendation Z.100 (11/99), Specification and Description Language(SDL).International Telecommunication Union, Geneva (1999).

12. Færgemand, O. and R. Reed. Proceedings of the 1991 SDL Forum. 1991. North-Holland.ISBN 0-444-88976-0.

13. Færgemand, O. and A. Sarma. Proceedings of the 1993 SDL Forum. 1993. North-Holland.ISBN 0-444-81486-8.


http://www.ist-/

http://www.emobility.eu.org/

Public


14. Bræk, R. and A. Sarma. Proceedings of the 1995 SDL Forum. 1995. North-Holland. ISBN 0-444-82269-0.

15. Cavalli, A. and A. Sarma. Proceedings of the 1997 SDL Forum. 1997. Elvesier. ISBN 0-444-82816-8.

16. Dssouli, R., G.v. Bochmann, and Y. Lahav. Proceedings of the 1999 SDL Forum. 1999.Elvesier. ISBN 0-444-50228-9.

17. Reed, R. and J. Reed. Proceedings of the 10th SDL Forum. Vol. LNCS 2078. 2001. Springer.ISBN 3-540-42281-1.

18. Bræk, R. and Ø. Haugen. Engineering Real Time Systems. 1993. Prentice Hall. ISBN 0-13-034448-6.

19. Microsystems, S. The Java tutorial. Available from:http://java.sun.com/docs/books/tutorial/essential/threads/ [accessed: March 2007

20. SIMS deliverable D2.1 - Language and Method Guidelines, 1st version. 2006.

21. Gouda, M.G. and Y.-T. Yu. Synthesis of communicating Finite State Machines withguaranteed progress. IEEE Transactions on Communications, 1984. 32(7): p. 779-788.

22. Floch, J. and R. Bræk. Using Projections for the Detection of Anomalous Behaviours, in SDL2003: System Design, 11th International SDL Forum, Stuttgart, Germany, July 1-4, 2003, R. Reed andJ. Reed, Editors. 2003, Springer-Verlag GmbH: Stuttgart, Germany.

23. Richard Torbjørn Sanders. Collaborations, Semantic Interfaces and Service Goals: a wayforward for Service Engineering. Doctoral theses at NTNU, 2007:68, (March 2007).

http://java.sun.com/docs/books/tutorial/essential/threads/

Public


Appendix G: Integrating UPMS-HA and Semantic WebServices

This annex describes the possible extensions of UPMS-HA for the support of Semantic Web Servicessuch as OWL-S, WSMO, SWSF, WSDL-S, etc. This chapter is based on input form DERI andUniversity of Augsburg [1].

The first part of the annex introduces possible extensions to UPMS-HA to serve semantic web servicedevelopment need. It illustrates, how UPMS-HA concepts can be extended with constructs describingnon-functional properties as well as a linkage to elements in an ontology. The second part provides anoverview over prominent semantic web service approaches and standards (OWL-S, WSMO, SWSF,WSDL-S). We also describe how the extension of UMPS-HA can be mapped to these mentionedsemantic web service standards.

In general one can say that the service specification concepts from the UPMS-HA service packageand the concepts from the UPMS-HA process package are the most relevant for modelling anddeveloping semantic web services.

G.1.1 Extending UPMS-HA to a Semantic Web Service MetamodelThis section describes a possible extension of the UPMS-HA to support also constructs that areneeded for modelling semantic web services.

G.1.2 Using ontology concepts in UPMS-HAFor modelling and execution of semantic web service it is possible for any NamedElement of UPMS-HA to reference elements of an ontology (SemanticElements). The metamodel for ontology model wedescribe here provides basic constructs to model ontologies and is an extract form the OntologyDefinition Metamodel (ODM) [2]. ODM has the advantage that it is implementation independent withrespect to the ontology language (OWL or WSML) used for implementing concrete semantic webservices. A RDFSResource is a specialization of the abstract concept SemanticElement.RDFSResource is part of an ontology. A resource can either be a class (or concept as it is called inWSML) or a property. RDFSClasses can be connected to other classes via RDFProperties whichcontain the domain and range of the property. Every class (resp. property) can be generalized andthere exist specializations for OWL classes which are the mostly used presentation form of currentontologies.

Figure 96: Extending UPMS-HA with ontology conceptsHowever, there are a few concepts deserve special interest in the context of modelling semantic webservices.

Public


Every service (or its service specification) has required and provided interfaces which includes anumber of Operations. Similar to the WSDL-S or the SAWSDL approach each operation might bedescribed with a semantic element from the ontology. The Messages that are exchanged asparameters of the operations can also be described with semantic attributes through the items theytransfer (Items are NamedElements and therefore point to SemanticElements, too)..

Figure 97: Extending UPMS-HA Operations with ontology conceptsAdditionally, it is possible to describe the preconditions and effects of each task. Preconditionsdescribe the state of the world before the execution of the task and the effect describe the state of theworld after execution of the task. These concepts are similar in all semantic web service approaches(sometimes called assumptions and postconditions, but the meaning is the same).

Figure 98: Extending UPMS-HA Tasks with Preconditions and Effects

G.1.3 Extending Service Specifications of UPMS-HAThere exist several description mechanisms for services that are commonly used by semantic webservice approaches. It seems reasonable to incorporate these descriptions in extension of UPMS-HAthat is dedicated to develop semantic web services.

Categorization is one description mechanism that is used by OWL-S and SWSF. A ServiceCategoryconsists of a categoryName, a path to a taxonomy, a specific value in the taxonomy and the codeassociated to a taxonomy.

Each process can be also described with a ServiceDescriptor. According to OWL-S ServiceDescriptorincludes a service name, a textual description, and contact information (contact_info). Additionalinformation that is used by SWSF is the author of the service, the version, releasedate, etc..

A third option that is used to describe services is NonFunctionals. These contain attributes to describethe non-functional properties of a service. Some non-functional properties the WSMO-approach usescan be seen in the NonFunctional class. These aspects could also be incorporated into the QoSaspect of UPMS-HA.

Public


Figure 99: SWS extension of UPMS-HA for additional semantic propertiesA further extension of the UPMS-HA to serve semantic web service standards’ needs is to modelgoals. Goal-oriented modelling is not only used in the context of the semantic web, there are manyother approach that have to be considered, but WSMO is prominent representative of goal orientedmodelling. However, the goals extension of UPMS-HA it based on results from the SemanticInterfaces for Mobile Services (SIMS) project (http://www.ist-sims.org/), which has dealt withintegrating goals into roles of services and collaboration between roles in UML models. The UPMS-HAgoal extension can be mapped to current versions of goal-oriented semantic web servicespecifications like WSMO.

Service specifications of UPMS-HA can have semantic interfaces. Semantic interfaces define thegoals (RoleGoal) and the behavioural semantics of services in service contracts. Goals can be alsodefined for service contracts. One usage of service goals (collaboration goals and role goals) is, tovalidate (at design time and/or run-time) and to check if components can collaborate usefully inspecific service contracts.10

Figure 100: SWS extension of UPMS-HA for additional semantic properties

G.1.4 Aligning the Semantic Web Service Metamodel with existingSemantic Web Service standards

In this section we will have a closer look at four semantic web service approaches, OWL-S, WSMO,WSDL-S and SWSF (which have all been submitted to the W3C), and how they can be aligned withUPMS-HA and the semantic web service extension, respectively.

10 See also the annex about ‘Collaborative services through Semantic Interfaces’.


Public


WSDL-S

OWL-S WSMO SWSF

no ontology language andlogic pre-defined

describtion logic(DL)

first-order logic /higher order logic

(FOL / HOL)

singl

e-ste

ppr

oces

ses

mul

ti-st

eppr

oces

ses

WSDL-S

OWL-S WSMO SWSF

no ontology language andlogic pre-defined

describtion logic(DL)

first-order logic /higher order logic

(FOL / HOL)

singl

e-ste

ppr

oces

ses

mul

ti-st

eppr

oces

ses

Figure 101: Semantic Web Service languagesFigure 101 depicts a categorization of the above mentioned semantic web service. WSDL-S does notforce to use a specific ontology language and therefore it does not define any specific logic. It is onlyusable for single-step processes whereas the other standards can handle multi-step processes, too.OWL-S builds on OWL which is based on description logic (OWL DL). SWSF uses first-order logic andrule languages to model the ontology in its underlying language SWSL and WSMO offers both logiclayers (first-order logic and higher-order logic – each in a different specification part of the language)for the modelling of ontologies in WSML.

G.1.5 OWL-S: Semantic Markup for Web ServicesOWL-S [3] (currently version 1.2 is developed) enables the discovery of services (that meet particularrequirements and adhere to specified constraints), invocation (by agents or other services),interoperation (through specification of the needed vocabularies), composition (automated servicecomposition and synthesis to provide new services) and verification (of service properties). OWL-Sbuilds on the formerly developed DAML-S and was one the first submission of a semantic web serviceto the W3C and currently gets a lot of support in Northern America and Asia. Each Semantic WebService in OWL-S consists of a service profile, a service model and a grounding (see Figure 102). Theservice profile describes what the service does and is used to advertise the service. The service modelanswers the question “how is it used?” and describes how the service works internally. Finally, theservice grounding specifies how to access the service (“how does one interact with it?”).

Figure 102: OWL-S meta-model: ServiceTo give a detailed perspective on how to interact with a service, it can be viewed as a process. OWL-Sdistinguishes three kinds of processes: Atomic processes, Simple processes and CompositeProcesses. Atomic processes are directly callable and correspond to the actions a service can performby engaging it in a single interaction; composite processes correspond to actions that require multi-step protocols and/or multiple server actions; finally, simple processes are not callable and notassociated with a grounding and only provide an abstraction mechanism to enable multiple views ofthe same process.

Public


Figure 103: OWL-S meta-model: Service ModelThe service profile describes the functional and non-functional (e.g. service category) parts of theprocess and has several parameters (such as Input or Output) and Expressions like Precondition andEffect.

Figure 104: OWL-S meta-model: Service ProfileThe grounding of a service specifies the details of how to access the service – details having mainly todo with protocol and message formats, serialization, transport and addressing. Only the servicegrounding deals with the concrete level of specification, the service profile and model are only thought

Public


of as abstract representations. The main aim of grounding is to concretely realize the inputs andoutputs of an atomic process as messages. These further carry the inputs and outputs in a specificdefined communicable form.

Figure 105: OWL-S meta-model: Service GroundingOWL-S is based on the Web Ontology Language OWL and supplies web service providers with a coreset of markup language constructs for describing the properties and capabilities of their web servicesin an unambiguous, computer-interpretable form. For a detailed overview of the OWL-S meta-model,see appendix A.

Finally, the following table shall give an overview how OWL-S could be aligned to UPMS-HA and itsextensions.

UPMS-HA OWL-S

Process Simple/Atomic/CompositeProcess

isAbstract = true SimpleProcess

serviceClassification serviceClassification

serviceProduct serviceProduct

serviceParameter serviceParameter, sParameter

service_name serviceName

description textDescription

contact_info contactInformation

ServiceCategory ServiceCategory

categoryName categoryName

taxonomy taxonomy

value value

code code

ServiceSpecification Profile

Task.input Input

Task.output Output

Task.precondition Condition

Task.effect Result/Effect

Split, Join Split / Split-Join

Decision, Merge Choice, If-Then-Else

Task AtomicProcess / Grounding

Public


Process CompositeProcess

Fork Sequence, Any-Order

G.1.6 WSMO: Web Service Modelling OntologyBased on the Web Service Modelling Framework (WSMF) [4], the Web Service Modelling OntologyProject (WSMO) [5] developed mainly by the Digital Enterprise Research Institute (DERI) is a formalontology and language that consists of four different main elements for describing semantic webservices:

Ontologies: They provide the terminology used by other elements to describe the relevantaspects of the domains of discourse.Goals: They state the intentions that should be solved by web services and arerepresentations of one or more objectives which need to be fulfilled.Web Services: A Web Service is a computational entity which is able to achieve a part of orthe complete goals a user seeks to fulfill. WSMO web service descriptions describe variousaspects of a service and consist of functional, non-functional and the behavioural aspects of aweb service.Mediators to resolve interoperability problems. They describe elements to overcomeinteroperability and incompatibility problems between different elements on data (ooMediator),process (ggMediator, wgMediator) and protocol level (wwMediator).

WSMO comes along with a modelling language (WSML) [6] and a reference implementation (WSMX).WSML has five variants: WSML-Core which is based on the intersection of Description Logic andLogic Programming and which is the least expressive variant; WSML-DL which is an extension ofWSML-Core and offers similar expressive power as OWL-DL and is based on description logic, too.WSML-Flight extends the Core (disjoint to WSML-DL) in the direction of Logic Programming; WSML-Rule which extends WSML-Flight and thus offers the same kind of conceptual modelling features andallows the use of function symbols and unsafe rules. Finally WSML-Full is a superset of WSML-Ruleand WSML-DL and can be seen as a notational variant of First-Order Logic with non-monotonicextensions. All WSML variants are specified in terms of a human-readable syntax with keywordssimilar to the elements of the WSMO conceptual model. WSMO uses F-Logic syntax to provideaxioms and logical inference support. F-Logic was originally developed for defining, querying andmanipulating database schema. F-Logic combines the advantages of typical frame based languageswith the expressiveness, the compact syntax and the well defined semantics from logics.

The EU-funded project WSMO also develops an execution environment (WSMX) which enablesdiscovery, selection, mediation, invocation and interoperation of semantic web services. Besides thereference implementation WSMX, there is the Internet Reasoning Service, IRS-III, which provides therepresentational and reasoning mechanisms for implementing the WSMO meta-model describedbelow. It supports the developer at design time by providing a set of tools for defining, editing andmanaging a library of semantic descriptions and also for grounding the descriptions to a standard webservice (e.g. described in the Web Service Description Language WSDL).

Most of the elements in WSMO can be described with non-functional properties in greater detail. Thisincludes Quality-of-Service aspects, economic aspects and additional descriptions.

Public


Figure 106: WSMO top level elementsThe ontology in WSMO consists mostly of concepts, attributes and instances. Each of them can bedescribed using non-functional properties. Concepts can build a taxonomy and are linked to otherconcepts using attributes. There can be functions and relations using these concepts as parameterand axioms which are logical expressions together with their non-functional properties.

Figure 107: WSMO ontologyEach web service in WSMO builds on one or more ontologies and might use mediators to translatebetween several ontologies or web services. They are described using interfaces and capabilities. The

Public


interface for a complex web service is characterized using the web service orchestration orchoreography which is built using an abstract state machine (on states and transitions). The capabilitydescribes the functional parameters of the (one-step or multi-step) web service. It specifies thepreconditions (the information state of the web service before execution), assumptions (the state of theworld before execution), postconditions (the information state of the web service after its execution)and effects (the state of the world after execution).

Figure 108: WSMO web serviceWSMO goals enable the possibility to model the intentions that should be solved by one or more webservices. They describe an interface that should be implemented and capabilities that need to befulfilled. Therefore, ontologies and mediators might be needed to achieve the goal.

Figure 109: WSMO goals

Public


Additionally, WSMO defines how to model mediators. These are necessary to make a semanticmatchmaking of different ontologies (ooMediator), different web services (wwMediators), between webservices and goals (wgMediator) as well as between several goals (ggMediator). To our latestinformation there is a distinction between goal template and goal instance, which would alsostrengthen the variability aspect of UPMS-HA. Goal templates are generic, reusable objectivedescriptions, and goal instances denote concrete client requests as instantiations of a goal template.Stollberg at al. [7] provide more details on how to specify goals and services in the context of WSMO.

Finally, the following table shall give an overview how WSMO could be aligned to UPMS-HA and itsextensions

UPMS-HA WSMO

Ontology ontology

RDFSClass concept

RDFSsubClassOf hasSuperConcept

RDFProperty Attribute

RDFSsubPropertyOf hasSuperRelation

Part state

Flow guarded transition

Task.input shared variable and precondition

Task.precondition assumption

Task.output shared variable and postcondition

Task.effect effect

service_name title

service_author creator

contact_info owner

service_contributor contributor

service_description description

service_url source

service_identifier identifier

service_version version

service_releasedate date

service_language language

service_trust trust

service_subject subject

service_reliability reliability

service_cost Financial

RoleGoal, CollaborationGoal goal

G.1.7 WSDL-S: Web Service SemanticsWSDL-S [8] is another semantic web service approach submitted to the W3C in November 2005 andextends the WSDL standard with semantic information (using a new attribute modelReference).

Public


Currently it only considers single-step services and there is no specification how a composition ofseveral web services should be handled. However, there are already efforts to annotate web servicechoreography languages like WS-BPEL similar to the annotations made in WSDL-S. WSDL-S usesthe extensibility elements of WSDL and introduces new elements to describe the semantics of aservice, of its inputs and outputs and of preconditions and effects.

All input and output types can be annotated with semantic elements and additional “mediators” (asthey have been called in WSMO) can be defined using XSLT-transformations. Each operation canhave a semantic annotation and for each interface categories can be defined (similar to OWL-S).

The advantages of this approach can be summarized as follows:

it builds on existing web services standardsit supports the user’s choice of the semantic representation languageit allows the association of multiple annotationsit supports semantic annotation of web services whose data types are described in XMLschema

Figure 110: WSDL-S meta-modelFinally, the following table shall give an overview how WSDL-s could be aligned to UPMS-HA and itsextensions

UPMS-HA WSDL-S

Interface Interface

Operation Operation

Link to SemanticElement modelReference

Message message

ServiceCategory category

categoryName categoryname

code taxonomyCode

taxonomy taxonomyURI

value taxonomyValue

Public


G.1.8 SWSF: Semantic Web Services FrameworkAnother W3C submission (from September 2005) beside OWL-S and WSMO is the Semantic WebServices Framework (SWSF) [9] which represents an attempt to extend the work of OWL-S andconsists of two major parts:

the language SWSL as an underlying basis: The Semantic Web Service Language has twosublanguages:SWSL-FOL which is based on first-order logic and primarily used to express the formalcharacterization of web service concepts andSWSL-Rules that is similarly to WSML-Rule based on logic programming; andthe ontology SWSO above. The Semantic Web Service Ontology presents a conceptualmodel by which web services can be described and, again, which can be divided in two forms:

FLOWS, the first-order logic ontology for web services which has (following the high-level structure ofOWL-S) three major components: Service Descriptors, Process Model and Grounding. It adapts thekey concepts from the Process Specification Language PSL (ISO 18629) which was originallydeveloped to enable sharing of descriptions of manufacturing processes. A fundamental building blockof FLOWS is the concept of an atomic process (similar to OWL-S). Associated with an atomic processare zero or more parameters that capture the inputs, outputs, preconditions and effects (simply calledIOPEs)

ROWS, the rules ontology for web services which enables implementations in reasoning andexecution environments based on logic-programming.

SWSF emerged from the work in service composition which might require more expressivity than isavailable in OWL and is therefore based on logic programming, first-order logic and policy research. Itbuilds on DAML-S, OWL-S and WSMO and provides rich semantics for greater automation ofdiscovery, selection and invocation, content transformation, composition, monitoring and recovery andverification. Lying the focus on the messages similar to WSDL 2.0 (where several Message ExchangePatterns (MEP) have been developed), it introduces the concepts of Channels and Messages whichcan be created and modified using several specialized actions.

Public


Figure 111: SWSF Meta-model: FLOWS CoreTo compose several services in a multi-step process, it defines control constraints (in the style ofOWL-S) for alternatives, loops, parallel flows, choices, etc. Additionally, it defines ordering constraintsto allow the specification of activities defined by sequencing properties of atomic processes(OrderedActivity), Occurrence Constraints to support the specification of nondeterministic activitieswithin services (OccActivity), State Constraints (for activities which are triggered by states) andException Constraints.

Figure 112: SWSF meta-model: Other ConstraintsFinally, the following table shall give an overview how SWSF could be aligned to UPMS-HA and itsextensions

UPMS-HA SWSF

Public


ServiceDescriptor ServiceDescriptor

service_name name

service_author author

contact_info contact

service_contributor contributor

service_description description

service_url url

service_identifier identifier

service_version version

service_releasedate releaseDate

service_language language

service_trust trust

service_subject subject

service_reliability reliability

service_cost cost

ServiceChannel channel

Process Domain-specific atomic processcombined with a Produce_Message,Read_Message and eventuallyDestroy_Message

Task.input input

Task.output output

Task.precondition precondition

Task.effect effect

Split, Join Split

Decision, Merge Choice, If-Then-Else

Flow Sequence, Unordered

G.1.9 References1 Lautenbacher, F.: A UML profile and transformation rules for semantic web services.Technical Report TR 2006-20, Institute of Computer Science, University of Augsburg, September 2006

2 Object Management Group (OMG): “Ontology Definition Metamodel (ODM), Fifth RevisedSubmission to OMG/RFP ad/2003-3-40”, January 2006, available online athttp://www.omg.org/docs/ad/06-01-01.pdf

3 Martin, D. et al: “OWL-S: Semantic Markup for Web Services”, November 2004, W3CMember Submission, available online at http://www.w3.org/Submission/OWL-S/

4 Fensel, D. and Bussler, C.: “The Web Service Modeling Framework WSMF”, ElectronicCommerce: Research and Applications, 2002

5 Lausen, H., Polleres, A. and Roman, D. (Eds.): “Web Service Modeling Ontology (WSMO)”,June 2005, W3C Member Submission, available online at http://www.w3.org/Submission/WSMO/

http://www.omg.org/docs/ad/06-01-01.pdf

http://www.w3.org/Submission/OWL-S/

http://www.w3.org/Submission/WSMO/

Public


6 de Bruijn, J. and Lausen, H. and Polleres, A. and Fensel, D.: “WSML – a LanguageFramework for Semantic Web Services”, W3C Workshop on Rule Languages for Interoperability,Washington DC, USA, 2005

7 Stollberg, M., Keller, U., Lausen, H., and Heymans, S.: Two-phaseWeb Service Discoverybased on RichFunctional Descriptions. European Semantic Web Conference (ESWC), 2007

8 Akkiraju, R. et al.: “Web Service Semantics – WSDL-S”, November 2005, W3C MemberSubmission, available online at http://www.w3.org/Submission/WSDL-S/

9 Battle, S. et al.: “Semantic Web Services Framework (SWSF) Overview”, September 2005,W3C Member Submission, available online at http://www.w3.org/Submission/SWSF/

http://www.w3.org/Submission/WSDL-S/

http://www.w3.org/Submission/SWSF/

Public


Appendix H: SEA – SOA based Enterprise ArchitectureSOFTEAM has worked within an open consortium in France to define model based methodologies forSOA (see www.praxeme.fr), and has set up a methodology called SEA (SOA Enterprise Architecture)that supports system modelling from the first vision and goal definition stages until the implementation.SEA separates the models into aspects covering the main areas or concern, one (the logical aspect)being entirely devoted to SOA. SOFTEAM provides a modelling tool supporting SEA, calledObjecteering EA, based on OMG standards (UML, MDA, BPMN) and providing SEA specificextensions and support.

This appendix presents parts of the SEA approach developed by SOFTEAM, and its UML profileimplementation. SEA stands for SOA based Enterprise Architecture. The scope of SEA ranges fromhigh level Enterprise Architecture modelling down to software and physical implementation. SEA issupported by a white paper published under the www.softeam.fr web site, currently only available inFrench (version 1.0), but currently in the process of being published in version 1.1 and translated inEnglish.

SEA is based on the most important common practices for SOA and Enterprise Architecture, and itsambition is to influence and be aligned with the upcoming UPMS OMG standard. It is based on theUML2 standard, and uses the MDA technology. Its objectives are:

To provide a global approach for Enterprise architecture and SOA modelling,To align Enterprise Architecture and software modellingTo maximize the benefits of the MDA technologyTo use extensively the standards such as typically UML and BPMNTo provide models dedicated to each kind of participants to a system, from the stakeholders tothe developers, that fits their viewpoints.

SEA is also based on results from the PRAXEME methodology, which is shortly presented below. Oneof the key features of PRAXEME is its decomposition into predefined view points (called “aspects”within PRAXEME), that provide the main important perspectives to each aspect of a system, and toeach kind preoccupation of the participants.

Within the scope of UPMS, we will concentrate on the “Logical” aspect, that provide a support for SOAarchitecture, independently of the final implementation (realized in the technical/software/physicalaspects).

SEA is currently supported by a set of profiles, each of them supporting one or several aspects(viewpoints) of SEA.

The purpose of the present document is to provide initial input to the UMPS response work, in order toensure that UPMS provides the essential concepts to model SOA based systems.

H.1.1 The Praxeme approachPRAXEME is an open initiative that aims to provide a methodology to support the entire systemrepresentation and implementation activity, ranging from the stakeholders view and goals down to itsrealization and deployment. (see www.praxeme.fr)

The Praxeme methodology defines models and representations for all aspects of the enterprise. Itcarefully organizes them in order to be able to integrate them within a coherent workflow, which goesfrom strategy to implementation. It also specifies modelling techniques, organized around a commoncore and specialized according to the aspect being described. The modelling techniques benefit fromthe UML standard and are explicitly orientated towards communication.

Table 1. Aspects of the Enterprise System

Aspect Equivalentterms

Definitions

Semantical Conceptual, The semantic aspect is only concerned with those objects thatmake up the essence of the business activity. Only the knowledge

http://www.praxeme.fr)/

http://www.softeam.fr/

http://www.praxeme.fr)/

Public


Essential,Business

Model

is described and is represented independently to the way thebusiness is actually performed.

Pragmatical Organisational The pragmatic aspect describes the way business activities areperformed: actors, responsibilities, actions on objects, process,and work contexts.

Geographical Communication,

Environment

The geographical aspect models the location of objects andactions. It shows concepts such as sites, locations andcommunication requirements.

Logical Functional Intermediate aspect where decisions are be taken on the mostimportant structures of the information system, in a way that isrelatively independent from technical solutions.

Technical Technological The technical aspect is concerned with the choice of technologiesand the way they are implemented.

Hardware Logistical The hardware aspect features all physical hardware of which thesystem is composed, with all their properties (capacity,interoperability, cost, etc.). Examples of hardware are PCs,telephones, fax machines, sensors etc.

Software Applicative The software aspect displays all software components whichautomate some part of the system.

Physical Deployment From the physical aspect, the distribution of software components(including databases) on hardware is described.

Enterprises and their CIO’s or CEO’s are currently concerned with some important issues:

Enterprise management: balanced scorecard, Six Sigma and other methods like ABC or TQM.Business modelling (more specifically, semantic modelling): enterprise repository andknowledge management.Business organisation: business process optimization and reengineeringInformation systems: city planning innovation using the expected potential of emergingtechnologies, infrastructure optimization…

All these trends – once the hype cycle are matured – have added value for the enterprise. Theirprinciples and technical contents must be rapidly fixed, before the original ideas get distorted byvulgarization and approximation. A simple precaution which should be taken in order to takeadvantage of them consist in placing every procedure on the global map. This way, we specify thelevel of reflection and the path to follow towards implementation. The Enterprise System Topology isthe tool to use for this kind of planning.

Figure 1 represents, using the UML package diagram formalism, the aspects and their organisation.The dashed arrows show the dependency or usage links. Equipped with cartography, managers canorganize projects and skills more easily. Topology handles the System, the object on which we shouldact. The understanding of its structure is a prerequisite for organizing action. From this schema we candeduce the constraints for the different activities, as well as the activities that can be executed inparallel. For instance, the “Y”-life cycle is present in the schema. It is validated by the fact that thelogical and technical aspects are relatively independent.

Public


Figure 113 – Topology of the aspects (view-point) from Praxeme

H.1.2 The SEA « logical » profileIn this model we show how UML is extended to support the SEA logical profile. Note that the referencemetamodel is currently a mix between UML2 and UML1.4 metamodel (for historic reasons) that will befinalized later on UML2. The transposition to UML2 is however straightforward.

All stereotypes are prefixed by “log” for “logical aspect”.

The key notions of the SEA logical profile are :

ServiceService ComponentServiceData

Service components are layered based on predefined layers that can be extended. Predefined kindsof Service Components are:

“Interaction” Component: This kind of Component is not by itself a « service component » butcomplements a service component architecture by providing external (typically « end user »)interaction behaviour. Typically, this kind of component supports the GUI.“Process” Component : supports business processes by providing orchestration betweendifferent components. It typically orchestrates Entity components.“Entity” Component: Provide access and handling of persistent data, of the main entities of asystem. CRUD access are typically provided by these components.“Utility” Components: Components of a wide range of interest, that are used transversally tomany applications.

These kinds of components are layered in the order mentioned below. These four layers arepredefined. Other layers can be defined by the modellers. Layers allow organizing large numbers ofcomponents.

Public


<<extension>>

<<extension>>

<<extension>>

<<extension>>

<<extension>>

<<extension>>

<<extension>><<extension>><<extension>>

<<extension>>

<<extension>><<extension>><<extension>>

<<extension>>

<<extension>>

<<extension>>

logLogicDomain<<stereotype>>

logBusinessComponentOperation<<stereotype>> logInternalActor

<<stereotype>>

logExternalActor<<stereotype>>

logServiceAccessRequired<<stereotype>>

logServiceAccessProvide<<stereotype>>

logInteractionComponent<<stereotype>>

logUtilityComponent<<stereotype>>

logSystemFederation<<stereotype>>

logServiceData<<stereotype>>

logServiceAccess<<stereotype>>

logService<<stereotype>>

logSecondary<<stereotype>>

logProcessComponent<<stereotype>>

logPrimary<<stereotype>>

logLogicAspect<<stereotype>>

logLayer<<stereotype>>

logHabilitation<<stereotype>>

logEntityComponent<<stereotype>>

logEnterprise<<stereotype>>

logDataBase<<stereotype>>

logBusinessComponent<<stereotype>>

Component<<metaclass>>

logSystem<<stereotype>>

logApplication<<stereotype>>

Dependency<<metaclass>>

Package<<metaclass>>

Association<<metaclass>>

Interface<<metaclass>>

Operation<<metaclass>>

Port<<metaclass>>

ObjectFlowState<<metaclass>>

Signal<<metaclass>>

Actor<<metaclass>>

Figure 114 – UML extensions supporting the SEA logical profile

H.1.3 Description

Stereotype Description ExtendedMetaclass orParent stereotype

logApplication An application is a tangibleelement from the end user’sperspective, that gather servicecomponents in order to providea consistent set of services for adedicated business or a specifickind of usage of the system. Anapplication is an assembly ofservice components.

Stereotype “system”

logBusinessComponent Should be called « servicecomponent ». Autonomousbuilding block unit of an SOAsystem. A Service Component

Service“component”

logDataBase Repository gathering severalEntity components. This kind ofcomponent is used to representlegacy systems, that have anexisting repository in whichseveral entity components arestored.

Stereotype “Servicecomponent”

logEnterprise Represents the top systemcomponent, under which allother components areassembled.

Stereotype “system”

logEntityComponent Service component representing Stereotype “Service

Public


a key entity of a system. CRUDservices are typically providedby the component

Component”(BusinessComponent)

logHabilitation Habilitation describe which kindof role is allowed to access towhich kind of service and orservice component

Dependency

logLayer Layers organize systems ofcomponents

Package

logLogicAspect Structure unit of model elementsfor a certain view point on thesystem : the logical view

Package

logPrimary Defines the actor that initiates aUse Case

Association

logProcessComponent Service component thatorchestrates several servicecomponents in order to supporta specific business process


logSecondary Defines an actor participating ina Use Case as a secondary role(not initiating it)

association

logService Service provided by theinformation system, that ispublished, callable through acontract, in order to bemutualised and orchestrated.

Interface

logServiceAccess Entry point of the service. Pointthrough which a servicecomponent is activated toprovide the service

Port

logServiceData Information exchanged betweenservices. This information has tobe independent of the specificimplementations of the serviceproviders and requesters, and tohave a given level of autonomyand usability.

Signal (accidental:could be Class)

logSystem Consistent assembly of Servicecomponents that represents asystem or subsystem of theinformation system.

Component

logSystemFederation Highest level of granularity, thatrepresents the assembly ofsystems to form the root of thesystems representation

Stereotype “System”

logUtilityComponent Kind of Service component thatprovides services for a widerange of usages, usable invarious information systems.

Stereotype “servicecomponent”

logInteractionComponent Service component thatconnects the end user or thirdparty systems to the Service


Public


components of the informationsystem. Typically they supportthe GUI

logServiceAccessProvide Defines the services provided bya service component.

Stereotype “ServiceAccess”

logServiceAccessRequired Defines the services required bya service component.

Stereotype “ServiceAccess”

logExternalActor Actor external to the Informationsystem

Actor

logInternalActor Actor part of the informationsystem

Actor

logLogicDomain Unit of model elementsstructuring within the logicalaspect

Stereotype“LogicAspect”

H.1.4 Examples

Service Component CS<<component>>

CS administration

CS statistics

CS management

Figure 115 – Example of Business component providing three services

Figure 116 – Traceability between Software process, Use Cases and Services

Public


Responsable commercialC lient Marketing Commercial agence

Agence de Voyage<<component>>

:GestionHabilitation

:IHM G Commercia le

:IHM Catalogue

:Paie

:Partenaire

:Gestion Client

:Allocation Séjour

:Facturation

:Gestion Commerciale

:Gestion Cata logue

:Referentie l

Prime

réservation chambre

Maj Séjour

facturer

Enregistrement vente

liste catalogues

gérer habilitation

réservation vol

Maj Client Maj Destination

Figure 117 – Assembly of service components, identification of their interaction with actors

Catalog list<<interface>>

list destinations()

detail destinations()

detail availabilities()

Figure 118 – Service, with a set of service operations

Figure 119 – Habilitation diagram : who can access to a given service

Public


Figure 120 – Example of a service data modelService data can be presented as an information flow diagram, that show how information navigatesbetween different Service Components from a high level perspective.

The UPMS-HA metamodel concepts and definitions for service contracts and service components hasbeen influenced by SEA.

Service UPMS Agents Variability SoaML - STI Innsbruck · APPENDIX B: UPM FOR AGENTS 65 B.1.1 Agent...

Documents

Transcript of Service UPMS Agents Variability SoaML - STI Innsbruck · APPENDIX B: UPM FOR AGENTS 65 B.1.1 Agent...