NEXOF-RA - Europa

NEXOF-RA • FP7-216446 • D6.3 • Version 1.0, dated 30/06/2010 • of 135

NEXOF-RA

NESSI Open Framework – Reference Architecture

IST- FP7-216446

Deliverable D6.3 The NEXOF Reference Model V3.0

All NEXOF-RA Partners, NESSI Strategic Project and External Contributors

Due date of deliverable: 30/06/2010 Actual submission date: 30/06/2010

This work is licensed under the Creative Commons Attribution 3.0 License.

To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

This work is partially funded by EU under the grant of IST-FP7-216446.


EXECUTIVE SUMMARY A reference architecture subsumes reoccurring and well-proven concepts and patterns of a set of specific software architectures [5]. The main goal of the NEXOF-RA project is to provide a reference architecture for service-based software systems which facilitates the reuse of well-proven service-oriented concepts. The NEXOF Reference Architecture is provided in form of a construction kit that guides the construction of specific service-based infrastructures. The construction kit consists of a set of building blocks implementing architectural patterns which in turn are related to a conceptual model. The NEXOF Reference Model captures the relevant entities and dependencies among them that constitute a service-oriented system on a conceptual level in order to foster the communication about the relevant elements on a higher abstraction level. This document is the final version of the NEXOF Reference Model specification and thus completely replaces the earlier version of the reference model (document D6.2 [21]). It is organised in three parts. The first part focuses on defining the syntax and semantics of the model. This includes describing the goals, scope and boundaries of the model and the terminology used within the model as well as across all NEXOF-RA documents. One section is dedicated to the introduction of the structure of the model. It is explained which views, concepts and diagram types are used for the different purposes of the model following the idea of separating structure and behaviour/functionality. Thus, the first part provides a guideline on how to read, use and interpret the model specification by explaining what the syntax and semantics of the different elements constituting the NEXOF Reference Model are. The actual specification of the reference model constitutes the second part of the document. Since the NEXOF Reference Architecture is structured into nine concerns, the specification of the model is organized according to those concerns. It defines the functionalities provided by a NEXOF compliant architecture qualifying the value of these functionalities by specifying the input-output relations along with the actors involved in these functionalities. Each diagram as well as all contained concept constituting the reference model are furthermore explained by textual descriptions and examples. The third part of the document focuses on the application of the NEXOF Reference Model in order to demonstrate how it can be used in practice. For this it is explained how the reference model is embedded into the overall NEXOF Reference Architecture with emphasis on the dependencies with other elements. First of all, the relations with the business- and system requirements are described, which form the baseline for the specified functionalities, and then with the patterns, which provide different ways of implementing the described functionalities. Furthermore, it is partially illustrated how the model can help in the derivation of actual NEXOF compliant architecture instances by using an example harbour scenario. The last section of the document draws a conclusion over the achievements of the NEXOF Reference Model during the course of the project. Finally, an


evaluation of the reference model and a detailed analysis of potential points for further work in the continuation of building the NESSI Open Service Framework are given. While the three main parts focus on the essential information about the model specification, this document is also accompanied by a set of appendices, which give more technical details of specific topics. This includes, among other things, a list of updated glossary terms in comparison to the last version, the complete set of functionality descriptions enriched with explicit dependencies towards the system requirements and references to the sources of the functionalities as well as the complete definition of the service term as provided by the Service Description Investigation Team.


Document Information

IST Project Number

FP7 – 216446 Acronym NEXOF-RA

Full title NESSI Open Framework – Reference Architecture

Project URL http://www.nexof-ra.eu

EU Project officer Arian Zwegers

Deliverable Number D6.3 Title The NEXOF Reference Model V3.0

Work package Number WP6 Title Reference Architecture: Model

Date of delivery Contractual 30/06/2010 Actual 30/06/2010

Status Version 1.0, dated 30/06/2010 final

Nature Report Demonstrator Other

Abstract (for dissemination)

Keywords

Internal reviewers UPM

CINI

Authors (Partner) All NEXOF-RA Partners, NESSI Strategic Project and External Contributors

Responsible Author

Vanessa Stricker Email [email protected]

Partner LDU Phone +492011834658

http://www.nexof-ra.eu/�


TABLE OF CONTENTS EXECUTIVE SUMMARY ........................................................................................... 2

TABLE OF CONTENTS ............................................................................................ 5

1 INTRODUCTION ................................................................................................... 7

1.1 Objectives of the NEXOF Reference Model .............................................. 8

1.2 Scope of this document ............................................................................. 9

1.3 Navigating Through the Document .......................................................... 10

PART I – NEXOF REFERENCE MODEL SYNTAX AND SEMANTICS ............ 12

2 THE NEXOF COMPLIANT PLATFORM VIEWPOINT ............................................... 13

2.1 Platform Definition ................................................................................... 13

2.2 Characteristics of NEXOF Compliant Platforms ...................................... 15

2.3 Relevance for the NEXOF Reference Architecture ................................. 17

3 REFERENCE MODEL TERMINOLOGY, SCOPE, AND STRUCTURE ............................ 18

3.1 Architecture-Related Terminology ........................................................... 18

3.2 Context Definition .................................................................................... 20

3.3 Separation into Structure, Behavior and Functionality Views .................. 26

3.4 Models and Concepts Used in the NEXOF Reference Model ................. 27

PART II –NEXOF RERFERENCE MODEL SPECIFICATION .......................... 31

4 THE NINE CONCERNS ....................................................................................... 33

5 SERVICE CONCERN .......................................................................................... 36

5.1 Structure View ......................................................................................... 37

5.2 Data Flow in the Service Concern ........................................................... 38

6 MESSAGE CONCERN ........................................................................................ 43

6.1 Structure View ......................................................................................... 44

6.2 Data Flow in the Message Concern ........................................................ 44

7 DISCOVERY CONCERN ...................................................................................... 49

7.1 Structure View ......................................................................................... 51

7.2 Data Flow in the Discovery Concern ....................................................... 52

8 COMPOSITION CONCERN .................................................................................. 58

8.1 Structure View ......................................................................................... 58

8.2 Data Flow in the Composition Concern ................................................... 59

9 PRESENTATION CONCERN ................................................................................ 65


9.1 Structure View ......................................................................................... 65

9.2 Data Flow in the Presentation Concern ................................................... 66

10 MANAGEMENT CONCERN ................................................................................ 71

10.1 Structure View ....................................................................................... 72

10.2 Data flow in the Management Concern ................................................. 73

11 SECURITY CONCERN ...................................................................................... 81

11.1 Structure View ....................................................................................... 82

11.2 Data Flow in the Security concern ......................................................... 83

12 RESOURCE CONCERN .................................................................................... 87

12.1 Structure View ....................................................................................... 87

12.2 Data Flow in the Resource Concern ...................................................... 90

13 FUNCTIONAL AREAS OF THE NEXOF REFERENCE MODEL ............................... 93

PART III – APPLICATION CONTEXT OF THE NEXOF REFERENCE MODEL 95

14 DEPENDENCIES OF THE MODEL WITH NEXOF REFERENCE ARCHITECTURE ELEMENTS ......................................................................................................... 96

14.1 The Structure of the Reference Architecture ......................................... 96

14.2 Relation to Requirements ...................................................................... 98

14.3 Relation to Patterns ............................................................................... 99

15 DERIVING INSTANCES OF NEXOF COMPLIANT ARCHITECTURES ...................... 101

15.1 Conceptual Instantiation Process ........................................................ 101

15.2 Harbour Scenario ................................................................................ 104

16 CONCLUSION ............................................................................................... 107

REFERENCES ................................................................................................... 109

APPENDIX A: FUNCTIONALITY SPECIFICATION..................................................... 112

A1: SERVICE ............................................................................................... 113

A2: MESSAGE.............................................................................................. 114

A3: DISCOVERY: .......................................................................................... 116

A4: COMPOSITION ....................................................................................... 118

A5: PRESENTATION ..................................................................................... 120

A6: MANAGEMENT ....................................................................................... 121

A7: SECURITY ............................................................................................. 123

A8: RESOURCE ............................................................................................ 125

APPENDIX B: SERVICES AND SOFTWARE SERVICES DEFINITION ........................... 129


1 INTRODUCTION Shaping the Future Internet around the new service-oriented paradigm has become an important task in research and industry, especially, considering the importance of this infrastructure as information, service, and networking means to the overall society world-wide. Taking the open world assumption of the Internet into account, the path towards the Future Internet reveals an omnipresent trend towards the integration and federation of heterogeneous service-based systems (SBS) from various domains. Different trends like software as a service, cloud computing, Internet of Services, Internet of Things, and web 2.0/3.0 result in the need for different types of architectures to support these different SBSs. Thus, the Future Internet needs to be architected in a way that allows the integration and federation of these SBSs. Considering the large number of technologies and standards that emerged to address different aspects of architectures for SBSs, defining a specific architecture that meets designated requirements is a challenging task. A reference architecture for SBSs as it is created within the NEXOF-RA project aims at providing guidance in this process. A reference architecture subsumes reoccurring and well-proven concepts and patterns of a set of specific software architectures [5]. The main goal of the NEXOF-RA project is to provide a reference architecture for service-based software systems which facilitates the reuse of well-proven service-oriented concepts. The need to capture and address the different (sometimes contradicting) requirements of different types of SBSs and their characteristics has resulted in the adoption of a pattern-based approach within the NEXOF-RA project. Each pattern that is part of the NEXOF Reference Architecture Specification is the specification of reoccurring, well-know architectural solutions for a certain architectural problem. The pattern-based approach has been implemented to allow the derivation of specific architectures for specific contexts in different domains following the generally known idea of architectural or design patterns (cf. [1], [14]). In this sense, the approach fosters the creation of a reference architecture as a system of patterns as described by Buschmann et al. (cf. [8], [9]) that can be composed when deriving a specific architecture (a NEXOF compliant architecture) in order to meet specific, given requirements. Accordingly, each different type of SBS is described by a system of patterns. In comparison to other existing reference architectures such as the OASIS reference architecture, this pattern-based approach has the characteristics of openness and extendibility that allows the integration and federation of different types of SBSs as well as the possibility to cope with new emerging trends in the future. NEXOF-RA does not provide a “one-fits-all” SOA solution but rather defines a reference architecture from which individual infrastructure instances that adhere to the principle of service-orientation can be derived according to different requirements and contexts. NEXOF-RA does not define characteristics to determine whether an IT system is service-oriented or not. However, it describes typical functionalities provided in a service-oriented environment in its conceptual view. This view will be used as a baseline for specifying different


(alternative) patterns for providing these functionalities and recommendations on how and when to use those patterns. In its ambition to provide a reference architecture that allows the easy derivation and creation of specific architectures, the pattern-based reference architecture can be seen as a construction kit for system architects and designers. This ambition raises different expectations going beyond the scope of traditional, well-known architectures. While all the different pattern families constitute the NEXOF reference Architecture Specification and provide certain architectural solutions to certain problem spaces decomposed into small parts, they are related to the NEXOF Reference Model which describes the SBSs that can be derived from the NEXOF Reference Architecture on a conceptual level independently from any implementation details. The NEXOF Reference Model captures the relevant entities that constitute such a SBS as well as their dependencies on a conceptual level in order to foster the communication about the relevant elements on a higher abstraction level1

1.1 Objectives of the NEXOF Reference Model

. This document constitutes the final version of the NEXOF Reference Model specification within the NEXOF-RA project.

The term “software architecture” traditionally addresses the organizational structure of all elements that are part of a software system [5] (see section 3.1 for further explanations on terminology). A software system can be differentiated into various types of elements, whose structure can be described by different architectural documents. A system provides an operational environment that allows the deployment of applications and processes. Accordingly, these systems can be divided into the infrastructure and the operative elements (e.g. services and service-oriented applications for service-based systems) that can be deployed independently. Service–based solutions provide - amongst other things - an infrastructure on which services can be deployed and executed in a distributed way. Thus, the NEXOF-RA project describes a reference architecture for distributed systems coming from different domains and of different types. However, the NEXOF Reference Architecture only addresses the architecture of the infrastructure. Concrete applications and services deployed on this infrastructure are not in the focus since the reference architecture should be domain independent and open. The infrastructure architecture addresses both the hardware infrastructure architecture and the software infrastructure architecture. Some basic services are also provided by the overall infrastructure in order to allow the operative elements to be exploited. Thus, the NEXOF-RA infrastructure can be perceived as an operating system for services and service-oriented applications. The NEXOF Reference Model specifies the conceptual view of this reference architecture while being technology and solution independent so that it provides an abstract description of all possible architecture instances. Compared to the 1 The NEXOF Reference Model is accompanied by a Glossary which can be found under www.nexof-ra.eu in its current version.

http://www.nexof-ra.eu/�


NEXOF Reference Architecture Specification, which describes HOW certain facilities of an infrastructure architecture can be achieved, the model describes WHAT facilities the infrastructure architecture provides to its surrounding, neglecting implementation solutions. Since the facilities and added value of the NEXOF Reference Architecture can only be described when considering the way in which it is used, the model does not only take entities and concepts related to the infrastructure architecture into account but also captures its context in which the SBS is embedded in. Thus, different stakeholders and their different usage purposes have to be considered to ensure that important requirements are addressed by the NEXOF Reference Architecture in terms of functionalities. Since the conceptual model is defined on a reference level and not for a concrete context, the services and service-based applications hosted on the infrastructure under development are only considered on a conceptual level by abstracting from business domains and technological solutions. In summary the reference model follows the two objectives:

• To describe (on a conceptual and generic level) a service-based system where different entities (organizations or individuals) interact to realize their business goals,

• To define the functionalities offered by a platform which can host service-oriented software applications of such a service-based system without defining how the functionalities are realized and without considering any specific business context.

The NEXOF Reference Model that is described in this document will be based on open standards and it is vendor and software platform independent while adhering to the principle of technology neutrality. Technology neutrality in the context of the architecture specification means that the implementation of the platform-components is open to the vendor. In the same way, the implementation of platform-services is open to the potential providers.

1.2 Scope of this document The version of the reference model presented in this document is based on the State-of-the-Art Analysis that has been performed at the beginning of the project ([19], [22]), on the requirements analysis [24], an analysis of existing standards and vendor solutions, results coming from NESSI Strategic Projects (NSPs), results from the NEXOF-RA Investigation Teams as well as State-of-the-Practice knowledge of the project partners. According to the sources that have been used, two tracks that have been followed to build the model can be differentiated:

• The first track follows a top-down approach starting from the State-of-the-Art analysis described in the NEXOF-RA Model V1.0 [19] and the State-of-the-Art Report [22] as well as the identified system requirements derived from the SotA analysis [24].

• The second track follows a bottom-up approach based on the State-of-the-Practice knowledge of the partners, investigation teams and other projects that focuses on a more detailed level on the needs of the user of the reference architecture.


The intermediate results of these tracks were an integrated SotA model, an initial nine concern model as well as a functional decomposition including the description of information entities and a high level view focusing on the behaviour related to NEXOF compliant architectures. All intermediate results have been consolidated in the final version of the reference model described in this document. Thus, it replaces the second version of the model [21]. Since the focus of the model is on the conceptual description of NEXOF compliant architectures, no specification activities are presented in this document. Although, the content of this document will show that the conceptual view and the specification of the reference architecture are closely related and cannot be clearly separated in every case, all definitions have been made from a conceptual point of view without considering any concrete implementation viewpoints. Thus, the standards that will be referenced in this document have only been used in order to analyse them with regard to the most important and generally accepted elements that should be part of an SOA infrastructure. The essence of those standards has been extracted and been considered in the concepts of the model on a conceptual level. However, the model is independent from any standard. No decisions about the adoption or the degree of adoption of specific standards are given within this document. The right place to elaborate and analyse any standard adoption or extension is within the specification deliverables. Quality aspects such as high availability and scalability are crucial aspects of SOA infrastructures and are explicitly addressed by a dedicated team within the project. However, they are not addressed in the presented conceptual model explicitly. Quality attributes can be ensured by different architectural solutions. That is why each pattern described within the NEXOF Reference Architecture has a dedicated section for describing the influence of the architectural solutions on different quality attributes. However, since those quality attributes are inherent characteristics of actual architectural solutions being part of NEXOF Compliant System instances, they cannot be expressed on a conceptual level independently from certain solution aspects in terms of structure, behaviour, and functionality.

1.3 Navigating Through the Document This document is portioned into three parts. The first part focuses on defining the syntax and semantics of the model. This includes a description of the goals, scope, and boundaries of the NEXOF Reference Model (Section 2), the terminology used within the model (Section 2) and across all NEXOF-RA documents, and an introduction to the structure of the model (Section 3). It is explained which views, concepts, and diagram types are used for the different purposes of the model following the idea of separating structure, behaviour, and functionality. Thus, the first part provides a guideline on how to read, use, and interpret the model specifications by explaining what to expect from the different elements constituting the NEXOF Reference Model. The reader familiar with the NEXOF-RA project and the structure of the NEXOF Reference Model can skip this part and directly move to the second part.


This second part constitutes the actual specification of the reference model. Since the NEXOF Reference Architecture is structured into nine different concerns (Section 4), the specification of the model is organized according to those concerns: service (Section 5), message (Section 6), discovery (Section 7), composition (Section 8), presentation (Section 9), management (Section 10), security (Section 11), and resource (Section 12). The analysis concern is not supported by the reference model or the reference specification in their current versions due to the prioritisation of the different research areas within the NEXOF-RA project according to the partner’s competencies. Each of the concern sections reflects the mentioned separation of structure, behaviour and functionality in its organisation. Every section is structured as follows:

• First an overview of the relevant functionalities and the involved entities is given by providing use case diagrams.

• Then the information entities relevant for the provided functionalities are qualified, and finally the described behaviour is specified in more detail by activity diagrams. These aspects clearly define the functionalities that should be provided by NEXOF compliant architectures by qualifying the value of these functionalities by specifying the input-output relations. Each diagram is accompanied by textual descriptions and examples.

• The third part of the document focuses on the application of the NEXOF Reference Model in order to explain how it can be used. It is explained how the reference model is embedded into the overall NEXOF Reference Architecture stressing the dependencies to other elements (Section 14). Especially the relations with the requirements, which are the baseline for the specified functionalities, and the patterns, which in turn provide different ways of implementing the described functionalities, are provided.

Furthermore, it is partially illustrated how the model can help in the derivation of actual NEXOF compliant architecture instances by using an example scenario of a service-base harbour management system (Section 15). The last section of the document contains conclusions where the achievements of the NEXOF Reference Model during the duration of the project are critically evaluated (Section 16). Furthermore, a detailed analysis of potential subjects for further work is provided to support the sustainability planning of the NEXOF Reference Architecture. While the three main parts of this document focus on providing the core information that is needed to understand the model specification, this document is also accompanied by a set of appendices that provide more technical details over the model parts:

• The complete set of functionality descriptions enriched with explicit dependencies with the system requirements and references to the sources of the functionalities (Appendix A)

• The complete definition of the service term as provided by the Service Description Investigation team (Appendix B)


2 THE NEXOF COMPLIANT PLATFORM VIEWPOINT ............................................... 13

2.1 Platform Definition ................................................................................... 13

2.2 Characteristics of NEXOF Compliant Platforms ...................................... 15

2.2.1 Openness .......................................................................................... 15 2.2.2 Extendability ...................................................................................... 15 2.2.3 Federation ......................................................................................... 16 2.2.4 Interoperability .................................................................................. 16

2.3 Relevance for the NEXOF Reference Architecture ................................. 17

3 REFERENCE MODEL TERMINOLOGY, SCOPE, AND STRUCTURE ............................ 18

3.1 Architecture-Related Terminology ........................................................... 18

3.2 Context Definition .................................................................................... 20

3.2.1 Boundaries ........................................................................................ 20 3.2.2 Different Stakeholders....................................................................... 21 3.2.3 Human vs. Agents ............................................................................. 23 3.2.4 Lifecycle Stages ................................................................................ 26

3.3 Separation into Structure, Behavior and Functionality Views .................. 26

3.4 Models and Concepts Used in the NEXOF Reference Model ................. 27

PART I – NEXOF REFERENCE MODEL SYNTAX AND SEMANTICS


2 THE NEXOF COMPLIANT PLATFORM VIEWPOINT In order to understand the scope and the structure of the NEXOF Reference Model, it is necessary to understand the subject that is addressed by the NEXOF Reference Architecture as the overall objective. A NEXOF Compliant Infrastructure (NCI) is a distributed SOA Infrastructure that is compliant with the NEXOF Reference Architecture, i.e. it is an implementation of a NEXOF Compliant Architecture that is derived from the NEXOF Reference Architecture. A NCI is distributed. It means that in most cases it is realized by means of a federated collection of sub-systems, named NEXOF Compliant Platform (NCP), deployed on different interconnected computational nodes. Each NCP is built by integrating a set of plugable platform-components, it is federated, and can co-operate with other NCPs through platform-services that build on a specific set of software technologies. This way of federating different platforms is especially important in the scope of an Internet scale infrastructure. It needs to be clear that this is a different goal than the creation of SOA infrastructures on an enterprise scale and holds different challenges. Mainly, in an enterprise IT environment, it is easier to standardize and also easier to establish an overlay layer – mostly referred to as middleware in SOA. Hence the focus will be on this layer and less on platforms. In an enterprise SOA environment, the integration of service platforms is only relevant for moving out IT functionality to external providers. The following picture shows a possible constellation of federated NCPs. Business services and applications are developed, deployed, and executed on top of the overall NEXOF Compliant Infrastructure.

NCP

Business Service

NCP

Business Service

NCP

Environment A Environment B Environment C

Figure 1: NEXOF Compliant Infrastructure

2.1 Platform Definition A widely accepted and rather pragmatic definition of a platform is "a place to launch software" [QUELLE]. Whereas this sounds simple, it provides actually a good criterion for distinction. With regard to the NEXOF understanding of platforms it is important to note that "service platforms" are in the focus. Service


Platforms mark a further evolutionary step beyond "hardware platforms" and "software platforms". The concept of "service platforms" is very fundamental to NESSI and NEXOF. The three different types can be described as follows:

• A hardware platform is the fundamental type of platforms in computing. For example the IBM PC architecture based originally on the x86 processor and several standard ways of handling I/O and bus information. Intel has been using the x86 processor architecture in many following generations to continue to comply with this platform. Still there are new hardware platforms emerging e.g. for Gaming or in the mobile or Internet of Things domain.

• Fundamental software platforms are operating systems – they allow the execution of software applications on different hardware platforms (e.g. Linux running on Intel-based PCs, Macs, and up to Mainframes). Another evolutionary step are software platforms such as Java that allow the execution of software applications even independently from a specific operation system as they introduce a further layer of abstraction via virtual machine technology.

• A service platform introduces a next level of abstraction - it is not just a place to execute software, it is a place to execute a service. This is for example relevant in the emerging field of cloud-service platforms (e.g. as provided by the Amazon Elastic Compute Cloud E2C). On these platforms it is not only possible to execute software applications but also to combine the execution with service characteristics – for cloud services this is called "elasticity rules". In other words, a service platform can not only be programmed, it can be parameterized in a way that the software that runs on it complies to certain service requirements. Also – contrary to a software platform – a service platform will dynamically be adapted (together with the application) in order to ensure the characteristics of a service (e.g. defined by SLAs). This concept of service platforms does not only apply to lower-level compute power or storage services as in the E2C example, it can also be applied to higher level services.

Facebook, for example, is such service platform as it allows programming and executing social applications. Again, here an application ties in with services that the platform provides, e.g. Facebook provides a socially intelligent software distribution scheme in which applications become more popular and gain also more access to resources the more people are using them. The application can of course also be build based on the many social network specific APIs and data sources that the platform provides. Programming service platforms is a very powerful way to develop and even run applications with complex behaviour without the need for the developer to engage into how this complex behaviour is realized internally in the platform or to invest in infrastructure. Programming service platforms are considered to be the next evolutionary step of software development and will in particular change the world of small-sized and bespoke application development.


2.2 Characteristics of NEXOF Compliant Platforms Several service platforms emerged recently and became popular in the Internet environment, for example social networks (e.g. Facebook, OpenSocial etc.). However, these service-based platforms differ in many ways. For instance, they can be differentiated according to their openness, their extensibility, supported levels of interoperability or degree of federation. 2.2.1 Openness Concerning the openness of platforms, it can be differentiated between “closed platforms” and “open platforms”. . This addresses the degree of how a platform can be programmed and adapted by users and, accordingly, the use of open standards. Regarding the characteristics of these platforms, the types of applications that can be built and run on it are restricted. A “closed platform” mainly considers functionality and techniques for publishing and searching of services, e.g. the focus is on service lookup or semantic techniques. The interaction is only performed based on APIs and not via deployment of services. Such a platform can be used to build an application but it cannot be used to actually deploy a third party application on the platform and run it since it normally will be in the hand of one provider. Closed platforms are for example the Google Application Engine and Azure. An “open platform” instead allows applications to be executed on the platform and that different providers can extend it. Accordingly, this approach goes beyond “software as a service”. Furthermore, the platform is not any longer in the hands of one provider. The use of open standards is promoted within NEXOF-RA in order to prevent to be dependent on dominating service platforms. For instance Facebook as the dominating social network platform does not spent any efforts within a group of other social networking platforms – known as OpenSocial – to create open APIs and common ways of programming social platform applications. 2.2.2 Extendability Different types of extension approaches can be distinguished for open platforms. First, platforms only allow rendering an existing type of functionality provided by the platform in a new way. This means that the existing footprint of the platform is unchanged and only specific existing parts are replaced, e.g. by new implementations of certain components or services. The second type really allows enriching the functionality of the platform by adding new features. This can be done by using two different types of “plug-ins”. A platform can be extended by executing something (e.g. Services, Applications) on the platform or it can be extended by publishing a service on it which is intended to be used by “everyone”. The example of Google demonstrates that a company can adapt this scale of expandability according to business tactical reasons for certain parts of their platforms. Google e.g. has closed down even access APIs for their core search services – because it would erode the advertising business if Google search functionalities are simply accessed from the outside as services. From this point


of view it is a closed platform. On the other hand Google is allowing plug-in APIs for Google maps and provides a runtime environment for OpenSocial applications. Thus, this part of the Google platform is open and extendable. Still it has to be noted that service platforms can be entirely using proprietary standards (like Facebook) and cannot be open from an interoperability perspective. 2.2.3 Federation In a federated environment the access layer for the services becomes a single integrated way to access capabilities from all federated platforms – therefore federated platforms gain the character of a service infrastructure. If interoperability on specific levels can be assured then it is worth aiming at achieving federation of service platforms. The distinction is that in a federated environment of service platforms the outside developer can access the functionalities of all platforms via one – or that he can use an access layer service to access all underlying platforms. Regarding the federation of platforms, different levels can be identified on which federation in the platform can be performed. The federation can be based on the execution/cloud level. It can be based on the federation of security policies, management policies, on the federation of service quality, or service processes or orchestration. The latter one is specific for SOA platforms since all other mentioned federation types also need to be considered by non-service based federations. The federation can be event triggered or based on a minimum level policy (for example performance rules for service provisioning). An example is the federation of cloud services across different providers - the objective of the NESSI Strategic project RESERVOIR2

2.2.4 Interoperability

. Elasticity is achieved by using the combined capacities of all platforms in the federation – e.g. the placement of virtual images is dynamically allocated across the federated sides.

Interoperability is a requirement that needs to be fulfilled if services from several platforms should be used together in a combined service application. Different levels of interoperability have to be considered due to the possibility of federating platforms. For the (federated) NEXOF Compliant Platform the following four levels have been identified:

• Business Level Interoperability: interoperability at business level that allows the creation of loosely coupled business processes (dotted red arrow in Figure 1, page 13)

• Business – Platform Interoperability: if it should be possible to deploy and perform business services on arbitrary platforms independently of any federation, a certain interoperability must be assured between the top level business services and applications that are executed on a platform and the platform itself

2 http://www.reservoir-fp7.eu/


• Platform Components Interoperability: if it should be possible to plug-in and plug-out, within a platform, components provided by different vendors. Platform-components must be compliant to a pre-defined interoperability protocol to enable their cooperation within the platform

• Platform Services Interoperability: this level of interoperability addresses the federation of platforms. In a federation this interoperability must be assured. It addresses the interoperability between platform services provided by the different platforms (solid blue arrow in Figure 1, page 13)

Most existing approaches in the SotA on interoperability only address the parts of those different levels. The OASIS Standard for eBusiness Interoperability (ebXML) [25] for example defines in the European Interoperability Framework (EIF) and the EBIF e-business roadmap three levels of interoperability: technical, semantically and organizational. These, however, can all be assigned to the first level of interoperability described above. Another approach that deals with different levels of interoperability is described by Barès [4] who defined “… a formalism of three interoperability domains that describe the ability of the systems to define their own level of interoperability within the coalition by assessing their own and the other systems’ ability to interact on actions of the coalition.” The three different domains are called interconnectivity (ability to exchange messages), interoperability (ability to identify what tasks it is able to interoperate on) and intercooperability (systems have the ability to evaluate all other systems in a coalition). Accordingly, Barès focuses on the interaction between the systems within a coalition, which can be mapped to the 4th level of interoperability described above.

2.3 Relevance for the NEXOF Reference Architecture The NEXOF-RA aims at supporting the derivation of a “fully distributed open platform”, it will enable the federation of platforms on different levels, and it will address different levels of interoperability between platform instances as well as provide appropriate extension mechanisms. Closed platforms can also be NEXOF-RA Compliant Platforms. Accordingly, the NEXOF-RA Compliant Platform is an extendable and evolvable platform that also can be federated on different levels, mainly focusing on policy and service based federation.


3 REFERENCE MODEL TERMINOLOGY, SCOPE, AND STRUCTURE This section will describe the context and the scope addressed by the NEXOF Reference Architecture as well as the structure used to specify the reference model. For this, some terminology descriptions on architecture-related terms are first given, so that a common understanding of concepts is assured.

3.1 Architecture-Related Terminology According to the IEEE standard glossary of software engineering terminology [16] architecture is “the organizational structure of a system or component.” Thus, the architecture of a software system is an inherent characteristic of the software system that is non-tangible but can be observed and can be described with different types of models and languages.

Figure 2: Architecture terminology in software engineering

In Figure 2 the different terms related to software architecture within traditional software engineering are presented. The terms are classified in concepts representing non-tangible characteristics, specifications that describe those characteristics, and implementations that are built based on the specifications. Consequently, the implementation must have the described non-tangible characteristics. The term of software architecture traditionally addresses the organizational structure of all elements that are part of a software system. However, a software system can be differentiated into different types of elements, whose structure can be described by different architecture documents. For NEXOF-RA it is especially important that a software system comprises an infrastructure as one part as well as operative elements that can be deployed on the provided infrastructure on the other hand, whereas the infrastructure comprises the hardware as well as the software infrastructure. Accordingly, one part of the software system architecture addresses specifically the architecture of the infrastructure. In contrast to traditional non-distributed software systems, this differentiation of the operative elements and the infrastructure is important for complex and distributed systems that are becoming more relevant. Distributed systems provide some kind of operative environment that allows for the deployment of applications and processes. Accordingly these systems can be divided into the infrastructure on the one hand and the operative elements that are deployed on

Software System

Architecture

Software Architecture Specification

Software System

Infrastructure Reference Architecture

describes_a has

is_part_of

derived_from Infrastructure Architecture

is_part_of

has

concrete level reference level Specifications

non-tangible characteristics Implementations


the infrastructure on the other hand in order to achieve the business objectives of the system. Like all other software system architectures a SOA has a non-tangible characteristic. However, service-based software systems based on a service-oriented architecture implement this metaphor of an operation system in a specific way. An appropriate infrastructure has to be provided that offers specific services that allow the operative elements to be deployed. These infrastructure services comprise for example the ability to discover or publish business services or service-based applications. Accordingly, the operative elements of a service-based software system are those services that are deployed on the SOA infrastructure in order to create a business value. In order to show the relationship between traditional software systems and service-oriented software systems, the concepts of the traditional software engineering terminology as presented in Fiugure 2 are specialiced for the service-based context in Figure 3.

Figure 3: Architecture terminology in service engineering

In traditional software engineering the concept of a reference architecture is used to capture reoccurring and well-proven concepts of a set of specific software architectures [5]. A reference architecture is not an inherent characteristic of a system but a collection of pattern specifications from which concrete software architecture specifications can be derived. The reference architecture therefore fosters the reuse of well-proven concepts. Within the context of NEXOF-RA, a reference architecture is defined from which specific SOA specifications can be derived called NEXOF Complaint Architecture Specifications. Such a NEXOF Compliant Architecture specification however does not describe a complete SOA, called NEXOF Compliant System Architecture but only the architecture of the according infrastructure – the NEXOF Compliant Infrastructure. Thus, a NEXOF Compliant Architecture only addresses organizational structure characteristics of the hardware and software infrastructure. The infrastructure implementation that has this NEXOF Compliant Architecture is called a NEXOF Compliant Infrastructure. A distinctive feature of this NEXOF Compliant Infrastructure is that it is an open federation of several smaller service-based software infrastructures (see Figure 1) called NEXOF Compliant Platforms (see Section 2 for a detailed description). A system that is based on such a NEXOF Compliant Infrastructure is called a NEXOF Compliant System. The relationship between the architecture related

non-tangible characteristics Implementations

SOA Service-based

Software System

Service-based Software

Infrastructure

/has

is_part_of

SOA Infrastructure

SOA specification

/describes_a

concrete level

is_part_of is_a

Specifications


concepts presented in Figure 2 are specialised for the NEXOF context in Figure 4.

Figure 4: Architecture terminology in the NEXOF context

3.2 Context Definition Section 2 gave an introduction to NCIs as they are addressed by NEXOF-RA. In the following an introduction to the scope of the model that is addressed in order to contribute to the reference specification for NCIs will be given. This includes on the one hand the description of the boundaries and context of the NCI addressed by the model as well as the understanding of the stakeholders who need to be taken into account and the different lifecycle stages addressed by the model. 3.2.1 Boundaries As described in section 3.1, the architecture of a software system can be separated into the architecture of the infrastructure and the architecture of the software system hosted and running upon this infrastructure. Within the context of NEXOF-RA the infrastructure architecture is called NEXOF Compliant Architecture and the system architecture is called NEXOF Compliant System Architecture. Thus, the NEXOF Reference Architecture addresses only the NEXOF Compliant System in its architectural specifications from which NCIs can be derived. The architectural specifications captured by the patterns address certain system requirements while neglecting applications and services created for different business goals that can be hosted on it. The reference model however, describes the NCIs as a blackbox including its value, usage and its context. However, it does not take into account how the architectural solutions are realized internally. The NEXOF Reference Model on the other hand also considers the elements of service-based systems. Since the main purpose of a NCI is to provide an operational environment for those applications and services that can be hosted on it, the model has to take the overall service-based systems into account. The foundation for this are the business requirements derived from the scenarios as described in the requirements report [24]. However, the reference model abstracts from any business domain or application context and captures the relevant elements only on a conceptual level. The different platform and system boundaries that are relevant within the NEXOF-RA context are displayed in figure 5.

NEXOF Compliant

System Architecture

NEXOF Compliant

Architecture Specification

NEXOF Reference

Architecture

NEXOF Compliant

System

NEXOF Compliant

Infrastructure

NEXOF Compliant Platform

federates

NEXOF Compliant

Architecture

has

derived_from

concrete level reference level

has

describes_a

is_part_of

Specifications non-tangible

characteristics Implementations


Figure 5: Boundaries of the NEXOF Reference Model

Another boundary that has to be considered is that of the context of the service-based system itself. SBSs are constructed to serve a specific purpose and thus there are also stakeholders in this context. This context can also influence the NCI since usage requirements towards the SBS might need to be supported by the NCI as well. Thus, aspects of the SBS context might need to be populated down to the NCI. As a result of the different boundaries it can be stated that the reference model describes entities and their relationships of a SBS and its context while the focus is on capturing the interactions of those entities with the NCI. It does not try to model the whole world outside the NCI and furthermore, it does not model actual systems and thus stays on a conceptual abstraction level. It is not intended to model the SBSs and their context for concrete business domains or organizational settings. 3.2.2 Different Stakeholders The users/stakeholders addressed in the model are those developing/deploying services/applications on the platform and users of these deployed services/applications. The underlying assumption of the NEXOF Reference Architecture is that certain services and applications will be hosted and provided on NCIs in order to meet the demand of service requester. In order to adequately address the different contexts of the NEXOF Reference Architecture all possible stakeholders and how they use the reference architecture have to be considered. However, it has to be taken into account that this project does not define a specific architecture of a software system but an architecture that will be a reference for service-oriented systems. Because of this reference character of NEXOF-RA, two kinds of stakeholders have to be distinguished:

• User of the NEXOF Reference Architecture: This kind of stakeholder will likely be some software architect that derives a NEXOF Compliant Platform instance based on the RA-Model and the RA-Specification in a specific context

• User of the NEXOF-RA instantiation: Since the requirements of this user to the NEXOF Reference Architecture depend on the context in which the platform should be instantiated, it is abstracted over the usage to gain an set of common functionalities that need to be supported and considered by NEXOF-RA


The user of the NEXOF Reference Architecture is the direct stakeholder for this project, since he or she uses NEXOF-RA to create the architecture of a service-based system. However, for the specification of the reference architecture, including the users of a NCI instantiation as indirect stakeholder is equally important. Taking the different boundaries considered by the model into account, four different types of users can be identified:

• SBSs user: Stakeholder that directly benefit from the usage of the business services, service-oriented applications etc. that are deployed on the NCI. This type of user can be human but also other applications etc. The user does not necessarily have to be aware of the fact that the underlying infrastructure is service-oriented.

• Application provider: In order to allow the SBSs user to use an application/process there is a stakeholder that uses the NCI. This stakeholder creates service-oriented application and hosts them on the NCI so that they can be used by SBSs users.

• Service provider: There is a second user of the NCI in order to create and deploy services. The NCI support that is needed by this user for his creation activity differs from those needed by the application developer for creating service-oriented applications since for instance, the implemented application, although implemented by composing services, does not need to become another reusable services. Furthermore, the individual services of a SBS differ from service-oriented applications in terms of granularity, since services are much more fine-grained entities compared to applications. Of course there will be overlaps between those two worlds. A composition mechanism for example is needed in both of them. However, these mechanisms/functionalities need to support the different granularity levels.

• NCI provider: The fourth stakeholder that can be identified is the one that creates/constructs/provides the NCI that is used by the other stakeholders using the NEXOF Reference Architecture documents to derive concrete instances of it.

Figure 6: Different usage and support perspectives in the conceptual model

z

NCI

Service1

SoAp1 SoAp2

Service2 Service3

NCI provider

Service provider

Application provider

SBS user

SBS

Context


Figure 6 shows a simple graphical representation of all four stakeholders. It is important to note that the stakeholder (except the SBS user who is their “end-user” in the NEXOF-RA viewpoint) can take on different roles since they are also consuming the products of the other stakeholders and transform them in a way so that they can provide products according to their business goals. 3.2.3 Human vs. Agents When speaking about SOA, it is very important to clearly recognize that SOA is not a specific technology but a paradigm to design and realize new systems. It also concerns with business strategies and actions. Therefore, it has extensive organizational, procedural, and process implications. In order to proceed to the effective analysis and characterization of the NEXOF Compliant Infrastructure, the subsequent questions need to be answered:

• ”What is a service?” The definition of “Service” from a very general perspective (i.e. independent from the IT perspective) must be captured and fixed.

• “How are services related to IT?” It is important to recognize which informational and/or behavioural aspects of the service definition could be managed/automated by IT.

• “How can IT provide the right support to services?” The functionality/features that a software system (an SOA Infrastructure) should provide to properly help the automation of services.

The definition of the service term as produced by the Service Description Investigation team provides answers to these questions. Service is defined by this investigation team as follows (the complete deduction of this definition and all its concepts can be found in Appendix B):

Service Definition: An action performed by one entity (provider) that matches a request of another (requesting entity), according to the interpretation of the latter.

This definition follows the main assumption underlying the service-orientation paradigm as described in section 3.2.2 which is that two entities communicate with each other to fulfil a certain demand. In all of the different boundaries considered in the NEXOF reference Model there are certain players that act in order to achieve their business goals by providing certain facilities (service provider) that can be exploited to fulfill certain demands of other players (service demand). An important facet of service-orientation is that everything can be provided as a service and thus the service provider can become a service consumer itself when providing its services. The definition is a very general perspective which is also independent from IT. However, it is possible to adapt this definition to IT by adding some constraint to the current definition, resulting in the definition of the concept of Software Service. It requires identifying the entities that interact to request/perform an action. Therefore, a Software Service is defined as a Service in which software agents, a requester and a provider agent, mediate the interaction between


requester entity and provider entity. The direct interaction never happens between humans but it is important to specify that human interaction is not excluded by this definition. Indeed, to fulfil their duty software agents can make use of human interaction. The NEXOF Reference Model explicitly includes human actors as entities of the interactions. All roles that are taken by actors thus can be performed by human actors or running software components. Running software components that provide services are called Agents in NEXOF-RA. Which of those two options need to be supported, depends on the architectural solutions chosen to be included in a NCI instance. In most cases the human actors will be the entities initiating certain behaviour which is performed by software agents on behalf of the human actors. Figure 7 shows a class diagram defining the structure viewpoint of the NEXOF Reference Model with regard to the relationship between entities and how a software service is provided. Human actors can only communicate with IT services which are part of the NCI via a software agent. However, if some human actors communicate with each other without involving IT support, this scenario is not excluded by the NEXOF Reference Model.

Actor

Entity

OrganizationPerson

Agent

ServiceDescription

Agent Description

0..* 1

+owner

{complete}

+RequesterAgent

+ProviderAgent

Action

Software Service

Se

rvice

De

scrip

tion

0..*

Ag

en

tD

esc

riptio

n

Figure 7: Actor and their relation to services in the NEXOF Reference Model

A service consists of a sequence of observable actions. The observable actions characterise the service that is offered. Different observable actions are related to each other through predecessor and successor relationships. These relationships describe sequences of observable actions. An observable action may have several predecessors and successors. This allows specifying alternative actions during a service execution. The following Figure 8 illustrates the predecessor and successor relationship.

Observable


Service

ObservableAction

*

1

predecessor

successor**

MessageExchange

Figure 8: Service characterisation

We are going to illustrate the description of a service with a simple example. Assume a service type called “recipe service” that allows you to identify a cooking recipe for the set of ingredients that you have at home. First, the set of owned ingredients is communicated to the service. The service shows a number of recipes names that are possible with the communicated set of ingredients. After selecting a recipe, the service returns the list of ingredients for the selected recipe. The following Figure 9 illustrates the “recipe service” as a model. The cook sends (as action provider) his owned ingredients (e.g. the ones in the refrigerator) to the recipe service (as action consumer). The recipe service analyses the ingredients and sends (as action provider) a set of possible recipe names to the cook (as action consumer). The cook selects a recipe and sends the recipe name to the recipe service. The recipe service sends the complete list of ingredients to the cook.

Owned set ofingrendients

Possible recipenames

Selected recipe

List of ingr.for selected recipe

Recipe serviceprovider

Recipe servicerequester

actionprovider

actionprovider

actionprovider

actionprovider

actionconsumer

actionconsumer

actionconsumer

actionconsumer

predecessor

successor

predecessor

successor

predecessor

successor

Figure 9: Example for a service

The communication between a service provider and a service requester is assumed to be a mediated communication. If one considers for example a federated architecture between different companies, the communication between a service provider and a service requester is performed with the help


of a mediator. The structure of this kind of communication is shown in the following Figure 10.

MediatorParticipant

Action provider

Action consumer*

*

ObservableAction

*

*

Sender

Receiver

Figure 10: Principle communication in a SOA

3.2.4 Lifecycle Stages In order to define the interaction between actors of the different contexts (human or software agents), the different needs that need of those stakeholders in order to achieve their business goals as provider have to be identified. For this the different lifecycle stages of the artefact under development that need to be supported can be analysed. For software system it is traditionally differentiated between requirements engineering, design, implementation, deployment and provisioning, and run-time. However, this is not sufficient for service-based systems anymore. As defined by the S-Cube Lifecycle for example [28] a second iterative cycle is needed that allows for the adaption of running service-based systems. One challenge is that the stages interleave in the service-based context since dynamic creation of artefacts is one of the main goals and challenges. Furthermore, it has to be differentiated between the life cycles of different types of artefacts. In the NEXOF-RA context for example there are different phases for the NCI, its integrated platform services, hosted services, and applications which are integrated into SBSs. In the SECSE project3

[10]

for example an approach has been developed that allows the creation of service compositions at run-time

. Thus, the design, implementation and deployment are performed dynamically when the service is actually requested. The NEXOF Reference Model does not make any assumptions about the time at which the different functionalities are performed and interactions occur. It just assumes that at some point the traditional phases still have to be completed and takes also the possibility of late binding and adaptation into account.

3.3 Separation into Structure, Behavior and Functionality Views A common approach in software engineering (e.g. in requirements engineering or design) is to separate the descriptions of a system into structure, behaviour, and functions [27]. Without this separation, the models of a system may comprise more than one of these aspects and thereby mix and merge information about the system that should be documented separately. Thereby,

3 http://www.secse-project.eu/

http://www.secse-project.eu/�


this separation fosters on the one hand the creation of models, since an engineer can focus on one aspect. On the other hand, the separation supports the understanding of models, since the models are clearly focussed on one aspect (e.g. the behaviour of a system) and typically smaller and thereby easier to understand. In the traditional separation of those viewpoints, the structure perspective focuses on the definition of the structure and information to be managed by the system under development. The static aspects of the structure and information are considered and defined, such as the entities, relationships between entities, attributes, and attribute types relevant for the system. The manipulation of the model information entities (the dynamic aspects of the data) is not considered in this view. The functional perspective typically defines the processes (functions) to be provided by the system. This implies describing the interactions between the processes, the manipulation of the data in each process, and the input-output relationships (information flows) among the processes. The behaviour perspective defines the overall behaviour of the system. Within this perspective, the external stimuli that the system receives and the reactions of the system as well as the relationship between stimuli and reactions are defined. In addition, the possible states (or modes) the system can be in and the allowed transitions between the states (as reactions to stimuli) are defined. Since all of those perspectives describe the same system with focus on different aspects, there are some overlaps and dependencies between the concepts used within them. The structure and functional perspectives for example are related via the data relevant to the system. They are defined and qualified in terms of their relationships in the structural perspective, but are also subject to the data flows (input and output data) between processes and data stores modelled in the functional perspective. The two perspectives focus on different aspects of the data. For instance, a functional specification does not define attributes, relationships between the data entities, cardinalities, etc. A similar relationship can for example be found between the functional and the behaviour perspective. A functional specification is used to define the functions (processes) to be provided by the system. In addition, a behavioural specification typically defines when specific functions shall be executed (e.g. it defines the states and/or the transitions at which a function shall be executed). Due to the complexity of a SOA, we follow the introduced separation for NEXOF-RA. How this separation is expressed by using different types of UML models in order to allow a precise documentation of these concepts will be described in the section 3.4.

3.4 Models and Concepts Used in the NEXOF Reference Model The separation of structure, functionality and behaviour originates from the requirements engineering domain but is also widely used in design documents since these are traditionally closely related to requirements specifications. The Unified Modeling Language (UML) [26], which is the chosen modelling language


within NEXOF-RA, for example also distinguishes its diagrams into structure- and behaviour diagrams. However, since the UML provides a large amount of diagram types and concepts it has been carefully chosen which of them are used within NEXOF-RA to reflect only the relevant information of the different perspectives. The structure view is commonly described by entity-relationship diagrams (ER-diagrams) which include entities, their attributes as well as relationship between them. The UML provides class diagrams which offer similar concepts and allow expressing the same semantics. In fact UML class diagrams are syntactically and semantically richer than ER-diagrams and thus it has to be carefully selected which elements are used within the structure perspective to focus only on the relevant aspects of this view. Thus, the NEXOF Reference Model uses class diagrams in order to define the actors as well as the information and the dependencies between them that are relevant within the reference architecture. Entities are represented as classes and their dependencies and the hierarchies between them by the different types of associations and specializations. This view allows including human actors as well as systems in their different roles they may be taken in a NEXOF compliant system. Furthermore, classes can be associated with behavioural features which can be referenced in other diagram types focusing on behavioural aspects of the system. Since the reference model specification is structured according to the nine concerns identified within NEXOF-RA (see section 4) the structure perspective is separated into several information models (whereas the integrated version of all parts of information model constitutes the complete information model for the NEXOF Reference Architecture). One class diagram per concern describes the relevant information whereas the information entities can be referenced in the different concerns. The functional view traditionally is specified using data flow diagrams [12] which solely focus on data flow. Control flow is completely neglected in order to focus only on the input-output transformation describing the manipulation of data. UML does not support the concept of functions in its metamodel nor does it provide a dedicated diagram type for modelling those. However, since the functional view already focuses on dynamic aspects of the system, the behavioural diagram types of UML provide different concepts and diagram types which provide comparable semantics as DFDs and thus can be used to represent the functional view. Use cases for example specify a “[...] set of actions performed by a system that represents a declaration of an offered behavior of the system without reference to its internal structure which is of value for one or more actors or other stakeholders of the system.” [26] Furthermore it is defined that “[...] each use case specifies a unit of useful functionality that the subject provides to its users.” Thus, this matches exactly the intention of the reference model to describe the functionality provided by a NCI to its users without specifying how this is done. Another concept that is provided by the UML and which is already referenced in the definition of uses cases is the one of actions. An action is “[...] the fundamental unit of executable functionality. The execution of an action represents some transformation or processing.” [26] The UML definition for collaborations also speaks about a specialized function provided by


collaborating elements. However, it also says that its primary purpose is to explain how a system works, which is not the scope of the reference model but specified within the pattern documents. Thus, the concepts of uses cases and actions are used in the NEXOF reference Model in order to specify the functionality view. These concepts are part of two different types of diagram types that are relevant within the reference model context. Use cases are typically specified by use case diagrams, displaying the boundary of the target (sub)system as well as the roles of actors involved in the performance of the use cases. Furthermore, the includes and the extends relationships can be used to describe how use cases can be decomposed into smaller parts of offered behaviour. The UML defines use cases as a specialization of the general concept of behaviour. Similar to the traditional behaviour viewpoint the UML defines a behaviour as “[...] specification of how its context classifier changes state over time.” Compared to data flow diagrams a main difference is also that the processed information cannot be displayed and that roles involved in the behaviour are modelled, whereas the UML states that “[...] all behavior is the consequence of the actions of structural entities.” Thus, this diagram type does not allow separating the behaviour aspects from functionalities but includes both. However, for each of the nine concerns one overview use case diagram is specified in order to show the main functionalities that the subsystem provides to its context. Use cases are commonly described in more detail by activity diagrams describing an activity, which is the second type of diagrams relevant for the functional view of the NEXOF Reference Model. “An activity is the specification of parameterized behavior as the coordinated sequencing of subordinate units whose individual elements are actions. The focus of activity modeling is the sequence and conditions for coordinating lower-level behaviors, rather than which classifiers own those behaviours.” Activities provide the possibility to define the data flow that is processed by the actions within the activity. Thus, it allows using the information entities from the structure view to focus on the data transformation and dependencies between the functionalities. If this data flow is used in a certain manner, assuring that for each action the input and the output data objects are defined while neglecting from the other concepts provided by activity diagrams, it thus allows to replace the semantics provided by DFDs. Another important aspect of use case diagrams, activities and actions is the inherent hierarchy between those concepts that allows the stepwise refinement of the system. While an activity diagram can be used to describe use cases in more detail and thus describe the decomposition of the top-level functionalities into lower level functionalities, each action within an activity diagram can be described by an activity itself. Thus subfunctionalities can also be refined on further levels of decomposition and thus allow reducing the complexity of the different model parts. Besides the dependencies between the concepts of the behavioural diagrams of UML there are also dependencies towards the structure diagrams. A class in a class diagram for example can be associated with behaviour features (e.g. operations) and these can be referenced in


behavioural models, e.g. a registry has operations like update, add delete etc. which are used in the activity diagrams describing the functionalities of the discovery concern. Furthermore, the information modelled in the class diagrams are used as object instances in the activity diagrams, e.g. the registry itself is included as datastore in the discovery concern in which services can be published. In summary it can be said, that the following diagrams are used to specify the NEXOF Reference Model:

• Structure view: o Diagram: One class diagram per concern to define the part of the

information model relevant for the functionalities within this concern. o Concepts used: classes, associations, generalization and

aggregations annotating roles and cardinalities. • Functional/Behaviour view:

o Diagram: One use case diagram per concern to define the top-level functionality of the concern and how different roles are involved.

o Concepts used: use cases, actors and dependencies between them o Diagram: Different activity diagrams refining the use cases and

actions stepwise on different levels focusing on the processing of the data.

o Concepts used: actions (including events), data objects as well as all nodes needed to specify the control flow between them

Accordingly, the functionality and behaviour view are not clearly separated but the focus on decomposing the different diagrams allows keeping them simple and small enhancing the comprehensibility of the NEXOF Reference Model. Full behaviour definition using state diagrams is not reasonable in the context of NEXOF-RA due to its reference nature and the different realisations that can be created. As described above, from the conceptual level it cannot be specified if certain functionalities are performed at design time or run time and thus the system might behave differently depending on the chosen solutions. This can also depend on whether certain functionalities within the solution are provided by platform services which are not owned by the platform provider or by components within the platform. All diagrams are accompanied by explaining textual descriptions as well as simple examples.


4 THE NINE CONCERNS ....................................................................................... 33

5 SERVICE CONCERN .......................................................................................... 36

5.1 Structure View ......................................................................................... 37

5.2 Data Flow in the Service Concern ........................................................... 38

5.2.1 Creation of Service Component ........................................................ 39 5.2.1.1 Design of Service Component .................................................... 40 5.2.1.2 Implementation of Service Component ....................................... 40 5.2.1.3 Promotion of Legacy Component to Service ............................... 41

5.2.2 Execution of Service Component ...................................................... 42 6 MESSAGE CONCERN ........................................................................................ 43

6.1 Structure View ......................................................................................... 44

6.2 Data Flow in the Message Concern ........................................................ 44

6.2.1 Exchange of Messages ..................................................................... 45 6.2.1.1 Validation of Messages ............................................................... 46 6.2.1.2 Routing of Messages .................................................................. 46 6.2.1.3 Adaptation of Message ............................................................... 47

7 DISCOVERY CONCERN ...................................................................................... 49

7.1 Structure View ......................................................................................... 51

7.2 Data Flow in the Discovery Concern ....................................................... 52

7.2.1 Publication of Service Offering .......................................................... 52 7.2.2 Publication of Service Demand ......................................................... 53 7.2.3 Discovery of Service ......................................................................... 54

7.2.3.1 Browsing for Services ................................................................. 55

PART II –NEXOF RERFERENCE MODEL SPECIFICATION


7.2.3.2 Searching for Services ................................................................ 56 8 COMPOSITION CONCERN .................................................................................. 58

8.1 Structure View ......................................................................................... 58

8.2 Data Flow in the Composition Concern ................................................... 59

8.2.1 Creation of Service Components ...................................................... 60 8.2.1.1 Implementation of Service Composition...................................... 63

8.2.2 Execution of Service Composition .................................................... 63 9 PRESENTATION CONCERN ................................................................................ 65

9.1 Structure View ......................................................................................... 65

9.2 Data Flow in the Presentation Concern ................................................... 66

9.2.1 Creation of User Interface Components ............................................ 67 9.2.1.1 Implementation of User Interface Components ........................... 68

9.2.2 Execution of User Interface Components .......................................... 69 10 MANAGEMENT CONCERN ................................................................................ 71

10.1 Structure View ....................................................................................... 72

10.2 Data flow in the Management Concern ................................................. 73

10.2.1 SLA management............................................................................ 74 10.2.2 Deployment Management and Configuration .................................. 76

10.2.2.1 Deployment ............................................................................... 77 10.2.3 Monitoring ....................................................................................... 78 10.2.4 Billing and accounting ..................................................................... 79

11 SECURITY CONCERN ...................................................................................... 81

11.1 Structure View ....................................................................................... 82

11.2 Data Flow in the Security concern ......................................................... 83

11.2.1 Authorization ................................................................................... 84 11.2.2 Authentication ................................................................................. 84 11.2.3 Privacy ............................................................................................ 85 11.2.4 Integrity ........................................................................................... 85

12 RESOURCE CONCERN .................................................................................... 87

12.1 Structure View ....................................................................................... 87

12.2 Data Flow in the Resource Concern ...................................................... 90

12.2.1 Lifecycle Management of Infrastructure Resource Groups ............. 90 12.2.1.1 Configuration of Infrastructure Resources ................................. 91 12.2.1.2 Assignment of Computational Resources ................................. 92

13 FUNCTIONAL AREAS OF THE NEXOF REFERENCE MODEL ............................... 93


4 THE NINE CONCERNS The NEXOF Reference Model is designed to cover all areas of functionality that are required to support the successful implementation of SBSs. It is the result of a logical set of deductions, which are based on the nature and objectives of SOA as they are commonly recognized within the most important initiatives that aim at providing a reference specification for it, such as OASIS and W3C. The following description will identify these areas and explain their needs. This is done taking the different lifecycle stages and the central concept of service-orientation, which are “Services”, into account as well as the SotA (e.g. [35]). The goal is to anticipate the functionalities needed to create an environment in which these services can be used within a business context. Thus, the areas that will be described in the following are identified from the point of view of a software architect, designer or developer respectively. This first introduction is done on a high level of abstraction. The starting points for building the reference architecture are Software Services. In particular, a SBS is built around the concept of services, this being a reusable piece of logic designed to execute a piece of business process with standard access and invocation interfaces. As described in section 3, the underlying assumption adopted by NEXOF is that two entities communicate with each other to fulfil a certain demand. In order to meet the demand of a requester, a provider provides services. So the first capability of any service-based reference architecture should consider the creation of services (design-time support), whether formed out of old components or newly written ones, as well as their execution (run-time support). The power of a SBS is derived from joining these software services together. Therefore, any service-based reference architecture has to deal with mechanisms to enable the consumption of the software services. The most flexible way to achieve this is to opt for the “loosely-coupled”, platform-independent approach of messaging. Using messaging, software services can be joined together to build more complex Software Services. However, existing services and information about the functionalities they provide need to be published to allow service provider to find them and compose them in more complex contexts. A discovery capability is required that allows to find this information. This capability can for example be based on the adoption of a “registry” where software services can be published and catalogued. An important aspect of the mentioned services is that they are clearly related to pieces of business functionalities, rather than simply being an IT-centric piece of code. This allows that these services can be composed into a complete business process by using orchestration technologies. These technologies can handle service flows to ensure the correct execution of the process, based on its business rules and policies. The relationship between business processes and the IT components that underpin them makes it possible to observe the behaviour of the operational system in business terms, and this in turn makes it possible to use analysis


technologies to understand and predict business performance and the impact of changes. Using these technologies, IT systems can be matched much more closely to business needs, and changes can be handled quickly and efficiently. Once software services become a key part of business processes, it becomes a challenge to manage and control the actual behaviour and usage of these services in the production environment. This requires the availability of management technologies at certain levels. These do not only have to observe what is happening with the services (monitoring), but also provide essential governance functionalities and policies to prepare service execution (deployment). Moreover, considering the needs for “loosely-coupled” integration mechanisms and the goal of building composite applications by using services several security issues need to be addressed in a SOA. Especially when considering that the used services are provided by software systems potentially owned and administered by different business organizations. User-based security (e.g. a GUI sign-on) as well as the new type of system-to-system based security should be considered. The final piece of the puzzle is to ensure that the end-user can take advantage of these new capabilities with minimal disruption and retraining. User interaction (presentation) technologies such as personalized portals and role-based tools will limit the disruption of SBS deployments — in terms of changes introduced on the user’s desktop — while improving user productivity and effectiveness. The above paragraphs have introduced all the aspects that a general-purpose service-based system infrastructure has to provide in order to help and accelerate the development of services and service-based applications in different business domains. Starting from that, it is possible to derive and sum up the following top-level requirements that need to be addressed by the NEXOF Compliant Infrastructure:

• The infrastructure has to support the creation and execution of services • The infrastructure has to enable service interaction by means of messages • The infrastructure has to support the discovery of (provided and required)

services • The infrastructure has to support the composition of services • The infrastructure has to provide tools to analyse the services it supports

with respect to the business goals • The infrastructure has to support presentation interfaces to enable human-

users to interact with services and applications • The infrastructure has to support the management and monitoring of its core

components and of services and applications it supports • The infrastructure has to provide mechanisms and policies to accomplish

different level of security A further requirement has to be added to the previous ones that concerns the operating environment (i.e. tin terms of computational resources) needed to support the execution of the NEXOF Compliant Infrastructure itself. This could be the following:


• The infrastructure requires computational resources to be executed These nine top-level requirements suggest a methodical approach to the analysis and definition of the conceptual architecture. In fact, they provide an effective separation of concerns of a SOA infrastructure. Thus, the conceptual architecture view of the NEXOF Compliant Infrastructure is organized according to the following separation of concerns:

• Services – It addresses the underlying building blocks of SOA • Messaging – It enables services to communicate and interact • Discovery – It provides the bases for reuse • Composition – It links services into business processes • Analysis – It enables continuous process improvement • Presentation – It incorporates people into the SOA equation • Management – It addresses service levels and governance • Security – It makes SOA reliable • Resources – It makes SOA effective Till now the work within the project has not revealed any aspects that cannot be accounted to one of these concerns. Aspects related to quality attributes like high-availability and scalability are addressed separately within NEXOF-RA however, since they are mainly influenced by concrete architectural solutions they are not considered within the NEXOF Reference model. Instead, they are considered in the specification of the architectural solutions in form of patterns. Due to the prioritisation of research areas and the expertise of partners within the project NEXOF-RA the Analysis concern is not addressed in the NEXOF-Reference Architecture at the moment - not on a conceptual level in the reference model nor in the pattern specification documents. It should be subject to future work on the NESSI Open Service Framework.


5 SERVICE CONCERN The services concern is dedicated to capture all the functionalities to support the creation (design and implementation) and execution of services as shown in the following use case diagram (see figure 8). It covers both support at design-time and run-time. It is important to highlight that these functionalities do not address any support to service composition, which is totally covered by the Composition concern. As stated in section 3.2, actors within the NEXOF Reference Architecture can have different roles. The functionalities of the service concern are performed by a role called service developer, which can be human or an software agent (in generative approaches) and who acts on behalf of an service provider in order to develop services according to the provider’s needs. This concern addresses the methods for service creation including all those features provided by the platform that enable new services to be created from scratch as well as to enable existing applications to be exposed as service implementations. The implementation functionality also allows functionalities to be modified and to create new compatible versions of existing services and, finally, validate and test them.

<<Service>>

ServiceDeveloper

Design ofService

Component

ServiceProvider

Implementationof Service

Component

Promotion of Legacy

Component toService

<<include>>

<<include>>

<<include>>

acts on behalf of

Creation ofService

Component

Execution ofService

Component

Figure 11: Service Subsystem Use Case Diagram

Exposing existing applications as services is more problematic. It requires smart technology, such as adapters to the different systems and application environments used by the applications as well as wrappers to make these applications look like standard services. Finally, service execution refers to the computation performed by the service after it receives a client request (invocation) asking that a specific operation is carried out. The result is computed and returned back to the client in a response message. We have to distinguish the execution and the invocation of the service. The invocation is the act of sending a request to the service done by a


client using the routing of messages functionality of the message concern, while the execution is the computation performed by the provider agent to reply to the service invocation. We have also to underline that service invocations are performed by clients (applications or other services) in a loosely-coupled manner (i.e. mediated by functionalities related to the Messaging concern). Accordingly, service execution functionalities are only exposed to be invoked by functionalities that support messaging.

5.1 Structure View The following model describes the information entities that are relevant to the service concern. As it can be seen, the service component is the central entity which is a specialization of a software component. A software component is the implementation of an agent which can realize one or several services (see Figure 7). An agent that realizes a service is a provider agent and realized by a service component. A service component can be specialized into simple service components and composite service components. A simple service component can also be a connector service component which wraps legacy application components in order to promote them as services.

Software Component

Legacy Component

ConnectorComponent

UIComponent

Service Component

ConnectorService

Component

CompositeService

Component

SimpleService

Component

Service

Observable Action

realize

ProviderAgent

ServiceDescription

de

scrib

es

Facet

*

Service Component

Specification

Service Request

imp

lem

en

ts

1

Figure 12: Information model of the Service concern

A service description represents the information that describes a service. As defined by the SECSE project, this description comprises information about several aspects or facets of a service. Important service facets that should be part of the service description are functional facets and quality facets (for detailed information about relevant facets see [10]). A service facet is a


particular information piece that describes a particular aspect of a service, constrained to a particular concern. Service Facets may be described using different ways:

• Unstructured informal descriptions: for instance using free text. That introduces internalization aspects, that is, service descriptions that are provided in different languages.

• Structured formal descriptions: • Descriptions that use syntactic grammar: XML • Descriptions that use a semantic grammar: RDF(S), OWL

Furthermore, the description contains a service component specification which constraints the implementation of the described service in a service component.

Creation ofService

ComponentRequirement

ServiceComponent

<<Management>>

DeploymentManagement and

Configuration

ServiceInstance[running]

Execution ofService

ComponentRequest

ObservableAction

Figure 13: Data Flow in the Service Concern

5.2 Data Flow in the Service Concern As the top level activity diagram for the service concern in figure 13 shows that service components are created to meet certain requirements towards a service, which is the result of a service execution in form of an observable action. This observable action can either be the change of states of objects in the real world but also a message returning some computed data. The functionality creation of service component produces the service component which then can be deployed using the functionality deployment management


and configuration of the management concern (see section 10) which results in a running instance. A running instance of a service component is called a provider agent. A provider agent can execute a service (functionality execution of service component) upon the arrival of a dispatched message (see message concern in section 6) requesting the invocation. The result of the execution of the service is an observable action satisfying the demand of the service consumer. The functionalities are described in more detail in the following. 5.2.1 Creation of Service Component The functionality creation of service component represents the capabilities for designing service components, implement them, adapt legacy systems to be used as a service component and enable their execution as shown in the activity diagram in figure 14. Based on the requirements towards the service, the first step is to create the design of the service component which results in the service description with all its composite parts as shown in the information model. The service design then is used to perform the functionality implementation of service component which creates a service component from scratch and results in the creation of a Simple service component.

Design ofService

Component

LegacyComponent

Service Description

Promotion of Legacy Component to

Service

Implementation ofService Component

ServiceComponent

Requirement

Figure 14: Functionality Creation of Service Component

Alternatively the service description can be used in order to perform the functionality promotion of legacy component to service component, which takes


an existing legacy application and creates some wrapper components, so that the output is a connector service component (which is a specialization of a single service component as shown in the information model). Each of these capabilities is described in more details by the functionalities design of service component, implementation of service component, promotion of legacy component to service in the following.

5.2.1.1 Design of Service Component The functionality design of service components allows the creation of different artefacts that constitute a service description – the design of a single service component that can be used as the baseline for the implementation. A service designer specifies at least a subset of the following information based on the requirements that are the input to this functionality:

• the functional description of the service to define what the service does • the interface of the service to define how a service will be accessed. It

should contain the information needed to implement the operations and information that will be provided to potential clients. It should also include the details on the communication protocol that will be used to access the service. Moreover, a further interface description must be provided if the management of the services must be done remotely or by a management system

• the quality of service (QoS) i.e. a collection of quality attributes that express a capability or a requirement about the overall service or about a given aspect of the service to define its ability to satisfy stated or implied needs of users.

• The definition of the transactional support to define the information to enable the service to be part of a transactional business process.

It should be possible to enrich the description of the service as convenient for the service designer. The design of services must produce a service description that can be used in the implementation phase to create the service.

5.2.1.2 Implementation of Service Component The functionality represents a way to implement a service through coding, debugging and testing (see figure 12) in an essentially similar manner as other software component-based programming. Moreover, a remote accessible interface must be generated as well as a client stub to access the service from a remote client following the interface specification that is part of the service description. The implementation of the service must be done according to the parameters defined in the design phase.


Coding

ServiceDescription

ServiceComponent

Debugging

ServiceComponent[debugged]

Testing

ServiceComponent

[tested]

Figure 15: Functionality Implementation of Service Component

5.2.1.3 Promotion of Legacy Component to Service The functionality promotion of legacy component to service allows the adaptation of legacy applications in order to be accessible as a service and to enable the possible integration in a SOA system. It takes the service design that has been created for the resulting service into account as well as the existing legacy component and allows the creation of a wrapper for the legacy application which exposes the described interface as a service. The wrapper must be capable to forward the requests coming from (remote) clients to the legacy application, and enables the legacy application to return back the response to the client. In contrast to the creation of a service component from scratch the computational logic provided by a connector service component is implemented by the legacy component and no code has to be implemented for this, however, the wrapper itself has to be implemented. The resulting Connector service component will be used for deployment in the same way as new service component created from scratch and thus will only be recognised


as simple service component without exposing the information about the legacy application. 5.2.2 Execution of Service Component The functionality execution of service components represents the procedure performed by the service, after a client sends a request to it asking for a specific procedure to be carried out, in order to transmit the result back to the client in a response. The request starting the invocation is submitted in form of a dispatched message as result of the functionality exchange of message of the message concern. The execution, i.e. the actual processing of the implemented logic, of the service is taken apart from the invocation, which represents the request of the user asking for the execution of the service. The execution implies the usage of computational resources with the purpose to execute the code of the service to respond to an invocation performed by a client. The computational resources have already been assigned by the functionality deployment management and configuration of the management concern by deploying the service component so that it becomes a running service component – a provider agent.


6 MESSAGE CONCERN The message concern addresses the communication capability that allows applications or services to interact with other services. The term messaging reflects the fact that such a communication capability is based on message exchange. The following use case diagram (see figure 16) shows that the message exchange comprising the validation and the routing of messages is the relevant functionality for the message concern. A role message broker is involved in the message exchange as well as a number of communication parties sending and receiving messages. All involved roles can be taken by humans as well as software (service) agents. The message broker mediates the interaction among the communication parties. This could be an ESB for example but it could also be a postal service if the communication parties decide to communicate by writing letters.

<<Message>>

Exchange ofMessage

MessageBroker

Routing ofMessage

Validation ofMessage

<<include>>

Communication Party

<<include>>

Figure 16: Functionalities of the Message Concern

One specific characteristic of the service-oriented paradigm is that connectivity is connection-independent – that is, the service requestor and service provider (communication parties) should be loosely-coupled rather than tightly-bound. This is usually implemented by using an asynchronous messaging approach, although synchronous messaging may also be required. Just providing the connectivity to allow components and services to interact in a connection-independent way is not enough. In order to achieve clean interfaces between services, data formats may have to be manipulated. It is an issue that different programs may have different expectations regarding data formats. Therefore, it may be necessary to map one data format into another in order to establish the level of independence a SOA requires. In this way, each program receives and outputs data in its native format with the messaging layer transforming between data formats as required. It frequently happens that messaging middleware solutions offer some intelligent routing support to allow process flows making up the service to be altered based on business policies and conditions. In our conceptual view, this


concern does not cover this kind of routing called run-time adaptation since it is recognized as something more closely related to service composition (see section 8). The only forms of routing we want to capture by the messaging concern are those that perform the selection of service instances as recipient within sets of services that are all equivalent from the process and business perspective (i.e. routing to achieve location transparency, routing to achieve semantic replacement of services).

6.1 Structure View The information relevant for the message concern are displayed in the following information model (see figure 17). The core concept is the one of messages. A message is a basic unit of communication exchanged between a consumer and a provider (definition according to W3C web glossary, adapted to the NEXOF context [34]). This includes both human actors as well as software agents. The structure of a message is defined by a message type. It defines how the message has to be interpreted. The message type further more defines the message metadata - information associated with the content of the message that are used to process and deliver the message, e.g. the data format that has to be used for a message. In order to be dispatched to the correct recipient a message needs to be associated with an endpoint. An endpoint is the entry point of a given service. The endpoint contains information to uniquely identify a service and provide an address to send individual messages to the service (definition according to W3C web glossary, adapted to the NEXOF context [34]). An endpoint furthermore uses and supports a certain transport protocol. A message exchange generally adheres to an interaction model defined for the messaging. This interaction model defines and establishes the patterns for the exchange of the messages between two communicating parties (W3C Glossary).

MessageMessage Metadata

ProtocolInteraction Model Endpoint

Message Type

defines

contains

Defines thestructure of

co

nta

ins

1 0..*0..* 1

uses

0..* 1

Figure 17: Information Model of the Message Concern

6.2 Data Flow in the Message Concern The following top level activity diagram (see figure 18) for the message concern shows that the functionality exchange of messages processes a message upon its arrival in such a way that it is dispatched to the appropriate receiver afterwards. One part of this functionality is to assure that the message is valid. For this validation properties are taken into account in order to validate that the message meets certain requirements. The exchange of messages is described in more detail in the following sections.


Exchange ofMessage

Message

Message[dispatched]

ValidationProperties

Figure 18: Data Flow in the Message Concern

6.2.1 Exchange of Messages The functionality exchange of messages allows communication parties (agents or human actors) to send/receive a message. The interaction model should be specified to declare the kind of interaction, which can be synchronous or asynchronous. Furthermore, it should be supported by message exchange patterns4 (MEPs) such as request/response, on-way and peer-to-peer conversations, as defined by messaging framework of W3C5


Message

ValidationProperties

RejectionNotification

Message[validated]

Routing ofMessage

Message[dispatched]

not validvalid

.

Figure 19: Functionality Exchange of Message

4 http://www.w3.org/TR/soap12-part1/#soapmep 5 http://www.w3.org/TR/soap12-part1


As shown in figure 19, the interaction deals with the validation, the adaptation and the routing of messages. The arriving message that needs to be dispatched first is validated against the validation properties by the functionality validation of message before the validated message is processed by the functionality routing of message. If the message is analysed as not being valid, it is not forwarded to be dispatched but instead a rejection notification is produced. This notification needs to be provided to the sender of the message and can contain different information depending on the architectural solution, e.g. the message itself, information about which properties are not valid etc. The routing itself can be performed in different ways. Examples of the mechanisms for the exchange of messages that could be supported are:

• the forwarding of messages to an agent through the declaration of the endpoint that uniquely identify the agent

• the forwarding of messages to a broker that dispatch the message to any agent capable to reply to the request, based on the type of message forwarded and the applied load balancing techniques

The mechanisms described above must be considered only as examples and can be changed as preferred.

6.2.1.1 Validation of Messages The message sent by a communication party is validated with respect to its message type to verify if the structure of the message matches the required properties. An example of validation is the verification if a message contains a well-formed document and conforms to a particular schema or interface document that describes the structure of the message.

6.2.1.2 Routing of Messages The validated message sent by a communication party is routed to the recipient according to the routing information contained in the service description. As shown in figure 20, the message is routed by performing the following operations:

• Forwarding of the message, i.e. the sender sends the message to the message broker. If the message does not contains the endpoint of the recipient, the message broker selects an endpoint of an agent capable to respond to the request

• [Optional] In case that the messages are exchanged between agents required adaptations of the message can be identified

• Dispatching of the message to the target endpoint


Forwarding ofMessage

Message[forwarded]

Dispatching ofMessage

Adaption of Message

Message[adapted]

Message[dispatched]

Message

Figure 20: Functionality Routing of Message

6.2.1.3 Adaptation of Message The adaptation functionality can comprise different types of adaptations as shown in figure 21 taking the endpoint information into account. The data format of a message for example is converted into a different target data format that the output message is expected to have, according to the data format handled by the recipient agent. The message bound to a certain transport protocol is converted according to a different transport protocol that the output message is expected to have, according to the transport protocol handled by the recipient Agent. Moreover, the information contained in a message can be enhanced according to what is expected by the recipient agent. The enhancements consist in one or more of the following alternatives:

• the enrichment with further information to the original message as needed to dispatch the message, e.g. addition of the sent date if this is expected by the recipient


• the removal of not required information from the original message, e.g. the removal of the sent date if the recipient is not able to process it.

• the splitting, the aggregation, the sequencing of the existing information into one or several messages in order to convert the message in the format expected by the recipient Agent.

The adaptation of the message must preserve the semantic of the message.

Forwarding ofMessage

Metadata Data FormatTransportProtocol

Enhancement ofMessage

Adaptation ofData Format

Adaptation ofTransport Protocol

AdaptedMessage

Endpoint

Message[forwarded]

Figure 21: Functionality Adaptation of Message


7 DISCOVERY CONCERN The discovery concern covers all functionalities that are needed to support the discovery of services. It also addresses mechanisms and policies to make discovery effective, such as the publication of service descriptions into service registries or things alike. The use case diagram in figure 22 shows the functionalities relevant for the discovery concern. The roles involved are the service provider, service consumer as well as a service broker that mediates the offer and demand between the other two roles.

<<Discovery>>

Browsing forService

Provider

Search forService

Publication ofService Offering

ServiceBroker

Discovery ofService

Publication ofService Demand

<<include>>

<<include>>

Consumer

Figure 22: Functionality of Discovery Concern

For an SOA to be effective, it is vital that developers of services or service-based applications can easily find services they can reuse. Otherwise, developers might be tempted to take the potentially more interesting option of writing the functionality themselves, creating redundancy and detracting from one of the key advantages of an SOA. So, the functionalities related to this concern must offer easy-to-use browsing facilities and clear descriptive information about the services so that developers can quickly identify the specific services that will be of value to them. In addition, because a successful SOA strategy will result in high levels of reuse, it becomes essential that developers are alerted to any changes to services that are listed in the registry since these changes might affect the way different parts of business operations work. The registry should also hold a range of associated attributes for each service. These might be dependent on business policies, for example when and where information should be encrypted as it passes between services, or could be installation relevant attributes such as the name of the service provider. The important factor to consider is that the registry should hold all relevant information regarding each service and present it in an easily digestible way.


The role of service registries in a service-oriented architecture can be fulfilled by several mechanisms. There is a trade-off here between simplicity of usage of the mechanism provided by the system and the complexity and completeness of the publishing and searching techniques. A first distinction can be made with respect to the context in which service discovery is done:

• At design-time, a designer queries the service catalogue to retrieve one or more service descriptions that meet certain criteria and uses the returned service or incorporates them into a business process

• At run-time, during process execution for instance, the system itself could be able to query the service catalogue to find services matching users and process requirements

Another distinction can be made with respect to how a consumer becomes aware of the existence of services. We can refer to the following policies:

• Pull policy: consumers directly search on a registry to find services that have been previously described and published

• Push policy: a consumer is notified, with respects to its subscribed interests, as soon as a new service is published

Service Demand

Search Criteria

de

scri

be

s

Search QuerySubscription

CriteriaCatalogues

Schema Criteria

Search Criterion

1..*

Search Result

CandidateService

0..*

Facet

spe

cif

ies

Service Description

de

scri

be

db

y

Catalogue Schema

refe

rsto

<<datastore>>Registry

stru

ctu

res

pu

blis

he

nd

Service OfferInformation Category

1..*

Figure 23: Information model of the discovery concern


7.1 Structure View The information relevant for the discovery concern is shown in the information model in figure 23. As it can be seen, a search which is based on a certain service demand is defined by several search criteria where each included search criterion matches to a facet of the service description. Search criteria can either be defined as a search query, subscription criteria or catalogue schema criteria depending on the type of discovery that is performed. The search result matching the search query is a list of candidate services which links to the service descriptions of those services. The service descriptions are published in a registry (which is a datastore, in which the service descriptions are stored permanently) according to a defined catalogue schema consisting of different categories that are referenced by the catalogue schema criteria.


Service Description

ServiceOffer

Information

Discovery ofService

<<Datastore>>Registry

SearchCriteria

Publication ofService Demand

SubscribeCriteria

Service OfferInformation

Service Description

<<select>>

criteria = offer

ServiceDemand

Figure 24: Data flow in the discovery concern


7.2 Data Flow in the Discovery Concern The functionalities of the discovery concern take existing service descriptions and demands for services into account. The discovery can be divided into three main functionalities as shown in figure 24. In order to allow the selection of a service, an existing service offering needs to be published. Based on the service description describing the running service instance that is offered, the functionality publication of service offering places the information of the service offer into a registry according to the catalogue schema. The detection of services satisfying a certain service demand can be differentiated in a push and a pull mode. The discovery of service functionality allows finding services according to a service demand in a pull mode. The publication of service demand functionality allows finding services in a push mode by explicitly publishing the service demand and waiting for matching services to be published. Since it has to be taken into account that matching services could already be published in the registry when a demand is published first a discovery on the existing offers is performed. For the results selected from the registry the search criteria match the facet descriptions of the offer. Since the registry is a database this selection retrieves only copies of the service offer information but does not remove them from the registry so that they can still be discovered in later queries. Afterwards, the service demand is transferred into subscription criteria by the functionality publication of demand which are used to subscribe to the registry. Whenever a new service offer is published on the registry or updated, this triggers an event that tries to match the subscription criteria against the new service offer. The result of both, the discovery and the publication of a demand, is the service selected to meet the service demand. The functionalities are explained in detail in the following. 7.2.1 Publication of Service Offering The functionality publication of service offering allows advertising the service offering to potential users by means of the publication of the information related to the service offered based on an existing service description. Such information is published on a repository which must be reachable by users enabled to search and browse the repository. The published information should contain sufficient details to enables the potential users to invoke the service, such as the endpoint of the service, the transport protocol and the data format used, and sufficient details to allows the potential users to state which are the effects produced by the service in order to state if the service can satisfy their needed. The structure of the published information is pre-defined by the repository on which the service offer should be advertised. As the activity diagram in figure 25 shows, an published service offer can also be removed from a registry upon a delete request (functionality removal of service offer information) as well as updated upon a change request (functionality update of service offer information).


Publication ofService

Offer Information

Service Description



Update ofService OfferInformation

Removal of ServiceOffer Information

Change Request

Delete Request

<<remove>><<update>>

<<create>>

Figure 25: Functionality “Publication of Service Offer”

7.2.2 Publication of Service Demand The functionality publication of service demand allows performing the discovery of services in a push mode. As shown in the following activity diagram (see figure 26) the potential users publish their service demand (functionality subscription). The way to describe the requirements depends on the matching algorithm and the structure of the registry. Whenever a new or updated service offer is published on the registry the functionality matching is triggered that checks whether the description of the service offer matches the published service demand. If a match is found the user who subscribed the demand is notified and as part of this notification functionality the selection of service can be performed if it is evaluated as appropriate. If the new offer does not match the subscription criteria, the functionality waits for the next update event to fire, until the demand subscription is removed.


SubscriptionServiceDemand

SubscriptionCriteria


Matching

SearchResult

Notification Unsubscription

ServiceDescription

match

no match

<<update>>

RequestDeleteRequest

RequestService

OfferInformation

Figure 26: Functionality Publication of Service Demand

7.2.3 Discovery of Service The functionality discovery of service allows finding services according to a set of requirements defined by service users in a pull mode. The requirements can be specified in several ways (i.e. keywords, semantic queries, natural language, etc.) and times (design time, runtime, etc.). The discovery of services can be performed in two modes: a search can be performed where an algorithm finds matches to a specified query or the registry can be browsed for services narrowing down the search results step by step until an appropriate service can be selected. In both cases the search criteria that have to be applied (either the search query or the browse criteria) are used to select appropriate service offers from the registry that will allow to select a service meeting the service demand (see figure 24).


ServiceDemand

Browsing forServices

Searching forServices

CatalogueSchemaCriteria


Search Query

SelectedService

Figure 27: Functionality Discovery of Service

In both cases the discovery can be performed in different ways and applying different algorithms, and they will depend on the way to represent the requirements. Candidate services (which fulfil the requirements) will be returned to users, in order to support the service selection. The two types of discovery are described in detail in the following highlighting the differences of the provided information.

7.2.3.1 Browsing for Services The functionality browsing for services allows users to find services by browsing through the content of a service registry in order to select those services which are interesting according to the service demand that needs to be met. It will depend on the way to organize and structure the registry and the service demand to specify the simple queries according to the categories that will be admitted in order to narrow down the list of candidate services. Based on the category options the candidate services will be selected and presented as result from which the consumer can select the most appropriate service as shown in the following activity diagram.


Access ingCatalogue

ServiceDemand

CatalogueSchema

Specification ofParameter

CatalogueSchema Criteria


SearchResult

SelectionService

Description

<<select>>

Figure 28: Functionality Browsing for Service

7.2.3.2 Searching for Services The functionality searching for services refers to an alternative of performing service discovery. It consists on receiving a service demand on which the functionality specification of query allows the definition of a complex search query specification, so the discovery engine can perform a more complex but accurate matching between requirements and published services based on the search query. Query format and discovery engine have to be compliant and the possibilities are wide, as they can be based on complex semantic queries or just some keywords and data types. In contrast to the browsing functionality the search functionality also includes the ranking of the resulting candidate list according to the service demand, before the ranked list is used to select the most appropriate service as shown in the following activity diagram.


Specification ofQuery

ServiceDemand

SearchCriteria

MatchingSearchQuery


SearchResult

Ranking

SearchResult

[ranked]

SelectionService

Description

selection

Figure 29: Functionality Search for Service


8 COMPOSITION CONCERN The composition concern addresses the creation and execution of software processes as shown by the use case diagram in figure 30. It covers both, the support at design-time (orchestration, choreography) and at run-time (static/dynamic composition).

<<Composition>>

Creation ofService

Composition

Service Developer

Execution ofService

Composition

<<include>>

<<include>>


Composition

Design ofService

Composition


Composition

<<include>>

Figure 30: Functionality of the Composition Concern

The result of the composition of services is called process. It can be used as a workflow or it can be published as a service itself (composite service) and be used (i.e. described, published, discovered and composed) transparently as any other service. It also addresses the ability to support dynamic process reconfigurations, delivering much improved business agility. The system should support the composition of services component that are available and published. It includes the design and implementation of a process as well as the execution of a process. Sometimes the system should also support dynamic composition. Those are processes, which are capable to automatically discover new services to interact with and automatically select them according to a number of criteria. This concern also deals with human workflow elements, where the process passes through a human touch-point. This places more distinct requirements, such as the ability to manage the assignment of work and tasks to individuals as well as groups, and handle long-running tasks spanning days rather than seconds. This is an important distinction given that in a human-intensive workflow there may be long periods between different steps. This may require the system to maintain transaction states for days or weeks.

8.1 Structure View The information entities relevant for the composition concern are shown in the following information model in figure 31 which is largely based on the results of


the SECSE project. As it can be seen the central concept is the one of service composition, described by a service composition description, which can either be an orchestration or choreography. This description is based on existing service descriptions and specifies the data as well as the control flow of the service composition. A service composition is implemented by an executable workflow which is constrained by the service composition description. A service composition can be exposed as a composite service. Such an exposed composite service is implemented by a composite service component that capsules the executable workflow and allows it to be accessed. For the publication of a composite service component the composite service description is modified in a way that it the internal implementation of the logic is not visible anymore but only the information as specified for a simple service. Thus, from a consumer point of view it is not visible if the service is a composite service or a simple service.

ServiceComponent

CompositeService

Service Description

ServiceComposition

ServiceCompositionDescription

ChoreographyOrchestrationExecutableWorkflow

Control Flow Data Flow

ServiceCompositionComponent implements describes

published as

described by

capsules

implements

Figure 31: Information Model for the Composition Concern

8.2 Data Flow in the Composition Concern The composition concern addresses two main functionalities that allow handling service compositions. On the one hand it allows the creation of service compositions by the service developer including the design and the implementation and on the other hand it allows executing those service compositions.


As the following top level activity diagram for the composition concern shows (see figure 32), service compositions rely on existing services which are composed in a way to meet certain requirements for process support. The functionality creation of service compositions allows taking the specifications of existing service components into account which can be discovered using the functionalities provided by the discovery subsystem. The functionality creates a composition that arranges the existing services according to the requirements that are the input to the functionality in order to create an executable service composition. This executable service composition in form of a workflow description is used by the functionality execution of service composition to actually execute the process described by the composition upon the event of dispatching a message that starts the invocation of the composition. The functionality processes the executable workflow description which also includes the invocation of already running services instances. The result of the execution of the service composition is a series of observable actions for the different services that are invoked within the process execution. The functionalities are described in more detail in the following.

Creation ofService

Composition

Requirement

CompositeService

Component

ExecutableWorkflow

ServiceDescription

Execution ofService

Composition

<<Discovery>>Discovery of

Service

Message[dispatched]

ObservableAction

ServiceComponent

[running]

<<Management>>Deployment

Figure 32: Data Flow in the Composition Concern

8.2.1 Creation of Service Components The functionality creation of service composition is focused on creating service compositions, which requires performing several activities grouped in phases. The creation of compositions can be done in several ways like manually, in a semi-automatic way and even a mixed one, based on models or directly on an execution language. It comprises design and implementation activities, so


several services will be combined in compositions which may represent business processes. As the following activity diagram in figure 33 shows that the functionality can be detailed to the functionalities design of service composition, implementation of service composition and promotion to composite service. Taking existing service specifications and the requirements towards the service composition into account, the functionality design of service composition creates a service composition description. This description can either be a description of an orchestration or a choreography. This functionality is only focused in the modelling of the different parts of the composition, which means main activities with their control and data flows, as well as other non functional needs related to areas such as security and transactions. It can be performed manually or it can be done with the support of tools which create parts of the composition or suggested templates. According to the discovery approach described by the SECSE project, the binding of services into the composition can be performed at different stages in the development process. The earliest possibility to bind existing services is in the design of the service composition, but it does not necessarily have to be done. This is called requirements discovery in SECSE.

Service CompositionDesign

Service CompositionDescription

Implementation ofService Composition

ExecutableWorkflow

Promotion toComposite Service

Component

Composite Service

Component

Requirement

Service Description

Figure 33: Functionality Creation of Service Composition


Based on this description and the existing services the functionality implementation of service composition creates an executable service composition specification by using an execution language (such as WS-BPEL). A service composition can be created for different purposes. It can for example be used to support and implement business processes within a company. However, it can also be created in order to develop complex services which itself can be published on a registry to be integrated in further compositions realizing business processes. If a composition is not only developed for internal use but should also be provided as a service offer it needs to be transformed into a service that is accessible and publishable. The functionality promotion to composite service enables this exposition of the service composition as service. Once a service composition has been implemented and tested, it can be exposed as a new complex service, by producing adequate descriptions (WSDL files and, optionally, semantic descriptions) which together with the executable service composition specification constitute a composite service component. For a consumer of such a service it is not visible if the implemented logic has been implemented from scratch as a simple service or if it has been composed.

Transformationin Executable

Code

Service CompositionDescription

ExecutableWorkflow

Design-time Binding

ExecutableWorkflow[enriched]

TestingExecutedWorkflow[tested]

ServiceDescription

Figure 34: Functionality Implementation of Service Composition


8.2.1.1 Implementation of Service Composition The functionality implementation of service composition can be detailed further into the functionalities transformation into executable code, design-time binding and testing as shown in the following activity diagram (see figure 34). Taking the service composition description into account then the functionality transformation into executable code basically creates an executable workflow description that describes the control- and dataflow as specified in the design activity in an executable manner, e.g. as a BPEL file. This executable workflow description is enriched with binding information if they already have been specified during the design activity or if they are selected during the implementation. The discovery (functionality provided by the discovery concern) of appropriate services to be used within the composition at this time is called architectural discovery in SECSE. However, the binding information does not necessarily have to be integrated at that point in time but can also be postponed till run-time. The enriched executable workflow description is used by the functionality testing to ensure that certain quality standards are met and detected failures can be improved before the service composition is either executed or exposed as a service. 8.2.2 Execution of Service Composition The functionality execution of service composition refers to the activities performed for executing a service composition implementation, carrying out service invocations and data transformations. There are execution engines which perform static execution, sticking only to the implementation itself, while other engines are able to perform more dynamic executions, adapting activities, control and data flows depending on context information and errors detected, sometimes even triggering the generation of parts of the composition (cf. creation of service composition) at runtime. The functionality can be detailed into the functionalities processing of step, invocation of services, and adaptation of execution. The execution is started upon the arrival of an invocation message that is dispatched by the message broker (see message subsystem in section 6). In case that the service binding has been postponed till the actual run-time the functionality run-time binding allows to enrich the executable workflow description using existing, running service instances. For each step defined in the workflow the functionalities processing of step and if the step calls a service invocation of service resulting in sending out a message based on the endpoint information. The result of these invocations is a set of observable actions which together constitute the result of the service composition. During runtime the composition still can be adapted according to different events, for example when a service offer is updated or a new matching service offer is available for a published service demand that provides advantages over the currently bound service. Monitoring data indicating that certain criteria are not met can also result in changes of the service binding as well as in the adaptation of the control- or data flow. Thus, the execution can be interrupted at any time following certain transaction policies. The adaptation can either result in the newly execution of the whole composition or resume at the point where the current execution has been interrupted.


ExecutableWorkflow

Message[dispatched]

RuntimeBinding

ServiceDescription

AdaptationExecutableWorkflow[enriched]

Workflow

While Workflow has next Step

AdaptationRequest

Processing ofStep

End Point

Invocation ofService

Message

ObservableAction

Figure 35: Functionality Execution of Service Composition


9 PRESENTATION CONCERN The presentation concern addresses all mechanisms to enable human users to interact and make use of the functionality provided by the overall platform. It covers both the offering of graphical user interfaces for supporting human user interactions and APIs to enable the creation, customization and execution of such graphical user interfaces as shown in the following use case diagram in figure 36.

<<Presentation>>

Design of User Interface

Component

Implementationof User Interface

Component

Creation of UserInterface

Component

SFE/MashupDesigner

Execution ofUser Interface

Component

<<include>>

<<include>>

Publication ofUser Interface

Component

<<include>>

Figure 36: Functionality of the Presentation Concern

It aims at making it possible for a new breed of application developers to work in a highly personalized, simplified environment, by means of mechanisms that enable to assemble composite end-user applications from a set of uniform building blocks, (e.g. service-widgets, service-portlets). This should be achieved in a way where applications are assembled with no coding at all, simply bringing together different blocks. An effective user interaction layer will enable companies to achieve dramatic time-to market improvements for new initiatives, efficiently and without the need for high-cost specialized skills.

9.1 Structure View The relevant information entities for the presentation concern are shown in the model in figure 37. A service frontend resource (SFER) can either be a gadget, a gadget group or a workspace. Similar to a service component a SFER is specified by a description consisting of several resource properties which have a certain value. A gadget groups is composed by several gadget instances which implement a gadget and which are connected via channels. Gadget groups are part of a workspace, which are owned by a user and provide users a highly personalized and simplified environment to compose these gadget groups. The workspaces in turn compose an access point. Resources are


composed in a catalogue where they can be published for use in mashups. Domain elements are published and consumed through a domain element.

Resource Description

Resource

Resource Priority

Resource Property Value

Channel

Gadget Instance

Gadget

Access Point

Catalogue

WorkspaceGadget Group

User DomainElement

0..* 1 1

1..*

1..*

0..*

0..*

0..*

0..*1..*

1

publish

consume

connectedTo

publish

owns

0..*

0..*

0..*

0..*

11

1..*

1..*1..*

1..*

1..*

0..*

1..*

Figure 37: Information Model of the Presentation Concern

9.2 Data Flow in the Presentation Concern The activity diagram in figure 38 shows the main data flow between the functionalities of the presentation concern. Upon the arrival of requirements for a SFER, a SFER is created and published. This includes both simple gadgets as well as composed gadget groups creation. These SFERs then can be executed to meet a certain service demand resulting in observable actions.


RequirementsCreation of User

Interface Components

SFER

Execution of User Interface

ComponentsObservable

Action

Figure 38: Data flow in the Presentation Concern

9.2.1 Creation of User Interface Components The functionality creation of user interface components allows the design, the implementation and publication of user interface components (see figure 39), including the creation of individual SFERs and the composition of them creating a mashup as. The description of the SFER is designed according to the requirements for the SFER. Based on the description and for the creation of mashups based on existing SFERs that have been published in a catalogue, a SFER is implemented which then can be published in a catalogue itself.


RequirementsDesign of User

InterfacceComponents

Implementation ofUser Interface Components

SFE Resource

SFERDescription

<<Datastore>>SFER Catalogue

Publication of User Interface

Components

SFE R[published]

Figure 39: Functionality Creation of Service Front-End Resources

9.2.1.1 Implementation of User Interface Components The implementation of a SFER differs depending on whether a simple SFER is created or a composed one. The implementation of a simple SFER just includes the implementation of the user interfaces and the logic implemented by them while the mashup implementation includes the search and selection of individual SFER and the design of the workspace, including the connection of SFER as shown in the activity diagram in figure 40. Based on the SFER description, the first step is to select those existing SFERs that meet the stated needs. Similar to the discovery concern a search query is specified which is performed on a SFER catalogue that allows retrieving a list of candidate SFERs. From this list a selection is made of those resources that are intended to become part of the mashup. These SFERs are included into the workspace and then connected via channels. The result is a new SFER.


Search of SFER

SFER Design

Selection of SFER

<<Database>>SFER Catalogue

Search Result

Design of SFE Workspace

SFER [published]

WorkspaceConnection of SFER

SFER

Coding

Channels

Figure 40: Functionality Implementation of SFER

9.2.2 Execution of User Interface Components This functionality is aimed at rendering SFERs and providing the results of the execution of the services invoked by those SFERs. It also deals with the connections between the SFERs that allow information exchange at the level of interface components. Based on contextual information the SFER is adapted to its context if needed. This adapted SFER is the basis for performing the rendering of the SFERs, which then can be delivered. The delivery needs the connections between SFERs to be handled in order to achieve the observable action that was intended by the demand for the execution of the SFER.


SFERAdaptation to

Context

Delivery Format

Delivery of SFER SFER

[delivered]

ContextInformation

SFER[adapted]

Rendering of SFER

Management ofSFER Connection

Observable Action

Figure 41: Functionality Execution of SFER


10 MANAGEMENT CONCERN The management concern is devoted to the management and monitoring of services and processes, and in more general to the management and monitoring of the usage of all platform functionalities as shown in the following use case diagram.

<<Management Subsystem>>


ConfigurationService

Consumer

Billing andAccounting

Monitoring

Service Provider

Admin

SLA Management

Figure 42: Functionality of the Management Concern

Management takes a holistic approach. Services can be decomposed into smaller components, both software and hardware. Services and their underlying components can be configured and deployed in many different ways, each of them resulting in different QoS and service cost. Management is the activity that takes care of deciding how to configure and deploy services on the underlying components at system level. This results in federated management, resulting in a global management action orchestrating lower-level management actions which can also delegate management actions to other components. Management aims at guaranteeing SLAs whilst maximizing other explicit service level objectives such as cost reduction, etc. A system component (resources, services…) in order to be managed needs to be monitored, so its behaviour must be observed and quantified to drive management decisions. Additionally, it compiles billing and accounting information as result of monitoring tasks. From the management perspective (governance), controls are needed to manage development-time as well as change-time, access requirements and the processes around modifying as well as changing services. Services and processes, as well as their containers, should offer a management interface in order to be controlled. This interface should be implemented by a management entity, which is in charge of executing actions on the managed elements. The management capabilities include operations to deploy/undeploy the service in a particular service-oriented environment, set the configuration (access point, name, etc.), and start/stop service instances (allowing particular configurations). The specific configurations of the services are defined in metadata. The processes are managed in the same way as the services.


On the execution (monitoring) front, facilities are needed to monitor the availability of services and their performance and take appropriate actions when quality-of-service problems occur (such as slow response time). This demands a logging capability, and it should also be possible to track the occurrence of particular business events. This business event tracking is based upon the characteristic of an SOA where services actually represent some distinct business operation. This enables operational information to be related to an actual business event rather than a technical occurrence. Reporting mechanisms are required, ideally providing both real-time and off-line statistical summaries of operational activities. Support must be provided to allow services to be stopped, taken off-line, and restarted. Fault avoidance and fault tolerance mechanisms should also be put in place, such as fail-over support and the ability to re-route around failures. Once performance is being monitored, it also becomes desirable to start tracking the SLA status of individual services. This is important when trying to ensure that the SOA is serving the business appropriately and delivering the expected benefits. Businesses should be able to specify what the service level requirements are for individual services, and then IT should have the ability to monitor the SLA to detect any out-of-compliance situations. This section provides the description of functionalities related to management. The different functionalities have been determined based on the given system requirements and based on knowledge of practical solutions.

10.1 Structure View The following diagram captures the information entities and the dependencies between them, which are relevant for the management subsystem. As it can be seen, the entity servcie component which is the result of the functionality creaeion of service component in the service subsystem plays a central role also for the management subsystem. A service level agreement (SLA) for example is always related to a specific service offering. A SLA consists of service level objectives (SLO) that allow to express the requirements (goals) of the service (e.g. in terms of response time capacity, availability, reliability, recoverability, maintainability, safety, security…), constraints that bind the goals, configuration parameters that define the current behaviour of the service and rules (policies) that can handle events appropriately, is related to a certain service component. Both, the SLOs and the constraints are defined in the SLA by using metrics, which could be metrics for the performance, usage etc. Policies can be differentiated into monitoring policies and management policies. Whereas both consist of configuration parameters, detailling information about the mode in which the monitoring is performed, the relevant information that are monitored, the time frame during which the service is monitored etc. The service component is also the target of the monitoring activity. Monitoring data are collected which describe its execution (adhering to the monitoring policy). These monitoring data are used to create billing and account information which can be used as input parameter for functionalities that are actually initiating the payment process.


SLA Policy

Service Component

Monitoring DataConfiguration

Parameter

Management Policy

Monitoring Policy

Metric

SLO Constraint

ad

he

res

to

de

fin

ed

by

…Performance Usage

defined by

Billing andAccountingParameter

1..*

1..*

manages

0..*

1..* 1..*1..* 1..*

1..* 0..*

Figure 43: Information Entities in the Management Concern

10.2 Data flow in the Management Concern The following top level activity diagram summarizes all the functionalities and the data flow between them relevant to the management concern. As it can be seen the four functionalities are initiated upon different demands. The functionality SLA Management for example uses existing service offer information and creates an SLA based on a service demand which needs to contain information about the targeted characteristics using the different metrics that have been defined. However, this functionality does not only allow creating and negotiating SLAs but also to monitor if the SLAs are met. Thus, monitoring data are used to analyze the compliance and produce compliance information upon which the service consumer can take appropriate actions in order to allow satisfying certain business needs. Deployment management and configuration uses an existing service component which can be simple or composite in order to deploy it on computational resources and thus make it a running software component that can be executed. As additional input some constraints on the deployment are used which are the baseline for the definition of management policies. The billing and accounting functionality is performed upon the arrival of a billing and accounting demand (this can either be based on a regular time interval, after a service execution has been completed or on other events defined in a


contract). The billing and accounting information, which a service provider can use in order to charge the customers, are based on monitoring data. The monitoring functionality is performed if a monitoring demand exists. This monitoring demand needs to specify certain monitoring parameter like what needs to be monitored, which characteristics over which time etc. so that a monitoring policy can be created based on this information. The output is a collection of logged monitoring data that can be used for further analysis. The activity diagram in figure 44 shows all the functionalities related to the information elements at a glance. Each functionality is described in detail in the following.

Service Offer Information

ServiceDemand


Billing andAccountingParameters

SLA Management SLA

ConfigurationParameters

Monitoring Data

Monitoring


Configuration

ServiceComponent

Service Component

[running]

Figure 44: Data flow in the Management Concern

10.2.1 SLA management This functionality allows managing both, functional and non-functional requirements and capabilities of services, which might be expressed through SLAs and its components, the SLOs. It comprises functionalities that allow

• to describe a SLA (Service Level Objectives, constraints, configuration parameters and policies/rules),

• to translate the description into an interpretable form that the system can understand,


• to negotiate SLAs between the service consumers and providers (the systems should drive this negotiation in order to reach an agreement between both parties),

• to monitor the compliance of services towards SLAs.

MetricsDescription

of SLA

SLAInitial Definition

Translation of SLA

SLAMachine

Interpretable

Negotiationof SLA


SLA

Monitoring DataMonitoring of SLA

Compilance

SLA not satisfied

SLA satisfied

Figure 45: Functionality SLA Management

The activity diagram above shows the main SLA management functions. Based on a service demand (expressed in certain characteristics that the service offer needs to be met using the available metrics) an initial SLA description is created, which is described in terms of SLOs and constraints. This SLA is then


translated into a form interpretable by software systems. The constraints are transferred into policies and the SLOs into configuration parameter. Based on this interpretable SLA notation, the SLA is negotiated by the provider and requester agent taking the service offer information of the provider into account. This service offer is also expressed in terms of an SLA described by SLOs and constraints. The negotiated SLA then can be used to analyse the compliance of the performed service. The results obtained from monitoring the QoS of services must be compared with the requirements specified in their SLAs. This functionality ensures that the negotiated SLA is fulfilled. In case that the contract is not fulfilled, it can be re-negotiated. 10.2.2 Deployment Management and Configuration This management functionality allows controlling easily complex (decentralised) applications, services and platform services, allowing service providers and administrators to deal with the whole system in an efficient manner for administrative purposes. It comprises functionalities that allow controlling the management policies/rules, deploy/undeploy and configure services, service compositions and platform services in heterogeneous infrastructures (NCI) in a transparent way, taking into account the configuration parameters and relationships between different components.


Configuration ofManagement Policy

ManagementPolicy

Deployment

Service Component

Service Component[running ]

Figure 46: Functionality Deployment Management and Configuration

Both, human actors and computer systems (self-management) can perform the management functionality (adopting an administrator role). Self-management allows systems to manage their own configuration and operation, minimizing human intervention. The rules that drive management can be derived mainly from SLAs and service monitoring. That is, the entities administrating the system (either humans or autonomous systems) base their management decisions mainly on the SLAs that have been agreed and must be fulfilled and


the information extracted from monitoring, that is used to quantify the QoS for the SLAs. The activity diagram above shows the main deployment management and configuration functions. Configuration parameters, which normally are specified by a certain SLA (but can also have a different source), are used to define the deployment policy for a service or a set of services to be deployed as part of the NCI. This management policy as well as the implemented service component are used by the deployment functionality in order to create a running service component that can actually be executed by the service subsystem.

10.2.2.1 Deployment The deployment functionality can be more detailed as described in the following. Service deployment refers to the basic functionality where to deploy a service and when to start or stop it etc. Deployment is an optional but typical step between service creation and service execution (as described for the service concern). Already in non-SOA-based systems, it is standard behaviour that a piece of software can be executed on a different computer than the one where it has been created. This involves typically copying the software to a folder, uncompressing it, and optionally executing an installation program. This can be seen already as a simple form of deployment. To gain more flexibility, the decision where a service will be executed can be deferred until its execution. In advance, a network of computational nodes can be chosen but it remains transparent where the service will be executed. Moreover, this location can even be changed dynamically. Service deployment can be done completely manually but to reach its full power it has to be automated or at least has to be supported by a software environment. Also note that deployment can assign a physical node or in the case of virtualized resources a symbolic node, which has an influence on the registry entries and how to resolve them. The following activity diagram shows that a service component which is subject to deployment is first configured according to the management policy before it is deployed. A deployed service component still cannot be invoked - it has to be started first. After the start functionality it is a running service component which can be executed to perform the service it provides. A service component can also be stopped to prepare for undeployment. Stopping is only feasible in certain execution states of a service. Sometimes this is not supported while a service is executed. Then enforced stopping will lead to errors or inconsistencies from which consumer and provider have to recover. Upon an undeploy request, which has to specify the component and its location, the targeted service component can be undeployed. In this case a change request is created which triggers an update of the according service offer information in the discovery subsystem to remove the information about the endpoint reference.


Configuration ofComponent

Service Component

ManagementPolicy

ServiceComponent

[connfigured]

Deployment

Service Component[deployed]

StartService

Component[running]

Stop

StopRequest

Undeployment UndeployRequest

ChangeRequest

<<Discovery >>

Update of Service Offer Information

Figure 47: Functionality Deployment

10.2.3 Monitoring Monitoring is a complementary task for the management of computer systems. A computer system must monitor its components (both resources and services) in order to capture important information that may be useful for taking managing decisions on the system as a whole or in a particular component. Monitoring may range from simply checking that a component exists to actively querying its state and responsiveness. The monitoring functionality supervises the elements that comprise a service-oriented infrastructure, i.e., the running applications and services and platform services that constitute each concrete infrastructure. It comprises functionalities


that allow to setup/modify the different parameters and metrics to monitor from the services (% of usage, availability, performance, efficiency, security…) and the policies/rules that drive the monitoring tasks, to gather statistics of the usage of monitored elements and to gather information about the different metrics (availability, performance, efficiency, security, etc.). So, it is a prerequisite for every service that requires to be monitored to log this information (e.g. in a storage area) in order to be further used. As the following activity diagram shows, a monitoring policy is first configured based on a set of specified configuration parameters stating which metrics have to be monitored, which service component etc. Using this monitoring policy as well as the running service instance that has to be monitored, the actual monitoring data are collected. This monitoring data can be retrieved in different ways. Monitoring includes both polling and notification mechanisms to the actors involved in the monitoring tasks (e.g. services and administrators).


Configuration ofManagement Policy

ManagementPolicy

Service Component

Collection ofMonitoring

Data

MonitoringParameters

Figure 48: Functionality Monitoring

10.2.4 Billing and accounting Based on the information provided by the monitoring functionalities, this functionality allows to produce billing and accounting information of the service usage and QoS provided. This information is useful for service providers in order to calculate and charge consumers for service usage depending on the SLAs agreed. It is also useful for service consumers in order to evaluate the current usage of services with regard to the SLAs agreed (e.g. to detect if they have contracted too much system capacity). The following activity diagram shows the main billing and accounting functions.


MonitoringData

Analize MonitoringData

Metrics

Generate Billing andAccountingInformation

Billing andAccountingParameters

Figure 49: Functionality Billing and Accounting


11 SECURITY CONCERN The security concern addresses the support to manage the security of the system. It covers aspects concerning:

• User/client authentication • Access control authorization • Link level encryption or network segregation of messages • Denial of service attacks • Tampering with information flows Security can be managed through the whole SOA-based system by promoting a policy-based security services approach. In this context, policy-based security services will provide all relevant functions for security management to NEXOF Compliant Infrastructures as well as its domain specific instances. The overall process leading to authorize or deny a request sent on behalf of a subject to access a protected resource, can be described as a “security pipeline”, that is, identification followed by authentication, followed by authorization.

<<Security>>

Authentication

Authorization

Privacy

Provider

Consumer

Integrity

Administrator

Developer Figure 50: Functionalities of the Security Concern

“Security is key issue with many Implications, and it is critical throughout software systems. Thus, when we speak of security in software, it can refer to many areas of system - applications, data, networks, communications, users, host systems, and so forth. Within each of these areas are common security requirements and goals that involve the protection of data. Data is passed over communication paths that may be open to authorized viewers needs to be protected; this is the concept of privacy. This same data must be protected from unauthorized changes during transit; this is the concept of data integrity. Users, whether human or programmatic, must be able to prove their identities before


being allowed to access to the data; this is the concept of authentication. Once authenticated, the system needs to ascertain what type of access the user has to the data; this is the concept of authorization.” [29] The use case diagram (see figure 50) above shows the four main security functionalities.

11.1 Structure View The important information entities relevant to the security concern are shown in the information model in figure 51.

Authentication Data

Authentication Result

Access Rights

Enryption

Message

Digital Signature

Credentials

Identity Data AuthorizationData

Privacy DataLogin

Password

TrustedTimestamp

Authentication Protocol

1based on

1..*

1..*

1

AuthorizationProtocol

basedon

Resource

Digital Certificate

use

s

uses role based on

ac

ce

sso

n

limite

d tim

e

pro

tec

ted

by

Privacy Policy

encrypt

ad

he

res

to

sign

sign trust

Figure 51: Information Model of the Service Concern

Authentication relies on both identity data and authentication data. Identity data are the credential consisting of a set of authentication protocols that gives the identity of the consumer, i.e. commonly a login. An authentication result is always computed against the authentication data. Authentication data can be from different types, according to the technology. This includes static passwords and digital signature based on digital certificates. Digital certificates can be digital signatures or trusted timestamps for example. Digital signatures rely on


the public key infrastructure technology where certificate revocation lists enable to check the validity of the certificates. Timestamps can also grant a certain authorization protocol which constitutes authorization data an access to a resource for a limited time. Access rights are computed based on the authorization data. Digital signatures and timestamp also can be used to sign and trust messages and the data they contain as well as privacy data.

11.2 Data Flow in the Security concern The activity diagram in figure 52 shows the data flow of the described information entities between the security functionalities. The authentication functionality provides an authentication result based on the authentication data which states whether the identity of an entity is valid or not. This authentication result is mandatory for the authorization - whatever technology is used for authentication – in order to provide an access right for the authenticated entity.

AuthenticationAuthentication

DataAuthentication

Result

AuthorizationData

Auhorization

Digital Certificate

AccessRights

IntegrityCheck

IntegrityMessage

PrivacyCheck

Privacy

PrivacyData

PrivacyPolicy

Figure 52: Data Flow in the Security Concern

Authorization relies on authorization data from different types:


• Some authorization technologies rely on digital signature which embeds user roles (this is e.g. adopted by PERMIS6

• Timestamps also can be used in an authorization process if the access control policy depends on periods of time or completion of an action before a dead-line, etc.

)

Integrity consists of checking that a data or message has not been modified during a process. The functionality needs as input the message to be checked in order to compare it, for example, with a digital signature and/or a time stamp that have been computed at the beginning of the security process. The integrity functionality provides an integrity check. Privacy is the ability to give the owner of private data insurance to that his data will be used according to a privacy policy agreed between the consumer and the provider of the service. All the technologies above, from authentication, to authorization, to integrity, combined to serve a given privacy purpose, can contribute to trace the actions on the data and ensure transparency to the end user about the usage of his data. The functionalities are described in more detail in the following. 11.2.1 Authorization This functionality allows determining whether an entity can access to the given protected resource in order to execute an operation. The authorization enables a simple entity, a service consumer or a service provider to capitalize on the Internet infrastructure together with controlling the access to the resource or pieces of information it connects. According to the context where it is used, this relates to confidentiality of the information. It always relies on identity management and previous authentication of the entity. One efficient and experienced way to manage authorization consists in categorizing types of access needs by describing roles. Each role is associated with related access rights. User identities need then to be bound to these roles. 11.2.2 Authentication This functionality ensures that an entity’s identity is truly what the entity claims it to be. Authenticated identities are then the basis for applying other security mechanisms, such as access control. Loosely speaking, a user can be authenticated on the basis of something he holds, he is, or he knows. Various mechanisms are currently available to implement each such approach. “Something you know” is typically implemented through mechanisms such as password, or challenge-response protocols. The “something you hold” approach is implemented through token-based mechanisms, smartcards, or a PIN that the user possesses and must present in order to be authenticated. Finally, the “who you are” paradigm is based on biometrics and includes techniques such as fingerprint scans, retina scans, voiceprint analysis, and others. Once the identity of a user has been verified, the system resources are made available to the user, possibly under the constraints specified by the access control policies, 6 http://www.openpermis.org/

http://www.openpermis.org/�


until the user exits the system. Such an approach may be appropriate for low-security environments or for environments in which the same strength of authentication is required for all resources. However, it is not appropriate in cases in which the same system may have resources with different requirements concerning authentication strengths for the subjects wishing to access them. 11.2.3 Privacy This functionality provides a feature to protect the privacy of personal data during service execution. In doing that, obviously, also legislations regulating the privacy have to be taken in account. This can be achieved by enforcing the user privacy preferences, which implies to match them against the privacy policies associated with the services (i.e. the enterprise privacy policies). To this aim, the functionality exploits the existing standard to represent both user privacy preferences and privacy policies, like The privacy functionality is the concept which is related to other functionalities such as: Signature, Accountability and Encryption etc. One of the aspects of privacy is to track all actions of an entity on the authorized resource (Accountability or Traceability).

Addition ofIntegrity

Information

Message

Digital Certificate

Need forAdaptation

Check ofIntegrity

Message[enhanced]

IntegrityCheck

Figure 53: Functionality Integrity

11.2.4 Integrity The functionality integrity allows guaranteeing that data is not modified either accidentally or maliciously. The integrity can be separated into two steps as shown in figure 53. On the one hand the message needs to be enriched with integrity information which results in the need for a message adaptation which is addressed by the functionality adaptation of message in the message subsystem. One the other hand an enhanced message that is received can be checked for its integrity against certain characteristics. The integrity can be obtained in different manners. The encryption of a document protects against to the unauthorized access. The digital signature guarantees that the document has not been modified since the signature. Trusted time-stamping adds the


information of the time of the signature. The authorization controls the access to the external agent (resources, software system…) and assures that the modification on a document is made by the authorized entity.


12 RESOURCE CONCERN The resources concern deals with the infrastructure of NCIs. It includes all the computational resources needed to support the execution of all the software components that constitute the platform: virtualization of computing, storage and network resources. It is important to highlight that, in this context, software components, such as service containers, message brokers, service registries, process engines that are commonly considered SOA Infrastructure components, are not considered as part of the resources subsystem (the infrastructure of the SOA infrastructure). A basic premise is that infrastructure will be made available as services (called infrastructure service in the following to differentiate from services of the service concern). In very general terms these services will support the execution of software components (in the sense of units of deployment rather than anything more technologically specific). The functionalities provided by the resource concern are shown in the following use case diagram (see figure 54). The virtualized service administrator (VSA) is an actor, who is responsible for deploying/undeploying and starting and stopping infrastructure resources.

<<Resource>>

LifecycleManagement ofInfrastructure

ResourceGroups

Monitoring ofInfrastructure

Resources

Metering ofInfrastructure

Resource Usage

VirtualizedServiceAdmin

Consumer

InfrastructureProvider

acts on behalf of

Figure 54: Functionality of the Resource Concern

12.1 Structure View The information model shown in figure 55 depicts the information entities relevant for the resource concern. The central class is service component, describing the service that is going to be executed by a virtualized infrastructure service that is managed by the service manager. The virtualized service manager (VSM) is the component that interacts with the service providers to receive their service manifests, negotiate pricing, and handle billing. A service manifest is the formal request for deploying a service within an infrastructure provider. It includes all the information needed to instantiate a service


application, as well as the information needed for automatically managing the service application lifecycle. In the virtual service repository (VSR) all virtualized services and their attributes are saved. The attributes are SLA definitions, business rules, service definition, elasticity rules and service lifecycle. When a service gets deployed, the attributes of the specific service are requested from the VSR.

Resource Utilization Data

Service Component

Service ManifestPay Per Used

Data

Virtualized Infrastructure

Service

Virtual Service Repository

Virtual Execution Environments

Virtualized Service Manager

de

plo

yed

by

managed by

pro

vide

sapplies to

use

s

Elasticity RulesService Lifecycle

InfoService Level

AgreementService Definition

Service Manager Interface

pro

vide

s

Virtual Execution Environment Host

Virtual Execution Environment

Manager

manages

Virtual Execution Environment Management

Interface

pro

vide

s

Co

op

era

tio n

Computational Resource Group

Computational Resource

represents

rep

rese

nts

…CPU Memory

federated

Figure 55: Information model of the resource concern

The service management interface with its service manifest exposes a standard interface for service providers. The service manager interface (SMI) is a set of


interfaces that the VSM offers to the service providers and virtualized service administrators to manage the service delivery. Through SMI, the service providers can manage their services lifecycle by designing the service deployment lifecycle process over a federated virtualized infrastructure, and they can be billed for the use of the infrastructure. The service manager is also responsible for ensuring SLA compliance and dynamically adjusts the service application capacity as defined in the elasticity rules in the manifest. It is also responsible for compiling requests for the provisioning of infrastructure services, as represented by a service definition manifest, into a list of virtual execution environments (VEEs) and the related placement constraints. VEE is a term used to refer to a generic virtual resource regardless of the virtualization technology, for example Xen domains7 are VEEs, in the case of server virtualization; Virtuozzo Containers8 or AIX WPARs9

A virtualization execution environment host (VEEH) is a physical machine along with the virtualization software required to host and control a particular type of VEEs. For example a physical machine with Xen’s hypervisor and dom0 are a VEEH; a physical machine with Linux and the Virtuozzo OS virtualization layer on top is also a VEEH. A VEEH hosts VEEs of the same virtualization technology.

are also VEEs if OS virtualization is used. VEEs are the basic unit of resource management. VEEs abstract away the physical characteristics of the infrastructure resource and enable sharing. VEEs can have affinities to specify whether a particular VEE type can be deployed in the same host, site or domain as other VEEs. Each VEE is instantiated in runtime, creating some VEE replicas that reflect the running state of each virtual machine created using VEE as a template.

The virtual execution environment manager (VEEM) is responsible for the optimal placement of VEEs into VEEHs subject to constraints determined by the VSM and can place and move VEEs on the same site as well on the remote sites. Of course the placement must be compliant with the constraints. The VEEM is only aware of the VEEs, it is responsible for (local and remote placement), as well as their state and placement. The VEE host interface (VHI) is a generic API for interaction between VEEH and VEEM. It abstracts the specific virtualization technology and supports the VEE. The VEEM is interacting with the VSM above it, the VEEH below, and the VEEM at other sites in order to enable federation. The VEE management interface (VMI) is a general interface to interact with the virtual execution environment manager. It provides the functionality needed to dynamically deploy, control and monitor complex services.

7 http://www.xen.org 8 http://www.parallels.com/splp 9 http://www.ibm.com/developerworks/aix/

http://www.xen.org/�

http://www.parallels.com/splp�

http://www.ibm.com/developerworks/aix/�


12.2 Data Flow in the Resource Concern The activity diagram in figure 56 shows the data flow between the main functionalities of the resource concern. Upon the arrival of a service manifest, describing the formal for an infrastructure service, the available VEEs are taken into account in order to manage the lifecycle of infrastructure resource groups and provide the infrastructure service as requested. The virtualized infrastructure service is used in order to monitor its usage, so that based on this monitoring the consumer can be billed in a pay-per-use manner, where users are charged only for quantity of resources allocated or reserved. Users must be able to monitor relevant aspects of the state and utilization of all the virtual resources allocated as well as the status of any unused reserved capacity. Infrastructure service providers will require related capabilities although the details and scope of the monitored information will be different. The lifecycle management and the monitoring are continuous activities so that changes in the state of a resource can also be monitored and not only the usage of a provided service. The lifecycle management functionality comprises different functionalities including the configuration of computational resources as well as the assignment as described in more detail in the following sections.

LifecycleManagement ofInfrastructure

Resource Groups

InfrastructureResources

LifecycleEvent

ServiceManifest

VirtualizedInfrstructure

ServiceMonitoring ofInfrastructure

ResourcesResourceUtilisation

Data


Resource UsagePay-per-UseInformation

Figure 56: Data flow in the resource concern

12.2.1 Lifecycle Management of Infrastructure Resource Groups Infrastructure services are low-level services relatively close to the physical infrastructure (typically these would offer interfaces familiar to network and systems administrators who are used to dealing with physical or virtual


resources, operating systems and generic software platforms). This functionality allows the management of infrastructure resource groups throughout their whole lifecycle including the configuration of infrastructure resources as well as the assignment of virtualized services to computational resources. Based on the service manifest and the available computational resources, the computational resources are configured in a way that they can provide the requested infrastructure services. The virtualized services are then assigned to the infrastructure resources according to the service manifest resulting in the provision of the infrastructure services. Lifecycle events as specified in the service manifest can trigger the configuration functionality to cope with adaptations maybe resulting in a change of assignments. The two functionalities can be decomposed into further functionalities as described in the figure 57.

Configuration ofInfrastructure

Resources

InfrastructureResources

ServiceManifest

ResourceGroup

Assignment ofInfrasturcture

Resources

InfrastructureService

ResourceUtilisation

Data

LifecycleEvent

Figure 57: Functionality Lifecycle Management of Infrastructure Resource

Groups

12.2.1.1 Configuration of Infrastructure Resources The functionality configuration of infrastructure resources allows configuring the infrastructure resources of the infrastructure, i.e. the computational nodes (CPU, RAM, …), the storage, and the network. It can be decomposed into the functionalities of suspending and resuming a resource set as well as replacing or deleting a resource in a resource set. Infrastructure services have to support suspending entire virtual resource sets to enable users to temporarily stop entire applications to avoid costs, or to use allocated capacity for a higher priority application without losing the lower priority application. Clearly this functionality is geared mainly toward compute resources, but similar concepts are applicable to other types of resources, for example, a suspended virtual disk may be moved to secondary storage (tape),


i.e. the suspended state for a resource means that although it is not being used now, it can be easily (and rapidly) restored to full functionality. Accordingly, infrastructure services have to support resuming a previously suspended virtual resource set (otherwise suspend is equivalent to delete). This may be used when the demands of a higher priority application reduce and lower priority applications may run. At any time during the life of a virtual resource set, the user may request from the infrastructures service to remove or replace one or more virtual resources from the set. This functionality is needed to allow the user to control costs since used or reserved capacity is likely to be chargeable. Similar, at any time during the life of a virtual resource set, the user may request from the infrastructure service to add more virtual resources to the set. The request has to be accepted up to the reserved capacity (if any). Beyond reserved capacity, acceptance is on a best-effort approach. This functionality is needed for example when more servers need to be added to a complex multi-server application that is under stress (e.g. due to high traffic/usage).

12.2.1.2 Assignment of Computational Resources The functionality allows assigning the computational resources to the different components of the NCI. It can be detailed into provision, migration and removal of resource sets as well as into release and reserve capacity. To ensure effective use of limited resources, it must be possible to release reservations of capacity. Once reserved capacity has been provisioned, the reservation is released. Alternatively, if a reservation is not exercised within a defined time period (e.g. specified by provider policy or as part of the reservation), the reservation may be released automatically Similar, to ensure successful provision of a set of inter-related virtual resources, the user may request to reserve capacity prior to the actual provisioning of resources. If capacity is available the infrastructure service will put it aside (commit it) for the sole use of the requesting user/customer. Not all of the reserved capacity has to be used at once. The reserved capacity is associated with the user and not with a specific virtual resource set. Users of infrastructure services need the capability to provision and merge sets for provision of one or more inter-related virtual resources. The definition, requirements and interdependencies for each requested resource in the set are specified by the user and, if there is enough capacity to satisfy the resource requirements of the entire set, the infrastructure service will instantiate it, i.e., allocate the requested capacity on physical resources, and in the case of computational virtual resources activate them so they are available for use. When a user no longer needs the capabilities of a particular resource set, he/she may request to completely remove the set. Once deleted, the virtual resource set cannot be restored and the user is not charged any more for it (although he/she can still be charged for unused reserved capacity).


13 FUNCTIONAL AREAS OF THE NEXOF REFERENCE MODEL After the functionalities relevant for a specific context have been identified the question has to be answered how these functionalities can be bridged to an implementation. The new view created for the model addresses this issue. In this view the functionalities are grouped into functional areas that have to be considered during the creation of a specific architecture and thus can be found in the implementation of these. On a conceptual level it defines a structure that all top level patterns follow despite of the domain they are created for. However, this view does not make any architectural decisions on how these functional areas are actually allocated in architecture instances. The view describes the functional areas, the functions they include as well as their inter-dependency. The new view does not replace the nine concerns but presents the reference architecture on a conceptual level putting the main focus on a different perspective. Different views of a model generally present the same thing while showing different aspects of the modelled system. The new view focuses on how functionality are logically decomposed while the nine concerns originally have been identified to structure the research activities within the project and are orthogonal in all views. The functional areas that have been identified for the NEXOF Reference Architecture can be seen in the following picture

Figure 58: Functional Areas of the NEXOF Reference Model

The Infrastructure area deals with (optionally virtualized) hardware and operating systems. It deals with the provision of the allocation, the configuration and the control functionalities (aka. Management) of these hardware and operating systems. The Service Platform is the core of the reference architecture. It runs over/on the Infrastructure Services and includes the functional areas that deal with the Service Execution, Publication and Discovery, and the User Interface. The Publication and Discovery area supports to publish (required), to search, and (optionally) to browse for services. The User Interface area is constituted of mechanisms to support the design and execution of user interfaces to services in a context-aware manner (i.e. user-aware, platform-aware, and environment-aware). The Service Execution area focuses on execution of services, messaging, and compositions. It is constituted of functionalities that allow the design and execution of services as well as of


composite services (i.e. services implemented through the invocation of multiple services). The execution includes all service lifecycle aspects beyond design; e.g. deployment instantiation and execution. Security and management are cross-cutting aspects whereas security includes privacy, trust, audit, and compliance. Management focuses on configuration (online and offline), monitoring, self-*, scalability, availability and SLA/QOS etc. Each subsystem is responsible for the local application of the cross-cutting aspects provide guidelines, management interfaces, integration, federation, and a holistic view. The grouping of the top level functional decomposition towards the functional areas in this view can be seen in the following figure. Starting from the functional areas architectural solutions can be selected that address the identified functionalities as well as dependencies between them. Selecting solutions for single functionalities would be too fine granular.


14 DEPENDENCIES OF THE MODEL WITH NEXOF REFERENCE ARCHITECTURE ELEMENTS ......................................................................................................... 96

14.1 The Structure of the Reference Architecture ......................................... 96

14.2 Relation to Requirements ...................................................................... 98

14.3 Relation to Patterns ............................................................................... 99

15 DERIVING INSTANCES OF NEXOF COMPLIANT ARCHITECTURES ...................... 101

15.1 Conceptual Instantiation Process ........................................................ 101

15.2 Harbour Scenario ................................................................................ 104

15.2.1 Mapping to the NEXOF Reference Architecture ............................ 104 15.2.2 Functional Decomposition ............................................................. 104 15.2.3 Relation to Requirements .............................................................. 105

16 CONCLUSION ............................................................................................... 107

PART III – APPLICATION CONTEXT OF THE NEXOF REFERENCE MODEL


14 DEPENDENCIES OF THE MODEL WITH NEXOF REFERENCE ARCHITECTURE ELEMENTS

The variety of technologies and standards in the domain of service-based systems makes it complex to build architectures which fit specific project contexts. A reference architecture accompanied by guidelines for deriving context-specific architectures for service-based systems can ease this problem. The NEXOF-RA project is defining a reference architecture for service-based systems that serves as a construction kit to derive architectures for a particular project context. Experience in developing the reference architecture over the last two years has shown that the service-oriented context results in different and sometimes contradicting demands for the reference architecture. Therefore, the development of a single and integrated reference architecture is not feasible. Instead, for constructing the reference architecture, the project has chosen a pattern-based approach that allows the consideration of different types and demands of service-based systems. Thus it can deal with contradicting demands of different types of service-based systems and is extensible to include new future trends of service-based systems. This section will shortly introduce the elements that constitute the NEXOF Reference Architecture and shows how the reference model is integrated into this structure. Its relation to the other elements of the reference architecture as well as the consistency between those elements is demonstrated.

14.1 The Structure of the Reference Architecture

The pattern-based reference architecture is composed of several parts, capturing the information necessary to design service-oriented systems (see Figure 59). The main constituents of the pattern-based reference architecture are the following three elements: The guidelines and principles: This captures on the one hand the principle underlying the construction of the framework as well as the set of reference properties associated with each of the components and patterns in the reference architecture. Capturing this knowledge explicitly allows the pattern-based reference architecture to be an evolvable, dynamic reference architecture that can be continuously created by an open community in order to cope with new upcoming trends in the Future Internet. On the other hand this part captures the guidelines used to instantiate a specific system architecture according to its requirements. Since the reference architecture will provide a huge set of architectural solutions and information it is crucial to have a sound methodology that supports system architects during the derivation of actual architectures for a specific context. This is documented in form of a decision tree for a certain part of a system of patterns that helps the architect to evaluate which patterns are the appropriate ones for a certain context considering the different tradeoffs of the quality attributes that are associated with them.


The reference architecture model: As described in the first and the second part, this conceptual model describes the essential entities that constitute SBSs as well as the relationships between these entities and the key elements in the context. It is accompanied by a glossary which defines the terms used across the whole pattern-based reference architecture. While the systems of patterns only specify the internal characteristics of the architecture for a service-based system the model also considers the applications and services that can be deployed on top of a platform realizing a derived architecture. Thus, the model tries to capture the whole service-based system. Differentiating between the platform and the whole system is crucial in order to understand how the platform realizing a derived architecture is used by its surrounding. Beneken [7] describes a functional decomposition as provided by the NEXOF Reference Model as functional reference architecture while the structure viewpoint of the model corresponds to what he calls a logical reference architecture. Thus, the reference model is part of the reference architecture and does not accompany it as an external document as proposed by Vogel et al. [33] or Bass et al. [5].

Reference Specification

Reference Architecture

Standards Catalog

Pattern Ensemble

Top-level Patterns(system families)

XXX SOA

P P P P

YYY SOA

P P P P

Pattern 1P P C

Pattern 2C P P

Pattern 3C C C

Pattern 4C C P

Pattern 6c c c

Pattern 7c c c

AbstractDesign Patterns

ImplementationDesign Patterns

Pattern 5c P C

S

Component Catalog(aka. Building Blocks)

S

S

S

Guidelinesand Principles

Reference Model

Abstract(class of products)

Concrete(refers toproducts)

CS

CS

cSS

cS

cS

S SS S

S S

About:• construction principles• reference properties• instantiation guidelines

S

About:• actors• functionality• information

ConceptualModel

Glossary

Figure 59: Structure of the pattern-based reference architecture

The reference architecture specification: This contains three collections: The standards catalogue describes the standards referred to in the reference architecture. Each standard is linked to the relevant elements of the guidelines and principles as well as to the concepts it addresses. The level of granularity considered in the reference architecture is that of components, which roughly correspond to coherent sets of functionality delivered as software products or software components, which can be configured separately. The component catalogue groups both, abstract descriptions of components (e.g. an UDDI registry) as well as product- or software-based components (e.g. the jUDDI library). Each description refers to the standards it implements, the concepts it addresses as well as its behavioural characteristics.


The System of Pattern, as described above, represents the actionable part of the reference architecture. The specified patterns define various ways of realizing some functionality by associating components and other patterns in a defined manner. The architecture specification includes three types of patterns: top-level patterns, abstract design patterns, and implementation design patterns. Relationships between patterns (e.g. “excludes” or “requires”) are explicitly described. To better support the production of a set of inter related patterns, a top-down production process has been adopted for the pattern-based reference architecture. Starting from the production of top-level patterns, i.e. the most general and abstract patterns, other patterns are produced with respect to other already committed patterns. This way, the problem they address and the context where they are applicable are clearly and well-defined. Taking the ESOA family into account, the “Distributed ESB in E-SOA” pattern for example can only be specified after the “Enterprise SOA” top-level pattern has been created and the use of the ESB component as well as its relationships to other components are clearly defined and thus can be refined in a separate pattern. This approach simplifies the verification of the consistency of the overall set of patterns and makes it more controllable. As mentioned above, the pattern-based reference architecture does not distinguish between the actual architecture description and the reference model but includes both of it. Thus, the part of the reference architecture specification in the presented structure constitutes the part that is traditionally referred to as reference architecture in literature. The different types of patterns and different levels of abstraction that are covered by them provide all the information that should be given in a logical as well as a technical reference architecture (cf. [7]). The component and the standards catalogue accompany the system of patterns to make the patterns directly reusable adhering to the construction kit concept. The model constitutes especially the bridge from requirements to the patterns as described in the following.

14.2 Relation to Requirements Within NEXOF-RA a detailed requirements analysis has been performed in order to define the needs that have to be met by NCIs [24]. This requirements analysis has resulted in two different kinds of requirements sets. On the one hand the scenarios provided by the partners of the project have been used to derive business requirements towards service-based systems (independent of the type of SBS, i.e. taking enterprise as well as Internet of Services scale into account). Although the scenarios address certain business domains, the business requirements have been abstracted from those domains as well as the SBS type. Furthermore, a SotA analysis has been performed, which resulted – taking also the business requirements and the initial nine concerns model into account – in the definition of system requirements that specify the needs that a NCI has to meet without taking the services and service-based applications that maybe hosted on it into account.


Based on the initial set of system requirements as reported in the requirements report (cf. [24]), a further analysis has been performed in order to derive a more detailed view on the needs that need to be met by a NCI (intermediate results have been reported in the last version of the model using textual descriptions). Since these descriptions however have been quite inconsistent and on different level of abstractions due to the status of the research results at this time, this representation however, has been advanced in the final version of the reference model. In requirements engineering, a common approach is to use goal oriented modelling to describe the intentions of stakeholders with regard to the usage of the system (cf. [11], [15], [32], [36]). In some domains, stakeholders prefer to use feature models in requirements engineering instead of goal models. While goal modelling was introduced in requirements engineering to document the stakeholder intentions, feature modelling originated from architectural design methodologies and was introduced to document decompositions of functional and quality properties of an architecture at an abstract, intentional level. The underlying modelling concepts of feature models (see e.g. [18], [30], [6]) are thus very similar to goal modelling concepts. “Feature models as well as goal models mainly document hierarchical decompositions.” [27] Besides the documentation of goals and scenarios, solution-oriented requirements have proven to be a reasonable requirements artefact (cf. [3], [2], [17], [31], [37]). These are traditionally documented using the separation between structure, behaviour and functionality as presented in section 3 and which also has been applied to the NEXOF Reference Architecture. Thus, the functional decomposition as provided by the reference model is a different approach of documenting the system requirements. However, since these features originate from the initial system requirements set, every functionality defined within the model can clearly be related to the requirements. This relation is documented for all functionalities and can be seen in the complete set of functionality specifications in Appendix B.

14.3 Relation to Patterns All functionalities that are provided by the architectural solutions described in the patterns instantiate a functionality that is captured in the functional decomposition. As said earlier not all of the functionalities need to be included in the top level patterns. An example of this mapping is shown in the following picture. As it can be seen, the “Discovery of Service” functionality is instantiated by the functionality “find” in the ESOA pattern and the functionality “Publication of Service Offering” is instantiated by the functionality “register” in the ESOA pattern. Full details about the mapping dependencies between the pattern and the functional decomposition can be found in the pattern report [23].


EnterpriseSOA


Search for Services

Browsing for Services

<<include>>

Discovery of ServicesPublication of

Service Demand

Service Discovery

Template-basedDiscovery

Multi-faceDiscovery

ServiceMatchmakingand Ranking

isPartOf[sdGUI]isPartOf[sdEngine]

isPartOf[SpecialisedSdEngine]

isPartOf[Registry]

<<include>>

Designerand Runtime

Tools for E-SOA

Front End in E-SOA

isPartOf[Designer Tool, Runtime]

isPartOf[Designer Tool, Runtime]

Figure 60: ESOA Functionality Mapping for the Discovery Concern


15 DERIVING INSTANCES OF NEXOF COMPLIANT ARCHITECTURES The main goal of a SOA is to change the approach of IT from building monolithic and bespoke applications to building applications that are developed more and more composing assets from a collection of shared, reusable functionality, i.e. software services, in large and distributed, heterogeneous environments. SOA is an architectural style for distributed software systems. This architectural style is based around the concept of software services which represent the fundamental mechanism that SOA introduces to enable application or other software services to remotely use functionality, typically to share data, overcoming economic and technical boundaries and barriers. In line with this, the main assumption that supports the conception and the designing of a NEXOF Compliant Architecture is the following: Software systems for different business domains can be built by adopting the SOA approach. These systems contain business applications that are realized by implementing and composing services that are specific for the corresponding business domain (i.e. business services). Although systems for different business domains differ with respect to the set of business services they contain, they have many fundamental commonalities that are strictly related to the fact that they all are based on software services. These commonalities can be captured, specified and implemented as a domain-application-independent software system that is a service-oriented infrastructure. From the previous assumption it follows that a distributed SOA infrastructure can be adopted to accelerate and facilitate the implementation of complete SOA-based systems in different business domains. These systems can possibly be heterogeneous regarding the specific implementations with different owners. It represents the easiest way to deploy and consume shared, reusable software services, facilitating incremental adoption both economically and technically. It also enables greater deployment flexibility, adaptability and maintainability, e.g. single services can be certified for update more easily than entire applications. This section focuses on describing how actual architecture instances can be derived using the NEXOF Reference Architecture and explains the role of the reference model within this process.

15.1 Conceptual Instantiation Process As identified by Fettke et al. [13] there are two processes that need to be distinguished: the construction of the reference model and the construction of company-specific information models based on these reference models. This differentiation can also be made for the pattern-based reference architecture. On the one hand it is important to have a sound method as presented in the “Definition of an architectural framework & principles” [19] describing how the reference architecture is built to allow the evolution of it in the future. The described approach tries to foster an adaptable and dynamic evolvable


reference architecture that can cope with new trends beyond the NEXOF-RA project to provide a framework for integrating experiences and research results. On the other hand, the process of adopting the reference architecture to derive specific architectures needs to be addressed by providing sufficient guidance at some steps of the process (e.g. selecting the most appropriate patterns to fulfill the non-functional requirements). As described as part of the guidelines, the pattern-based reference architecture will come with a methodology that support system architects during the derivation of concrete architecture instances. The combination of all elements defined as part of the pattern-based reference architecture allows deriving specific instances of a software architecture for service-based systems that adhere to specific requirements. The principles and guidelines provide guidance for the whole process and especially provide a starting point by describing how the requirements can be mapped towards the reference architecture. The process to derive a NCI from the NEXOF Reference Architecture is captured on an abstract level in the following figure.

Reference Architecture

(Description of) System Architecture

Service-based Software System

Requirements,Needs,

Demands

DesignActivity

(produces)


complete set of possible functionalities, a NEXOF Compliant Platform does not have to implement this full set of functionalities but only the subset required to fill the requirements. Together with the instantiation guidelines the reference-architecture can be tailored to the specific context. Through the functionality matching, the architect will select, and combine patterns to design the architecture of the system to be built and deployed. Starting from the top-level pattern of the identified system family for all selected functionalities, the according abstract patterns can be selected following the path through the pattern map down to the implementation patterns. The functional decomposition of the model addresses, for example, the need of functionalities addressing the discovery of services. More specifically it distinguishes between the functionality to search a service and the functionality to browse for a service. The ESOA top-level pattern specifies a functionality called “find” that is partly mapped to the discovery functionality and that is related to the component “Registry” within the ESOA pattern. Within the ESOA family a pattern “Service Discovery” is specified that refines the “Registry” component. Thus, the architectural solution provided by this pattern should be included for an architecture instance that includes the discovery functionality in its functional decomposition. For different types of discovery different abstract design patterns refining the “Service Discovery” pattern are specified, e.g. the “Template-based Discovery” and the “Multi-Phase Discovery” abstract design patterns. Additionally non-functional requirements have to be addressed. Once a NCI has been derived taking into account the functional aspects, it must be enhanced by applying non-functional abstract patterns, which will allow fulfilling the non-functional requirements. Considering the dependencies between the patterns, the needed patterns can be selected and combined in order to describe the system architecture. The final result will be a technical architecture that is accompanied by implementation components provided in the components catalog. The ideal scenario is that there will be enough implementation components so that the derived architecture already comes with an interoperable implementation. As it has been mentioned above, several different system architectures that are NEXOF Compliant Architectures can be derived from the reference architecture. A NEXOF Compliant Architecture can be the architecture of several service-based software systems that are NEXOF Compliant Systems. According to this approach, NEXOF-RA will allow the building of a NEXOF Compliant Infrastructures following a construction kit paradigm. A construction kit contains State-of-the-Art solutions, but also solutions for new and upcoming trends and white spaces. In order to describe the usage of the model within this process in more detail an example scenario is used. This allows showing that artefacts that have been created within the NEXOF-RA project are suitable to guide the creation of an SOA for a specific context starting from a concrete problem situation towards the selection of appropriate architectural solutions.


15.2 Harbour Scenario The example scenario originates from the logistic domain and deals with the management of a cargo harbour, which is of local interest for the University of Duisburg-Essen since one of the world’s largest inland harbours is situated in Duisburg. For the harbour a SOA needs to be created that allows the on demand management of all services provided by the harbour. The harbour consists of storage for packages, docks for ships and trucks, different robots to move the packages as well as an information system that processes all relevant data like package positions, destinations and manages preregistration of ships and trucks. In this scenario the harbour management company guarantees its customers, who are logistic companies, the correct processing of their goods. This includes for example the dispatching of cargos coming in by ship or truck according to their delivery destinations on demand, the processing of the shipping data in order to create shipping documents, the management and storage of stock etc. which are all provided by different companies located on the harbour side. The scenario has been implemented as a service based system within the context of a student project at the University of Duisburg-Essen using Lego Mindstorms technology to simulate the robots. At the time of the implementation the NEXOF Reference Architecture Specification has not been available in the extend as it is now. However, the first drafts of the ESOA pattern have been proven to be useful in this context and guided the concrete implementation relying on technologies as mule, JBOSS, Apache ODE and SOAP. 15.2.1 Mapping to the NEXOF Reference Architecture The communication between the logistic companies, which request a service, and the harbour management company, which provides a service, does not necessarily have to be enabled by a service-oriented architecture (although this could be allowed by a web based user interface) but can also be realized by picking up the phone and agreeing on the service that needs to be performed, the duration, the costs etc. But on the other hand, in order to be able to provide the service of cargo processing to its customers, the harbour management system in this example scenario needs to use the different services provided by the different companies and thus is also a service requester. Different Dock Companies for example offer the service of loading and unloading ships and trucks. The service offer depends on the availability of storage space, docks and robots. The SOA is supposed to allow the composition of the offered services on demand according to the customers need. The harbour management company aims for example at minimal package pick-up counts since fees have to be paid for package movements as well as at a fast dispatching since inactive ships or trucks in the docks are expensive. 15.2.2 Functional Decomposition Focusing on this view a functional decomposition of the needs lead to different features that need to be supported by the SOA. Two of those features will be used to demonstrate their occurrence in the NEXOF reference architecture. In order to allow the Harbour Management System to select an appropriate unloading service, the dock companies need to be able to publish the services


they are currently offering and the harbour management system needs to be able to publish its demand and find services. Accordingly, a service registrar is needed in the SOA as shown in the following figure that supports the discovery of services. The functional decomposition provided by the NEXOF reference architecture addresses related functionalities in the discovery concern. In order to ease the selection of relevant functionality, the functionality view has been adapted and different levels of abstraction have been introduced. For each of the identified nine concerns, a coarse-grain decomposition has been performed that captures all necessary functionalities relevant to that concern. The resource concern for example contains only two functionalities: “Lifecycle Management of infrastructure Resource Groups” and “Monitoring and Metering of Resource Infrastructure”. The first of those functionalities however, can be decomposed in several other functionalities on the next decomposition level. These could include adding, deleting or provisioning resources for example. For the harbour scenario the functionalities “Publication of Service Offering”, “Publication of service Demand” and “Discovery of Service” need to be selected, whereas it has to be decided on the needs of the harbour management if the included functionalities “Browsing for services”, “Searching for Services” and “Subscribing for Services” should be supported by the SOA or if for example only the Search functionality is needed to satisfy their demands. The functionality decomposition does not imply, that all functionalities need to be supported by all architecture instances that are derived from the reference architecture, although it is expected that a large amount of the top-level decomposition functionalities are covered by architecture instances. 15.2.3 Relation to Requirements Since the functionalities contribute to system requirements that have been collected for the NEXOF reference architecture, they can be related to those. ”Discovery of service”, “Publication of Service Offering” and “Publication of Service demand” address the system requirement “SR 3.1. How can a service be published to make it knowable so that it can be found and used by consumers (browsing)?” and “Search for Services” the system requirements “SR 3.1.2. How can a service that satisfies client requirements be found (searching)?” The system requirements have been derived from the business requirement R34 dealing with service discovery as “…the search and retrieval of services […] based on different criteria”. The example scenario furthermore includes the requirement to consider the decentralized character of the architecture and thus to deal with decentralized workflows which have been captured in the business requirements R4 and R21. Based on the business requirement R21 the system requirement “SR 5.3. How can a process be enacted?” has been derived which is addressed by the functionalities “Execution of Service Components” in the Service concern and “Implementation of Composite Components” in the Composition concern.


Apart from the functional decomposition, it is necessary to address the non-functional requirements implicit in the Harbour scenario. In here, the main non-functional requirement to address is availability. If the system is not available at some point, no operations can be performed at the docks, what implies a loss of time and money. Moreover, other QoS-related attributes should be considered, such as response times and performance (e.g. measured in transactions per second) offered by each functional service. With regard non-functional attributes, availability and QoS are captured in the System Requirements “SLA Management” and “QoS Monitoring” and business requirement R31 (Monitoring and reliability).


16 CONCLUSION The result presented in this deliverable is the current integrated version of the NEXOF Reference Architecture Model that has been built based on the State-of-the-Art Analysis that has been performed at the beginning of the project ([8], [21]), on the requirements analysis [24], an analysis of existing standards and vendor solutions, results from NESSI Strategic Projects (NSPs), results from the investigation teams as well as State-of-the-Practice knowledge of the project partners. It has been recognised that the holistic view of the project requires a well-defined structure of the reference architecture model. Accordingly, a structure has been defined that provides a framework in which all elements of the conceptual model can be integrated to provide a holistic view. This includes a separation of structure, behaviour and functions in order to allow focused views within the model. Besides this, different levels of granularity have been introduced so that not all detailed aspects are in the focus during all phases of the definition process. Additionally, the perspectives of different stakeholders have been introduced by identifying different classes of users of the reference architecture in order to recognise the socio-economic environment in which the reference architecture will be deployed. Understanding the different stakeholder types will help to understand their different needs and maybe influence design decisions that have to be made. This definition of different views within the model fosters the provision of good communication means. This is a crucial factor to enable the adoption of the reference architecture in order to derive specific architectures for SOA infrastructures. This makes it a sound foundation for further specification activities. It currently captures the concepts of service-oriented systems and is the foundation for capturing well-proven and reoccurring as well as innovative patterns for service-oriented systems. Using the harbour scenario as an example context in which the reference architecture provides guidance in deriving a concrete architecture has shown that the elements in the nine concerns that have been specified to be part of the NEXOF Reference model so far do provide (partially) help when deriving a concrete architecture. The functional decomposition as an entry point has helped to identify for what problems architectural solutions are needed. The ESOA pattern has served as a high level architecture to system architects that have never build a service-oriented architecture before. It thus has provided guidance to these architects in the process of scanning existing solutions that fit the harbour context in order to create a specific architecture that can be implemented. The links with the patterns that have been specified help to choose which architectural solutions are needed once the conceptual level has been defined. The model however is not final or closed for future developments. Till now the analysis concern has not been addressed. Future work should focus on getting knowledge about the requirements to this concern and address them in


requirements, model elements and architectural solutions. On the other hand, all elements that are needed to understand the architectural solutions provided by the patterns could be included in one of the nine concerns. However, the NEXOF Reference Architecture will evolve in future in order to include new alternative solutions for the existing types of families and the architectural problems addressed by them but also to cope with new emerging trends like the Internet of Things. These trends will be addressed by new pattern families and might define new elements that have to be included into the NEXOF Reference Model on a conceptual level. This might even result in the identification of the need to define a new concern. The nine concerns identified so far are not a closed set however, the definition of new ones should be driven by the need to define them in order to cope with elements that cannot be accounted to one of the existing concerns. In general the evolution of the model should be driven by new needs that will be addressed by the NEXOF Reference Architecture and thus by new requirements that also will be addressed by new architectural solutions. The caretakers of the NEXOF Reference Architecture beyond the project need to make sure that the different artefacts defined in the NEXOF Reference Architecture structure are consistent to each other and the relations between them are maintained.


REFERENCES [1] C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, S. Angel,

A Pattern Language, Oxford, University Press, New York, 1977. [2] A. I. Antón: Goal-Based Requirements Analysis. In: Proceedings of the 2nd

International Conference on Requirements Engineering (ICRE ’96), IEEE Computer Society, Washington, DC, USA, 1996, pp. 136–144

[3] A. I. Antón, C. Potts: The Use of Goals to Surface Requirements for Evolving Systems. In: Proceedings of the 20th International Conference on Software Engineering (ICSE’98), IEEE Computer Society, Washington, DC, USA, 1998, pp. 157–166.

[4] M. Barès, Formal Approach Of The Interoperability Of C4IRS Operating Within A Coalition; In: Proceedings of the 5 the International Command and Control Research and Technology Symposium; 2000

[5] L. Bass, P. Clements, R. Kazman, Software Architecture in Practice. (SEI Series in Software Engineering), Addison-Wesley Longman, 2nd edition, Amsterdam, 2003.

[6] D. Batory: Feature Models, Grammars, and Propositional Formulas. In: Proceedings of the International Software Product Line Conference (SPLC), 2005, pp. 7–20.

[7] G. Beneken, Referenzarchiteckturen, In: R. Reussner, W. Hasselbring (Ed.): Handbuch der Softwarearchitektur, dpunkt.verlag, Heidelberg, 2006 (in German).

[8] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, Pattern-Oriented Software Architecture, A System of Patterns, Volume 1. John Wiley & Sons Ltd, 1996.

[9] F. Buschmann, K. Henney, D. C. Schmidt, Pattern-Oriented Software Architecture, On Patterns and Pattern Languages, Volume 5, John Wiley & Sons Ltd, 2007.

[10] Colombo, M.; Nitto, E. D.; Penta, M. D.; Distante, D.; Zuccalà, M.: Speaking a Common Language: A Conceptual Model for Describing Service-Oriented Systems. In: Proceedings of the 3rd International Conference on Service Oriented Computing (ICSOC 2005), Springer, 2005.

[11] A. Dardenne: On the Use of Scenarios in Requirements Acquisition. Technical Report CIS-TR-93-17, Department of Computer and Information Science, University of Oregon, Eugene, 1993.

[12] T. DeMarco, Structured analysis and system specification. Prentice Hall, Englewood Cliffs, NJ, 1978.

[13] P. Fettke, P. Loos, Methoden zur Wiederverwendung von Referenzmodellen – Übersicht und Taxonomi, In: J. Becker; R. Knackstedt (Ed.): Referenzmodellierung 2002 - Methoden - Modelle – Erfahrungen, Pages 9-33, 2002 (in German).

[14] E. Gamma, R. Helm, R. Johnson, J. M. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional, illustrated edition, 1994.

[15] P. Haumer, K. Pohl, K. Weidenhaupt: Requirements Elicitation and Validation with Real World Scenes. IEEE Transactions on Software Engineering, Vol. 24, No. 12, 1998, pp. 1036–1054.

[16] IEEE; IEEE standard glossary of software engineering terminology IEEE Std 610.12-1990, 1990

[17] M. Jarke, K. Pohl: Establishing Visions in Context – Towards a Model of Requirements Processes. In: Proceedings of the 14th International Conference on Information Systems, 1993, pp. 23–34.


[18] K. Kang, S. Cohen, J. Hess, W. Nowak, S. Peterson: Feature-Oriented Domain Analysis (FODA) – Feasibility Study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute (SEI), Carnegie Mellon University, Pittsburgh, 1990.

[19] NEXOF-RA Project Team; Definition of an architectural framework & principles (version b); Public Project deliverable; 30. November, 2009; http://www.nexof-ra.eu/?q=node/569

[20] NEXOF-RA Project Team; NEXOF-RA Model V1.1; Public Project Deliverable; 12. September 2008; http://www.nexof-ra.eu/?q=node/337

[21] NEXOF-RA Project Team; NEXOF-RA Model V2.0; Public Project deliverable; 02. April 2009; http://www.necof-ra.eu/?q=node330

[22] NEXOF-RA Project Team; NEXOF Reference Architecture Specifications – State-of–the-Art Report; Public Project Deliverable; 26. June 2008; http://www.nexof-ra.eu/?q=node/45

[23] NEXOF-RA Project Team; NEXOF Reference Architecture Specifications – Pattern Report; Public Project Deliverable; 30. June 2010

[24] NEXOF-RA Project Team; Requirements Report; Public Project Deliverable; 10. October 2008; http://www.nexof-ra.eu/?q=node/200

[25] OASIS; ebXML Registry Information Model Version 3.0; May 2005; http://docs.oasis-open.org/regrep-rim/v3.0/

[26] Object Management Group: Unified Modeling Language (UML), Superstructure, V.2.2. 02.02.2009, OMG document: formal/09-02-02.

[27] K. Pohl: Requirements Engineering – Fundamentals, Principles, and Techniques. Springer, to appear in 2010.

[28] S-Cube Project Team; CD-IA-1.1.1 Comprehensive Overview of the State of the Art on Service-based Systems; Public Project Deliverable; 25. September 2008; www.s-cube-network.eu

[29] C. Steel, R. Nagappan, R. Lai, Core Security Patterns, Sun Microsystems Edition 2006.

[30] P. Schobbens, P. Heymans, J.-C. Trigaux, Y. Bontemps: Feature Diagrams: a Survey and a Formal Semantics. In: Proceedings of the 14th IEEE International Requirements Engineering Conference (RE’06), IEEE Computer Society, Washington, 2006, pp. 136–145

[31] A. van Lamsweerde; Goal-Oriented Requirements Engineering – A Guided Tour. In: Proceedings of the 5th IEEE International Symposium on Requirements Engineering (RE’01), IEEE Computer Society Press, Los Alamitos, 2001, pp. 249–263.

[32] A. van Lamsweerde: Requirements Engineering: From System Goals to UML Models to Software Specifications. Wiley, West Sussex, 2009.

[33] O. Vogel, I. Arnold, A. Chughtai, E. Ihler, U. Mehlig, T. Kehrer, U. Zdun, Software-Architektur, Grundlagen – Konzepte – Praxis, 2. Auflage, Spektrum Akademischer Verlag, 2009 (in German).

[34] W3C: Web Services Glossary, W3C Working Group Note, 2004, http://www.w3.org/TR/ws-gloss/, Accessed on 2010-06-28.

[35] Ueli Wahli; Owen Burroughs; Owen Cline; Alec Go; Larry Tung, Web Services Handbook for WebSphere Application Server 6.1, IBM Redbooks, 2006.

[36] E. Yu; An Organisational Modelling Framework for Multiperspective Information System Design. In: J. Mylopoulos et al. (Eds.): Requirements Engineering 1993 –

http://www.nexof-ra.eu/?q=node/45�

http://www.nexof-ra.eu/?q=node/45�


Selected Papers, Tech Report DKBS-TR-92-2, Department of Computer Science, University of Toronto, Toronto, 1993, pp. 66–86.

[37] E. Yu: Towards Modeling and Reasoning Support for Early-phase Requirements Engineering. In: Proceedings of the 3rd International Symposium on Requirements Engineering (RE’97), IEEE Computer Society Press, Los Alamitos, 1997.


APPENDIX A: FUNCTIONALITY SPECIFICATION

Management Presentation

Composition

Discovery

Messaging

Service

Resource

SecurityDeployment

Management andConfiguration

Monitoring


SLAManagement

Authorization

Privacy

Authentication

Integrity

Creation of User Interface

Component

Design of UserInterface

Components

Implementation ofUser Interface

Component

Execution of UserInterface

Component

Creation of ServiceComposition

Execution of Service Composition

Design of Service Composition

Implementation of Service

Composition

Promotion toComposite Service

Component

Publication of Service Offering

Publication of Service Demand

Discovery ofService

Browsing for Service

Search forService

Exchange ofMessage


Routing ofMessage

Creation of Service

Component

Execution ofService

Component

Design ofService

Component

Implementation ofService

Component

Promotion ofLegacy Component

to service

Lifecycle ManagementOf Infrastructure Resource Groups

Monitoring ofInfrastructure

Resources


Resource Usage

<<include>> <<include>>

<<include>> <<include>> <<include>>



<<include>> <<include>> <<include>>

Analysis

Publication of UserInterface

Component


A1: SERVICE

Functionality name: Creation of Service Component Description: It represents the capabilities for designing Service Components, implement them, adapt legacy systems to be used as a Service Components and enable their execution. Each of these capabilities is described in more details by the functionalities Design of Service Component, Implementation of Service Component, Promotion to Service Component of Legacy Applications. Further Decomposition: Design of Service Component, Implementation of Service Component, Promotion of Legacy Component to Service Related system requirements: SC Source: SCA

Functionality name: Design of Service Component Description: It represents the way to specify a service in order to allow its implementation. A service designer specifies at least a subset of the following information:

• the functional description of the service to define what the service does • the interface of the service to define how a service will be accessed. It

should contain the information needed to implement the operations and information that will be provided to potential clients. It should also include the details on the communication protocol that will be used to access the service. Moreover a further interface description must be provided if the management of the services must be done remotely or by a management system

• the Quality of Service (QoS) i.e. a collection of attributes that express a capability or a requirement about the overall service or about a given aspect of the service to define its ability to satisfy stated or implied needs of users.

• The definition of the transactional support to define the information to enable the service to be part of a transactional business process.

It should be possible to enrich the description of the service as convenient for the service designer. The design of services must produce a service specification that can be used in the implementation phase to create the service. Further Decomposition: none Related system requirements: SC_SPE, SI_ADD, SI_DES Source: NEXOF-RA Project Team

Functionality name: Implementation of Service Component Description: It represents a way to implement a service through coding and debugging phase in an essentially similar manner as other software component-


based programming. Moreover, a remote accessible interface must be generated as well as a client stub to access the service from a remote client. The implementation of the service must be done according to the parameters defined in the design phase. Further Decomposition: Coding, Debugging, Testing Related system requirements: SC_IMP, SC_IMP_TES, SI_TES Source: state-of-the-art analysis in SW development, NEXOF-RA Project Team

Functionality name: Promotion of Legacy Component to Service Description: It represents a way to adapt legacy application in order to be accessible as a service and to enable the possible integration in a SOA system. It consists in the creation of a wrapper for the legacy application which exposes an interface as a service. The wrapper must be capable to forward the requests coming from (remote) clients to the legacy application, and enables it to return back the response. Further Decomposition: none Related system requirements: SC_IMP_LEG Source: SCA

Functionality name: Execution of Service Components Description: It represents the procedure performed by the service, after a client sends a request to it asking for a specific procedure to be carried out, in order to transmit the result back to the client in a response. The execution of the service is taken apart from the invocation, which represent the request of the user asking for the execution of the service. The execution implies the usage of computational resources with the purpose to execute the code of the service to respond to an invocation performed by a client. Further Decomposition: none Related system requirements: SE, SE_MNG, SI Source: SCA

A2: MESSAGE

Functionality name: Exchange of Message Description: This functionality allows an Agent to send/receive a message to/from another Agent. The interaction mode should be specified to declare the kind of interaction, which can be synchronous or asynchronous. Furthermore, it


should be supported by message exchange patterns10 (MEPs) such as request/response, on-way and peer-to-peer conversations, as defined by messaging framework of W3C11

Examples of the mechanisms for the exchange of messages that could be supported are:

.

• the forwarding of messages to an Agent through the declaration of the endpoint that uniquely identify the Agent

• the forwarding of messages to a broker that dispatch the message to any Agent capable to reply to the request, based on the type of message forwarded and the applied load balancing techniques

The mechanisms described above must be considered only as examples and can be changed as preferred. The interaction deals with the validation, the adaptation and the routing of messages. Further Decomposition: SI_MES Related system requirements: Message exchange, Message formatting, Message validation and transformation Source: Service Description Investigation Team; Products: Apache ServiceMix, Mule; Standards: JBI; Books: Enterprise Integration Pattern.

Functionality name: Validation of Message Description: The message sent by an Agent to another Agent is validated with respect to its message type to verify if the structure of the message matches the required properties. An example of validation consist in verifying that a message contains a well-formed document and conforms to a particular schema or interface document that describes the structure of the message. Further Decomposition: none Related system requirements: SI_MES_CV Source: Apache ServiceMix, Mule

Functionality name: Routing of Message Description: The message sent by an Agent is routed to the recipient Agent according to the routing information contained in the service description. The message is routed by performing the following operations:

• Forwarding of the message, i.e. the sender sends the message to the message broker. If the message does not contains the endpoint of the recipient, the message broker selects an endpoint of an agent capable to respond to the request

10 http://www.w3.org/TR/soap12-part1/#soapmep 11 http://www.w3.org/TR/soap12-part1


• [Optional] Identification of the required adaptations of the message (see adaptation of messages)

• Dispatching of the message to the target endpoint Further Decomposition: Forward Message, Dispatch Message, Adaptation of Message Related system requirements: SE_MES_ROU Source: Products: Apache ServiceMix, Mule, Celtix; Standards: JBI; Books: Enterprise Integration Patterns

Functionality name: Adaptation of Message Description: The messages exchanged between Agents are adapted according to a target data format and transport protocol. Data format adaptation:

The data format of a message is converted into a different target data format that the output message is expected to have, according to the data format handled by the recipient Agent.

Transport protocol adaptation: The message bound to a certain transport protocol is converted according to a different transport protocol that the output message is expected to have, according to the transport protocol handled by the recipient Agent. Moreover, the information contained in a message is enhanced according to what is expected by the recipient Agent. The enhancements consist in one or more of the following alternatives:

• the enrichment with further information to the original message as needed to dispatch the message

• the removal of not required information from the original message • the splitting, the aggregation, the sequencing of the existing information into

one or several messages in order to convert the message in the format expected by the recipient Agent.

The adaptation of the message must preserve the semantic of the message. Further Decomposition: Data Format Adaptation, Transport Protocol Adaptation, Enhancing of Message Related system requirements: SE_MES_ADP, SE_MES_ADP_SPLIT, SI_MES_PRO Source: Products: Apache ServiceMix, Mule; Standards: JBI; Books: Enterprise Integration Patterns

A3: DISCOVERY:


Functionality name: Publication of Service Offering Description: This functionality allows advertising the service offering to potential users by means of the publication of the information related to the service offered. Such information is published on a repository which must be reachable by users enabled to surf the repository. The published information should contain sufficient details to enables the potential users to invoke the service, such as the endpoint of the service, the transport protocol and the data format used, and sufficient details to allows the potential users to state which are the effects produced by the service in order to state if the service can satisfy their needed. Further Decomposition: Publication of Service Offer Information, Removal of Service Offer Information, Update of Service Offer Information Related system requirements: SD_PUL_DES, SD_PUL_VIS, SD_REG Source: Investigation Team, Projects (SOA4ALL, SeCSE, INFRAWEBS, METEOR-S, COCOON, FUSION), Standards (UDDI, ebXML, UX)

Functionality name: Publication of Service Demand Description: It allows performing discovery of services in a push mode, i.e. the potential users publish their requirements (subscribe to a registry) and they are notified when some services matching the requirements are available a new service is published or an existing one is modified. When a service demand is published the description of the existing services are checked to verify possible matching with the requirements. The way to describe the requirements will depend on the matching algorithm. Further Decomposition: Subscription, Matching, Notification Related system requirements: SD_PUS, SD_REG Source: Investigation Team, Projects (INFRAWEBS), Standards (UDDI, ebXML, UX)

Functionality name: Discovery of Service Description: This functionality allows finding services according to a set of requirements defined by service users. Requirements can be specified in several ways (i.e. keywords, semantic queries, natural language, etc) and moments (design time, runtime, etc). Discovery can be performed in a different ways and applying different algorithms, and they will depend on the way to represent the requirements. Candidate services (which fulfil the requirements) will be ranked and returned to users, in order to support service selection. Further Decomposition: Browsing for Services, Searching for Services Related system requirements: SD


Source: Investigation Team, Projects (SOA4ALL, SeCSE, INFRAWEBS, METEOR-S, COCOON, PYRAMID-S, FUSION, ASTRO), Standards (UDDI, ebXML, UX)

Functionality name: Browsing for Services Description: This functionality allows users to find services by browsing through the content of a service registry in order to select those services which are interesting according to their requirements. It will depend on the way to organize and structure the registry, admitting simple queries according to the categories defined. Further Decomposition: Accessing Catalogue, Specification of Parameter, Selection Related system requirements: SD_PUL Source: Investigation Team, Tools (Eclipse WTP, Rational Application for WebSphere, WSO2, Mule Galaxy), Projects (SeCSE), Standards (UDDI, ebXML, UX)

Functionality name: Search for Services Description: This functionality refers to an alternative of performing service discovery. It consists on receiving user requirements as a complex query, so the discovery engine can perform a more complex but accurate matching between requirements and published services. Query format and discovery engine have to be compliant and the possibilities are wide, as they can be based on complex semantic queries or just some keywords and data types. Further Decomposition: Specification of Query, Matching, Ranking, Selection Related system requirements: SD_PUL_SEA Source: Projects (SOA4ALL, SeCSE, INFRAWEBS, METEOR-S, COCOON, FUSION, PYRAMID-S, SOA4ALL, ASTRO), Standards (UDDI, ebXML, UX)

A4: COMPOSITION

Functionality name: Creation of Service Composition Description: This functionality is focused on creating service compositions, which requires performing several activities grouped in phases. The creation of compositions can be done in several ways like manually, in a semi-automatic ways and even a mixed one, based on models or directly on an execution language. It comprises design and implementation activities, so several services will be combined in compositions which may represent business processes.


Further Decomposition: Design of Service Composition, Implementation of Service Composition, Promotion to Composite Service Component Related system requirements: PRO Source: Investigation Team

Functionality name: Design of Service Composition Description: This functionality is only focused in the modelling of the different parts of the composition, which means main activities with their control and data flows, as well as other non functional needs related to areas such as security and transactions. It can be performed manually or it can be done with the support of tools which create part of the composition or suggested templates. Further Decomposition: none Related system requirements: PRO_DSG, PRO_DSG_DYM, PRO_DSG_INT, PRO_TRA Source: Investigation Team

Functionality name: Implementation of Service Composition Description: With this functionality, the design and the models generated become software assets which can be executed in an execution engine. For doing so, it will be necessary to select those services which implement the identified activities and the glue code by using an execution language (such as WS-BPEL). If models were produced during design activity, they could be transformed using appropriate tools Further Decomposition: Design Time binding, Transformation into Executable Code, Testing Related system requirements: PRO_IMP, PRO_IMP_TES Source: Investigation Team

Functionality name: Promotion to Composite Service Component Description: Once a service composition has been implemented and tested, it can be exposed as a new complex service, by producing adequate descriptions (WSDL files and, optionally, semantic descriptions). Further Decomposition: none Related system requirements: PRO_SERV Source: Investigation Team

Functionality name: Execution of Service Composition


Description: This functionality refers to the activities performed for executing a service composition implementation, carrying out service invocations and data transformations. There are execution engines which perform static execution, sticking only to the implementation itself, while other engines are able to perform more dynamic executions, adapting activities, control and data flows depending on context information and errors detected, sometimes even triggering the generating of parts of the composition (cf. Creation of Service Composition) at runtime. Further Decomposition: Run Time Binding, Adaptation, Processing of Step, Invocation of Service Related system requirements: PRO_ENC, PRO_ENC_MON, PRO_ENC_DYC, PRO_TRA, PRO_MON, SC_ADA, SE_MON Source: Investigation Team

A5: PRESENTATION

Functionality name: Creation of User Interface Components Description: This functionality will allow the design, implementation and publication of the user interface components, including the creation of individual SFER and the composition of them creating a Mashup Further Decomposition: Design of User Interface Components, Implementation of User Interface Components, Publication of User Interface Components Related system requirements: UI_ACC, UI_COMP, UI_COMP_DES, Source: EzWeb NSP

Functionality name: Implementation of User Interface Component Description: This functionality will allow the creation of a User Interface Components. Besides the simple coding to implement a simple User Interface Component, mashups can also be created. This includes the search and selection of individual SFER, the design of the workspace, including the connection of SFER. Further Decomposition: Coding, Search for SFER, Selection of SFER, Design of SFER Workspace, Connection of SFER Related system requirements: UI_COMP, UI_COMP_PUB, UI_COMP_FIND, UI_COMP_CON Source: EzWeb NSP

Functionality name: Execution of User Interface Components


Description: This functionality is aimed at rendering service front-end (SFE) resources and providing the results of the execution of the services invoked by those SFEs. It also deals with the connections between the SFERs that allow information exchange at the level of Interface Components. Further Decomposition: Adaptation to Context, Rendering of SFER, Delivery of SFER, Management of SFER Connection Related system requirements: UI_CTX, UI_DEV Source: EzWeb NSP

A6: MANAGEMENT

Functionality name: Deployment Management and Configuration Description: This management functionality allows controlling easily complex (decentralised) applications, services and platform services, allowing service providers and administrators to deal with the whole system in an efficient manner for administrative purposes. It comprises functionalities that allow controlling the management policies/rules and deploy/undeploy and configure services, service compositions and platform services in heterogeneous infrastructures (NCI) in a transparent way, taking into account the configuration parameters and relationships between different components. Both, human actors and computer systems (self-management) can perform the management functionality (adopting an administrator role). Self-management allows systems to manage their own configuration and operation, minimizing human intervention. The rules that drive management can be derived mainly from SLAs and service monitoring. That is, the entities administering the system (either humans or autonomous systems) base their management decisions mainly on the SLAs that have been agreed and must be fulfilled and the information extracted from monitoring, that is used to quantify the QoS for the SLAs. Further Decomposition: Configure Management Policy, Deployment Related system requirements: MNG, MNG_EXE, MNG_ACT, MNG_DEC, SE_MNG, SE-MON Source: EGA Specification, SCA

Functionality name: Monitoring Description: The monitoring functionality supervises the elements that comprise a service-oriented infrastructure, i.e., the running applications and services and platform services that constitute each concrete infrastructure.


Monitoring includes both polling and notification mechanisms to the actors involved in the monitoring tasks (e.g. services and administrators). It comprises functionalities that allow to setup/modify the different parameters and metrics to monitor from the services (% of usage, availability, performance, efficiency, security…) and the policies/rules that drive the monitoring tasks, to gather statistics of the usage of monitored elements and to gather information about the different metrics (availability, performance, efficiency, security, etc.). So, it is a prerequisite for every service that requires to be monitored to log this information (e.g. in a storage area) in order to be further used. Further Decomposition: Configuration of Monitoring Policy, Logging of Monitoring Data Related system requirements: MON, MON_SYS, PRO_MON, MON_CNF, MON_DCL, MON_PFR, SE_MON Source: EGA Specification

Functionality name: Billing and accounting Description: Based on the information provided by the monitoring functionalities, this functionality allows to analyze the results and to produce billing and accounting information of the service usage and QoS provided. This information is useful for service providers in order to calculate and charge consumers for service usage depending on the SLAs agreed. It is also useful for service consumers in order to evaluate the current usage of services with regard to the SLAs agreed (e.g. to detect if they have contracted too much system capacity). Further Decomposition: Analysis of Monitoring Data, Generation of Billing and Accounting Billing information Related system requirements: MON, PRO_MON Source: EGA Specification

Functionality name: SLA management Description: This functionality allows managing both, functional and non-functional requirements and capabilities of services, which might be expressed through Service Level Agreements (SLAs) and its components, the Service Level Objectives (SLOs). It comprises functionalities that allow to describe a SLA (Service Level Objectives, constraints, configuration parameters and policies/rules), to translate the description into an interpretable form that the system can understand, to negotiate SLAs between the service consumers and providers and the systems should drive this negotiation in order to reach an agreement between both parties and to monitor the compliance of services towards SLAs.


Further Decomposition: Description of SLA, Translation of SLA, Negotiation of SLA, Monitoring of SLA Compliance Related system requirements: SI_AGR Source: EGA Specification, Web Services Level Agreement Specification (IBM), WS-Agreement

A7: SECURITY

Functionality name: Authorization Description: This functionality allows determining whether an entity can access to the given protected resource in order to execute an operation. The authorization enables a simple entity, a service consumer or a service provider to capitalize on the Internet infrastructure together with controlling the access to the resource or pieces of information it connects. According to the context where it is used, this relates to confidentiality of the information. It always relies on identity management and previous authentication of the entity. One efficient and experienced way to manage authorization consists in categorizing types of access needs by describing roles. Each role is associated with related access rights. User identities need then to be bound to these roles. Further Decomposition: Accountability: none Related system requirements: SEC, SEC_AUTZ Source: XACML Specification12 [29], PERMIS, Core Security Patterns

Functionality name: Authentication Description: This functionality ensures that an entity’s identity is truly what the entity claims it to be. Authenticated identities are then the basis for applying other security mechanisms, such as access control. Loosely speaking, a user can be authenticated on the basis of something he holds, he is, or he knows. Various mechanisms are currently available to implement each such approach. “Something you know” is typically implemented through mechanisms such as password, or challenge-response protocols. The “something you hold” approach is implemented through token-based mechanisms, smartcards, or a PIN that the user possesses and must present in order to be authenticated. Finally, the “who you are” paradigm is based on biometrics and includes techniques such as fingerprint scans, retina scans, voiceprint analysis, and others. Once the identity of a user has been verified, the system resources are made available to the user, possibly under the constraints specified by the access control policies, until the user exits the system. Such an approach may be appropriate for low-

12 www.oasis-open.org/committees/xacml/

http://www.oasis-open.org/committees/xacml/�


security environments or for environments in which the same strength of authentication is required for all resources. However it is not appropriate in cases in which the same system may have resources with different requirements concerning authentication strengths for the subjects wishing to access them. Further Decomposition: none Related system requirements: SEC, SEC_AUTZ Source: XAML Specification, NEXOF-RA Team

Functionality name: Privacy Description: This functionality provides a feature to protect the privacy of personal data during service execution in the SOA where the Privacy Manager Service is located. In doing that, obviously, also legislations regulating the privacy have to be taken in account. This can be achieved by enforcing the user privacy preferences, which implies to match them against the privacy policies associated with the services (i.e., the enterprise privacy policies). To this aim, Privacy functionality exploits the existing standard to represent both user privacy preferences and privacy policies, like The privacy functionality is the concept which is related to other functionalities such as: Signature, Accountability and Encryption… One of the aspects of privacy is to track all actions of an entity on the authorized resource (Accountability or Traceability) Further Decomposition: none Related system requirements: SEC, SEC_PRV Source: Core Security Patterns

Functionality name: Integrity Description: The functionality allows guaranteeing that data is not modified either accidentally or maliciously. The integrity can be obtained with different manners. The encryption of a document protects against to the unauthorized access. The digital signature guarantees that the document has not been modified since the signature. Trusted time-stamping adds the information of the time of the signature. The Authorization Service controls the access to the external agent (resources, software system…) and assures that the modification on a document is made by the authorized entity. Further Decomposition: Addition if Integrity Information, Checking of Integrity Related system requirements: SEC, SEC_TRW Source: Core Security Patterns


A8: RESOURCE

Functionality name: Lifecycle Management of Infrastructure Resource Groups Description: Infrastructure Services are low-level services relatively close to the physical infrastructure (typically these would offer interfaces familiar to network and systems administrators who are used to dealing with physical or virtual resources, operating systems and generic software platforms). This functionality allows the management of infrastructure resource groups throughout their whole lifecycle including the configuration of computational resources as well as the assignment of virtualized services to computational resources. Further Decomposition: Configuration of Infrastructure Resources, Assignment of Infrastructure Resources Related system requirements: INFR, INFR_FLEX, INFR_ENV Source: RESERVOIR

Functionality name: Configuration of Infrastructure Resources Description: It allows configuring the computational resources of the infrastructure, i.e. the computational nodes (CPU, RAM, …), the storage, and the network. Further Decomposition: Suspending Resource Set, Resuming Resource Set, Deletion of Resource from Resource Set, Replace ment of Resource in Resource Set, Addition of Resource to Resource Set Related system requirements: INFR, INFR_FLEX, INFR_ENV, INFR_MAN Source: RESERVOIR

Functionality name: Suspending Resource Set Description: Infrastructure service has to support suspending entire virtual resource sets to enable users to temporarily stop entire applications to avoid costs, or to use allocated capacity for a higher priority application without losing the lower priority application. Clearly this functionality is geared mainly toward compute resources, but similar concepts are applicable to other types of resources, for example, a “suspended” virtual disk may be moved to secondary storage (tape?), i.e. the “suspended” state for a resource means that although it is not being used now, it can be easily (and rapidly) restored to full functionality. Further Decomposition: none Related system requirements: INFR_MAN Source: RESERVOIR


Functionality name: Resuming Resource Set Description: Infrastructure service has to support resuming a previously suspended virtual resource set (otherwise suspend is equivalent to delete). This may be used when the demands of a higher priority application reduce and lower priority applications may run. Further Decomposition: none Related system requirements: INFR_MAN Source: RESERVOIR

Functionality name: Deletion of Resource from Resource Set Description: At any time during the life of a virtual resource set, the user may request from the infrastructures service to remove one or more virtual resources from the set. This functionality is needed to allow the user to control costs since used or reserved capacity is likely to be chargeable. Further Decomposition: none Related system requirements: INFR_MAN Source: RESERVOIR

Functionality name: Replacement of Resource in Resource Set Description: At any time during the life of a virtual resource set, the user may request from the infrastructures service to replace one or more virtual resources from the set. This functionality is needed to allow the user to control costs since used or reserved capacity is likely to be chargeable. Further Decomposition: none Related system requirements: INFR_MAN Source: RESERVOIR

Functionality name: Addition of Resource to Resource Set Description: At any time during the life of a virtual resource set, the user may request from the infrastructure service to add more virtual resources to the set. The request has to be accepted up to the reserved capacity (if any), beyond reserved capacity, acceptance is on a best-effort approach. This functionality is needed for example when more servers need to be added to a complex multi-server application that is under stress (e.g. due to high traffic/usage). Further Decomposition: none Related system requirements: INFR_MAN Source: RESERVOIR


Functionality name: Assign Computational Resources Description: It allows assigning the computational resources to the different components of the NCI. Further Decomposition: Releasing Capacity, Reservation of Capacity, Provisioning of Resource Set, Migration of Resource Set, Removal of Resource Set Related system requirements: INFR_MAN, INFR_PERF Source: RESERVOIR

Functionality name: Releasing Capacity Description: To ensure effective use of limited resources, it must be possible to release reservations of capacity. Once reserved capacity has been provisioned, the reservation is released. Alternatively, if a reservation is not exercised within a defined time period (e.g. specified by provider policy or as part of the reservation), the reservation may be released automatically. Further Decomposition: INFR_MAN, INFR_PERF Related system requirements: Source: RESERVOIR

Functionality name: Reservation of Capacity Description: To ensure successful provision of a set of inter-related virtual resources, the user may request to reserve capacity prior to the actual provisioning of resources. If capacity is available the infrastructure service will put it aside (commit it) for the sole use of the requesting user/customer. Not all of the reserved capacity has to be used at once. The reserved capacity is associated with the user and not with a specific virtual resource set. Further Decomposition: Related system requirements: INFR_MAN, INFR_PERF Source: RESERVOIR

Functionality name: Provisioning of Resource Set Description: Users of infrastructure services need the capability to provision sets of one or more inter-related virtual resources. The definition, requirements and interdependencies for each requested resource in the set are specified by the user and, if there is enough capacity to satisfy the resource requirements of the entire set, the infrastructure service will instantiate it, i.e., allocate the requested capacity on physical resources, and in the case of computational virtual resources activate them so they are available for use. Further Decomposition:


Related system requirements: INFR_MAN, INFR_PERF Source: RESERVOIR

Functionality name: Removal of Resource Set Description: When a user no longer needs the capabilities of a particular resource set, he/she may request to completely remove the set. Once deleted, the virtual resource set cannot be restored and the user is not charged any more for it (although he/she can still be charged for unused reserved capacity). Further Decomposition: Related system requirements: INFR_MAN Source: RESERVOIR

Functionality name: Monitoring of Resources Description: User must be able to monitor relevant aspects of the state and utilization of all the virtual resources allocated as well as the status of any unused reserved capacity. Infrastructure service providers will require related capabilities although the details and scope of the monitored information will be different. Further Decomposition: Related system requirements: INFR, INFR_MAN, INFR_FLEX, INFR_INTEROP Source: RESERVOIR

Functionality name: Metering of Resource Usage Description: Infrastructure services should support the pay-per-use model, where users are charged only for quantity of resources allocated or reserved. Further Decomposition: Related system requirements: INFR, INFR_MAN, INFR_FLEX Source: RESERVOIR


APPENDIX B: SERVICES AND SOFTWARE SERVICES DEFINITION This section starts introducing some key concepts that are relevant for the definition of Service. In particular, it starts from one very generic concept and continues by introducing the others in a way that each one is a refinement of the previous one (i.e. is subsumed by the previous one). After that, the section concludes by stating which the definition of Service is that is adopted by NEXOF-RA and how it relates to IT. The first relevant concept is (action for benefit):

C1: An action performed by one entity (provider) for the benefit of another (consumer)

Concept C1 is quite general. It captures the following things:

• A provider entity (P) that performs an action (A) • A consumer entity (C) that have a benefit (B) from the performed action C1 depends on other sub-concepts: a provider entity, a consumer entity and an action that depends on something that the consumer perceives as a benefit for himself. Shortly, this concept is expressed by using these notations:

• (Textual): C1 =def [P,A(B),C] by using this notation the criteria to take a part concept instances (identity criteria) is highlighted: the identity of first level sub-concepts instances determines the identity of the main concept instance. In this case: Let be x=[p1,a1(b1),c1] and y=[p2,a2(b2),c2], then x==y p1==p2 and a1(b1)==a2(b2) and c1==c2. note: it is not required that b1==b2 !

• (Graphical):

Figure 62: Action for benefit - graphical notation

• (UML):

Figure 63: Action for benefit - class diagram


Then, it is introduced an example that can easily be abstracted by this concept (and, of course, by its sub-concepts).

Ex1: a person (cook) prepares and serves the meal to another one (hungry-man).

With respect to the different parts, it is stated that:

• P: “cook” is the provider entity • C: “hungry-man” is the consumer entity • B: “the prepared and served meal satisfy the hungry-man’s hunger” is the

benefit • A(B): “prepares and serves the meal if the prepared and served meal

satisfies the hungry-man’s hunger” is the conditioned action The following variant of concept C1 aims to remove the dependency from the sub-concept “benefit”, as such sub-concept is not easily captured. Furthermore, this new concept also accounts for the very etymological meaning of the term “service” (from Latin: “servus”), i.e. to act on someone’s wishes. With this respect, this concept wants to capture the fact that the action is performed only if someone explicitly requests it. The second concept (action on request) is expressed as follows:

C2: An action performed by one entity (provider) that matches a request of another (requesting entity), according to the interpretation of the latter

Concept C2 captures the following things:

• A requesting entity (R) that makes a request (Q) to a provider entity (P) to perform a certain action (A)

• A provider entity (P) that performs the requested action (A) Note: this concept captures only the circumstance where the provider entity performs “exactly” the action requested by the requesting entity. “Exactly” is used in the following sense: the requesting entity observes that the action performed by the provider matches with his request. Thus, C2 depends on a provider entity, a requesting entity and an action that depends on an explicit request. Shortly, this concept is expressed by using these notations:

• (Textual): C2 =def [P,A(Q),R] • (Graphical):

Figure 64: Action on request - graphical notation


• (UML):

Figure 65: Action on request – class diagram

Now, it is introduced an example that can easily be abstracted by this concept (and, of course, by its sub-concepts).

Ex2: A person (hungry-man) asks another person (cook) to prepare and serve a meal to him, after that the latter (cook) does what he has been requested to do.

With respect to the different parts, this example is abstracted as follows:

• P: “cook” is the provider entity • R: “hungry-man” is the requesting entity • Q: “asked to prepare and serve a meal” is the request • A(Q): “prepare and serve a meal if it is asked to prepare and serve a meal”

is the conditioned action C2 captures only those situations where the requesting entity observes that the action performed by the provider matches his request. With this respect, the requesting entity is the only entity that can recognize the occurrence of C2 (i.e. that a certain situation can be abstracted by C2). It is important to recognize two important elements that are introduced by the example Ex2:

• The cook interprets the request and consequently perform the action • The hungry-man observes the action performed and interprets it to verify if it

meets his request There are two “interpretations” performed by different entities that have not been agreed. The result could be, for instance, that the provider entity is sure to have performed what requested, but the other one disagree! C2 is based on the interpretation of the requesting entity. It is introduced a further concept in order to remove the asymmetry within C2 and capture the possibility to share, or at least to delegate to a third party, the criteria for recognizing if the action performed by the provider matches the request of the requesting entity. The new concept (action on agreement) is defined as follows:


C3: An action performed by one entity (provider) that matches the request of another (requesting entity) according to a previously established agreement between them.


• A requesting entity (R) that makes a request (Q) to a provider entity (P) to perform a certain action (A)

• A requesting entity and a provider entity that establish an agreement (G) on what has to be done

• A provider entity (P) that performs the requested action (A) with respect to the agreement (G)

Note that, even if in most cases the agreement is explicit (e.g. a contract to be signed or a verbal agreement), it can be implicit in some other cases. Thus, C3 depends on a provider entity, a requesting entity and an action that depends on an agreement that depends on an explicit request. Shortly, this concept is expressed by using these notations:

• (Textual): C3 =def [P,A(G(Q)),R] • (Graphical):

Figure 66: Action on agreement - graphical notation

• (UML):

Figure 67: Action on agreement – class diagram


Now, it is introduced an example that can easily be abstracted by this concept (and, of course, by its sub-concepts).

Ex3: a person (hungry-man) asks another person (cook) to prepare and serve a meal to him, they agree on preparing and serving fresh fish, after that the latter (cook) does what has been agreed.

With respect to the different parts, Ex3 is abstracted with C3 as follows:

• P: “cook” is the provider entity • R: “hungry-man” is the requesting entity • Q: “asks the cook to prepare and serve a meal” is the request • G(Q): “agree on preparing and serving fresh fish if it is asked to prepare and

serve a meal” is the agreement resulting from the initial request • A(G(Q)): “prepare and serve fresh fish if it has been agreed on preparing

and serving fresh fish” is the action that depends on the agreement A further consideration can take into account if and how a provider is ready (committed) to receive requests from a requesting entity, first to achieve an agreement, and second to perform the agreed action. In other words, we are wondering if we are also interested in those actions that occasionally occur or if it is important to take a part only those actions for which it is possible to recognize a context (i.e. a process) that makes the provider capable to manage the reception of requests and the starting of the correspondent actions. The concept introduced in succession aims to exclude all the situations captured by the previous concept C3 where the two involved entities simply meet occasionally. Indeed, the provider entity puts into running (commits) a specific process that the requesting entity can recognize as the “right context” where he can submit requests. The new concept (action within an offering) is defined as follows:

C4: An action performed by one entity (provider), ready (the provider) at receiving requests and establishing agreements, that (the action) matches the request of another (requesting entity) according to a previously established agreement between them.


• A provider entity (P) that performs a process (O) to receive requests (Q) from requesting entities (R) and to establish agreements (G) with them

• A requesting entity (R) that makes a request (Q) through the process (O) to a provider entity (P) to perform a certain action (A)

• A requesting entity and a provider entity that establish an agreement (G) on what has to be done

• A provider entity (P) that performs the requested action (A) with respect to the agreement (G)


Thus, C4 depends on a provider entity, a requesting entity and an action that depends on an agreement that depends on an explicit request that depends on the existence of a specific running process. Shortly this concept is expressed by using these notations:

• (Textual): C4 =def [P, A(G(Q(O))), R] • (Graphical):

Figure 68: Action with an offering - graphical notation

• (UML):

Figure 69: Action with an offering – class diagram

Now, it is introduced an example that can be abstracted by this concept (and, of course, by its sub-concepts).

Ex4: a person (a cook) every morning open its restaurant to be ready to host people that want to have meals. Each day, different persons (clients) enter his restaurant. Each client asks him to prepare and serve him a meal and agree with the cook on preparing and serving a specific meal. Then the cook does what has been agreed.

With respect to the different parts, Ex4 is abstracted with C4 as follows:


• P: “cook” is the provider entity • O: “a cook every morning open its restaurant…where a client enter and ask

to…and agree with…” is the process for receiving request and achieve agreements

• R: “client” is the requesting entity • Q(O): “the client asks the cook to prepare and serve a meal after he entered

the restaurant ” is the request made through the process • G(Q(O)): “a client and the cook agree on preparing and serving a specific

meal if it is asked to prepare and serve a meal” is the agreement resulting from the initial request

• A(G(Q(O))): “prepare and serve the specific meal if it has been agreed on preparing and serving that specific meal” is the action that depends on the agreement

By the analysis of the concepts C1 to C4 it is stated that the most appropriate definition of service for NEXOF-RA is the concept C2 “action on request”. Thus, NEXOF-RA adopts the following definition of service:

Definition of Service: An action performed by one entity (provider) that matches a request of another (requesting entity), according to the interpretation of the latter

A very general perspective captures the reported definition of service and it is independent by IT. However, it is possible to adapt this definition to IT by adding some constraint to the current definition, resulting in fixing the concept of Software Service. It requires identifying the entities that interact to request/perform an action. Therefore, a Software Service is defined as a Service in which software agents that are an agent requester and an agent provider mediate the interaction between requester entity and provider entity. The direct interaction never happens between humans but it is important to specify that human interaction is not excluded by this definition. Indeed, to fulfil their duty software agents can make use of human interaction.

NEXOF-RA - Europa

Documents

Transcript of NEXOF-RA - Europa