Deliverable D2.1. Model-driven methodology and architecture specification

Transcription

1 Service and Software Architectures, Infrastructures and Engineering Small or Medium-scale Focused Research Project Semantically-enabled Heterogeneous Service Architecture and Platforms Engineering Acronym SHAPE Project No Flexible Business Models Web Grid Services Service Variability UPMS Agents Semantic Web P2P Services Heterogeneous Platforms Deliverable D2.1 Model-driven methodology and architecture specification Work Package 2 Leading partner: SINTEF Editor(s): Brian Elvesæter, Svein G. Johnsen (SINTEF) Author(s): Leire Bastida, Arne-Jørgen Berre, Brian Elvesæter, Christian Hahn, Svein G. Johnsen, Sebastian Kämper, Mick Kerrigan, Xabier Larrucea, Andreas Limyr, Marcel Muth, Geir Nilsen, Dumitru Roman, Jon Mikel Rubina, Michael Stollberg Dissemination level: Public Date: Version: 1.0 Copyright SHAPE Consortium

2 Versioning and contribution history Version Description Contributors 0.1 Initial outline. Andreas Limyr (SINTEF) 0.2 Added sections on enterprise architecture, method engineering and process frameworks. 0.3 Added sections on methodology and framework analysis. Brian Elvesæter (SINTEF) Arne-Jørgen Berre (SINTEF) 0.4 Formatting and layout. Brian Elvesæter (SINTEF) 0.5 Added sections on the OASIS adaptation blueprint, architectures and methodologies, and agent-oriented methodologies. 0.6 Document restructuring. Added section on ISE from SAP. Geir Nilsen (SINTEF), Jon Mikel Rubina (ESI), Xabier Larrucea (ESI), Marcel Muth (SAP), Christian Hahn (DFKI) Jon Mikel Rubina (ESI), Marcel Muth (SAP) 0.7 Added section on Enterprise Architecture Frameworks. Arne-Jørgen Berre (SINTEF) 0.8 Added section on Ontology Engineering. Mick Kerrigan (STI), Arne- Jørgen Berre (SINTEF) Layout and formatting. Resolved references. Added sections on MAF and ArchiMate Added sections on Variability Modelling. Updated glossary. Resolved remaining references. Minor layout and formatting Restructured report into two parts. Revised introduction. Updated sections on method engineering, state-of-theart analysis, and SHAPE methodology. Added new section on flexible business modelling Rewritten the introduction chapter. Updated the requirements for the SHAPE methodology and the list of method components. Minor revisions to the structure. Brian Elvesæter (SINTEF), Geir Nilsen (SINTEF) Marcel Muth (SAP), Brian Elvesæter (SINTEF), Christian Hahn (DFKI) Brian Elvesæter (SINTEF), Dumitru Roman (STI), Sebastian Kämper (DFKI), Geir Nilsen (SINTEF) Brian Elvesæter (SINTEF) Included the analysis of SAP s enterprise methodology. Marcel Muth (SAP) Removed section on Flexible Business Modelling analysis and on Variability Modelling Technologies. Added sections on analysis of SWS modelling, ESI method, SeCSE composition methodology. Updated section on Variability Modelling Methodologies Moved section on Ontology Engineering Methodologies into section 3. Part II is extracted to a separate Annex Moved sections on OASIS SOA and Open group SOA from Annex to section 3. Updated table of requirements in section 2. Also updated section and Marcel Muth (SAP), Michael Stollberg (SAP), Leire Bastida (ESI), Svein G. Johnsen (SINTEF) Svein G. Johnsen (SINTEF) Svein G. Johnsen (SINTEF) Updates and additions to sections 1, 2 and 4. Svein G. Johnsen (SINTEF) 0.9 Updates and additions to sections 3 and 5, finishing Executive Summary, performing overall walkthrough and spelling check. The report is ready for internal review Svein G. Johnsen (SINTEF) Copyright SHAPE Consortium Page 2 / 114

3 0.9.1 Comments and change requests from internal review incorporated. Marcel Muth (SAP), Svein G. Johnsen (SINTEF) Accepted by internal reviewer Marcel Muth (SAP) 1.0 Final check by TC - Copyright SHAPE Consortium Page 3 / 114

4 Executive summary This report and its Annex [SHAPE 2007a] presents Deliverable D2.1 Model-driven methodology and architecture specification of the SHAPE project. It is the first deliverable of Work Package 2 (WP2), including the results of Tasks T2.1 T2.4 as defined in the Description of Work [SHAPE 2007b]. This deliverable establishes the baseline for the model-driven methodology and architecture specification for SHAPE. The baseline comprises the conceptual foundation of the SHAPE project and the methodology, the approach for the methodology development, the initial requirements to the SHAPE methodology, and the initial set of candidates of existing framework and methodologies to be investigated further for inclusion in the first version of the SHAPE methodology. In the methodology development we adopt a method engineering approach in which a methodology that provides prescriptive guidelines for architecting, designing and implementing an IT system can be seen as a configuration of a set of method components tuned to the particular organisation or IT project at hand. The conceptual foundation for the SHAPE project and its methodology is established by: adoption of concepts derived from OMG s Model Driven Architecture (MDA) [OMG 2003a], i.e. the models of a system at different abstraction levels CIM, PIM and PSM and the transformations CIM2PIM and PIM2PSM i.e. mechanisms to provide conversions between representations of the system on the various levels, and based on results of several earlier projects of the partners and also inspired by others work (e.g. Zachman [Zachman 1987]), we introduce the horizontal dimension enriching the conceptual base with details for each abstraction level, providing separation of the additional areas of concerns (i.e. aspects) such as Ontology, Information, Service, Process, Rules, Organization etc. By elaborating on the conceptual foundation, the initial outline of the SHAPE Reference Matrix is established comprising the dimensions similar to the ones in the conceptual foundation. The SHAPE Reference Matrix is intended to serve as the overall reference framework for the technology components resulting from the SHAPE project, i.e. metamodels, tools and methodology. The SHAPE methodology will combine existing and relevant model-driven development (MDD) and service-oriented architecture (SOA) methods and best practices, and extend it with new method components for architecting, designing and implementing semantically-enabled heterogeneous service architectures (SHAs). As the first step in identifying the initial set of methods and best practices, we performed an comprehensive state-of-the-art analysis of existing and relevant frameworks and methodologies within the categories: Model-driven development (MDD) process frameworks, Enterprise architecture (EA) frameworks and methodologies, Service-oriented development methodologies and frameworks, Agent-oriented methodologies, Semantic Web Service (SWS) modelling, Variability modelling methodologies and Ontology engineering methodologies. The results of the analysis is presented in this report and its Annex [SHAPE 2007a]. From the results of the analysis, we then made a selection of 22 of the frameworks and methodologies based on criteria reflecting the assumed applicability for inclusion in the SHAPE methodology baseline. For each of the selected candidates, the relevance to the SHAPE methodology is expressed by indications in the SHAPE Reference Matrix. In the subsequent deliverable in WP2, D2.2 [SHAPE 2009], we will perform a detailed analysis of the components of the candidate methodologies, and the resulting selection of components will form the base set of method fragments of the SHAPE methodology. Copyright SHAPE Consortium Page 4 / 114

5 Table of contents EXECUTIVE SUMMARY... 4 TABLE OF CONTENTS... 5 TABLE OF FIGURES INTRODUCTION OBJECTIVE OF THIS REPORT ROLE OF THIS REPORT STRUCTURE OF THIS REPORT BASELINE FOR THE SHAPE METHODOLOGY PRELIMINARY The definitions of Method and Methodology Method engineering Process Framework AIM AND APPROACH CONCEPTS AND REQUIREMENTS The conceptual foundation of the SHAPE methodology Requirements for enterprise SOA/SHA methodology STATE-OF-THE-ART ANALYSIS OF SOA AND SHA METHODOLOGIES FRAMEWORK FOR ANALYSING AND COMPARING METHODOLOGIES Notation and language Process (and organisation) Tool support SOA/SHA system result Structure of the state-of-the-art analysis Overview of the frameworks and methodologies that are analysed MODEL-DRIVEN DEVELOPMENT (MDD) PROCESS FRAMEWORKS Overview Eclipse Process Framework (EPF) ENTERPRISE ARCHITECTURE (EA) FRAMEWORKS AND METHODOLOGIES Overview Zachman Framework GERAM (Generalised Enterprise Reference Architecture and Methodology) ARIS (Architecture of Integrated Information Systems) CIMOSA Enterprise Unified Process (EUP) Praxeme Motion SERVICE-ORIENTED DEVELOPMENT METHODOLOGIES AND FRAMEWORKS ISE SOMA (Service-Oriented Modeling and Architecture) COMET-S SAE SMART SOAD (Service-Oriented Analysis and Design) SODA ESI Method SeCSE Composition Methodology SeCSE Methodology Enterprise SOA OASIS SOA Adoption Blueprints The Open Group SOA Ontology AGENT-ORIENTED METHODOLOGIES Copyright SHAPE Consortium Page 5 / 114

6 3.5.1 Overview Gaia PASSI ADELFE Tropos Prometheus SEMANTIC WEB SERVICE (SWS) MODELLING The SWS Approach SWS Frameworks SWS Methodologies VARIABILITY MODELLING METHODOLOGIES FODA FAST FeatuRSEB KobrA ONTOLOGY ENGINEERING METHODOLOGIES Introduction Cyc Methodology Enterprise Ontology - Uschold and King TOVE - Grüninger and Fox METHONTOLOGY - basis for NeOn NeOn Methodology On-To-Knowledge (OTK) Methodology DILIGENT Methodology THE CANDIDATES FOR THE BASELINE SHAPE METHODOLOGY ENTERPRISE ARCHITECTURE (EA) FRAMEWORKS AND METHODOLOGIES Generalised Enterprise Reference Architecture and Methodology (GERAM) ARIS (Architecture of Integrated Information Systems) Enterprise Unified Process (EUP) SERVICE-ORIENTED DEVELOPMENT METHODOLOGIES AND FRAMEWORKS Inter-enterprise Service Engineering methodology (ISE) Service-Oriented Modelling and Architecture (SOMA) COMET-S SAE SMART Service-Oriented Analysis and Design (SOAD) ESI Method (ESIM) The SeCSE composition methodology (SCM) The SeCSE methodology (SM) Enterprise SOA (ESOA) OASIS SOA Adoption blueprints (OASIS) The Open Group SOA ontology (OGSOA) ONTOLOGY ENGINEERING METHODOLOGIES Cyc Methodology Enterprise Ontology - Uschold and King (EONTO) TOVE - Grüninger and Fox METHONTOLOGY - basis for NeOn NeOn Methodology On-To-Knowledge (OTK) Methodology DILIGENT Methodology SUMMARY OF THE RELATIONSHIPS TO THE SHAPE REFERENCE MATRIX CONCLUSION AND OUTLOOK GLOSSARY OF ACRONYMS REFERENCES Copyright SHAPE Consortium Page 6 / 114

7 Table of figures Figure 1: Engineering view of a method Figure 2: The Process Framework in an organisational context Figure 3: Models corresponding to the MDA viewpoints Figure 4: The conceptual model for SHAPE Figure 5: Initial structure of the SHAPE Reference Matrix Figure 6: Methodology reference model Figure 7: Unified process Figure 8: Service-oriented architecture with ESB Figure 9: Detailed operational environment for constructing a system development process Figure 10: GERAM modelling framework with modelling views Figure 11: View concept of ARIS Figure 12: CIMOSA framework for modelling Figure 13: Topology of the aspects (view-point) from Praxeme Figure 14: Microsoft Motion business architecture methodology [Lloyd 2006] Figure 15: ISE Framework Figure 16: SOMA template for SOA [Arsanjani 2004] Figure 17: Activities associated with SOMA methodology [Arsanjani 2004] Figure 18: Main modelling areas Figure 19: SoaML overview Figure 20: Realizing participant Figure 21: Architectural tiers...43 Figure 22: CBDI SAE SOA Reference Framework Figure 23: Analyses of converting the selected components to services Figure 24: The SOAD approach [Zimmermann, et al. 2004] Figure 25: The processes of the SeCSE Composition Methodology Figure 26: SeCSE Methodology Metamodel Figure 27: Enterprise SOA Technology Figure 28: Enterprise SOA Development Lifecycle Figure 29: The OASIS viewpoints Figure 30: The Business via Services view Figure 31: The Realizing SOA view Figure 32: Owning SOA view Figure 33: Various existing agent-oriented methodologies [Sudeikat, et al. 2004] Figure 34: The Gaia metamodel [Bernon, et al. 2004] Figure 35: The PASSI metamodel [Bernon, et al. 2004] Figure 36: The ADELFE metamodel [Bernon, et al. 2004] Figure 37: The Tropos metamodel related to the actor diagram [Susi, et al. 2005] Figure 38: The Tropos metamodel related to the goal diagram [Susi, et al. 2005] Figure 39: The Prometheus metamodel (part 1) [Dam, et al. 2006] Figure 40: The Prometheus metamodel (part 2) [Dam, et al. 2006] Figure 41: From WS to SWS...75 Figure 42: SWS Techniques for Automated Web Service Usage Figure 43: OWL-S Meta Model Figure 44: The WSMO Meta Model Figure 45: SAWSDL Meta Model Figure 46: Classification of Variability Figure 47: The Fast Process Figure 48: Activities in the Uschold and King Methodology Figure 49: Activities in the Grüninger and Fox Methodology Figure 50: Activities in the METHONTOLOGY methodology Figure 51: METHONTOLOGY Conceptualization Sub-activities Figure 52: Activities in the NeOn Methodology Figure 53: The OTK Methodology Knowledge Meta Process Figure 54: The OTK Methodology Knowledge Process Figure 55: Activities in the DILIGENT Methodology Copyright SHAPE Consortium Page 7 / 114

8 Figure 56: The GERAM relationship to the SHAPE Reference Matrix Figure 57: The ARIS relationship to the SHAPE Reference Matrix Figure 58: The EUP relationship to the SHAPE Reference Matrix Figure 59: The ISE relationship to the SHAPE Reference Matrix Figure 60: The SOMA relationship to the SHAPE Reference Matrix Figure 61: The COMET-S relationship to the SHAPE Reference Matrix Figure 62: The SAE relationship to the SHAPE Reference Matrix Figure 63: The SMART relationship to the SHAPE Reference Matrix Figure 64: The SOAD relationship to the SHAPE Reference Matrix Figure 65: The ESIM relationship to the SHAPE Reference Matrix Figure 66: The SCM relationship to the SHAPE Reference Matrix Figure 67: The SM relationship to the SHAPE Reference Matrix Figure 68: The ESOA relationship to the SHAPE Reference Matrix Figure 69: The OASIS relationship to the SHAPE Reference Matrix Figure 70: The OGSOA relationship to the SHAPE Reference Matrix Figure 71: The Cyc relationship to the SHAPE Reference Matrix Figure 72: The EONTO relationship to the SHAPE Reference Matrix Figure 73: The TOVE relationship to the SHAPE Reference Matrix Figure 74: The METHONTOLOGY relationship to the SHAPE Reference Matrix Figure 75: The NeOn relationship to the SHAPE Reference Matrix Figure 76: The OKT relationship to the SHAPE Reference Matrix Figure 77: The DILIGENT relationship to the SHAPE Reference Matrix Figure 78: Summary of the candidate s relationship to the SHAPE Reference Matrix Copyright SHAPE Consortium Page 8 / 114

9 1 Introduction 1.1 Objective of this report This report represents the SHAPE Deliverable D2.1 Model-driven methodology and architecture specification as described in the Description of Work (DOW) [SHAPE 2007b]. The objective of this report is to establish the baseline for the model-driven methodology and architecture specification for SHAPE methodology aligned with the objectives of Work Package 2 (WP2) of the project. WP2 focuses on an integrated tool-supported methodology for designing flexible business systems on heterogeneous SOA platforms. The work package will integrate methodological components such as metamodels and languages (WP3), modelling tools and services (WP4) and model transformations and model deployment (WP5). The objectives of WP2 are: to define a model-based methodology for designing service based landscapes using ShaML to define a methodology and model for management of services through their entire lifecycle to define methods of modelling flexible and reusable processes and services define a methodology for checking compliance between business processes and business contracts to implement the defined method fragments and patterns In this report the baseline for the model-driven methodology is established by defining the aim of the methodology and the approach in which the methodology will be based on, outlining the conceptual foundation for the methodology, and by identifying candidate state-of-the-art methodologies and frameworks to base the SHAPE methodology on. To support the identification of such candidates, a comprehensive state-of-the-art analysis of methodologies considered to be of relevance for SHAPE is performed. The results of the analysis are presented as part of this report, including its Annex [SHAPE 2007a]. 1.2 Role of this report The SHAPE project will define a methodology for model based engineering of Semantically-enabled Heterogonous Service Architectures. This will be done by defining a set of methodology fragments (methods), processes and best practises. The methodology itself will be model based, meaning that the methodology artefacts will be composable to a complete methodology using modelling techniques. The SHAPE project will put its main research efforts in getting a consistent and comprehensive top down approach, which supports service modelling starting from higher models such as goal modelling, requirement modelling, or BPM. Still, the approach will cover the important case of legacy application, which may have or not existing services to incorporate into the global model. The Enterprise Architecture approach will start by getting a model of the existing IS, and defining a migration path toward a modernized SOA based IS. This report describes the initial baseline for defining a model-based methodology for designing service-oriented landscapes and will serve as a conceptual guideline for how to specify, develop and integrate method components into a tool-supported methodology. The methodology will define distributed design principles for SOA, because proper functional layer design and level is crucial to the successful composition of SOA-based systems. The methodology will be layered into viewpoints addressing the specific focus of each kind of stakeholder involved in the development of an SOA based system. The usage of MDA will be emphasised by providing the definition of model transformation between viewpoints, assistance to the analysts & designers, consistency checks, and production of deliverables. The methodology and architecture will be developed iteratively and delivered incrementally with further details presented in forthcoming WP2 deliverables. Copyright SHAPE Consortium Page 9 / 114

10 1.3 Structure of this report This report is structured into the following chapters: Chapter 1 introduces the objective, role and structure of this report. Chapter 2 describes the baseline for the SHAPE methodology, i.e. the aim, the approach, the conceptual foundation and the requirements to the SHAPE methodology. Chapter 3 gives a state-of-the-art analysis of existing SOA and SHA methodologies and frameworks. Chapter 4 gives an overview of the methodologies and frameworks that are candidates to be included in the SHAPE baseline methodology, outlining the relationship between the candidates and the SHAPE Reference Matrix. Chapter 5 concludes the report and provides a short outlook for the continuing work towards the initial version of the SHAPE methodology. The Annex of this report is provided as a separate document [SHAPE 2007a] and provides supplemental information on frameworks and methodologies from the state-of-the-art analysis for further reading. Copyright SHAPE Consortium Page 10 / 114

11 2 Baseline for the SHAPE methodology This section provides an outline of the baseline for the SHAPE methodology. First, the needed definitions of core concepts such as method and methodology are given. Furthermore, the aim of the SHAPE methodology and the approach of methodology development are explained. The conceptual foundation for the SHAPE methodology in terms of the conceptual model for SHAPE is introduced, followed by an outline of the SHAPE Reference Matrix. At the end of the section, the overall requirements to the SHAPE methodology are summed up. 2.1 Preliminary The definitions of Method and Methodology Many different definitions of Method and Methodology can be found in the literature related to software engineering. For some the two terms denote the same concept, while others make a clear distinction between a method and a methodology like we do in the SHAPE project. Generally speaking, a method describes a regular and systematic way of how to accomplish something. In the domain of Information Systems engineering, [Brinkkemper, et al. 1998] defines a method as an approach to perform a systems development project, based on a specific way of thinking, consisting of directions and rules, structured in a systematic way in development activities with corresponding development product. According to [Booch 1991], a method is a rigorous process allowing to generate a set of models describing different perspectives of the system under development by using some well defined notations. From the engineering perspective (see Figure 1), a method is made up of a set of product models and a set of corresponding process models. A product model represents the concepts that are used in the method, relationships between these concepts as well as constraints that they have to satisfy. A process model represents the way to accomplish the development of the corresponding product. Method 1..* 1..* Process Model 1..* 1 Relates to Product Model Figure 1: Engineering view of a method In SHAPE, the term methodology denotes a set or collection of methods and related artefacts needed to support the model driven engineering of SOA based systems in semantically-enabled heterogeneous service architectures (SHAs). Our view on methodology as a collection of methods is aligned with e.g. [Blum 1994]: Methodology: A body of methods, meant to support all software development phases. and with [Estefan 2007] who defines methodology in the context of Model Based Systems Engineering (MBSE) as: A MBSE methodology can be characterized as the collection of related processes, methods, and tools used to support the discipline of systems engineering in a model-based or model-driven context Method engineering Definition The discipline dealing with the design, construction and adaptation of methods, techniques and tools for the development of software and information systems is called Method Engineering. Because of the fact that engineering situations vary considerably from one application system development project to another the traditional systems development methods are often not well suitable. Even though they claim to be universal and propose a large number of models and views for system analysis and specification, they cannot foresee every possible development situation. As a Copyright SHAPE Consortium Page 11 / 114

12 consequence, each software and information systems project requires for a specific method and tool to support the development process. It is clear that traditional method construction techniques are too expensive and time-consuming and are not well appropriate to tackle the project-specific method construction. As a reaction to this problem, the notion of Situational Method Engineering (SME) was first proposed by [Kumar and Welke 1992] as a new method engineering discipline the aim of which is to construct new methods and the associated tools or to adapt the existing ones to every system development project. A number of SME approaches have been already proposed in the literature. Most of them use assembly techniques based on the reuse of existing method parts in the construction of new methods or in the enhancement of existing ones. The process of Situational Method Engineering is based on two core steps: The reengineering of existing methods/models/ideas into reusable method chunks and The engineering of new situation-specific methods by selecting and assembling method chunks Concepts Method chunk. Based on the observation that any method has two interrelated aspects, product and process, several authors propose two types of method components: process fragments and product fragments [Brinkkemper, et al. 1998, Harmsen, et al. 1994]. Other authors consider only process aspects and provide repositories of process components/fragments [Firesmith and Henderson-Sellers 2002]. Method Repository. The prerequisite for modular method construction is a method repository containing a large collection of method chunks. Method Engineering Techniques. Situational Method Engineering deals with assemblybased method construction and adaptation techniques as well as modular method configuration techniques. Supporting Tools. The method construction process requires software support. Computer Aided Method Engineering Tools (CAME) have been designed and developed for this purpose Process Framework A process framework 1 [Firesmith 2008] is a repository of process elements (activities, methods, practices, etc.), patterns, guidance, and constraints on development work products and activities that an organization can use to construct a system development process. It is a structured collection of engineering and management practices enriched with support material such as document templates. It is like a warehouse, offering elements for building processes from which you select what you need, tailor the process elements you have selected, and thereby construct the process that is exactly right for you. 1 Method Engineering Framework is an alternative term. The term Process Framework is more common in the literature though. Either of them is suitable to represent the concepts described here. Copyright SHAPE Consortium Page 12 / 114

13 Figure 2: The Process Framework in an organisational context The responsibility of the method engineer is to identify and orchestrate the activities needed in the development process Figure 2. Based on the organisation s specific needs, the method engineer selects the different process elements, from different process frameworks, and defines an appropriate system development process for an organisation. The method engineer must ensure completeness of the defined system development process, e.g., ensure that roles adopted from the PF are coherent with roles existing within the organisation and so on Aim and approach The overall aim of the SHAPE methodology is to provide a comprehensive methodology for supporting the engineering process for SOA and SHA systems; to provide guidance for all aspects covered by the comprehensive SHAPE technology including proper support for all phases of the overall system engineering process as well as detailed methods for the modelling and development of specific aspects. The SHAPE methodology will be designed as a collection of method chunks along with a generic, toolsupported framework for creating individual, customized methodologies for specific scenarios and specific user needs. Such design will enable composition of a methodology tailored to the specific needs of a user in a given situation, and provide guidance limited to the concerns of the user. Users of an all-embracing methodology with a rigid structure would for the most cases have to consider large amounts of information with no relevance for the users' needs. The task of locating and applying the relevant, useful information could be a challenge of its own.. In the approach for development of the SHAPE methodology we take into account the presence of a lot of existing material for methodological support that will provide a valuable basis for our purposes. Hence, we will establish the base for the SHAPE methodology by reusing, integrating and extending existing methodologies from related areas by performing the following steps: 1. Perform state-of-the-art analysis of relevant, existing methodologies. 2. Identify candidates for reuse in the SHAPE methodology. 3. Perform a detailed analysis of the components of the candidate methodologies, and characterise each method fragment with the respect to the SHAPE conceptual aspects (see section 2.3.1) The resulting selection will form the base set of method fragments of the SHAPE methodology. 2 For an instance of Process Framework applied to MDE see section Copyright SHAPE Consortium Page 13 / 114

14 The results from step 1 and 2 above are presented in this report (section 2 and 4, respectively), while the results of step 3 will be represented in deliverable D2.2 from the SHAPE project [SHAPE 2009]. To enable the aspects of composition and customization of method fragments (method chunks) into individual tailored methodologies, the SHAPE methodology development must also include: provision of a method library for the collection of method chunks. The library will enable easy access to the collection and support development and management of the chunks, and provision of a tool-supported framework for use in maintaining of the method chunks and for composition and customization of the chunks into the tailored methodologies. 2.3 Concepts and requirements The conceptual foundation of the SHAPE methodology Important for the conceptual foundation of the SHAPE project and its methodology are the concepts derived from OMG s Model Driven Architecture (MDA). According to [OMG 2003a] this model-driven system development approach defines the following specific viewpoints of a system: The Computational Independent Viewpoint: focuses on the environment of the system and the requirements of the system; the details of the structure and processing of the system are hidden or as yet underdetermined. o A Computational Independent Model (CIM) is a view of a system from this viewpoint, hiding details of the structure of a system. The Platform Independent Viewpoint: focuses on the operation of the system while hiding the details necessary for a particular platform. A platform independent view shows that part of the complete specification that does not change from platform to platform. o A Platform Independent Model (PIM) is a view of a system from this viewpoint. A PIM exhibits a specific degree of platform independence so as to be suitable for use with a number of different platforms of similar types. The Platform Specific Viewpoint combines the platform independent viewpoint with an additional focus on the detail of the use of a specific platform by a system. o A Platform Specific Model (PSM) is a view of a system from this viewpoint. A PSM combines the specification in the PIM with the details that specify how that system uses a particular type of platform. In SHAPE, we also use the terms CIM, PIM and PSM to denote the abstraction levels corresponding to the associated viewpoints for the models. MDA also includes the artefact of transformation, i.e. a mechanism to provide mappings (i.e. conversions) between representations of the system on different levels. In SHAPE we separate between to kinds of transformations: Model-to-model: A transformation where both the source and the target for the transformation are models. Examples of model-to-model transformations are what we denote as CIM2PIM (a transformation with a CIM model as the source and a PIM model as the target) and PIM2PSM (a transformation with a PIM model as the source and a PSM model as the target). Model-to-text: A transformation where the source is a model and the target is formatted as text (i.e. source code). The models corresponding to the MDA viewpoints are outlined in Figure 3 below. The figure also indicating the transformations between the layers and the example of notations used in the Codelayer. Copyright SHAPE Consortium Page 14 / 114

15 Computational Independent Model CIM Platform Independent Model PIM Platform Specific Model PSM Code BPEL, WSDL, XML, XPDL, OWL-S, WSML, WSDL-S Figure 3: Models corresponding to the MDA viewpoints From results of several earlier projects of the partners and also inspired by others work (e.g. Zachman [Zachman 1987]), we introduce an additional, orthogonal dimension to the structure outlined in Figure 3 above. By this horizontal dimension we enrich the conceptual base with details for each abstraction level, providing separation of the additional areas of concerns (i.e. aspects) into corresponding viewpoints of importance for the model driven software engineering in the context of SOA and SHAs. The following viewpoints are added at the CIM-level: Ontologies (i.e. the terms that are used to express the concepts in the domain and their relations), business processes (i.e. the end to end processes that are necessary to realize the business goals), business rules (i.e. the conditions that govern and constrain legal behaviour and structure), goals (i.e. the goals that the business seeks to realize and is used to identify success or failure), NFA and quality (i.e. Non-Functional Aspects with quality principles like security, reliability, performance, integrity and many more), and organisational aspects (i.e. the organisation units, roles, positions or resources involved). Moving downwards to the PIM-level, the horizontal dimension reveals the PIM-viewpoints corresponding to the ones at the CIM-level: Information (dealt with by the business objects), processes (activities needed for achieving certain goals) services (capabilities offered by service providers that can be accessed by consumers via standardized interfaces.) Copyright SHAPE Consortium Page 15 / 114

16 rules (conditions for the usage of a service or process) non-functional-aspects (e.g. quality-of-service, security, SLAs, etc.), and UI (Use interfaces, i.e. the artefacts needed in the user interfaces of the system). At the PSM-level, the corresponding viewpoints are: Data (corresponding to Information at the PIM-level), workflow / process components (corresponding to processes at the PIM-level) interfaces (corresponding to services at the PIM-level) rules (corresponding to the PIM-level rules) non-functional-aspects (corresponding to the NFAs at the PIM-level), and UI (corresponding to the PIM-level UI). Having introduced the additional viewpoints at each level, it is also important to consider how the concepts within each viewpoint are related to concepts in other viewpoints as such relationships must be reflected in the design of the transformations. Finally, at the CODE-level, the horizontal refinement specifies the technologies by which the corresponding aspects could be realized. We consider the conceptual space spanned by the two dimensions to be the conceptual foundation, or the conceptual model, for the SHAPE project. The model is outlined in Figure 4 below. Examples of notations and languages to be used at the various levels are indicated to the right. CIM Ontologies Bus.Process Bus.Rules Goals NFA/Qualities Org BPMN, POP*, ARIS, ArchiMate, GERAM, GRAI, Zachman, UEML, B.Rules... PIM Information Process Services Rules NFA UI PSM Data Wflow/Comp Interfaces Rules NFA UI UML profiles and metamodels for BPEL, WSDL, XML, XPDL, OWL-S, WSML, WSDL-S Technologies/Realisation XML, BPEL/XPDL, WSDL, SWRL, Security, AJAX OWL, OWL-S/WSML WSDL-S, Induction, QoS Legacy and New systems/services, ERPs/ESAs Technology Reliastion Code Figure 4: The conceptual model for SHAPE By elaborating on the conceptual model outlined in Figure 4 above, we have established the first version of what we denote as the Reference Matrix for the SHAPE project. The matrix is intended to serve as the overall reference framework for the technology components resulting from the SHAPE project, i.e. metamodels, tools and methodology. Copyright SHAPE Consortium Page 16 / 114

17 The matrix is based on the same two dimensions as the conceptual model; the abstractions levels CIM, PIM and PSM with the intervening transformations along the vertical dimension, and the separation of concerns (denoted as aspects) along the horizontal dimension. The aspects are the following: Information (data or information dealt with by the business objects) Services (capability offered by service providers that can be accessed by consumers via standardized interfaces) Process (activity needed for achieving certain goals) Rules (conditions for the usage of a service or process) Events (occurrences or happenings that trigger an activity e.g. invocation or termination of a service or a process) Organization (i.e. the organization units, roles, positions or resources involved in the organization where the system is to be deployed) Goals (i.e. the goals that the business seeks to realize and is used to identify success or failure) Non-functional-aspects (e.g. quality-of-service, security, SLAs, etc.) UI (Use interfaces, i.e. the artefacts needed in the user interfaces of the system). Each elements of the matrix provides a placeholder for SHAPE result related to one aspect and one abstraction level / transformation, e.g. the element upper right would be the reference point for SHAPE results of relevance for CIM for the aspect of NFA (Non-functional-aspects). An outline of the initial version of the matrix is rendered Figure 5 in below. LEVEL ASPECT Information Service Process Rules Events Organization Goals NFA CIM CIM2PIM PIM PIM2PSM PSM Figure 5: Initial structure of the SHAPE Reference Matrix The SHAPE Reference Matrix will be defined in detail in the subsequent deliverables of WP 2, along with the content specification of the initial version of the SHAPE methodology Requirements for enterprise SOA/SHA methodology Requirements engineering (RE) is a field that searches for solutions for identifying, specifying, analyzing, validating, communicating and negotiating of requirements. Requirements change with time because of changes in user needs and platforms, and RE is therefore also about impact analysis and managing of changes. Traditionally, RE has struggled to solve problems of tracing business requirements to implementations and validating them, especially for the non-functional ones. SOA may solve these challenges by mapping business goals and requirements to services and services into the platform specific models. SOA views the system as services with constraints and nonfunctional properties that may be composed and thus provides a methodology to break down the requirements. Keeping traces of this mapping in the transformer is also a contribution of the proposal. Copyright SHAPE Consortium Page 17 / 114

18 The expected results of the project will be an integrated, tool-supported model-driven methodology for extended SOA. The extensions will be based on a standardised metamodel that we will participate in, and rooted in service-oriented methodologies from previous projects, like SeCSE (ESI-TECNALIA), COMET (SINTEF) and others. MDE is a paradigm for engineering of software, and is not a software development methodology as such. Work was done in the MODELWARE project on what was needed from a methodology or process to support MDE. It was generally found that existing methodologies that have models as artefacts are usable in a MDE setting. Typically some new artefacts (such as transformations and metamodels) and process steps (such as transformations) may have to be introduced into the existing processes. Since one in a MDE setting potentially will have to work with a set of different model types, and this set may change from project to project, methods and best practises for the model type at hand should be easily accessible. A process for a project may have a different set of model types (and method support) than a process for another project. Standards for the definition of software processes and methodologies exist today, SPEM is one example of such. Table 1: Requirements for enterprise SOA/SHA methodology Requirement name Business and IT architecture alignment Delivery strategy Incremental delivery Lifecycle coverage Clear roles and responsibilities Model-based Description There exist three common strategies in delivering a SOA: 1. The top-down strategy is closely tied to an organizations existing business logic, from which required services are derived. 2. The bottom-up strategy is the opposite in that it focuses on legacy systems, and Web services are built on an asneeded basis. 3. The meet-in-the middle (agile) strategy finds a balance between incorporating service-oriented design principles into business analysis environments without having to wait before integrating Web services technologies into technical environments. The methodology should support incremental delivery of the resulting work products Some proposed approaches aim to support the full SOA lifecycle, including planning, analysis and design, construction, testing, deployment, and governance activities, while others limit their scope to a subset of these phases, such as analysis and design. (Conception Inception Elaboration Construction Transition Operation Termination) A service-oriented methodology may support the provider view, the consumer view, or both the provider and consumer views in an integrated framework. In the consumer s view, development is declarative and business process oriented through service composition, while in the provider s view it is programmatic and component oriented. The methodology-support should be in compliance with the MDA principles. Copyright SHAPE Consortium Page 18 / 114

19 Use standard modelling languages Tool support Explain when and where to use different SHA technologies Shared information and semantics (business documents IT information models) Application integration Service reuse and governance Versioning Management (SLAs, monitoring, ) Include best practices Degree of prescription Process agility Adoption of existing processes/techniques/notation Industrial application The methodology should support the use of SoaML, BPMN 2.0, BMM. The methodology should be supported by tools based on ECLIPSE. The methodology should provide guidance on where and when to use the different SHA technologies dependent on the context of the task, e.g. the level of abstraction, the area of concern, the realisation platform etc. The methodology should support sharing of information and semantics between business documents and IT information models. The methodology should support integration of services with existing applications and systems. The methodology should support reuse of services in different contexts and by multiple users. The methodology should support for evolution of models. The methodology should support management of services, such as SLA, monitoring, Best practices for the various tasks should be easy accessible. SOA methodologies range from the most prescriptive ones that specify phases, disciplines, tasks, and deliverables for each of them, while others provide less detail, by purpose or not, leaving room for more flexibility and tailoring of the approach depending on the project context. A number of methodologies suggest an agile approach to Service Oriented development in order to address risks and add flexibility to change. Yet, some others follow a more rigid approach in the process lifecycle, or do not address the issue of agility at all. A large number of SOA methodologies propose reusing proven existing processes like XP and RUP,and techniques like OOAD, CBD, and BPM, seeing service-oriented development as an evolutionary rather than revolutionary step in software engineering. Also standardized notations, such as UML and BPMN, are being adopted to visually model various artefacts. It is important that a methodology be validated in proof-ofconcept case studies to show that it has practical applicability and to refine it based on feedback from the case studies. Unfortunately, most of the existing SOA methodologies are at an early stage and have not been applied yet in industrial projects. Copyright SHAPE Consortium Page 19 / 114

20 Metadata Administrati on Accessibility Identity Metadata Administrati on Accessibility Identity Public 3 State-of-the-art analysis of SOA and SHA methodologies This section describes the state-of-the-art analysis of existing SOA and SHA methodologies considered for the baseline SHAPE methodology. 3.1 Framework for analysing and comparing methodologies This section looks at the different methodologies that is aimed to support service-oriented architectures. To get some level of comparison the analysis will take the methodology reference model found in Figure 6 in account. Presentation and interaction Functional and core services Tasks and processes Enterprise Service Bus (ESB) Information fabric Registr y/ reposit ory Tools Enterprise modeling tools System modeling tools Programming tools, IDE CIM PIM PSM Notation& Language (i.e BMM, BPMN, UPMS, JEE, WS, - artifacts, metamodel) Process (discipline, phases, roles) -SPEM Business System Implementation PIM-K PSM-K SOA/SHA system Phases Process Components Inception Elaboration Construction Transition Requirements Analysis Architecture Level Design Class Level Implementation Test Supporting Components Project Management Process Configuration preliminary iter. iter. iter. iter. iter. iter. iter. iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1 Iterations Presentation and interaction Tasks and processes Enterprise Service Bus (ESB) Functional and Information core services fabric Registr y/ reposit ory Figure 6: Methodology reference model In the context of SHAPE we are interested in looking at methodologies that focus on the development of SOA and SHA systems. We have chosen to compare these using 4 different dimensions. Notation and language. Process and organisation. Tool support. SOA/SHA system result Notation and language The approach for describing the notation and the language is based on the needs derived from a service-oriented reference architecture and the areas of concern of an MDA (Model Driven Architecture) framework: CIM, PIM and PSM. The SOA Reference model provides us with the following areas of concern: Information, Process, Services, Rules, NFA and UI. With the focus on this we will look on which areas from CIM are provided and required to help to derive models to the PIM level, and how the PIM level is used as a basis for further mappings and transformations to the PSM level. Copyright SHAPE Consortium Page 20 / 114

21 3.1.2 Process (and organisation) By process, we mean the steps of the actions that are undertaken during the development. We will use the generic two-dimensional framework of phases and disciplines/workflow introduced for the description of the Unified Process [Jacobson and Rumbaugh 1999], but extendable to other methodology process description by changing the names and the contexts of phases and disciplines Tool support Figure 7: Unified process The tools are typically provided through an integrated environment, termed a Software factory or Development studio or Integrated Development Environment (IDE), and might be based on different architectural patterns SOA/SHA system result We illustrate the SOA/SHA system result with an SOA/SHA pattern, but assume that in many cases another architectural approach will have been used. In SHAPE, our aim is to use the SOA/SHA architectural pattern both for the SHAPE MDE toolset as well as for the target systems that will be created. Copyright SHAPE Consortium Page 21 / 114

22 Figure 8: Service-oriented architecture with ESB Structure of the state-of-the-art analysis The existing frameworks and methodologies are inspected in a free manner. This allows us to provide a sophisticated overview of the framework with respect to its specific characteristics. However, for each examined approach we will collect the following information, which is relevant for the further analysis that will be conducted for developing the SHAPE Methodology: Name of methodology/framework. Name of provider. Short description of the methodology/framework. Short description of the maturity of the methodology/framework. SOA/SHA system result (see above) Notation and language (see above) Process (and organisation) (see above) Tool support (see above) Overview of the frameworks and methodologies that are analysed Frameworks and methodologies within the following areas constitute the foundations for the development of a new method engineering framework for SHAPE: Model driven development (MDD) process frameworks. Enterprise architecture (EA) frameworks and methodologies. Service-oriented development methodologies and frameworks. Agent-oriented methodologies. Semantic Web Service (SWS) modelling frameworks and methodology. Variability modelling. Ontology engineering methodologies. Table 2 gives an overview of the frameworks and methodologies that are analysed. Detailed descriptions of each follow in the sections below. Copyright SHAPE Consortium Page 22 / 114

23 Table 2: Overview of methodologies/frameworks analysed Area Model-driven development (MDD) process frameworks Enterprise architecture (EA) frameworks and methodologies Serviceoriented development methodologies and frameworks Agentoriented methodologies Semantic Web Service (SWS) modelling frameworks and methodology Variability modelling Framework and methodology analysed Eclipse Process Framework (EPF) Error! Reference source not found. Zachman Framework GERAM (Generalised Enterprise Reference Architecture and Methodology) ARIS (Architecture of Integrated Information Systems) CIMOSA Enterprise Unified Process (EUP) Praxeme Motion ISE SOMA (Service-Oriented Modeling and Architecture) COMET-S SAE SMART SOAD (Service-Oriented Analysis and Design) SODA ESI Method SeCSE Composition Methodology SeCSE Methodology Enterprise SOA OASIS SOA Adoption Blueprints The Open Group SOA Ontology Gaia PASSI ADELFE Tropos Prometheus OWL-S The Web Service Modeling Ontology WSMO Semantic Web Services Framework (SWSF) Semantic Annotations for WSDL (SAWSDL) An Initial Methodology The Web Service Modeling Toolkit (WSMT) FODA FAST FeatuRSEB KobrA Copyright SHAPE Consortium Page 23 / 114

24 Ontology engineering methodologies Cyc Methodology Enterprise Ontology - Uschold and King TOVE - Grüninger and Fox METHONTOLOGY - basis for NeOn NeOn Methodology On-To-Knowledge (OTK) Methodology DILIGENT Methodology 3.2 Model-driven development (MDD) process frameworks Overview In order to support the MDD approach to software development we need standards to support the description of enterprise and domain models, as well as technical models at the platform-independent and platform-specific levels. Furthermore we need standards for the management and transformation of such models. Fortunately OMG provides a set of specifications that are publicly available at The core set of MDA technology standards are: Table 3: Core set of OMG MDA technology standards Technology Unified Modeling Language (UML) Meta Object Facility (MOF) XML Metadata Interchange (XMI) MOF Queries / View / Transformations (QVT) Software Process Engineering Metamodel (SPEM) Common Warehouse Metamodel (CWM) Description UML 2.0 [OMG 2003c, OMG 2003d] is the de-facto standard industry language for specifying and designing software systems. MOF 2.0 [OMG 2004] provides the standard modelling and interchange constructs that are used in MDA. These constructs are a subset of the UML modelling constructs. XMI 2.1 [OMG 2005c] is a format to represent models in a structured text form. In this way UML models and MOF metamodels may be interchanged between different modelling tools. QVT 2.0 [OMG 2005b] provides a standard specification of a language suitable for querying and transforming models which are represented according to a MOF metamodel. SPEM 1.1 [OMG 2005a] provides a standard for representing software development methods. CWM 1.1 [OMG 2003b] is the OMG data warehouse standard. It covers the full life cycle of designing, building and managing data warehouse applications and supports management of the life cycle. The MDD PF focuses on what is specific to model-driven development, such as modelling work products at the PIM and PSM levels separately, model building and model checking activities, model transformations, usage and management of modelling resources, etc. The MDD Process Framework should integrate in a consistent way with other process frameworks, allowing reuse of existing experience and therefore lowering required investment. This way, it will support the extension and revision of the company s processes and support the inclusion of MDDspecific practices into the organisation s development process. The MDD PF focuses on what is specific for model-driven development, such as model work products with distinctions between the PIM and PSM levels, model building and model checking activities, model transformations, usage and management of modelling resources, etc. Copyright SHAPE Consortium Page 24 / 114

25 Figure 9 provides an overview of the steps to follow when using the MDD PF. These steps and the elements identified in the operational environment of the MDD PF are used to detail the usage of the process framework. Note that actors identified below denote roles; hence one person may perform many roles at the same time: The method engineer builds a system development process based on process elements from the MDD PF and other process frameworks. The project manager adapts the system development process to the project-specific context. The system development team uses the process adapted to the specificities of the system development process to build the system. Lastly, the method engineer, the application designer and the project manager should provide feedback to the knowledge engineer for the modification, deletion or insertion of new process elements in the process frameworks. This final task allows maintaining an updated source of knowledge within the organisation. Figure 9: Detailed operational environment for constructing a system development process The major benefit of using the MDD PF is that the organisation establishes a common frame of reference, in other words, a common MDD information resource containing the knowledge of current practices of MDD. Organisations will benefit directly from a knowledge database of experiences of MDD adoption, by reducing the effort they would otherwise have to spend understanding and adapting MDD to their specific context Eclipse Process Framework (EPF) The Eclipse Process Framework (EPF) [eclipse.org 2008] project has two goals: To provide an extensible framework and exemplary tools for software process engineering - method and process authoring, library management, configuring and publishing a process. Copyright SHAPE Consortium Page 25 / 114

26 To provide exemplary and extensible process content for a range of software development and management processes supporting iterative, agile, and incremental development, and applicable to a broad set of development platforms and applications Notation and language The SPEM metamodel defines typical concepts of a process (process, phase, role, model, etc) that can be used to construct models that describe software engineering process. This metamodel has been recently approved (April 2008) as a formal specification at the Object Management Group [OMG 2008]. Concept Notation Description Activity Artifact CapabilityProcess ContentPackage DeliveryProcess Guidance Phase Process Team Profile Role RoleUse (Compatibility with SPEM1.1 ) Table 4: SPEM 2.0 concepts Activity is a work breakdown element and work definition. It describes a piece of work performed by one ProcessPerformer: the tasks, operations, and actions that are performed by a role or with which the role may assist. An Activity may consist of atomic elements called Steps. It is a work product definition. It is used to define tangible work products. One artefact could be composed by other artifacts. This feature is very useful in order to identify parts and the whole. CapabilityProcess represents a process component. This element is defined only once and it can be reused in several situations and processes This element is used to structure the method content and the library. DeliveryProcess represents a final process that will be published. Guidance elements may be associated with ModelElements, to provide more detailed information to practitioners about the associated ModelElement. Possible types of Guidance depend on the process family and can be for example: Guidelines, Techniques, Metrics, Examples, UML Profiles, Tool mentors, Checklist, Templates. A Phase is a specialization of WorkDefinition such that its precondition defines the phase entry criteria and its goal (often called a "milestone") defines the phase exit criteria. Phases are defined with the additional constraint of sequentiality; that is, their enactments are executed with a series of milestone dates spread over time and often assume minimal (or no) overlap of their activities in time. A Process is a special Activity that describes a structure for particular types of developments. TeamProfile represent a set of roles. Usually it is used to gather roles with particular mission. A Role is a ProcessPerformer and it defines a performer for a set of WorkDefinitions in a process. ProcessPerformer has a sub-class, ProcessRole. RoleUse is related to a specific task descriptor. Defines responsibilities over specific WorkProducts, and defines the roles that perform and assist in specific activities. (called Copyright SHAPE Consortium Page 26 / 114

27 Task TaskDescriptor Template RoleDescriptor in EPF) Usually one of the primary tasks during the construction of a methodology it is to define the main tasks within method content. This element is the relationship with a task defined in method content. SPEM2.0 and EPF help users to define their templates and thus they are used univocally Tools The Eclipse Process Framework is a method engineering platform that implements the Software Process Engineering Metamodel (SPEM 2.0). 3.3 Enterprise architecture (EA) frameworks and methodologies Overview We define a framework as a fundamental structure which allows defining the main sets of concepts to model and to build an enterprise. This section describes two types of frameworks: those for integrating enterprise modelling (such as Zachman, CIMOSA, etc.) and frameworks for integrating enterprise applications (such as ISO 15745, the MISSION approach, etc.). The dominant Enterprise Modelling Frameworks and Architectures that are being pursued by industry and interest organisations are: The Zachman Framework from the Zachman Institute for Architecture The GERAM Framework from ISO IS 15704:2000 (The University of Brisbane) The GRAI Framework from GRai Lab and Graisoft ARIS (Architecture of Integrated Information Systems) The CIMOSA Framework from CIMOSA GmbH The DoDAF Architecture Methodology from the FEAC Institute [The United States Department of Defense] The MODAF Architecture Methodology from UK Ministry of Defence The NAF NATO Architectural Framework methodology from NATO TOGAF Architecture Methodology from the Open Group The TEAF Methodology from the US Dept. of Commerce The Troux Enterprise Architecture Framework Zachman Framework When it comes to enterprises the Zachman Framework [Zachman 1987, ZIFA] is simply a logical structure for classifying and organising the descriptive representations of an enterprise that are significant to the management of the enterprise as well as to the development of the enterprise s systems. The diagrams of the Framework in its most simplistic form depicts the design artefacts that constitute the intersection between the roles in the design process, that is, OWNER, DESIGNER and BUILDER; and the product abstractions, that is, WHAT (material) it is made of, HOW (process) it works and WHERE (geometry) the components are, relative to one another. These roles are somewhat arbitrarily labelled PLANNER and SUB-CONTRACTOR and are included in the Framework graphic that is commonly exhibited. From the very inception of the Framework, some other product abstractions were known to exist because it was obvious that in addition to WHAT, HOW and WHERE, a complete description would Copyright SHAPE Consortium Page 27 / 114

28 necessarily have to include the remaining primitive interrogatives: WHO, WHEN and WHY. These three additional interrogatives would be manifest as three additional columns of the models that, in the case of Enterprises, would depict: WHO does what work, WHEN things happen and WHY various choices are made. A balance between the holistic, contextual view and the pragmatic, implementation view can be facilitated by a framework that has the characteristics of any good classification scheme, that is, it allows for abstractions intended to: simplify for understanding and communication, and clearly focus on independent variables for analytical purposes, but at the same time, maintain a disciplined awareness of contextual relationships that are significant to preserve the integrity of the object GERAM (Generalised Enterprise Reference Architecture and Methodology) GERAM (version 1.6.2) encompasses all knowledge needed for enterprise engineering / integration. Thus, GERAM is defined through a pragmatic approach providing a generalised framework for describing the components needed in all types of enterprise engineering/enterprise integration processes, such as: Major enterprise engineering/enterprise integration efforts (green field installation, complete reengineering, merger, reorganisation, formation of virtual enterprise or consortium, value chain or supply chain integration, etc.); Incremental changes of various sorts for continuous improvement and adaptation. GERAM is intended to facilitate the unification of methods of several disciplines used in the change process, such as methods of industrial engineering, management science, control engineering, communication and information technology, i.e. to allow their combined use, as opposed to segregated application. GERAM provides an analysis and modelling framework which is based on the life-cycle concept and identifies three dimensions for defining the scope and content of enterprise modelling. Life-Cycle Dimension: providing for the controlled modelling process of enterprise entities according to the life-cycle activities. Genericity Dimension: providing for the controlled particularisation (instantiation) process from generic and partial to particular. View Dimension: providing for the controlled visualisation of specific views of the enterprise entity. Copyright SHAPE Consortium Page 28 / 114

29 Figure 10: GERAM modelling framework with modelling views Figure 10 shows the three dimensional structure identified above which represents this modelling framework. The reference part of the modelling framework itself consists of the generic and the partial levels only. These two levels organise into a structure the definitions of concepts, basic and macro level constructs (the modelling languages), defined and utilised for the description of the given area. The particular level represents the results of the modelling process - which is the model or description of the enterprise entity at the state of the modelling process corresponding to the particular set of lifecycle activities. However, it is intended that the modelling languages should support the two-way relationship between models of adjacent life-cycle phases, i.e. the derivation of models from an upper to a lower state or the abstraction of lower models to an upper state, rather than having to create different models for the different sets of life-cycle activities ARIS (Architecture of Integrated Information Systems) The Enterprise Modelling approach of ARIS [Scheer 1994] is based on a view concept. The objective is to reduce the complexity by dividing the enterprise into individual views. In order to model the different views, different modelling languages are allocated to them, e.g.: Organisational charts, network diagram or shift calendars to the Organisational View. Function trees, objective diagram or application system diagram to the Function View. Entity Relationship Model (ERM), attribute allocation diagram or class diagram to the Data View. Product tree to the Product View. The integration of the different languages is done by the Control View. This combination process is done for two reasons. First, the structural relationships between the views are described and second, status modifications are explained that show the dynamic behaviour of the system. Languages used there are, e.g., Event-driven Process Chain (EPC), function allocation diagrams or value-added chain diagram. Copyright SHAPE Consortium Page 29 / 114

30 If there is the need to add a new object, this object can be defined including its attributes and then allocate this to the ARIS object list. Additional to this, the relationships of the new object to the existing ones have to be defined. After this it is necessary to assign the new object to one of the external ARIS views. A new method is generated by choosing the needed objects. If the chosen objects belong to different views, the new method is automatically allocated to the Control View. If they all belong to the same view, the new method would be assigned to the same one. Figure 11: View concept of ARIS The advantage of this procedure is on one hand the extensibility of the actual object and method list. So, new requirements to existing methods can easily be realised. On the other hand, the disadvantage is the huge amount of already existing methods and objects in ARIS which doesn t support the usability. In the future, extensibilities will only be done if this would cause benefit either to the usability or to the customer benefit. At the moment, it is possible to reduce the amount of methods by setting up filters to fade out unneeded methods or objects. ARIS has been developed by Prof. Scheer at the University of Saarbrucken in Germany. The conceptual design of the Architecture of integrated Information Systems (ARIS) is based on an integration concept which is derived from a holistic analysis of business processes. The first step in creating the architecture calls for the development of a model for business processes which contains all basic features for describing business processes. The result is a highly complex model which is divided into individual views in order to reduce its complexity (see Figure 11): Function view: The processes transforming input into output are grouped in the function view. The designations function, process and activity are used synonymously. Due to the fact that functions support objectives, yet are controlled by them as well, objectives are also allocated to the function view. In application software, computer-aided processing rules of a function are defined. Thus, application software is closely aligned with functions, and is also allocated to the function view. Organisation view: The organisation view presents the hierarchical organisation structure. It is created in order to group responsible entities or devices executing the same work object. This is why the responsible entities human output, responsible devices, financial resources and computer hardware are allocated to the organisation view. Copyright SHAPE Consortium Page 30 / 114

31 Data view: The data view comprises the data processing environment as well as the messages triggering functions or being triggered by functions. Preliminary details on the function of information systems as data media can be allocated to data names. Information services objects are also implicitly captured in the data view. However, they are primarily defined in the output view. Output view: The output view contains all physical and non-physical input and output, including funds flows. Control view/process view: This view displays the respective classes with their view-internal relation-ships. Relationships among the views as well as the entire business process are documented in the control or process view, creating a framework for the systematic inspection of all bilateral relationships of the views and the complete process description. To evaluate ARIS according to the requirements described in section 2.3.2, we will try to identify the different parts of the methodology and its position in the reference architecture. The ARIS methodology is taking a top down approach to describe and model the business service architecture. That means we start the analysis with respect to the architectures CIM level. The ontology could be modelled in a Technical term diagram, but also the repository of all objects created is in a wide sense also a part of the Ontology. The goals aspect is supported by SCORE card analysis and is described in e.g. KPI diagrams. For modelling the business processes, ARIS provide the Value Added Chain (VAC) and Event Driven Process chain (EPC) diagrams. The EPC diagram is the core diagram in which many of the relations are defined. To precisely describe a business rule and relating it to a decision, ARIS is using a familiar spreadsheet-like interface and connecting the business rule to the process in the EPC diagram. To model the organisation and its units, positions, roles and resources, ARIS provides an organisational chart diagram which objects are available in the EPC diagram. They could be connected to the process with various types of relations. Table 5: ARIS notation table Aspect Ontology Goals Process Services Rules NFA/Quality Organisation ARIS Diagrams Term Diagram KPI diagram VAC/EPC Service diagram Spreadsheet/EPC Related to goals Organisational chart CIMOSA CIMOSA [ESPRIT 1993] was developed under the framework of the European Union ESPRIT research programme. It results from the consortium AMICE (European CIM Architecture). The first objective of CIMOSA is to provide a framework to analyse the evolving requirements of an enterprise and translating these into a system which enables and integrates the functions that match the requirements. Copyright SHAPE Consortium Page 31 / 114

32 Figure 12: CIMOSA framework for modelling The CIMOSA framework (Figure 12) has three dimensions which are: A dimension of instantiation (three architectural levels) composed by: o o o A generic level which is a catalogue of basic building blocks. A partial level which is a library of partial models applicable to particular purposes. A particular level which is a model of a particular enterprise built from building blocks partial models. A dimension of model (three modelling levels) composed by: o o A requirements modelling for gathering business requirements. A design modelling for specifying optimised and system-oriented representation of the business requirements. o An Implementation modelling for describing a complete CIM system and all its implemented components. A dimension of view (to describe the model according to its four integrated aspects) composed by: o A function view for describing the expected behaviour and functionality of the enterprise. o o o An Information view for describing the integrated information objects of the enterprise. A resource view for describing the resource objects of the enterprise. An organisation view for describing the organisation of the enterprise. CIMOSA is only a framework for structuring enterprise modelling related issues. It addresses concepts Copyright SHAPE Consortium Page 32 / 114

33 and models that are necessary to model integrated enterprise systems focusing on process modelbased enterprise activity control Enterprise Unified Process (EUP) Enterprise Unified Process (EUP) [EUP] is an extension to the RUP. People familiar with RUP can see that the extensions include two new phases, Production and Retirement, and several new disciplines: Operations and Support and the seven enterprise disciplines: Enterprise Business Modelling. Portfolio Management. Enterprise Architecture. Strategic Reuse. People Management. Enterprise Administration. Software Process Improvement Praxeme Praxeme [Praxeme Institute] is an open initiative that aims to provide a methodology to support the entire system representation and implementation activity, ranging from the stakeholders view and goals down to its realization and deployment. The Praxeme methodology defines models and representations for all aspects of the enterprise. It carefully organizes them in order to be able to integrate them within a coherent workflow, which goes from strategy to implementation. It also specifies modelling techniques, organized around a common core and specialized according to the aspect being described. The modelling techniques benefit from the UML standard and are explicitly orientated towards communication. Aspect Semantically Equivalent terms Conceptual, Essential, Business Model Pragmatically Organizational Geographical Communication, Environment Table 6: Aspects of the Enterprise System Definitions The semantic aspect is only concerned with those objects that make up the essence of the business activity. Only the knowledge is described and is represented independently to the way the business is actually performed. The pragmatic aspect describes the way business activities are performed: actors, responsibilities, actions on objects, process, and work contexts. The geographical aspect models the location of objects and actions. It shows concepts such as sites, locations and communication requirements. Logical Functional Intermediate aspect where decisions are be taken on the most important structures of the information system, in a way that is relatively independent from technical solutions. Technical Technological The technical aspect is concerned with the choice of technologies and the way they are implemented. Hardware Logistical The hardware aspect features all physical hardware of which the system is composed, with all their properties (capacity, interoperability, cost, etc.). Examples of hardware are PCs, telephones, fax machines, sensors etc. Copyright SHAPE Consortium Page 33 / 114

34 Software Applicative The software aspect displays all software components which automate 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 and knowledge management. Business organization: business process optimization and reengineering. Information systems: city planning innovation using the expected potential of emerging technologies, infrastructure optimization. All these trends once the hype cycle is matured have added value for the enterprise. Their principles and technical contents must be rapidly fixed, before the original ideas get distorted by vulgarization and approximation. A simple precaution which should be taken in order to take advantage of them consists in placing every procedure on the global map. This way, we specify the level of reflection and the path to follow towards implementation. The Enterprise System Topology is the tool to use for this kind of planning. Figure 13 represents, using the UML package diagram formalism, the aspects and their organization. The dashed arrows show the dependency or usage links. Equipped with cartography, managers can organize projects and skills more easily. Topology handles the System, the object on which we should act. The understanding of its structure is a prerequisite for organizing action. From this schema we can deduce the constraints for the different activities, as well as the activities that can be executed in parallel. For instance, the Y -life cycle is present in the schema. It is validated by the fact that the logical and technical aspects are relatively independent Motion Figure 13: Topology of the aspects (view-point) from Praxeme Microsoft has developed the Motion methodology which is an architecture (patent-pending) to expose business models from organization. Motion [Lloyd 2006] is peculiar in the sense that it is technology- Copyright SHAPE Consortium Page 34 / 114

35 agnostic and mostly acronym-free. The principle of the approach is to identify capabilities as a basis for stable projects. The underlying architecture abstracts processes and focuses on business capabilities. This allows constructing an established view of businesses. The constructed view of an organization (i.e. the Motion Business Architecture) directs a fast decision making that is otherwise hard to reach. Capabilities answer to questions related to what the business is doing and are independent from the business implementation ( how ) of functions. The main artefact of the methodology is the capability map illustrated in Figure 14 and includes the following operational capabilities: Develop products/services. Generate demand for products/services. Produce/deliver products/services. Plan and manage the business. Collaborate with constituencies. Customer-facing channel partners Customers 1. Develop product or service 2. Generate demand 5. Collaboration 3. Fulfil Demand Request Resources 4. Plan and 3.1 Provide 3.3 Procure resources Create manage Service Sourcing and Supplier Contract Management the purchase enterprise Purchasing Advanced requisitions Planning 3.4 Produce Product 3.5 Logistics Business partners IT providers Financial service providers Figure 14: Microsoft Motion business architecture methodology [Lloyd 2006] The architecture includes interfaces with the following environmental stakeholders: customer-facing channel partners, customers, financial providers, logistics providers, infrastructure and compliance mechanisms and suppliers. The methodology is highly structured and identifies business capabilities that support products/services in a series of contexts including life cycle and collaboration. A capability is an unclear concept that encapsulates people, processes and platforms. It has inputs and outputs. 3.4 Service-oriented development methodologies and frameworks ISE 3 The Inter-enterprise Service Engineering (ISE) methodology is being developed in context of the German funded research project Theseus-Texo [Federal Ministry of Economics and Technology 2008]. The methodology is based on the Zachman Framework (see section 3.3.2) and OMG s Model- Driven Architecture [OMG 2003a] concepts. Figure 15 illustrates the framework which is related to ISE. Like Zachman it uses a two dimensional abstraction model to decompose the service engineering process. Each of the rows is related to a 3 The information on ISE is provided be the following Theseus Texo consortium members: SAP AG, empolis GmbH, intelligent views gmbh, ontoprise GmbH, Siemens AG, Fraunhofer Gesellschaft, FZI Forschungszentrum Informatik Karlsruhe, the German Research Center for Artificial Intelligence (DFKI GmbH), Technische Universität Darmstadt, Technische Universität Dresden, Technische Universität München and Universität Karlsruhe (TH). The information in this document is provided as is, and no guarantee or warranty is given that the information is fit for any particular purpose. The above referenced consortium members shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials subject to any liability which is mandatory due to applicable law. Copyright 2008 by the TEXO Theseus Texo consortium. Copyright SHAPE Consortium Page 35 / 114

36 phase in the development process while the columns describe the different perspectives in an SOA, which are defined as follows: Service: defines the development process of an atomic service. Process: provides guidance to develop a workflow between different services. Data: identifies the used data assets and their relations to each other. People: provides a way to develop user interfaces for services. Rules: provides guidance to regard business rules in the development process. The project members are also developing a workbench which supports the methodology. This workbench is based on Eclipse and EMF (Eclipse Modeling Framework) Language Process Figure 15: ISE Framework Because the ISE Framework is under development not every cell definitely provides a dedicated language. It is certain that Mind Maps should be used for the scope models and UML as well as OCL for business models. ISE only supports Web Services, so WSDL is used for the technical service model. For workflows BPMN is used as logical and BPEL as technical language. OWL is used on the technology layer for the data column, while the UML Ontology Profile is dedicated to the logical layer. The phases of the development process are specified through the vertical dimension of the ISE Framework: The Scope Model is dedicated to a business strategist or planner and provides information about what should be modelled in an informal way. The Business Model is dedicated to a business owner and provides a very abstract formal description. The Logical Model is dedicated to an IT architect and provides a technology-agnostic description. The Technical Model (physical) is dedicated to a developer and provides a technologydependent description. Each above described SOA perspective has a dedicated method and model at each process step. It will be transformed to the next model in the vertical dimension and is linked to models of other perspectives. Copyright SHAPE Consortium Page 36 / 114

37 3.4.2 SOMA (Service-Oriented Modeling and Architecture) The SOMA (Service-Oriented Modeling and Architecture) approach was developed by IBM based on the concepts from SOAD (see section 3.4.6) and identifies three areas that are not covered by OOAD methods and that should be addressed when developing an SOA [Arsanjani 2004]: 1. Services 2. Flows, and 3. Components realizing services. SOMA also targets the development of a methodology that clearly separates providers and consumers. Finally, SOMA introduces the concept of service ecosystem or service value-net where services are used in a supply chain and need to be exposed to business partners for composition. Figure 16 illustrates the elements of an organization that are important for SOMA. Figure 16: SOMA template for SOA [Arsanjani 2004] The seven layers from Figure 16 are used to design and make architectural decisions and can be described in the following way: The scope layer identifies which area of the enterprise that will be object of an SOA approach. The operational systems layer identifies existing systems such as legacy systems, CRM and ERP packaged applications, and custom applications. The enterprise components layer includes a description of the applications that manage and support components such as application servers and which implement workload management, high-availability, and load balancing. It also describes which business domains are supported and which functionalities are elected as components. The services layer categorizes the portfolio of services and makes services available to consumers. An adequate infrastructure needs to be put in place to make services scalable and to externalize their interfaces. The business process composition or choreography layer provides a platform to aggregate services into a flow through orchestration or choreography. The access or presentation layer provides graphical interfaces or presentation for services. This is important since SOA separates the user interface from services. The integration layer is responsible for the integration of services using mechanisms such as intelligent routing, protocol mediation, mappings, and transformation mechanisms. The QoS layer provides mechanisms to monitor, manage, and maintain QoS such as security, performance, and availability. SOMA prescribes a top-down, business-driven approach with a bottom-up approach, IT-based. It also recommends the use off a goal-service approach to reduce the number of candidate services identified. A sequence to carry out these three activities may be structured with, first, a top-down Copyright SHAPE Consortium Page 37 / 114

38 approach, then a goal-service modelling, and finally a bottom-up legacy analysis. A set of activities associated with SOMA, from a consumer and provider perspectives, include service identification, service categorization, service exposure, choreography and QoS. Figure 17 gives a detailed description of SOMA methodology and consists of three main steps: identification, specification and realization of services, and flow. Figure 17: Activities associated with SOMA methodology [Arsanjani 2004] Service identification uses top-down (domain decomposition), bottom-up (system analysis), and middle-out (goal-service modelling) approaches to integrate these different views. When the services have been identified, they can be classified and categorized into a hierarchy. This step helps to guide the composition and layering of services. The subsystem analysis identifies and specifies the interdependencies and flow between the systems. The component specification outlines the details of the software that will implement services. Details include data definitions, messaging and events, and business rules. Service allocation assigns services to the subsystems that have been identified previously. Finally, service realization identifies the software that needs to be selected, integrated, transformed or built to provide services COMET-S COMET [modelbased.net 2008] is a methodology from SINTEF that supports model-driven development of enterprise systems, focusing on model specifications, system methodology and software tools for the development of component-based information systems. The COMET-S (for Services) version from 2008 has introduced the use of new OMG metamodels like BPMN, BMM and UPMS for the purpose of modelling the CIM and PIM areas respectively. COMET follows a use-case driven, model-focused approach aimed at supporting the process of developing and maintaining products and product families. The methodology provides guidelines for specifying and implementing products, system, and components. The process is a structured set of development methods, procedures and modelling techniques that are used for the specification, development, testing and deployment of products, systems, or components. Comet-s is a methodology which is promoting a model based methodology in a three layer architecture, Business model(cim), Requirements model(pim) and the Service architecture model. The starting point for the COMET-S methodology (COMET for Services) is the existing COMET methodology as documented at As you can see from the figure below the focus for Comet-s is the Service, Process and Information areas. Comet-S also provide some guidelines for the development process and notation of models. The processes and techniques introduced her is based on the COMET methodology developed mainly by several related projects (COMBINE, INTEROP, ATHENA and SWING) and the information about the Comet-s methodology is taken from the MDE for SOA ( The COMET-S methodology is compiled of four different modeling areas, business-model, Requirements model, Architecture model and platform specific model. It is using the newly available metamodels from the OMG standardization projects. In particular for the CIM level BMM and BPMN are proposed, and for PIM the UPMS. The figure below gives an overview of the four main modeling areas of the Comet-S methodology. Copyright SHAPE Consortium Page 38 / 114

39 Business model Requirements model Architecture model Platform specific model Business model Figure 18: Main modelling areas The business modeling is used to outline and describe the part or role played by the product being developed. In addition this will be linked to the product's context that is driving its development. The modeling of a business is a recursive activity and some of the models could easily become multilayered. Meaning a process can contain subprocesses that are defined in separate models Process In the work of collecting domain information, all with interests in the product should attend and contribute in these activities. The possible Business stakeholders involved: Decision makers for authorization of funding for the development of the product People who are responsible for design and maintenance of the business processes to be supported by the Product. Copyright SHAPE Consortium Page 39 / 114

40 Product consumers Decision makers for acceptance of the Product Managers of operation for the productnotation and language: The business supported by a service architecture has goals as one of the primary drivers for what services to define and evolve. Other primary drivers for services are processes required to meet goals and the roles to fulfil them. The community structures groups of resources with common or interleaving goals. The business model consists of these work products: Scoping statements including context statements, vision for change and risk analysis Goal model describing the business goals being realized through developing, implementing and using the product. Community model including business processes, role modeling and business resources Scoping Statements with BMM The Context statement is modelled by BMM concepts and including definition of the scope of the business model and its position in its context. This will give a feet domain picture giving an overall understanding of the domain, identifying stakeholders, their relationships and concerns. The Vision statement is highlighting why this product should be funded, and giving a clear understanding of the gap between the current situation and where to go. The Risk analysis model is describing elements that might have an influence on the product, either good or bad. A return on investment(roi) estimate should also be a part of this work product Goal model Goals of the major stakeholders are agreed upon and serve as a reference throughout the development process. The Goal model has a central role in visualizing high level business processes that will be used as a base for further analysis in the Business Process model Community model The community model is a container with a set of communities that are collections of resources working together in one or more processes to achieve one or more goals. Communities are essential for performing recursive, parallel and decomposition of both structure and behaviour in business process modeling. The business resource model describes an information model identifying and defining relevant concepts of the domain (what it is) and the processes (what it does) that seeks to realize the goals from the goal model BPMN Business process and roles model The Business process model is defining the processes in the domain that is needed to realize stakeholders goals or relevant to the product. In addition it will describe roles that perform the processes. As already mentioned the model may be at many levels, from the high level business processes down to the Work Analysis Refinement Model(WARM). The process model is derived directly from the Goal Model. Starting with the identification of the enabling behaviour for the goals to be achieved. The different behaviours derived are then consolidated to a set of behaviours that covers all the goals. These processes are expressed through the BPMN language which has four distinct categories of concept elements. Flow Objects: Events, Activities, Gateways Connecting Objects: Sequence Flow, Message Flow, Association Swim lanes: Pool, Lane Artifacts: Data Objects, Group, Annotation Copyright SHAPE Consortium Page 40 / 114

41 Business resource model The business resource model is an information model of the main things and concepts relevant to the product and its context. The resource model is to be realized with UML class model or with a ontology model like OWL [W3C 2004] or a combination of both Work Analysis Refinement Model (WARM) The WARM is a refinement of the core Business model with focus on work analysis, asking which kind of resources does the specific kinds of work. WARM is not a specific model but a refinement of the existing models, defining what kinds of steps are preformed by whom, human or system? Requirements model The requirements model is identifying the system requirements including the functional requirements, non-functional requirements and constraints. The requirements model includes several sub models like the Use Case Model, a prototype, Non- Functional requirements and the BCE model. The Use Case Model consists of a System Boundary model and the Use Case Scenario model. The system Boundary model describes the System Boundaries, the actors and their responsibilities, and the services offered by the system. The Use Case Scenario model details the identified use cases. The prototype is made to reduce technical risks and ensuring user participation. It also contributes to the quality of user interfaces by testing critical use cases and other risky parts of the architecture. The Non-functional requirements describe requirements like efficiency, response, integrity and so on Business domain to system domain mapping The BCE model provides the link between the Requirements model and the Architecture model. The model is the output of a technique used to extract the system domain models (architecture model and platforms specific model) from the business domain models (the Business model and the Requirements model). Requirements model to architecture model transformation are also mentioned in the COMET-S methodology. The following transformations are proposed: All actors are mapped to a UserService and Interfaces as a provided interface of each actor are created. For all the use cases that the actor relates to, add a corresponding operation to the Interface. Naming conventions: The actor name is used to name the UserService and the same for the interface only prefixed with an I. The operations will be named according to the use cases. Map each <<Manage>> use case to a BusinessService providing CRUD operations as well as find and collection operations for the Resource(s) that are related to the <<Manage>> use case. Naming conventions: use the resource name prefixed with Manage Include and extend relationships can be handled like this: Include -> reuseable UserService with interface providing the include service or an operation in the interface of the extended UserService. Extend-> Operation in the interface of the extended UserService Service Architecture Model The Comet-S methodology is embracing the standards from OMG (Object Management Group), and is using the emerging UPMS SoaML standard as a framework for the service architecture. An open source implementation of the SoaML UPMS standard is in development by the European SHAPE IST project, and will be adapted further for the COMET-S methodology. Copyright SHAPE Consortium Page 41 / 114

42 Figure 19: SoaML overview The approach in Comet-S is to adapt and use the SoaML modelling approach for service modelling, as exemplified below. Figure 20: Realizing participant The service reference architecture in COMET-S defines a set of logical tiers, that consists of a set of components. As you see in Figure 21 it is divided into the user service domain and Business Service Domain with its respective tiers. Copyright SHAPE Consortium Page 42 / 114

43 The PSM model Figure 21: Architectural tiers The Service architecture model is to be transformed into a platform specific model which contains of the Platform Profile Model which specifies the system in alignment to the actual technology profile for the specific platform. Component Implementation Model, which describes the implementation of the component specifications in a given programming language like JEE SAE SAE extends the reference model by OASIS for SOA, developed by CBDI. SAE framework provides a more detailed and pragmatic conceptual view than the base OASIS model for SOA; actually it is not a model but a process framework [Butler 2007]. This framework provides the methodology elements that are intended to be tailored to a certain organisation s need in order to build the processes to drive the SOA adoption cycle. Consequently, it includes a pool of artefacts (methodology elements) for supporting the migration to a service oriented enterprise. These artefacts, tools and techniques are grouped in three main perspectives: organization, reference architectures and processes. Copyright SHAPE Consortium Page 43 / 114

44 Figure 22: CBDI SAE SOA Reference Framework Process: This perspective covers four key disciplines areas for SOA processes: o Manage: the processes required to define the organization s SOA capabilities, the current ones and the ones desired for the future. As well as, the processes motivated by the transition and the required SOA governance. o Consume: Assembling software solutions specially focused on the consumption of services. o o Provide: Provisioning and implementation of services. Enable: establishing the platform required to run services and ensuring its performance during the execution of services. See section for an enumeration of the main processes addressed by the framework. Organization: This group of elements is oriented to describe the organization: its roles and responsibilities, project profiles and funding models. The recommendations in order to successfully support the service lifecycle are exposed. Architecture: The architecture involves two orthogonal mechanisms: o o Language SOA views: they comprise a consistent level of abstraction for deliverable artefacts related to distinct set of stakeholders. These are: business, specification, implementation, deployment and technology. SOA practices: different SOA practices in the organisation are defined and clustered in each of the SOA views. These three views are based on a model that organises the language and principles of SOA for this framework. This model includes: The principles on which the whole framework is based. They are very close to the concept of an agile enterprise. Copyright SHAPE Consortium Page 44 / 114

45 Glossary: it is a consistent taxonomy containing the term to be used in the framework. Service Life Cycle. The metamodel that defines the rules to build an SOA model. It is documented as a UML profile Process [Allen 2007] SOA Adoption and Excellence: It compares current SOA capabilities against the desired outcomes according to certain maturity levels. The result is a suitable adoption plan. SOA Governance: ensuring that the SOA adoption process complies with the SOA Reference Framework. SO Business Requirements: This process consists of identifying business requirements specific to service orientation that otherwise would not be addressed. SO Business Improvement: transforming existing processes, products and capabilities into services; and creating new service-enabled ones that in turn improve the business. Solution Assembly: using several techniques based on services to design, code, and test the solution. Service Oriented Architecture and Design: this process adapts the SOA reference framework to a particular organization; evolving the service portfolio plan and the SO Security Architecture. Legacy Transition Planning: creates a plan heading towards an SOA vision but taking into consideration the existing IT architecture. Service Implementation: enabling services by means of the automation units, these will be either subcontracted or implemented in the organization. Equally, legacy systems have to be considered during this process. Service Provisioning: service brokering, quality assurance and certification. Service Platform Design and Installation: the development of the underlying service platform, potentially consisting of an ESB or a set of ESBs. Service Operations and Management: deploying, running, monitoring and controlling run time services SMART The Software Engineering Institute at Carnegie Mellon University has developed the Service-Oriented Migration and Reuse Technique (SMART) [Lewis, et al. 2005] to assist enterprises to analyze their legacy systems to evaluate their feasibility to integrate a Service-Oriented Architecture (SOA). SEI arguments that the approach allows to adapt legacy systems to services without affecting the involved systems while exposing functionality to a large number of client applications using standard-based interfaces. The SMART approach was applied with success in the U.S. Department of Defence (DoD). The methodology has helped the DoD in converting their existing systems into services. It has been established that specialized methodologies and approaches are indispensable for large organizations since the number of people and the heterogeneity of software involved may introduce a level of complexity that leaves the organizations in a worse position than before introducing an SOA. SMART provides a service migration strategy as its primary product. The methodology allows gathering a vast range of information about existing legacy systems, the SOA to deploy, and potential services to produce. The implementation of SMART involves five major composite activities: Establish stakeholder context. Describe existing capability. Describe the SOA State. Copyright SHAPE Consortium Page 45 / 114

46 Analyze the gap. Develop migration strategy. The first activity seeks to identify the people that have more knowledge about existing legacy systems. It seeks also to identify the objective of each system and what it should do as a service. The task of the second activity is to find a clear description of legacy systems. Examples of information that may be collected include the name, function, programming language, operating systems, and age of legacy systems. The main objective of the third activity, describe the SOA state, identifies the set of potential services that can be created from legacy applications. The fourth activity identifies the gap between the current state of the IT infrastructure and the desired SOA. It determines the effort and cost associated with the conversion of legacy systems into services. The last activity provides a strategy and a set of recommendations to achieve the initial organizational goal. Figure 23 shows a relatively simple technique to establish an initial analysis for the fourth activity. Figure 23: Analyses of converting the selected components to services While SMART methodology has reached a mature state, the authors point out that it has significant room for improvement. Suggested improvements include: incorporate decision rules, develop applications for gathering and analyzing data, and develop criteria for determining when sufficient information has been captured Language There is no specific language or model explicitly and formally defined in this technique, neither for the SOA concepts nor for the own concepts developed in the methodology. Consequently, a commonly accepted understanding of these concepts is due Process Establishing Stakeholder Context: this is a set of tasks in which the stakeholders involved in the migration process are consulted. As a result, several pieces of information are obtained about legacy elements: the distribution of responsibilities and knowledge, and about existing concerns regarding the migration process. Describe Existing Capability: this activity intends to obtain descriptive data about the components of the legacy system. Describe the SOA State: in this group of tasks, the target SOA state is described. At the same time, SMART gathers evidence about the potential for turning existing capabilities into services, these decisions are made considering what the intended SOA state is. Analyze the Gap: an activity that aims to balance the breach existing between legacy capabilities and the target SOA state. Develop Migration Strategy: the final set of tasks in which one or several goals are determined out of the gap analysis made; and a strategy to achieve them is developed. Copyright SHAPE Consortium Page 46 / 114

47 3.4.6 SOAD (Service-Oriented Analysis and Design) [Zimmermann, et al. 2004] from IBM, investigated how Object-Oriented Analysis and Design (OOAD), Enterprise Architecture (EA) frameworks, and Business Process Modeling (BPM) could be used to support successful SOA deployments. The authors termed their approach as Service-Oriented Analysis and Design (SOAD). It is argued that the methodologies employed fall short when applied independently of each other and that there is the need for a hybrid approach that combines concepts of all of the disciplines with a number of new aggregating elements. Figure 24 shows an integrated view of SODA. Figure 24: The SOAD approach [Zimmermann, et al. 2004] The methodology has been developed having in mind that OOAD, EA, and BPM cannot give a satisfactory solution when used in isolation from each other. The OOAD cannot be used in isolation since it does not capture the full scope of an enterprise-wide SOA system. EA approaches, such as Zachman, do not capture how enterprise-wide abstractions of quality facilitating reuse and longevity can be found. The Zachman framework has some limitations since it shows interconnection at a macro-level which does not fits very well since services need a low-level of detail to represent technical devices. Also, the framework is rather generic and does not reach down to the design and implementation domain which may impair architects and developers due to a lack of tactical information. As a result, some researchers believe that it does bridge the gap between enterprise and implementations. Nonetheless, they provide a basis for architectural consistency between individual solutions across multiple lines of business and organizational units. Finally, BPM does not adequately represent the architecture and implementation domain, and in many cases, process modelling and implementation are carried out separately. Nonetheless, existing BPM approaches can be a good starting point for SOAD, but they have to be extended with new elements to describe services and operations at a correct level. SOAD recommends a meet-in-the-middle approach, rather than pure, top-down or bottom-up process. At a global view, SOAD provides the glue to put together OOAD, BPM, and EA. Its main goals are the following: Interconnect and interrelate classes/ objects from OOAD to events of processes. Replace use case descriptions with business events and processes. Business events and processes are first class citizens. Consider syntax and semantics for ad hoc composition, semantic brokering, and runtime discovery. Definition of quality factors and best practices. Roles management (CEO, Business analysts, Developer, Architect, etc). Characterize functionalities that are good candidates to become services (level of reuse and importance). Facilitate end-to-end modelling and supply a comprehensive tool support. Copyright SHAPE Consortium Page 47 / 114

48 Develop a method spawning from the business to the architecture and application design domains. SOAD puts emphasis on quality factors to deploy services. The following elements are considered: Reduce dependencies between services. Make dependencies between services explicitly. Design services based on a CRUDS (Create, Read, Update, Delete, and Search) metaphor. Keep service naming understandable. Service granularity. Other important issues include: Service categorization (core service, composite services, operational services, security services, etc). Policies (business traceability - Sarbanes-Oxley (SOX) act). Meet-in-the-middle processes. Semantic brokering. Service harvesting and knowledge brokering Language SOAD is completely based on UML, as OOAD and BPM are. The main requisites of the SOAD methodology are: Both the processes and the notation used must be formally defined. There exists a structured manner to represent services. SOAD integrates both classes and objects used in OOAD and process models from BPM. Best-practices and quality factors are well defined. BPEL roles are clearly specified. The characteristics of every service need being questioned to determine if it is or it is not a good service. These requirements cannot be said to constitute a language as such, but summarize the directives within SOAD methodology to determine the terms, meanings and concepts used on SO development Process Service Identification: This process consists of a combination of top-down, bottom-up, and middle-out techniques of domain decomposition, existing asset analysis, and goal-service modelling. Service classification or categorization: This activity consists of a service classification into a service hierarchy, reflecting the composite or fractal nature of services: services can and should be composed of finer-grained components and services. Subsystem analysis: This activity takes the subsystems found during domain decomposition and specifies the interdependencies and flow between the subsystems. Component specification: The details of the component that implement the services are specified: data, rules, services, configurable profile and variations. Service allocation: It consists of assigning services to the subsystems that have been identified. Copyright SHAPE Consortium Page 48 / 114

49 Service realization: In this step a decision is made as to which legacy system module will be used to realize a given service and which services will be built from the ground-up". Other realization decisions taken include: security, management and monitoring of services SODA In Gartner, the Service Oriented Development of Applications (SODA) methodology [Rogue Wave 2008] was conceived as a result of a set of activities or processes for SOA development. Those processes that have been considered to be critic for SOA development are tackled by SODA. SODA is supposed to enable an organization for better, cheaper, faster software development. SODA is based on artefact reuse (from patterns and models to test plans and test beds). It will only be beneficial in those projects in which reuse are one of the main principles Language There is no specific language or model explicitly and formally defined in this technique, neither for the SOA concepts nor for the own concepts developed in the methodology. Consequently, a commonly accepted understanding of these concepts is due Process Design: Solution requirements are established at this stage. SODA requires that the design is mainly focused on process oriented design elements, rather than on component based systems. Process flow and process integration should be initially integrated in the application design instead of being considered at a later stage. Modelling: the structure of the solution is built by means of modelled services (with UML or other modelling mechanisms) Modelling affects three areas: business modelling, application modelling and technical modelling. Modelling is one of the key elements that cater to the required agility and reuse. Fabrication: that is creating the actual, functional components for the services in the application design. This includes writing and/or generating the code. The components created represent the functionalities that have been designed. Integration: in this activity, components are integrated into services. Assemblers or visual editors may help at this task. Governance: information flows and work flows among services are defined. Information flows require being defined; this can be achieved by means of work flow management products. At the same time, the mechanisms that are necessary to transform service data flows and to manage the data structure are determined. Automatization: this activity refers to automatically generating code, reducing the necessity for actual code writing. Several tools are to be used for this purpose. Less experienced developers are helped by this facility and experienced developers may rapidly manipulate code when required. Maintenance (Rapid Application Maintenance): this facility means undertaking several small changes rather than big changes: favouring service variability. SOA demands that services are able to adapt to new evolving objectives. This adaptation becomes a key element to make the solution achieved agile ESI Method ESi-Method is a methodology that describes the processes to develop an atomic service using webservices technologies. These are the objectives that the methodology meets: Support rapid development. It helps to reduce the time to market while keeping the cost and the quality. Copyright SHAPE Consortium Page 49 / 114

50 Allow rapid maintenance. It provides the support people with the right information to make easier the location of the source of the errors detected, to help in the understanding of the error, and to finally accelerate the error solving while keeping the integrity of the design information. Ensure product quality. Quality means to satisfy the user needs and expectations, including the implicit and explicit requirements. Therefore the methodology keeps the traceability between all user requirements and the final system. Allow easy management. It helps to the easy development of project plans through the provision of a coherent sent of activities that could be applied with several life cycles. Furthermore, it provides an extendable framework of phases, activities, work products, etc that could be specialised to specific domains. Support rapid evolution. The models, the architecture, and the developed system are built taking in mind that the systems could require further modifications. These modifications can be oriented to upgrade the system, to adapt the system to a new environment, to make it reusable, etc. Flexible methodology. It can be adapted depending on the type of product the developers want to build or on the organisational context. The organisational context includes project constraints, organisational culture, nature of the client, Provide flexible products. The products developed with this methodology could include adaptability features so they can be reused in other projects. Support process quality certification. It should support the requirements of processes models like CMMI. Easy to learn methodology. It provides a brief overview to make easier the overall understanding together with a set of specific guidelines, templates and examples to provide the lower level understanding required to the application of it Language There is no specific language or model explicitly and formally defined in this methodology, but in any case this methodology promotes the use of UML as a standard notation for the project documentation Processes ESI- Method defines the following process or phases: Requirement Identification: To agree with the customer and other relevant stakeholders on the set of requirements that will be realised by the system. In this stage, the role of the stakeholders is to provide their requirements and to decide which will be implemented and which will be omitted. On the other hand the role of the development team is to ensure the common understanding of the requirements and to evaluate the effort that the completion of each requirement will imply. The agreed set of requirements resulting from this stage will be the basis for the acceptance test at the end of the project. Business Model Analysis: To define the business model required to implement the functionalities described in the System Requirements Document in the agreed terms. The business model describes the interactions between the entities internal and external to the company required to provide a set of functionalities. Another issue is that there could be more than one business model able to fulfil the System Requirements stated in the Requirement Identification phase. Therefore this phase has implicit an activity of alternatives evaluation to select the business model that better fits the needs and skills of the stakeholders. Software System Analysis: To define the way in which the software system(s) will implement the different functionalities to be performed. This is, the solution to the software system requirements derived from the System Requirements and the Business Model e-service. At this point of the methodology, we focus in the behaviour of the software to be developed Copyright SHAPE Consortium Page 50 / 114

51 forgetting any other external issues. External issues such as how a external entity perform his task, or how a existing ERP (Enterprise resource planning) produces a invoice for a customer. Software Architecture Specification: To define the architecture of the system, identifying the components which will compose the final system and their interactions. This will be related with the solution specified in the Software System Analysis to guarantee that the design and implementation of the whole system meets the System Requirements. The components could be GUI, HTML, XSLT, databases, COTS, reused components, new components even web services. Detailed Design: To design in detail the components identified in the previous phase (Software Architecture Specification) to support their implementation. Depending on the nature of the component, the activities to be performed in this phase could change dramatically. The components could be GUI, HTML, XSLT, databases, COTS, reused components, new components even web services. Implementation: To obtain and test all the components identified and designed in the previous phases (Detailed Design), and in the Software Architecture Specification, so all the parts of the system are ready to be used. Some components are implemented, others are adapted, others are bought Integration And Testing: To integrate and test all the components once the are ready, making up a complete software system and having in mind the architecture defined before in the Software Architecture Specification. The integration is tested also to avoid the errors. Validation: To validate the system with the clients. In this phase, a simulation environment, similar to the one where the system is going to operate, is prepared. If the environment where the system is going to operate is prepared. Then, the final trials are done according to the Validation Criteria defined in the Requirement Identification phase. System Deployment: To finalise all the deployment activities, including the documentation of the manuals and the publicity and publishment of the system SeCSE Composition Methodology The purpose of the SeCSE composition methodology is to define a solution that allows the development of self-configuring and context-aware compositions, so this provides an innovative, easyto-handle solution that spans from design to implementation level. Using this approach, variation points and variants have shown their usefulness for describing the specific features that a composition may offer depending on context information. Copyright SHAPE Consortium Page 51 / 114

52 Processes Figure 25: The processes of the SeCSE Composition Methodology There are five processes that enable the development of static service composition: Enterprise Architecture Engineering: Defines and maintains domain-wide or organisationwide architecture models and assets with their correspondent benefit and drawbacks. This is important to select and maintain a set of architectures that may be used in new projects to facilitate the architectural work and encourage reliability, flexibility and performance of the solutions. In this process, architecture alternatives are also identified and assessed to fulfil system requirements. Functional Specification: Defines how to specify what kind of services will be needed to cover the functionality of the system. These services will be part of the composition and the specifications will be used to find services which can fulfil the requirements. All the defined specifications will guarantee that the business process will meet the original requirements. This process defines the optimal abstract service descriptions aligned to the business requirements and fulfils the needs of a strategic direction for the architecture. Design-Time Service Composition: Defines, at design time, an appropriate composition of service specifications fulfilling both functional and non-functional requirements defined previously. It also analyzes the best architecture for the business process, according to the architecture alternatives presented before. Composition Realisation: Selects candidate services and possible alternatives, using service specifications. These services and alternatives are also used in the composition to fulfil the requirements, keeping traceability between implementation and requirements. These services can be discovered or developed, depending on the possible candidates and the requirements of the system, and they are mapped to the composition specification. The goal is to obtain the final business process that fulfils the functionality expected from the system during its execution. Validation: Assures that selected services meet their specified functionality and quality of service (QoS). Validation also includes the verification of the design, the safety of the system, the ability to build the design correctly, the ability to reproduce the system, the ability to correct faults, etc To support the creation of dynamic compositions with the ability to change their behaviour depending on the context, the methodology proposes carrying out two additional and specific processes when developing services. Copyright SHAPE Consortium Page 52 / 114

53 Variation Point Management Process: Describes which parts of the composition are variable in such a way that they might change during the execution of the composition, according to the application domain. This is done by defining a set of requirements to perform this variability and maintain the coherence with the business process goals. Variation Point Realisation Process: Gathers the information indicating which services are candidates for each variation point and how those services fulfil the requirements of the variation point. Some rules or mechanisms may be specified to be set when one service or another is used to cover a variation point. These rules may be seen as the policies to change the composition depending on the context or the circumstances SeCSE Methodology The SeCSE methodology [Lefever 2005], by means of the processes featured, primarily represents the support that users of the SeCSE platform [SeCSE] would need to map their tools to the processes comprising the SeCSE conception of service-centric systems engineering Language Figure 26 shows the SeCSE Methodology metamodel, represented using the UML. The metamodel is process centric. Processes are grouped into Functional areas and consist of one or more tasks. These metamodel elements are: Functional area: a way to classify processes by similar functionality that constitutes a conceptual container into which processes are grouped. Functional areas provide high level views of the methodology. Process: a process is a sequence of operations and involved events, consuming time, space, expertise or other resources, which lead to the production of some outcomes that satisfy some requested goals. Task: a process can be divided (following some work flow) into tasks that manage concrete operational aspects of the process. Workproduct: artefact containing information that is read, produced or modified by the process and required for its performance. Workproducts have an attribute called action that may have one of the following values: o Create: A work product is created by the process. Therefore, the associated work product is an output of the associated process. o Delete: A work product is deleted by the process. Therefore, the associated work product is an input to the associated process. o Modify: A work product is modified by the process. Therefore, the associated work product is an input to and an output of the associated process. o ReadOnly: A work product is read, but not modified in any way, by the process. Therefore, the associated work product is an input to the associated process. SeCSE tool: software used to instantiate the process under the SeCSE platform. Actor: role played by one of the users participating in the process. Copyright SHAPE Consortium Page 53 / 114

54 Process Figure 26: SeCSE Methodology Metamodel At the highest level the SeCSE methodology is represented by three important functional areas: Service-Centric System Engineering functional area. This represents the core of the SeCSE project and most of the processes that are part of this area are supported by SeCSE tools or methods. This functional area comprises those Service-Centric Systems (SCS) processes, which provide specific support for the analysis, design, development, deployment and running of a software system based on services. It is related to, and dependent upon, the following two functional areas. Service Engineering functional area. The focus here is on developing, testing and delivery atomic services processes. In particular attention is paid here on the primitives necessary to make Service-centric System Engineering occur. It should be noted that the SeCSE project addresses only the subset of this functional area that is integral to support the Service-centric System Engineering one. Service Acquisition/Provisioning functional area. This area contains processes concerned with the provisioning and acquiring services: the service marketplace. As with Service Engineering, the SeCSE project addresses only the subset of this functional area that is integral to the support of Service-Centric System Engineering. Validation/Verification (V&V) is a cross-cutting functional area that verifies the validity of the outcomes of other processes coming from the functional areas above (e.g.,the service architecture validation). V&V is not considered a functional area by its own, but we identify it here to explain its importance to the functional area structure. These functional areas can be seen as logical grouping of sub-processes relevant for that specific area and referring to a specific aspect of the service oriented world Enterprise SOA Enterprise SOA [SAP] is SAP s blueprint for an adaptable, flexible, and open IT architecture for developing services-based, enterprise-scale business solutions which are running on a Business Process Platform (BPP). Copyright SHAPE Consortium Page 54 / 114

55 The initiative for enterprise SOA was started in 2003 (first under the name ESA) and was firstly provided with NetWeaver platform 7.0 in The SAP ERP release of the same year was the first application which was based on a Business Process Platform followed the remaining applications of the Business Suite, and BusinessByDesign a solution for midsize companies SOA/SHA results Enterprise SOA applications cover several layers (Figure 27): Service-enabled applications: contain required functionality Provisioning layer: provides abstraction from the actual backend systems by providing a consistent set of services. In addition, any business object or business logic not available in the backend systems can be created here. SOA middleware: o Enterprise Service Bus: is the communication infrastructure that is responsible for the integration of different systems in a system landscape o o Enterprise Services Repository (ESR): the central location for defining, accessing and managing SOA assets Service repository: On one hand it stores the definitions and metadata of Enterprise Services and business processes. On the other hand it is a central environment for modelling and design. Service registry: The registry supports the publication, classification and discovery of Enterprise Services. This UDDI-compliant registry also enables the management and governance of services. SOA Management Tools Consumption layer: Services are utilized to create user interfaces and processes. User interfaces layer: offers several possibilities to implement user interaction based on available services Tool support Figure 27: Enterprise SOA Technology SAP offers several tools to cover the above mentioned layers: Copyright SHAPE Consortium Page 55 / 114

56 ABAP Workbench: The ABAP Workbench is SAP s proven tool for ABAP development. Besides creating additional business logic, you can expose and consume web services and build user interfaces with Web Dynpro. NetWeaver Composition Environment: enables enterprise SOA consumption, development and composition of SOA applications. o NetWeaver Developer Studio: The Eclipse-based Developer Studio (NWDS) comprises development tools for Java and composition. You can create additional business objects and business logic (Java EE, Composite Application Framework), expose and consume web services, and create user interfaces (Web Dynpro, SAP Interactive Forms by Adobe) o NetWeaver Visual Composer: Visual Composer is a web-based visual modelling development environment that enables developers to quickly create and adapt modelbased transactional and analytical applications, without coding. o Guided Procedures Framework: Guided Procedures allow the creation user-centric business processes. With the browser-based GP Design Time you can design, implement, and configure processes based on Guided Procedures; you can access instances of these processes and you can administer and monitor them. o NetWeaver BPM: NetWeaver BPM provides process modelling capabilities based on the Business Process Modelling Notation (BPMN) o NetWeaver BRM: allows the creation of business rules. NetWeaver Process Integration: provides enterprise SOA provisioning and SOA middleware capabilities Enterprise Service Builder: The Enterprise Service Builder is an ARIS-based tool integrated in the ESR, for working on artefacts stored there, as well as handling process integration tasks Process SAP recommends a certain methodology for developing in an enterprise SOA environment which is depicted in Figure 28 and shortly explained in the following: 1. Define business requirements: Figure 28: Enterprise SOA Development Lifecycle Specifying the business process Copyright SHAPE Consortium Page 56 / 114

57 Specifying required services Specifying required user interfaces Specifying the required security protection for the SOA environment Identify missing services 2. Service Modelling: Model Business Objects Model Service Interfaces Model Service Operations 3. Service Definition: create the service signature 4. Service Implementation: implement the appropriate functionality following implementation rules and guidelines. 5. Discovery & Description: adding documentation for the services and publish them to the service registry 6. Service Consumption Notation & Language Processes: BPMN, EPC, WS-BPEL 2.0 Services: EPC, WSDL, WS-Policy Global data types: ebxml Core Components, UN/CEFACT CCTS Analysis Business and IT architecture alignment: Enterprise SOA is more aligned with developing business architecture. To develop an IT architecture you can use SAP s EAF (Enterprise Architecture Framework) which is based on TOGAF. Delivery strategy: The approach provides the top-down, the bottom-up and the meet-in-the middle strategy. Incremental delivery: Incremental delivery is supported. Lifecycle coverage: The full SOA lifecycle is supported. Clear roles and responsibilities: The methodology supports the provider and consumer view, as well as it defines groups and roles and relationships to phases in the SOA lifecycle. Model-based: The approach is model-based, whereby a full chain of automated model transformation is not supported. Use of standard modelling languages: Yes. Tool support: The whole methodology is supported by tools, whereby you have to change between different applications. Support of different SHA technologies: No, only web-service architecture is supported. Shared information and semantics: Yes, with the help of the ESR. Application integration: Yes, with the help of the Enterprise Service Bus. Service reuse and governance: Yes, with the help of the ESR. Versioning: Versioning is supported. Management: Management is supported by the middleware. Copyright SHAPE Consortium Page 57 / 114

58 Include best practises: Yes. Degree of description: The description of the methodology is very detailed. Process agility: Enterprise SOA follows more a rigid approach in the process lifecycle. Adoption of existing processes/techniques/notation: Enterprise SOA follows an own process, but uses standardized techniques like BPM, as well as standardized notions. Industrial application: SAP s enterprise SOA was proofed in internal as well as external projects Identified method components Because the enterprise SOA approach was proofed in several industrial projects, we can overtake best practices, rules and patterns for the SHAPE methodology. For example defines the methodology different building blocks and service types which are important to achieve homogeneous service definitions and to find the right service granularity. Building Blocks: Business Object o o Represents a type of uniquely identifiable business entities Consists of Business Objects Nodes which are sets of semantically related attributes Process Component o o Deployment Unit o o Service Types: Core Services o Reusable building block for business processes Groups semantically related Business Objects For flexible activation and deactivation of business functionality Groups semantically related process components For direct access of a Business Object o Defined for each Business Object Node in accordance to given patterns (Access, Query, Transaction, Action) Compound Services o o o Combines several Core Services Used for message based process integration: B2B interfaces: for communication between enterprises o A2A interfaces: for communication between Process Components and Deployment Units Enterprise Services o o o Combines Compound Services Represents a step in a business process Significant meaning for business of a company OASIS SOA Adoption Blueprints The SOA adoption blueprints can be seen as a set of functional descriptions of a service identification process. It provides a business problem statement, a set of business requirements and a normative Copyright SHAPE Consortium Page 58 / 114

59 set of functions to be fulfilled where vendor specific details are abstracted. It is supporting the use of the OASIS SOA reference model [OASIS 2006] and reference architecture [OASIS 2008], which spans over the whole Service oriented architecture with the intent to describe its core information. The Oasis blueprints consist of these elements: OASIS methodology: The OASIS methodology is highlighting the road on how to recognize and describe which services are needed to realize the business goals, objectives and the necessary capabilities [OASIS 2005]. OASIS reference model: A reference model is an abstract framework for understanding and describing important entities and their relationships, i.e. an ontology. The OASIS reference model has as a primary goal to create a foundation for a SOA vocabulary. It raises the question on what a "service oriented architecture" is and tries to address this. The reference architecture is more concrete as it expands the concepts in the reference model. OASIS reference architecture: A reference architecture describes a domain with respect to the abstract architectural elements from a non-vendor and technology independent view. As mentioned above, the OASIS reference architecture takes the reference model a bit further. Additional concepts are introduced due to the need for addressing the core questions of the reference architecture The OASIS methodology The methodology is in the context of the OASIS SOA reference model [OASIS 2006] and is addressing. Why services need to be defined; How to identify the shared and supporting services; The importance of a common language; How to define interactions between services at a high level; and The categorization of services for management But this methodology excludes: Defining how processes work between services. The full Enterprise or Solution Architecture. The technical requirements of services. The functional requirements of services. The implementation of services. Management of service programs. The SOA methodology provides a business problem statement, a set of business requirements, and a normative set of functions to be fulfilled, in which vendor specific details are abstracted. The methodology is supporting the use of the OASIS SOA reference model and reference architecture, which spans over the whole service oriented architecture. Well known architectural methodologies like Zachman [Zachman 1987] and others start the process of defining the business by investigating the context of the system or enterprise, the reason for its existence, and its intentions. This is a good starting point for both the business strategy identification and architecture elicitation The Big picture One of the major goals of creating a service-oriented architecture is to get the big picture. The big picture provides an overall guide to the enterprise, or a project, and will constitute the foundation for splitting the capabilities of the organizations or project into services. In addition it will provide a deeper Copyright SHAPE Consortium Page 59 / 114

60 understanding of how change requests may be handled and on how business change is embraced through IT support. The methodology describes a four step process to develop a service architecture: What, Who, Why and How. The methodology is mostly about the three first steps and provides only a direction for the fourth. The first step, What, is about defining the scope of the services and describe what they should offer. In the second step, Who, the external entities driving the services and the entities with whom they interact should be identified. In the third step, Why, the reason for why internal and external services should interact with each other should be clarified. The forth and last step, How, gives directions for how the services should be implemented Process The blueprint gives some guidelines for how to execute the methodology framework for service discovery, but does not pursue the approach of starting with the high level business processes as a baseline for service design. The distinct reason for this is that the process based discovery tends to drill down to the details to soon. Another reason is that process based service extraction seems to create silos of services, and according to the authors fail to create a common ground between processes. This methodology is first concerned about the broad What s of the business and only second drills down to discover the process as the orchestration of these whats OASIS reference architecture The OASIS reference architecture takes the reference model a bit further, and additional concepts are introduced due to the need for addressing the core questions of the Reference Architecture. The OASIS reference architecture for SOA follows the guidelines in ANSI/IEEE std recommended practice for architectural description for Software Intensive Systems [IEEE 2000]. The OASIS reference architecture aims to foster four principles. These are: Technology neutrality, platform independency. Parsimony, keeping it simple and minimizing the number of components and their relations. Separation of concerns, loose coupling and stakeholder need to know basis. Applicability, to cover as many aspects of the SOA as possible. Copyright SHAPE Consortium Page 60 / 114

61 Figure 29: The OASIS viewpoints The reference architecture for the SOA ecosystem provides tree main views corresponding to the viewpoints in figure Figure 29 above. The Business via Service view constitutes the foundation for conducting business in the context of SOA. The Realizing Service Oriented Architectures view addresses the detailed description of the participants, the services and its context, and how the services are realized at the platform independent modelling level. The Owning Service Oriented Architectures view is addressing how to own and maintain an evolving Service Oriented Architecture The business via services view The Business via Service view (cf. Figure 30) is related to the CIM level and contains four elements and the models for their description. The models are: the Stakeholder and Participant model, the Resources model, the Needs and capability model, and the Social structure model with extensions. Main concepts: To capture what SOA means for people using it to capture business Stakeholders: People, decision makers, analysts and standard architects Concerns: Conduct business safely and effectively Modeling methods: UML-class diagrams Copyright SHAPE Consortium Page 61 / 114

62 Figure 30: The Business via Services view The Realizing SOA view The realizing SOA view defines and describes the information needed to use, build, deploy, manage and manipulate a service. In addition to information and behaviour models used to define the service interface, the description also includes information needed to decide if the service is fitted for service consumers needs. Information describing service visibility, reachability, functionality, contracts and policies is also important in this picture. Figure 31: The Realizing SOA view Main concepts: Deals with requirements for constructing a SOA Stakeholders: Enterprise architects, business analyst, standard architect and decision makers. Concerns: Effective construction of SOA-based systems. Modelling methods: UML class, sequence, component and composite structure diagram. Copyright SHAPE Consortium Page 62 / 114

63 Owning SOA view Owning SOA view is about the different aspects of owning an SOA. An SOA based system is in a living and changing world and the environment the system is a part of is an ecosystem in a sense. To make the system adapt to the ecosystem, some management and governance are needed to ensure that all its components pull in the same direction. Figure 32: Owning SOA view Main Concepts: Issues involved in owning an managing a SOA Stakeholders: Decision makers, Service providers and Service consumers. Concerns: Processes for engaging in an SOA are effective, fair and assured. Modelling techniques: UML class diagrams. This view focuses on, as seen in Figure 32, three aspects of managing and governing SOA: security, governance and Services as managed entities The Open Group SOA Ontology In June 2008 the Open Group made a public release for comment of its SOA ontology [Open Group 2008]: Draft version of SOA ontology This Technical Standard defines a formal ontology for Service Oriented Architecture. Service-Oriented Architecture (SOA) is an architectural style that supports service orientation: a way of thinking in terms of services and service-based development and the outcomes of services. The ontology is written in the Web Ontology Language (OWL) defined by the World-Wide Web Consortium. The ontology uses OWL-DL, the sublanguage that provides the greatest expressiveness possible while retaining computational completeness and decidability. The first Chapter provides an introduction to the whole document. Chapter 2: Services Basic Definitions describes the basic concepts associated with services. Chapter 3: Services as Business Copyright SHAPE Consortium Page 63 / 114

64 Activities describes the concepts associated with activities, and in particular business activities, and describes how they relate to services. Chapter 4: Design and Implementation describes concepts related to the implementation of services, such as choreography, and orchestration. Chapter 5: Architecture and Governance describes concepts related to the development and management of service-oriented architectures, and to the governance of their development, implementation and operation. The Appendix contains the formal OWL definitions of the ontology, collected together. The ontology was developed in order to aid understanding, and potentially be a basis for model-driven implementation. To aid understanding, it can simply be read. To be a basis for model-driven implementation, it should be applied to particular usage domains. And application to example usage domains will aid understanding. The ontology is applied to a particular usage domain by adding to it instances which are things in that domain. This is sometimes referred to as populating the ontology. In addition, an application can add definitions of new classes and properties, can import other ontologies, and can import the ontology into other ontologies. This technical standard uses example applications to illustrate the ontology. One of these, the carwash example, is used consistently throughout to illustrate the main concepts. Other examples are used ad-hoc in individual sections to illustrate particular points. The ontology defines the relations between terms, but does not prescribe exactly how they should be applied. The sections of this Technical Standard that use the car-wash example are describing one way in which the ontology could be applied in a practical situation. Different applications of it to the same situation would nevertheless be possible. For instance, Joe's bucket becoming empty is not regarded as an event in the car-wash example as described in this standard, but it would be quite possible to treat this as an event. The precise interpretation of the terms of the ontology in particular practical situations is a matter for users of the ontology, and is not constrained by the ontology definition. The use of a term by an application does not imply that the term is used accurately or truthfully. Service is the core concept of this ontology. It is a concept that is well-understood in practice, but is not easy to define. The ontology assumes the following definition, which was developed by The Open Group s SOA Work Group. A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports). It is self-contained, may be composed of other services, and is a black box to its consumers. In the ontology: The class Service is defined as a subclass of the Activity class; Outcomes of services are instances of the class Effect, which is related to Service by the is effect of property; A service composition is an instance of the Composition class; A Description can describe a service as a self-contained black box ; A service consumer is an instance of the class Actor, which is related to Service by the consumes property. This chapter describes the basic concepts of the ontology: Services; Providers and Consumers; Effects; Information; and Systems and Composition. Copyright SHAPE Consortium Page 64 / 114

65 Service is the most fundamental concept of this ontology. This section describes the Service class. Services are activities The Service Class <owl:class rdf:id="service"> <rdfs:subclassof rdf:resource="#activity"/> </owl:class> A service is a logical representation of a repeatable business activity. The class Service is defined here as a subclass of the Activity class. A service has a provider, may have multiple consumers, and produces one or more effects (which have value to the consumers). The providers and consumers are actors Analysis and comments from the UPMS team Reference UPMS, we should attempt to align the terms XSD, WSDL and SCA are not referenced? OASIS SOA reference model and OASIS SOA reference architecture are not referenced. Explain the difference between conforming system and conforming application (I assume this means an application of this ontology using OWL?) The OWL XML fragments are distracting and not useful for readers. Prefer diagrams over XML. The XML is available in a separate document anyway. Provide links from the graphics to the XML elements if desired. Why not use standard UML notation instead of making one up? Ontology appears to be a UML class model where all properties are typed by other classes and shown using association notation. What is described as Service in section 2.1 sounds more like a function. This can lead to functional decomposition rather than SOA. Service should be a set of related capabilities offered by one participant to other participants having matching needs. This introduces the possibility of many functions involved, not just one, and a protocol or interaction between consumers and providers as the service is carried out. This keeps the notion of service focused on the connection between participants with capabilities and needs and leads to more of an architectural view. So a service should not be a kind of activity, but rather implemented by an activity or collection of activities. A service is an interaction point or port owned by a participant who is able to provide the service capabilities through its owned activities. But I see later that your notion of activity is very broad, and can cover this collection of many actions. Consider keeping Activity simple, and make complex things out of collections of activities. This is what UPMS (and UML) does with Class or Component owning many Activities which may be methods for operations representing capabilities provided by the component and available as services. The key distinction is that service is the interaction or connection point between the consumers and providers, not the activity that implements the capabilities. This keeps it an interface concept focused on connections which establishes the coupling in the SOA. A composition is a participant whose internal structure consists of references to other connected participants - an assembly of participants for some purpose. Use the term Participant for service consumers and providers not Actor - Actor has a long history in use cases and will be confusing to many. In UPMS, Service is a kind of Port of a Component (or Participant) through which consumers and providers interact. A Service consists of provided and required Interfaces which have Operations that define the capabilities (and needs) available through the service. Each operation can have a set of preconditions that must be true before the operation can be used, and post-conditions that are true upon successful completion. At the completion of the Copyright SHAPE Consortium Page 65 / 114

66 protocol for a service (which could be a single operation, or complex interaction between the consumer and provider involving many operations), some milestone may be reached or effect achieved which can be seen as the union of all the post-conditions. Information: UPMS distinguishes DataType and Message to reflect common RPC vs. document-centred interaction styles. These distinctions seem to be important to the SOA community 3.5 Agent-oriented methodologies Overview In accordance to [Ghezzi, et al. 2002], a methodology is a collection of methods covering and connecting different stages in a process. The purpose of a methodology is to prescribe a certain coherent approach to solving a problem in the context of a software process by preselecting and putting in relation a number of methods. Thus, in contrast to agent modelling languages, agentoriented methodologies provide mechanisms that support the design, analysis, and development of agent systems. In particular, this means in accordance to [Bordini, et al. 2007]: Concepts define the core building blocks used of the methodology. As already mentioned earlier, for agents a single set of basic concepts is not yet universally accepted or know, so each methodology focuses on concepts considered as most important. Process defines the order in which the different software development phases are applied. In general, the process comprises several phases like the analysis phase, design phase, or the implementation phase. Models and Notation are the artefacts generator during the analysis and design. These models are depicted using some notation, often graphical. Techniques usually formulated as heuristics guide the use through the existing phases in order to refine the developed design. Tool support is an essential feature of a methodology in order support the user during the various design phases. Tools can range from simple drawing packages, to more sophisticated design environments that provide various forms of consistency checking. Thus, in principle, a methodology can be understood as collection of methods covering and connecting different stages in a process. At this, the purpose of a methodology is to prescribe a certain coherent approach to solving a problem in the context of a software process by preselecting and putting in relation a number of methods. A methodology has two important components: (i) one component that describes the process elements of the approach, and one component that focuses on the work products and their documentation. AOSE methodologies mainly try to suggest a clean and disciplined approach to analyze, design and develop MASs, using specific methods and techniques. They typically start from a metamodel that identifies the basic abstractions to be exploited in agentbased development. On the base of this, they exploit and organize these abstractions so as to define guidelines on how to proceed in the analysis, design, and development, and on what output to produce at each stage. As Figure 33 depicts, several agent-based methodologies exist in the MAS community, like for instance, AALAADIN [Ferber and Gutknecht 1998], MESSAGE [Caire, et al. 2001], ROADMAP [Juan and Sterling 2003], etc. In the following section we specialize on the methodologies ADELFE, Gaia, PASSI, Prometheus, and Tropos. Each of them is designed in accordance to a particular metamodel. A first proposal to develop a unified metamodel was discussed in [Bernon, et al. 2004] by merging the metamodels of ADELFE, PASSI, and Gaia. Copyright SHAPE Consortium Page 66 / 114

67 3.5.2 Gaia Figure 33: Various existing agent-oriented methodologies [Sudeikat, et al. 2004] Principles: Gaia [Wooldridge, et al. 2000, Zambonelli, et al. 2003] has been designed to explicitly model and represent the social aspects of open agent systems, with particular attention to the social goals, social tasks or organizational rules. In Gaia, an agent is an entity that plays one or more roles where a role is a specific behaviour defined in terms of its responsibilities, permissions, activities and interactions with other roles. An agent plays a role by actualizing the behaviour in terms of service to be activated and de-activated in dependence of specific pre and post-conditions. Metamodel: The metamodel of Gaia is depicted in Figure 34. The main concept of Gaia is AgentType which is part of an Organisation, collaborates with other AgentTypes provides Services and plays several Roles. Additionally, a Role refers to Activities. The roles Initiator and Participant act in a Communication that specifies a Protocol PASSI PASSI (Process for Agent Societies Specification and Implementation) [Cossentino 2005] is an agentbased methodology to design MAS. PASSI conciliates classical software engineering concepts like problem and solution domain with the potentiality of the agent-based approach by integrating design models and concepts from both Object Oriented Software Engineering and MAS using UML notation. The convergence between agents and traditional issues of software engineering is obtained by introducing a new abstraction layer (agency domain). The communication and implementation in PASSI are FIPA-based. In [Chella, et al. 2004] an extension to PASSI called Agile PASSI has been presented that leads to a faster development process mainly oriented toward the code generation. Copyright SHAPE Consortium Page 67 / 114

68 Figure 34: The Gaia metamodel [Bernon, et al. 2004] Principles: PASSI covers in accordance to [Chella, et al. 2004] the following five phases of software development: In the system requirements phase a use-case based description of the functionalities and an initial decomposition of them is produced. The agent society phase is used to compose a model of domain ontology, social interactions and dependencies among the agents. In the agent implementation phase the solution architecture is modelled in terms of required agents, classes and methods. It includes a structural definition as well as a behaviour description of the whole system. The code phase aims to model a solution at the code level. It is largely supported by patterns reuse and automatic code generation. In the deployment phase the distribution of the system parts across a distributed platform is modelled. Furthermore, facilities for testing single agents as well as the whole society of the MAS after deployment are provided. Metamodel: The PASSI metamodel is organized in three different domains: Solution domain, agency domain and problem domain. The solution domain covers the concepts FIPA-Platform Agent, Service Description and FIPA-PlatformTask. The agency domain covers aspect like Agent that has a set of Roles that provide a Service and solve Tasks that includes a set of Actions. Furthermore, the Role is connected to Communication that works on Agent Interaction Protocols with a set of Performatives. The problem domain contains concepts like Resource, Non Functional Aspects and Requirements that are connected with the Agent. Copyright SHAPE Consortium Page 68 / 114

69 3.5.4 ADELFE Figure 35: The PASSI metamodel [Bernon, et al. 2004] Principles: ADELFE [Bernon, et al. 2002, Bernon, et al. 2005, Picard and Gleizes 2004] specifies a methodology to develop adaptive MAS by concentrating on cooperative behaviour. ADELFE is based on adaptive MAS and therefore a great effort is done in order to study all the situations that could enable or inhibit the cooperation among agents. The cognitive and behavioural representations of the agent are given in terms of its attitudes, skills and characteristics. Agents interact either via direct communications or via the environment. The development process of ADELFE is divided into four phases: In the preliminary requirements phase the user requirements are defined and validated. The final requirements phase the environment is characterized and the use case is determined. Furthermore, the developed prototype is elaborated and validated. In the analysis phase the domain is analyzed, the agents are identified, and the interaction between entities in studied. Finally, in the design phase the detailed architecture and the MAS model are studied. Metamodel: The metamodel of ADELFE is depicted in Figure 36. The core element within this metamodel is the Cooperative agent (i.e., an Element that is owned by the Environment) that possesses has a social attitude which is implemented using rules that allow to solve and detect Non Cooperative Situations (NCS). Specializations of the NCS are: Incomprehension, Ambiguity, Incompetence, Concurrency, Conflict, Unproductiveness and Uselessness. A Cooperative agent possesses a Representation of the world, i.e. beliefs about other agents, the physical environment, or the agent itself, that are used to determine the agent s behaviour. The Communication with other agents could be either done directly by exchanging messages or through the environment. Agent Interaction Protocols (AIPs) are used as pattern to exchange messages. An agent can have Perceptions which are used to receive information from the environment, Aptitudes allow the agent to reason about its knowledge and beliefs. Furthermore, the agent has Skills that are particular knowledge that support the agent to realize its task and functions and Characteristics which are intrinsic of physical properties. Copyright SHAPE Consortium Page 69 / 114

70 3.5.5 Tropos Figure 36: The ADELFE metamodel [Bernon, et al. 2004] Principles: Tropos [Bresciani, et al. 2004] is an agent-oriented methodology based on the concepts of actor and goal. The Tropos methodology consists of five phases [Giorgini, et al. 2001]. The early requirements phase deals with the problem understanding by studying the existing organizational setting. The output of this phase is an organizational model that defined relevant actors and their respective dependencies. The late requirements phase deals with the describing how the system should be within its operational environment, along with relevant functions and qualities. The output of this phase is a (small) number of actors which have a number of dependencies with actors in their environment. The architectural design phase deals with the definition of the systems global architecture, i.e. subsystems, interconnected through data and control flows. The detailed design phase deals with the definition of each architectural component in further detail in terms of inputs, outputs, control, and other relevant information. Thereby, Tropos adopts elements of AUML. Finally, the implementation phase deals with the implementation of the system. Thereby, Tropos uses the agent platform Jack Intelligent Agents. In [Perini and Susi 2005], a MDA approach to the transformations in the Tropos methodology is presented. Metamodel: The concepts related to the Tropos actor diagram are depicted in Figure 37. The core concept of this metamodel is the concept of Actor and its specializations Position, Agent and Role, where a Position covers at least one Role and an Agent may play Roles and may occupy Positions. Furthermore, an Agent may want Goals that are either HardGoals or SoftGoals. A Dependency defines a relationship between a depender (i.e. Actor), dependee (i.e. Actor) and a dependum (i.e. Goal, Plan or Resource). The concepts related to the Tropos goal diagram are depicted in Figure 38. The core concept of this metamodel is the concept of a Goal that can be analyzed by an Actor using Means-End Analysis, Boolean Decomposition and Contribution. The Means-End Analysis defines a relationship among the Actor (whose point of view is presented in the analysis), a Goal (the end) and feasible Plans and Resources (the means). The Contribution defines a relationship among the Actor (whose point of view is presented in the analysis) and two Goals to identify Goals that can positively or negatively affect other goals. Decomposition defines a relationship for a generic boolean decomposition of a root Goal into sub-goals, that can be in particular an AND- or an OR decomposition specified via the attribute Type in Boolean Decomposition which is a specialization of Decomposition. Further metamodel extensions of Tropos are discussed in [Susi, et al. 2005]. Copyright SHAPE Consortium Page 70 / 114

71 Figure 37: The Tropos metamodel related to the actor diagram [Susi, et al. 2005] Figure 38: The Tropos metamodel related to the goal diagram [Susi, et al. 2005] Prometheus Principles: In accordance to [Padgham and Winikoff 2002a, Padgham and Winikoff 2002b] Prometheus is detailed and complete in the sense of covering all activities required in developing intelligent agent systems. Furthermore, the authors argue that it is a generic modelling language that can be used for any MAS architectures and environment, even if it has been mainly be used for designing BDI agents. The Prometheus methodology consists of three phases [Padgham and Winikoff 2002a]. The system specification phase is used for specifying goals and scenarios. The system s interface to its environment is described in terms of actions, percepts and external data. Furthermore, functionalities are defined in the phase. The architectural design phase is used for identifying the agent types. The system s overall structure is captured in a system overview diagram. Scenarios are developed into interaction protocols. Finally, the detailed design phase is used for developing the details of each agent s internals that are defined in terms of capabilities, data and events. Prometheus Copyright SHAPE Consortium Page 71 / 114

72 [Padgham and Winikoff 2002b] is another well-known agent-oriented methodology that starts its modelling process by determining the systems percepts and actions. It follows with the definition of functionalities. In Prometheus the interaction protocols are modelled using AgentUML and the target implementation platform is BDI-style oriented. Metamodel: The metamodel of Prometheus is divided into two parts. Figure 39 depicts the concepts needed within the system specification phase, whereas Figure 40 depicts the concepts needed within the detailed design phase. Prometheus distinguishes between two sorts of Goals, namely AbstractGoal and ConcreteGoal (see Figure 39). The main difference between both is that the AbstractGoal have children which are again Goals. A Scenario consists of a set of concepts called StepOf-Scenario which is the parent class for the specializations ScenarioStep, GoalStep, ActionStep and PerceptStep. A Role could achieve Goals, has access to Data and has to handle Percepts. The core concept of the detailed design phase is the concept of an Agent (see Figure 40). An Agent may have access to a set of Capabilities, owns a set of Plans, plays a set of Roles. Additionally, the Agent may be either participant or initiator of a Protocol/Interaction which again refers to ExternalMsg which is like the InternalMsg a specialization of Message. Copyright SHAPE Consortium Page 72 / 114

73 Figure 39: The Prometheus metamodel (part 1) [Dam, et al. 2006] Figure 40: The Prometheus metamodel (part 2) [Dam, et al. 2006] 3.6 Semantic Web Service (SWS) modelling This section provides an overview of Semantic Web Services (SWS) and analyses the state-of-the-art in methodological support for modelling and building SWS-enabled applications. This shall serve as Copyright SHAPE Consortium Page 73 / 114

74 the basis for the extensions towards semantically enabled SOA technologies that shall be defined within the SHAPE framework and methodology. The following first explains the aim and motivation of the SWS approach, and then provides an overview of the most prominent frameworks. Finally, we inspect the current status on methodological support for modelling, building, and maintaining SWS applications The SWS Approach The aim of Semantic Web services (SWS) is to overcome the deficiencies of the initial Web service technologies, especially for the service detection and usability analysis. WSDL and UDDI limit this to manual inspection, which is not considered to be suitable for managing large-scale and dynamically changing SOA applications. To better support and automate the service detection and usability analysis, the SWS approach is to extend Web service descriptions with sufficiently rich annotations and, upon this, provide inference-based techniques for automating the detection and usage of Web services. Several research and development efforts work on SWS technologies, and there exists a wealth of work on this. We here provide a concise overview, referring to exhaustive literature for further details (e.g. [Cardoso and Sheth 2006], [Fensel, et al. 2007], [Studer, et al. 2007]). Essentially, SWS technologies apply reasoning techniques on formalized descriptions in order to better support the usability analysis of Web services and also to handle the integration problem on a semantic level. The primary tasks that can beneficially be supported by SWS technologies are discovery as the detection of suitable Web services for a given task, composition as the combination of several Web services to solve a more complex task, and mediation as the handling of heterogeneities that may occur between the requester and the provider. For this, the SWS approach extends Web service descriptions as follows (cf. Figure 41): 1. Instead of XML, ontologies are used as the data model for describing Web services. These provide formalized knowledge models of a domain that allow advanced information processing. Moreover, this pursues the alignment of Web services with the Semantic Web for which ontologies are considered as the base technology (see below). 2. Apart from non-functional aspects such as the owner, usage rights, quality-of-service and financial information, also the provided functionality is formally described. This facilitates the use of semantic matchmaking techniques for more precise Web service discovery. 3. The Web service interface for consumption, i.e. the WSDL description, is formally described in order to support automated compatibility analysis of the communication behaviour supported by the client and the Web service. 4. In addition, the aggregation of Web services describes how a complex Web service achieves its functionality by combining several other Web services. This aims at automated techniques for analyzing the executability of Web service aggregations in more complex SOA applications. Copyright SHAPE Consortium Page 74 / 114

75 Figure 41: From WS to SWS On the basis of such comprehensive semantic annotations of Web services, research around the SWS approach develops inference-based techniques for supporting the service detection and usability analysis. The ultimate aim of the SWS approach is to automate the complete Web service usage process with inference-based techniques that expose a sophisticated processing quality. Figure 42 illustrates the workflow of SWS environments for this. The input is a concrete client request that shall be solved by detecting and executing the suitable Web services; the grey boxes denote the necessary techniques for this. The first processing step is Discovery, which is concerned with the detection of suitable candidates out of the available Web services. This commonly is realized by semantic matchmaking of formal functional descriptions. Then, the usability of the discovered candidates is inspected in more detail. The Selection and Ranking component either selects one of the candidates or determines a priority list for the further processing with respect to quality-of-service criteria as well as other non-functional aspects, and the Behavioural Compatibility component checks whether the communication between the requester and the Web services can be carried out successfully. If this is given, then the executor automatically invokes the Web service in order to solve the client request. If a single suitable Web service does not exist, then the Composer is invoked which tries to construct a combination of several Web services for solving the request, utilizing the previously mentioned components. In addition, Mediation facilities can be employed in order to handle potentially occurring mismatches that hamper the successful interaction between the requester and the provider. Copyright SHAPE Consortium Page 75 / 114

76 Figure 42: SWS Techniques for Automated Web Service Usage SWS Frameworks We now present SWS frameworks that define comprehensive specifications for semantically describing Web services, in general following the approach as out lined above. The aim is to provide an overview of the conceptual frameworks that most of the research on Semantic Web services is based upon. As the most relevant ones, we here depict the approaches that have been submitted to or published by acknowledged standardization bodies OWL-S As the chronologically first approach for SWS, OWL-S defines an upper ontology for semantically annotating Web services. This has been developed in the years , driven by a mostly USbased consortium under the DAML programme (see The OWL-S model defines three elements for describing Web services as shown in the figure. Every element is defined on the basis of a domain ontology, using the standard ontology language OWL (W3C Recommendation). Copyright SHAPE Consortium Page 76 / 114

77 Figure 43: OWL-S Meta Model 1. the Service Profile holds information for Web service advertisement, containing the name of the service, its provider, a natural language description, and a formal functional description defined in terms of the in- and outputs, preconditions and effects (short: IOPE) 2. the Service Model describes how the Web service works whereby the service is conceived as a process. The description model defines three types of processes (atomic, simple, and composite processes), whereof each construct is described by IOPE along with basic controland dataflow constructs. 3. the Service Grounding gives details of how to access the service, which is realized as a mapping from the abstract descriptions to WSDL. The intended usage of OWL-S description is as follows. The service profile relates to the information stored in UDDI repositories. While the natural language descriptions are for human consumption, the formal functional description is used for automated Web service discovery by semantic matchmaking. The service model formally describes the external visible behaviour of a Web service, i.e. how to invoke and consume the service and what happens when it is executed. This is used to determine whether the communication between a client and the Web service as well as with other aggregated Web services can be carried out successfully. Finally, the service grounding maps the abstract semantic descriptions to conventional Web service technologies in order to conduct the actual message exchange for execution. Although being criticized in several aspects, OWL-S has served as the basis for various SWS research and development activities The Web Service Modeling Ontology WSMO The Web Service Modeling Ontology WSMO is developed by a European initiative since 2004 (see It takes a broader approach than OWL-S, aiming a comprehensive framework for semantically enabled SOA technologies. For this, it defines four top-level notions: ontologies that specify the domain knowledge, goals that describe objectives that clients want to achieve by using Web services, semantic description of Web services, and mediators for resolving potentially occurring heterogeneities (see Figure 44). Copyright SHAPE Consortium Page 77 / 114

78 Figure 44: The WSMO Meta Model In contrast to the other frameworks, WSMO does not only cover the semantic annotation of Web services but propagates a goal-based approach for Semantic Web services along with mediation as an integral part. The idea is that a client formulates requests in terms of a goal, which formally describes the objective to be achieved while abstracting from technical details; the system then automatically detects and executes the suitable Web services in order to solve the goal. The notion of goals provides an explicit element for the client side of SOA applications which allows lifting the Web service usage by clients to the level of problems that can be solved. In addition, integrated mediators facilitate the handling and resolution of potentially occurring heterogeneities that can be expected in open and decentralized environments like the Web and may hamper the successful interaction between clients and Web services. The WSMO framework defines description models for all four elements along with an own specification language. Web services are described by non-functional properties, a capability that specifies the provided functionality in terms of preconditions, assumptions, post conditions, and effects, a choreography interface that describes how a client can invoke and consume a Web service, and an orchestration interface that describes how the Web service interacts with other Web services to achieve its functionality. WSMO provides an own specification language called WSML ( which is a conceptual language for the WSMO elements along with five variants of logical languages that corresponds to the ontology languages developed for the Semantic Web. Several tools are provided for WSMO, including a suite of reasoners for the different variants and an API for the programmatic management of WSMO elements and definitions. Moreover, there are implementations for execution environments for Semantic Web services, namely the reference implementation WSMX ( and the Internet Reasoning Services IRS which provides a broker for Semantic Web services ( Semantic Web Services Framework (SWSF) The Semantic Web Services Framework (SWSF) has been developed by a joint working group of industrial and academic researchers [Battle, et al. 2005]. Essentially, it provides an extension of OWL- S that aims at replacing the initial, insufficient specification model and language for the Service Model with an appropriate formal process language. The major contribution of SWSF is a rich behavioural process model based on the Process Specification Language (PSL). SWSF provides two formalizations: (1) FLOWS is based on First-order logic with extensions form situation calculus to model changes of the world; (2) SWSLRules is a logic programming language that serves as both a specification and implementation language and provides support for tasks like discovery, contacting, and policy specification for Semantic Web services. Copyright SHAPE Consortium Page 78 / 114

79 Semantic Annotations for WSDL (SAWSDL) While the previously presented approaches have been published as W3C member submissions, Semantic Annotations for WSDL and XML Schema (short: SAWSDL) is the only official W3C technology recommendation for Semantic Web services existing at this point in time [W3C 2007]. In contrast to the other framework that define comprehensive frameworks for semantically describing Web services, SAWSDL defines extensions to WSDL in order to semantically annotate the XML data types as well as the messages and operations in a WSDL description. For this, a WSDL document is augmented with additional tags that refer to an external domain ontology. SAWSDL consists of two parts as illustrated in Figure 45: the mappings of XML schema defines to ontology concepts in order to define the correspondence of SOAP message contents to ontology data, and the semantic annotation of WSDL operations. For the latter, SAWSDL limits the annotation by referring to ontology concepts but does not support the definition of preconditions and effects, which limits the annotations to merely consists of keywords associated with a domain ontology. Summary and Comparison A comparison of the frameworks reveals the following commonalities and differences. OWL-S as the first approach defines a description model for Web services that covers all aspects of the SWS approach as described above, i.e. non-functional aspects, a formal functional, and descriptions of Web service interfaces for consumption and aggregation. This uses OWL as the specification language, thus is compliant with the W3C standards for the Semantic Web. SWSF extends and refines this approach with a richer process description model and more expressive specification languages. WSMO is a more exhaustive framework that propagates a goal-driven approach along with integrated mediation facilities. This goes beyond the idea of merely annotating Web services, aiming at an allembracing semantic SOA technology. WSMO defines an own specification language that covers all ontology languages that are considered for the Semantic Web, and provides reasoners for this along with a set of development tools as well as reference implementations. WSDL-S only partially realizes the SWS approach, therewith can be considered as a light-weight framework. However, it follows the W3C tradition of extending existing standards, and it has served as the conceptual basis for SAWSDL as the only approach for the semantic annotation of Web services that is recommended by a standardization body as of today. Copyright SHAPE Consortium Page 79 / 114

80 3.6.3 SWS Methodologies Figure 45: SAWSDL Meta Model We now examine the state-of-the-art in methodological support for the construction of SWS-enabled SOA systems. As the research on SWS technologies is a rather new discipline, elaborated and usecase-verified methodologies do not yet exist. Thus, it is one of the objectives of the SHAPE project to develop a MDA-driven methodology for the development of SWS-enabled SOA systems. The following presents initial methodology that has been identified in EU projects related to SHAPE, and the Web Service Modeling Toolkit an Integrated Development Environment for WSMO that will be extended in the course of the SHAPE project An Initial Methodology The following presents a methodology for constructing SWS-applications that has been extracted from practical use case experiences in the EU research projects DIP ( and SUPER ( This shall serve as a basis for defining the SHAPE methodology extensions for Semantic Web Services. 1. Scoping: identify target system purpose business aims required services identify legacy systems to be integrated 2. Develop Domain Ontologies for semantic annotations (applying Ontology Engineering Methodologies, see elsewhere) 3. Create Semantic Descriptions for Services & User Request Copyright SHAPE Consortium Page 80 / 114

81 Functional Descriptions Non-functional descriptions Behavioural Descriptions 4. Select / Develop required SWS techniques Identify required SWS techniques (e.g. discovery / composition / mediation) Analyze existing solutions Select most suitable ones / develop missing ones Integrate in SWS execution environment 5. Test / Evaluate in Testing Environment 6. Deployment (to live system) 7. Monitoring & Maintenance The Web Service Modeling Toolkit (WSMT) The Web Services Modeling Toolkit (WSMT) is an Integrated Development Environment (IDE) for Semantic Web Services implemented in the Eclipse framework. The WSMT aims to aid developers of Semantic Web Services through the WSMO paradigm, by providing a seamless set of tools to improve their productivity [Kerrigan, et al. 2007]. An Integrated Development Environment (IDE) is defined as a type of computer software that assists computer programmers to develop software. IDEs like the Eclipse Java Development Toolkit (JDT) and NetBeans for developing java software have proven that good tool support can improve the productivity of engineers. It could be said that the time of ontology and Semantic Web Service engineers is a more precious commodity, as the number of people who are currently skilled in conceptual modeling is much less than those that can code in Java. This underscores the need for adequate tool support for working with semantic technologies and an IDE can tie together these tools in such a way that the whole application is more than the sum of the parts that make it up. The main advantage of using the IBM Eclipse framework is the existence of other useful plug-in projects, for example the Eclipse Web Tools Platform (WTP), which provides tools for Web service technologies like WSDL and XML. This enables developers to put the WSMT and the WTP together to build their Web services and semantically describe them with WSMO. Editing: Firstly the actual descriptions must be created. It is important that users of different skill levels are supported within the IDE, thus editing support at different levels of abstraction should be provided. Considering ontologies, it may be more convenient for the engineer to create an ontology using a textual representation and then to use a graph based representation to learn more about the ontology. Validating: The most common problem that occurs when creating semantic descriptions is incorrect modeling. It can be very easy for an engineer to make a mistake without any tool support. Validation of semantic descriptions is a non trivial task and validation at both the syntactic and semantic levels can vastly reduce the time an engineer spends debugging an ontology. Testing: Once valid semantic descriptions exist the engineer needs to ensure that they behave in the expected manner in their intended environment prior to deploying them. Having testing integrated into the development environment reduces the overhead of the user performing a lengthy, iterative, deploy-test scenario. Deploying: Ultimately the descriptions created within the development environment must be used in some run-time system. Deploying descriptions can also be a huge overhead on the engineer and having tool support in an IDE can prevent mistakes occurring at this crucial stage of the process. WSMT focuses on three main areas of functionality, namely the engineering of WSMO descriptions, creation of mediation mappings and interfacing with execution environments and external systems. Copyright SHAPE Consortium Page 81 / 114

82 Towards these aims, the Eclipse editors and views available within the WSMT are broken up into three Eclipse perspectives. (1) The WSML Perspective for creating ontologies, incl.: a. WSML editors (text-based and form-based) b. Ontology Visualization c. Validation Service d. Integration with WSML Reasoners (2) The Mapping Perspective for creating mappings between ontologies, incl. a. Editors for Ontology Mappings (text-based & form-based) b. Visualization for Ontology Mappings c. Validation Service for Ontology Mappings (3) The SEE Perspective that integrates SWS execution environments, e.g.: a. The Web Service Execution Environment WSMX b. The Internet Reasoning Service IRS Variability modelling methodologies Variability increases the flexibility and reusing of services, which simplifying development and can cutting costs. It provides technologies to create special flavours (variants) of a service in order to meet the special requirements of a consumer. Variability exists within two dimensions [Pohl, et al. 2005]: Variability in time: means the evolution of products over time to meet new requirements of customers and the market. It is also called versioning. Variability in space: stands for the possibility to configure or extend a product to find a balance between reusability and individual requirements of consumers. In the context of the project the term Variability indicates only the space dimension. For the time dimension the term Versioning will be used. The consumer resolves the variability in a customizing-process, where can be distinguished between configuration and extension. Configuration means that an application will be developed with all functions, which can be selected, deselected or parameterized. Extension means that the application can be enhanced with additional functionality. This can be done in an explicit or implicit way. Explicit extensions are possible at preconceived and marked positions (e.g., Extension Points), while implicit extensions are possible on positions which are defined from the framework. For example the framework can provides the possibility to add code at the end or begin of methods or the insertion of additional attributes. Figure 46 illustrates the classification of customizing. Copyright SHAPE Consortium Page 82 / 114

83 Figure 46: Classification of Variability Next sections introduce some methodologies, which also pay attention for variability modelling. The methodologies originated in the area of Domain Engineering and not applied to services but they can provide ideas for developing a variability methodology for SHAPE. The requirements are: Model-based representation of service-oriented features (commonalties, variability and dependencies). Integration in the model-driven development chain to derive variants at different abstraction levels. Configuration at different binding times (design-, deploy-, run-time). Different scopes of extensibility interfaces depending of the user role FODA Feature-oriented Domain Analysis (FODA) [Kang et al. 1990] was introduced from the Software Engineering Institute (SEI) in 1990 and was refined and extended several times. Meanwhile, FODA is part of Model-Based Software Engineering (MBSE) program of the SEI. The defined process consists of three phases: 1. Context Analysis: In this phase the scope of the domain and relationships to other domains will be defined. 2. Domain Modelling: The goal of this phase is the modelling of the main commonalities and differences, which occurs in three steps: a. Information Analysis: The analysis yields an information model which comprises the domain entities and relationship between them. b. Feature Analysis: The result is a feature model which describes the customers understanding of the main capabilities (features) of the product. c. Operational Analysis: The behavioural relations between entities of information model and feature model are defined in the operational model. 3. Architectural modelling: In this phase the architecture for implementing a solution of the domain problem will be modelled. The most important part for variability modelling is the feature analysis step - an iterative process consisting following steps: 1. Capture similarities between instances, which are the common features. Copyright SHAPE Consortium Page 83 / 114

84 2. Capture differences between instances, which are the variable features. 3. Depict and organize the captured features in feature diagrams. 4. Examine combinations of features to find invalid or new ones. 5. Capture the additional information for features, like descriptions, rationales and binding time. FODA is the most well known methodology for modelling variable systems and was taken over in several further approaches, e.g., ODM [Czarnecki and Eisenecker 2005]. But FODA has also some shortcomings, e.g., Feature Models allows redundant representation for features [Bontemps, et al. 2004]. Furthermore, FODA doesn t say anything about connecting features with implementation artefacts FAST The FAST process (Family-Oriented Abstraction, Specification and Translation) was developed from Lucent Technologies and describes the developing of product lines and their derived products [Weiss and Lai 1990]. The process is depicted in Figure 47 rectangles stand for process steps and ovals stand for resulting products. The process steps are ordered in an activity tree and the resulting information in an artefact tree. Every process step is defined with the help of a PASTA-model (Process and Artefact State Transition Abstraction) which describes who should execute what, when and how, what is the resulting information and what are the conditions for finishing a process step. Figure 47: The Fast Process During the Domain Engineering phase the domain and the application engineering environment for the family will be designed and developed. The activity tree defines three main steps: 1. Domain Scoping 2. Domain Analysis 3. Domain Implementation Related to Variability Modelling the Domain Analysis is the most important step. The results of this step are a Decision Model and a Commonality Analysis. The Decision Model describes all decisions which must be made to create an application. FAST assumes the variability is exclusively described with parameters. Parameters have a predefined value range and a standard value. The Commonality Analysis is a document which contains following information in text and pictures: Introduction: short description of domain and relations to other domains. Definitions: glossary with the domain s technical terms. Commonalities: list with requirements applied to all applications of the family. Variability: list with requirements applied to the differences of family members. Copyright SHAPE Consortium Page 84 / 114