NEXOF-RA - CORDIS › docs › projects › cnect › 6 › 216446 › ... · 2017-04-19 · NEXOF-RA • FP7-216446 • D7.5b • Version 0.4, dated 30/06/2010 • Page 3 of 91 EXECUTIVE

NEXOF-RA • FP7-216446 • D7.5b • Version 0.4, dated 30/06/2010 • Page 1 of 91

NEXOF-RA

NESSI Open Framework – Reference Architecture

IST- FP7-216446

Deliverable D7.5b RA Specification V1.0

(Pattern Compass)

Piero Corte Desideri Debora

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.


Change History

Version Date Status Author (Partner) Description


EXECUTIVE SUMMARY

This document is part of D7.5b and provides a compass to access the patterns that constitute the RA Specification. It also contains a brief summary card for each pattern.


TABLE OF CONTENTS

EXECUTIVE SUMMARY ........................................................................................... 3

TABLE OF CONTENTS ............................................................................................ 4

INTRODUCTION ..................................................................................................... 6

1 INTERNET OF SERVICE DOMAIN ........................................................................... 9

1.1 Patterns per concerns ............................................................................. 11

1.2 Cards ...................................................................................................... 15

1.2.1 Assisted Composition Designer ....................................................... 16

1.2.2 Authorization .................................................................................... 17

1.2.3 Dynamic Binding of Services during Composition ............................ 18

1.2.4 Federated Distributed Message Bus ................................................ 19

1.2.5 IaaS - Infrastructure as a Service ..................................................... 20

1.2.6 Internet of Service ............................................................................ 21

1.2.7 MaaS – Mashup as a Service .......................................................... 22

1.2.8 Multi-phase Discovery ...................................................................... 23

1.2.9 Semantic Annotation Composition ................................................... 24

1.2.10 Semantic based Federated Registry .............................................. 25

1.2.11 Service Discovery........................................................................... 26

1.2.12 Service Matchmaking and Ranking ................................................ 27

1.2.13 Template-based Discovery ............................................................. 28

1.2.14 Trust Based Model Registry ........................................................... 29

2 CLOUD DOMAIN ............................................................................................... 30


2.2 Cards ...................................................................................................... 34

2.2.1 Authorization .................................................................................... 35

2.2.2 Cloud migration enabled by OSGi – step one .................................. 36

2.2.3 Cloudified Application Servers ......................................................... 37

2.2.4 Elastic Reliable Filesystems ............................................................. 38

2.2.5 IaaS - Infrastructure as a Service ..................................................... 39

2.2.6 Map Reduce ..................................................................................... 40

2.2.7 Not only SQL (NoSQL) Storage ....................................................... 41

2.2.8 PaaS – Platform as a Service .......................................................... 42

3 ENTERPRISE SOA DOMAIN ............................................................................... 43


3.2 Cards ...................................................................................................... 51


3.2.1 Active Replication ............................................................................. 51

3.2.2 Assisted Composition designer ........................................................ 53

3.2.3 Authorization .................................................................................... 54

3.2.4 Black-Box Database Replication ...................................................... 55

3.2.5 Cloud migration enabled by OSGi – step one .................................. 56

3.2.6 Data Mediation ................................................................................. 57

3.2.7 Designer and Runtime Tools for E-SOA ........................................... 58

3.2.8 Distributed ESB in ESOA ................................................................. 59

3.2.9 Dynamic Binding of Services during composition ............................. 60

3.2.10 Enterprise SOA .............................................................................. 61

3.2.11 Front-End in E-SOA ....................................................................... 62

3.2.12 Generic Group communication ....................................................... 63

3.2.13 Gray-Box Database Replication ..................................................... 64

3.2.14 Horizontal Replication with Replication Awareness ........................ 65

3.2.15 IaaS – Infrastructure as a Service .................................................. 66

3.2.16 Log-Mining Writeset Extraction ...................................................... 67

3.2.17 Models Manager............................................................................. 68

3.2.18 Monitoring in Enterprise SOA ......................................................... 69

3.2.19 Multicast-Based Replica Discovery ................................................ 70

3.2.20 Multi-phase Discovery .................................................................... 71

3.2.21 Multi-Tenancy Enabler ................................................................... 72

3.2.22 Multi-Tier Transactional Service Runtime ....................................... 74

3.2.23 Non-Repudiation ............................................................................ 75

3.2.24 OSGi-based SCA-Container .......................................................... 76

3.2.25 Reflective Database Replication .................................................... 77

3.2.26 Registry-Based Replica Discovery ................................................. 78

3.2.27 Security in Enterprise SOA ............................................................. 79

3.2.28 Service Discovery........................................................................... 80

3.2.29 Service Matchmaking and Ranking ................................................ 81

3.2.30 Session Replication with Multi-Tier Coordination ........................... 82

3.2.31 Template-based Discovery ............................................................. 83

3.2.32 Transparent Replication Proxy ....................................................... 84

3.2.33 Trigger Writeset Extraction ............................................................. 85

3.2.34 Trusted Timestamping .................................................................... 86

3.2.35 Vertical Replication......................................................................... 87

3.2.36 Virtual ESB ..................................................................................... 88

3.2.37 Virtualization of Computational Resources in E-SOA ..................... 89

3.2.38 White-Box Database Replication .................................................... 90

3.2.39 Writeset Extraction Based on Extended Interfaces ........................ 91


INTRODUCTION

This document provides a compass to access all the set of patterns of the NEXOF-RA specification. In particular it presents figures that show:

the pattern names: to identify and represent each pattern;

the patterns relationships: to show the main relationships among patterns;

In all pictures, the patterns are presented with different colors to show their development status and with different shapes to show their type (see respectively section 4 and section 3.2 in D7.2c1).

In particular, they use the following colors:

RED (in-conception): to refer to a pattern that has been identified and qualified only by means of the architectural problem it addresses. The architectural solution proposed by a pattern in this state has not been elaborated yet.

YELLOW (in-elaboration): to refer to a pattern that is under development. A draft of the architectural solution proposed by a pattern in this state is available.

BLUE (formally-consistent): to refer to a pattern that has been already elaborated and has succeeded the formal verification.

VIOLET (proved-by-poc): to refer to a pattern that has been successfully proved by a Proof-of-Concept (PoC)2 action.

GREEN (part-of-the-specification): to refer to a pattern that has succeeded the formal verification and has received the final approbation of the NEXOF Architectural Board to be part of the NEXOF-RA Specification;

and the following shapes:

PLAIN-RECTANGLE: to refer to a “non-cross-cutting” pattern type

TABBED-RECTANGLE: to refer to a “cross-cutting” pattern type

The document is parted into three main sections:

first section concerns with the Internet of Service domain;

second section concerns with the Cloud domain;

third section concerns with the Enterprise-SOA domain, and it is mainly an updated version of the content of previous version of the deliverable D7.5.

1 Definition of an architectural framework and principles , D7.2c, http://www.nexof-ra.eu

2 Proof-of-Concept release, D8.1.b, http://www.nexof-ra.eu

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



Before presenting the compass for the three domain, next picture provides some overall figures about all the patterns that the NEXOF-RA Specification is composed of.

First of all, next picture shows how many patterns have been developed per each domain.

Patterns per domanin

45

18

8

ESOA

IOS

CLOUD

The second picture shows how many patterns have been developed per type, i.e. how many functional patterns and how many non-functional-cross-cutting patterns are currently part of the NEXOF-RA Specification

Patterns per type

45

15

Functional

Non-Functional-Cross-Cutting


Finally, next two pictures show respectively how many patterns are related to each one of the main functional concerns of the NEXOF-RA Model and how the same relationship brakes down with respect to the three domains.

0 2 4 6 8 10 12 14 16

Service

Messaging

Management

Security

Discovery

Composition

Presentation

Resources

Cross-cutting

Patterns per concern

Patterns 8 6 11 9 11 14 7 5 15

Service Messaging Management Security Discovery Composition Presentation ResourcesCross-

cutting

Patterns per concern per domain

0 2 4 6 8 10 12

Service

Messaging

Discovery

Composition

Presentation

Resources

Management

Security

CLOUD

IoS

ESOA


1 INTERNET OF SERVICE DOMAIN

This section provides a compass to navigate among the set of patterns related to the Internet of Service domain.

It starts with a picture that introduces the overall set of patterns and how they are related each other starting from the top-level pattern: “Internet of Service (IoS)”.

The other two sections that follows respectively present:

The set of pattern grouped according with the main functional concerns of the NEXOF-RA model and how these patterns are related to specific functionality of the model.

The list of the identity cards of each pattern.


LEGENDA:


Figure 1: Internet of Service NEXOF-RA Patterns

1.1 Patterns per concerns

In this section, patterns are parted according to the main functional concerns of the NEXOF-RA Model.

The first picture provides the figures about how many patterns have been developed per each functional concern.

0 1 2 3 4 5 6 7

N. of patterns

Service

Messaging

Discovery

Composition

Presentation

Resources

Management

Security

co

nc

ern

s

IoS Domain

Next sub-sections address each one of the main functional concerns and present a picture that shows the patterns that are related to more specific functionalities of that concern. They are helpful for a software system architect that is specifically interested into finding architectural and/or design solutions related to a specific concern.

Pictures are very easy to read:

a rectangular shape represents a pattern showing its name (internal label) and its development status (color, see section 1).

an oval shape represents a functionality of the specific concern (the one stated by the sub-section title) of the NEXOF-RA Model.

an arrow between pattern represents their inter-relationships

an arrow between a patten and a functionality shows that the pattern provides an architectural solution for that particular functionality.

For instance in the next picture of the “Presentation” sub-section, the following facts are show:

The “Context Management”, “Mash up as a service (Maas)” and “Adaptive User Interface” are three patterns and, in particular, they are “partOf” of the top-level pattern “IoS”.

Each one of the three above mentioned patterns provides an architectural design solution of a system that offers the “Creation of User


Interface Components” and “Execution of User Interface Components” functionality.

Presentation

Composition


Discovery

Messaging

Service


Resources

Security


Management

1.2 Cards

Hereafter the identity cards (see section 3.5.1 in D7.2c3) of each pattern are reported. They are alphabetically listed in the next sub-sections. Each card provides a short abstract description of the pattern, and some other information concerning the authors, its category type and level.

Furthermore the list of quality attributes4 affected positively (+) or negatively (-) by the pattern is provided.

The table also contains the information on if the architectural choices of the pattern and/or its quality attributes have been validated by a Proof-of-Concept (PoC)5 6

Finally a reference to the document containing the complete description of the pattern is also provided.

3 Definition of an architectural framework & principles, D7.2b,http://www.nexof-ra.eu

4 Quality Model for NEXOF-RA Pattern Designing report, http://www.nexof-ra.eu

5 Proof-of-Concept Overall Process, D8.0b, http://www.nexof-ra.eu






1.2.1 Assisted Composition Designer

Name Assisted Composition Designer

Abstract This pattern captures the main elements which should be part of a Process Designer Tool which is able to provide service compositions created in an automatic way, so it will be easier for developers to implement business processes.

Level Abstract

Type Functional

Key Concerns Composition

Credits Fco. Javier Nieto (ATOS)

Contact [email protected]

Source http://www.nexof-ra.eu/?q=node/654

PoC Validation NO

Qality Attributes Buildability -

Integrability +

Modifiability +

Performance -

Reusability +

Testability +

Usability +

mailto:[email protected]

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


1.2.2 Authorization

Name Authorization

Abstract Authorization pattern should provide a feature to determine whether an entity can access to the given protected resource in order to execute an operation.

Level Abstract (Design Patterns) , Implementation (Idioms) (will be implemented with a PERMIS RBAC solution)

Type Functional

Key Concerns Security

Credits NEXOF-RA WP4

XACML Specification

PERMIS

Contact Phong CAO ([email protected])


PoC Validation YES

Quality Attributes Privacy +

Accountability +




1.2.3 Dynamic Binding of Services during Composition

Name Dynamic Binding of Services during Composition

Abstract This pattern enables dynamic execution of processes and invocation to services, by managing the services binding at the execution engine, which allocates invocations dynamically, reacting to the context

Level Abstract

Type Functional



Paolo Zampognaro (Engineering)



PoC Validation NO

Quality Attributes Buildability -

Maintainability +

Integrability +

Interoperability -

Modifiability +

Adaptation to new operating environments (Portability)

+

Recoverability +

Reliability +

Reusability +

Scalability +

Security -

Testability +

Usability +



1.2.4 Federated Distributed Message Bus

Name Federated Distributed Service Bus

Abstract The solution provided by such a pattern could emphasize, for instance, the fact that to properly scale on the Internet, the solution is based on a federated and distributed set of peer nodes, and there is no central point of control or failure. Moreover, it could include some semantic-based mediators that are capable to better deal with the syntactical and information heterogeneity of messages exchanged by software agents (those that participate to the realization of business services), that on the Internet scale are very likely expected.

Level Abstract

Type Functional

Key Concerns Messaging




PoC Validation NO


Maintainability -

Integrability +

Interoperability +

Modifiability +


+

Performance (efficiency) -

Recoverability +

Reliability -

Reusability +

Scalability +

Security +

Testability +

Usability +



1.2.5 IaaS - Infrastructure as a Service

Name Infrastructure as a Service (IaaS)

Abstract The IaaS pattern is aimed at providing Cloud Service Providers (e.g. Platform as a Service, Software as a Service) with computational resources, charged by usage and supporting automatic scaling. It enables its customers (higher level Service Providers) to deliver their own business services on the Internet without owning or administering ICT infrastructure.

Level TOP-LEVEL

Type Functional

Key Concerns Management, Resources

Credits RESERVOIR NSP

SLA@SOI NSP

Contact Shimon Agassi ([email protected])


PoC Validation NO

Quality Attributes Portability +

Interoperability +

Scalability +

Availability +

Reliability +

Modifiability +

Reusability +

Buildability +

Performance -

Security -




1.2.6 Internet of Service

Name Internet of Service

Abstract This pattern provides an architectural design of a world-wide internet-based platform to enable anyone to deliver, consume and prosume services at global scale.

Level Top Level

Type Functional

Key Concerns Services, Messaging, Discovery, Composition, Presentation, Management, Security, Resources

Credits Shimon Agassi, Pascal Bisson, Jose Manuel Cantera Fonseca, Ricardo Jimenez-Peris, Piero Corte, Debora Desideri, Antonio De Nigro



PoC Validation NO

Quality Attributes Build-ability +

Portability +

Modifiability / Extensibility +

Interoperability +




1.2.7 MaaS – Mashup as a Service

Name Mashup as a Service

Abstract In the context of the Internet of Services, this pattern suggests an architecture intended to enable end-user composition of heterogeneous Service Front-End Resources, yielding to Service Front-End Mashups.

Level Abstract

Type Functional

Key Concerns Presentation

Credits EzWeb

FAST

Contact JOSE MANUEL CANTERA FONSECA

([email protected])


Poc Validation NO

Quality Attributes Availability +

Integrability +

Modifiability (Adaptation to new operating environments)

+

Modifiability (Extension of capability)

+

Reusability +

Usability +

Security (Isolation) -

Resource Efficiency -




1.2.8 Multi-phase Discovery

Name Multi-phase Discovery

Abstract This pattern specifies a way to perform service discovery by applying different discovery algorithms in several phases, refining the list of candidate services in each phase.

Level Abstract

Type Functional

Key Concerns Discovery


András Micsik

INFRAWEBS



PoC Validation NO


Integrability +

Interoperability +

Modifiability +


Reliability -

Reusability +




1.2.9 Semantic Annotation Composition

Name Semantic Annotation Composition

Abstract This pattern describes how to perform dynamic service composition at design time by exploiting semantic information such as OWL-S or WSML based descriptions and goals

Level Abstract

Type Functional



Anna Hristoskova

Bruno Volckaert (Ghent Univ.)



PoC Validation YES

Quality Attributes Availability =

Buildability -

Maintainability +

Integrability +

Interoperability -

Modifiability +


+

Performance (efficiency) =

Recoverability +

Reliability +

Resource Efficiency =

Reusability +

Scalability +

Security -

Testability +

Usability +



1.2.10 Semantic based Federated Registry

Name Semantic Based Federated Registry

Abstract Based on semantic-annotation of business services, this pattern could emphasize how to design the architecture of the discovery sub system in order to be applicable and scale on the Internet, taking into account the fact that it should enable any user of Internet to discover (almost) any service published by any service provider of the Internet (global search). The solution could also introduce components dedicated to solve the gaps between the various description techniques (languages) that different providers adopt.

Level Abstract

Type Functional





PoC Validation NO


Maintainability -

Integrability +

Interoperability +

Modifiability +


+


Recoverability +

Reliability -

Reusability +

Scalability +

Security +

Testability +

Usability +



1.2.11 Service Discovery

Name Service Discovery

Abstract Describes the main elements related to discovering services according to some requirements coming from users.

Level Abstract

Type Functional Pattern





PoC Validation NO

Quality Attributes Integrability +

Interoperability +

Modifiability +


Reliability -

Reusability +

Portability +




1.2.12 Service Matchmaking and Ranking

Name Service Matchmaking and Ranking

Abstract This pattern defines those components involved in a simple discovery process which is divided in two tasks: matchmaking requirements and services and ranking candidate services

Level Abstract

Type Functional



Dimitrios Skoutas



PoC Validation NO


Integrability +

Interoperability +

Modifiability +


Reliability -

Reusability +




1.2.13 Template-based Discovery

Name Template-based Discovery

Abstract This pattern describes how to perform service discovery using as requirements a template which is filled-in by users who want to find services, as a way to support the requirements description

Level Abstract

Type Functional



András Micsik

INFRAWEBS



PoC Validation NO


Integrability +

Modifiability +


Reusability +




1.2.14 Trust Based Model Registry

Name Trust Based Model Registry

Abstract This pattern is a refinement of the Internet of Service pattern and focus on the architectural choices concerning the discovery of services described in the top level pattern. In particular, it focus on the definition of the components enabling the discovery of services on the basis of the quality of experience of the service’s users. Moreover, it focus on the capability of the system to be scalable to fit in a large scale ecosystem and the capability of the system to enable the notification of services matching the requirements of the users. The architectural choices made by this pattern describes a part of the IoS infrastructure at a very high level of abstraction and can be specialized to realize more specific architectural solutions.

Level Abstract

Type Functional

Key Concerns Services, Discovery

Credits Antonio De Nigro



PoC Validation NO


buildability +

Maintainability +


Scalability +




2 CLOUD DOMAIN

This section provides a compass to navigate among the set of patterns related to the Cloud domain.

It starts with a picture that introduces the overall set of patterns and how they are related each other starting from two top-level patterns: “Platform as a Service (PaaS)” and “Infrastructure as a Service (IaaS)”.





LEGENDA:




0 1 2 3 4 5

N. of patterns

Service

Messaging

Discovery

Composition

Presentation

Resources

Management

Security

co

ncern

s

Cloud Domain








For instance in the next picture of the “Service” sub-section, the following facts are shown:

The “Cloud migration enabled by OSGI”, “Cloudified Application Servers” and “Map-Reduce” are three patterns and, in particular, they are “partOf” of the top-level pattern “PaaS”.

Each one of the three above mentioned patterns provides an architectural design solution of a system that offers the “Execution of Service Components” functionality.

Currently, patterns that address the functionality “Creation of Service Component” in the Cloud domain are missing.

Discovery

Service


Resources

Security

Management


2.2 Cards

Hereafter the identity cards (see section 3.5.1 in D7.2b7) of each pattern are reported. They are alphabetically listed in the next sections. Each card provides a short abstract description of the pattern, and some other information concerning the authors, its category type and level.




7 Definition of an architectural framework & principles, D7.2b,http://www.nexof-ra.eu








2.2.1 Authorization

Name Authorization

Abstract Authorization pattern should provide a feature to determine whether an entity can access to the given protected resource in order to execute an operation

Level Abstract (Design Patterns), Implementation (Idioms) (will be implemented with a PERMIS RBAC solution)

Type Functional



XACML Specification

PERMIS



PoC Validation NO


Accountability +




2.2.2 Cloud migration enabled by OSGi – step one

Name Cloud migration enabled by OSGi – step one

Abstract The CMO1 pattern (Cloud Migration enabled by OSGi– step one) provides functionalities for migrating a functional component into the cloud and between clouds during runtime.

This pattern is based on common APIs and an OSGi based service platform using dependency injection. It enables migration of services into cloud and between clouds and shows one fundamental step towards an OSGi Based Cloud Platform Runtime. The pattern enables access to and use of a local as well as a cloud service. As an example service the functionalities of a database are described, but data migration between databases is disregarded.

Level Abstract

Type Functional

Key Concerns Services, Composition, Management, Resources

Credits Nicole Wengatz (Siemens)

Adam Nowakowski (Siemens)

Jonas Zierer (Siemens)

Contact Evelyn Pfeuffer ([email protected])


PoC Validation YES

Quality Attriubtes Adaptation to new operating environments (Portability)

+

Extension of capability +

Interoperability +




2.2.3 Cloudified Application Servers

Name Cloudified Application Servers

Abstract Describes the structure of application container components suitable for cloud computing platform.

Level Abstract

Type Functional

Key Concerns Service, Management

Credits WP-4

Contact Francisco Pérez-Sorrosal ([email protected])


PoC Validation NO


Performance (efficiency) +

Scalability +

Consistency -




2.2.4 Elastic Reliable Filesystems

Name Elastic and Reliable File Systems

Abstract It presents an architecture for file systems in order to store application information in the cloud computing platform.

Level Abstract

Type Functional

Key Concerns Management

Credits WP-4



PoC Validation NO


Reliability +


Scalability +




2.2.5 IaaS - Infrastructure as a Service


Abstract The IaaS pattern is aimed at providing Cloud Service Providers (e.g. Platform as a Service, Software as a Service) with computational resources, charged by usage and supporting automatic scaling. It enables its customers (higher level Service Providers) to deliver their own business services on the Internet without owning or administering ICT infrastructure

Level TOP-LEVEL

Type Functional



SLA@SOI NSP



PoC Validation NO


Interoperability +

Scalability +

Availability +

Reliability +

Modifiability +

Reusability +

Buildability +

Performance -

Security -




2.2.6 Map Reduce

Name Map Reduce

Abstract It simplifies the parallelization and distribution of large-scale computations in clusters.

Level Abstract

Type Functional

Key Concerns Service

Management

Credits WP-4



PoC Validation NO

Quality Attributes Performance +

Ease of Use +

Reliability +




2.2.7 Not only SQL (NoSQL) Storage

Name NoSQL Storage

Abstract It presents the structure of a new trend in storage system based on distributed hash tables that allows to provide elastic storage to many web applications deployed in cloud environments.

Level Abstract

Type Functional


Credits WP-4



PoC Validation NO



Scalability +

Consistency -




2.2.8 PaaS – Platform as a Service

Name Platform as a Service (PaaS)

Abstract The main goal of the PaaS pattern is to provide an execution environment for SaaS applications accommodating their requirements (basically in terms of the current workload and desired QoS attributes, e.g. performance, availability etc.) to the available resources in the infrastructure layer (e.g. IaaS) by means of an elastic behaviour.

Level Top-Level

Type Functional

Key Concerns Service, Management, Security, Discovery

Credits Francisco Pérez-Sorrosal (UPM)

Ricardo Jiménez-Péris (UPM)

Marta Patiño-Martínez (UPM)

Collaborations:

Shimon Agassi (IBM)

Phong Cao (Thales)

Edith Felix (Thales)



PoC Validation NO

Quality Attributes Elasticity +

Scalability +

Availability +

Privacy +

Accountability +

Manageability +

Portability -

Interoperability +




3 ENTERPRISE SOA DOMAIN

This section provides a compass to navigate among the set of patterns related to the Enterprise-SOA domain.

It starts with a picture that introduces the overall set of patterns and how they are related each other starting from the top-level pattern: “Enterprise-SOA”.






Figure 2: NEXOF-RA E-SOA Patterns

LEGENDA





0 2 4 6 8 10 12

N. of patterns

Service

Messaging

Discovery

Composition

Presentation

Resources

Management

Security

co

ncern

s

ESOA Domain







For instance in the next picture of the “Presentation” sub-section, the following facts are shown:

The “Designer and Runtime Tools for E-SOA” is a pattern that is a “partOf” of the top-level pattern “Enterprise SOA”, and the “Front End in


E-SOA” is a pattern that is “partOf” of the “Designer and Runtime Tools for E-SOA” pattern.

Each one of the two above mentioned patterns provides an architectural design solution of a system that offers the “Creation of User Interface Components” and “Execution of User Interface Components” functionality.

Presentation

Composition


Discovery

Messaging


Service

Resources


Security

Management


3.2 Cards

Hereafter the identity cards (see section 3.5.1 in D7.2b11) of each pattern are reported. They are alphabetically listed in the next sections. Each card provides a short abstract description of the pattern, and some other information concerning the authors, its category type and level.




3.2.1 Active Replication

11

Definition of an architectural framework & principles, D7.2b,http://www.nexof-ra.eu








Name Active Replication

Abstract This pattern describes a technique based on redundancy used for masking errors and achieving high availability of critical components.

Level Abstract

Type Non-Functional-Cross-Cutting

Key Concerns

Credits Francisco Pérez-Sorrosal

Ricardo Jiménez-Péris

Marta Patiño-Martínez



PoC Validation NO

Quality Attributes

High Availability +

Performance 0

Applicability 0

Maintainability +




3.2.2 Assisted Composition designer

Name Assisted Composition Designer

Abstract This pattern captures the main elements which should be part of a Process Designer Tool which is able to provide service compositions created in an automatic way, so it will be easier for developers to implement business processes.

Level Abstract

Type Functional





PoC Validation NO


Integrability +

Modifiability +

Performance -

Reusability +

Testability +

Usability +




3.2.3 Authorization

Name Authorization

Abstract Authorization pattern should provide a feature to determine whether an entity can access to the given protected resource in order to execute an operation

Level Abstract (Design Patterns) , Implementation (Idioms) (will be implemented with a PERMIS RBAC solution)

Type Functional



XACML Specification

PERMIS



PoC Validation YES


Accountability +




3.2.4 Black-Box Database Replication

Name Black-Box Database Replication

Abstract Describes a replication mechanism for databases outside the database kernel that does not need to access the database code.

Level Abstract


Key Concerns




Damián Serrano-Martínez



PoC Validation NO

Quality Attributes Scalability +

Availability +

Applicability +

Maintainability -




3.2.5 Cloud migration enabled by OSGi – step one

Name Cloud migration enabled by OSGi – step one

Abstract The CMO1 pattern (Cloud Migration enabled by OSGi – step one) provides functionalities for migrating a functional component into the cloud and between clouds during runtime.

This pattern is based on common APIs and an OSGi based service platform using dependency injection. It enables migration of services into cloud and between clouds and shows one fundamental step towards an OSGi Based Cloud Platform Runtime. The pattern enables access to and use of a local as well as a cloud service. As an example service the functionalities of a database are described, but data migration between databases is disregarded.

Level Abstract

Type Functional

Key Concerns Services

Credits Nicole Wengatz (Siemens)

Adam Nowakowski (Siemens)

Jonas Zierer (Siemens)



PoC Validation YES

Quality Attributes Adaptation to new operating environments (Portability)

+


Interoperability +




3.2.6 Data Mediation

Name Data Mediation

Abstract This pattern mediates between the incompatible and heterogeneous output and input messages exchanged between subsequent service invocations, whereby the output message of former service invocation can be consumed as input message by the later service.

Level Abstract

Type Functional


Credits SOA4ALL (Atos, Manchester Univ, CEFRIEL)

Contact Fco. Javier Nieto (ATOS)

[email protected]


PoC Validation NO

Quality Attributes

Buildability +

Maintainability +

Integrability +

Interoperability +

Modifiability +


Scalability +

Testability +

Usability +



3.2.7 Designer and Runtime Tools for E-SOA

Name Designer and Runtime Tools for E-SOA

Abstract This pattern is a refinement of the Enterprise SOA pattern and focus on some of the architectural choices described into the top level pattern. In particular, it focus on the functionalities provided by software components that are responsible for the design of software artefacts and their execution. The pattern starts from these subset of software components and functionalities provided by the Enterprise SOA pattern and describes how they are decomposed according to the kind of software artefact to be designed or executed. The architectural choices made by this pattern describes a part of the SOA infrastructure at a very high level of abstraction and can be specialized to realize more specific architectural solutions

Level Abstract

Type Functional

Key Concerns Services, Presentation, Composition, Management

Credits WP2

Contact Antonio De Nigro ([email protected])


PoC Validation NO

Quality Attributes Buildability +

Availability +

Maintainability (Extension of capability)

+

Throughput +

Reusability +

Usability -





3.2.8 Distributed ESB in ESOA

Name Distributed ESB in ESOA

Abstract This pattern represents the bridge between two services which use different protocols and/or datatypes and need to interact. It is able to perform those transformations needed in order to enable interoperability

Level Abstract

Type Functional


Credits Fco. Javier Nieto

Contact Fco. Javier Nieto ([email protected])


PoC Validation NO


Integrability +

Interoperability +

Modifiability +


+


Recoverability +

Reusability +

Scalability +

Security +

Testability +




3.2.9 Dynamic Binding of Services during composition

Name Dynamic Binding of Services during Composition

Abstract This pattern enables dynamic execution of processes and invocation to services, by managing the services binding at the execution engine, which allocates invocations dynamically, reacting to the context.

Level Abstract

Type Functional



Paolo Zampognaro (Engineering)



PoC Validation NO


Maintainability +

Integrability +

Interoperability -

Modifiability +


+

Recoverability +

Reliability +

Reusability +

Scalability +

Security -

Testability +

Usability +



3.2.10 Enterprise SOA

Name Enterprise SOA

Abstract This pattern describes the characteristics of a SOA infrastructure specifically designed to support enterprise service-based applications

Level Top-Level

Type Functional

Key Concerns Services, Messaging, Discovery, Composition, Presentation, Management, Security and Resource

Credits WP2

Contact Debora Desideri ([email protected])


PoC Validation NO

Quality Attributes Build-ability +

Portability +

Modifiability / Extensibility +

Interoperability +



3.2.11 Front-End in E-SOA

Name Front-End in E-SOA

Abstract This pattern is a refinement of the “Designer and Runtime Tools for E-SOA” one. Concretely, it focuses on the functionalities provided by software components that are responsible for the design and execution of artefacts devoted to the NEXOF presentation (front-end) concern All the architectural choices made by this pattern are related to the decomposition into three functional aspects: accessing to and adapting SFERs, composing SFERs and engineering SFERs. In addition, the “Context of Use Manager” component, covers the cross-cutting aspect that has to do with the provision of contextual information (what is the device, browser, network, location, etc.) needed to adapt automatically the interaction to different computing platforms, users or environments

Level Abstract

Type Functional

Key Concerns Presentation, Discovery, Management

Credits Project EzWeb, Project MyMobileWeb, Project FAST

Contact JOSE MANUEL CANTERA FONSECA ([email protected])


PoC Validation NO


Integrability +

Modifiability (Adaptation to new operating environments)

+

Modifiability (Extension of capability)

+

Reusability +

Usability +

Security (Isolation) -





3.2.12 Generic Group communication

Name Generic Group Communication

Abstract This pattern defines a generic interface that may be used to wrap multiple toolkits.

Level Abstract


Key Concerns

Credits Nuno Carvalho

José Pereira

Luis Rodrigues

Contact N. Carvalho


PoC Validation NO

Quality Attributes Applicability +

Maintainability +



3.2.13 Gray-Box Database Replication

Name Gray-Box Database Replication

Abstract Describes an efficient replication mechanism for databases outside the database kernel that needs access to the source code

Level Abstract


Key Concerns







PoC Validation YES


Availability +




3.2.14 Horizontal Replication with Replication Awareness

Name Horizontal Replication with Replication Awareness

Abstract The Horizontal Replication pattern provides high availability and scalability for applications deployed on multi-tier architectures by replicating each tier independently.

The Replication Awareness pattern helps in introducing awareness of replication in the different tiers when the Horizontal Replication pattern is used.

Level Abstract


Key Concerns

Credits UPM

Contact Ricardo Jiménez-Péris ([email protected] )


PoC Validation NO


Availability +

Applicability +

Maintainability -




3.2.15 IaaS – Infrastructure as a Service


Abstract The IaaS pattern is aimed at providing Cloud Service Providers (e.g. Platform as a Service, Software as a Service) with computational resources, charged by usage and supporting automatic scaling. It enables its customers (higher level Service Providers) to deliver their own business services on the Internet without owning or administering ICT infrastructure.

Level Top-Level

Type Functional



SLA@SOI NSP



PoC Validation NO


Interoperability +

Scalability +

Availability +

Reliability +

Modifiability +

Reusability +

Buildability +

Performance -

Security -




3.2.16 Log-Mining Writeset Extraction

Name Log-Mining Writeset Extraction

Abstract Describes the log mining mechanism, a method that can be used for writeset extraction in database replication

Level Abstract


Key Concerns







PoC Validation YES

Quality Attributes

Performance -

Maintainability +




3.2.17 Models Manager

Name Models Manager

Abstract This pattern defines the elements involved in the management of models, which may represent languages for process execution, so a composition can be created and edited easily.

Level Abstract

Type Functional





PoC Validation NO


Maintainability -

Integrability +

Interoperability -

Modifiability -


+

Recoverability +

Reliability +

Reusability +

Scalability +

Security -

Testability +

Usability +




3.2.18 Monitoring in Enterprise SOA

Name Monitoring in Enterprise SOA

Abstract Monitoring is an essential task for decision making in Enterprise-SOA at all levels, from the running services and applications, to the infrastructure itself along with its computational resources. This document offers a top-level pattern that describes different options to monitor the elements included in NEXOF-Compliant Infrastructures (NCI)

Level Abstract

Type Functional-Cross-Cutting



Ricardo Jiménez-Peris




PoC Validation NO


Maintainability +


Scalability/Adaptability +




3.2.19 Multicast-Based Replica Discovery

Name Multicast-Based Replica Discovery

Abstract This replica discovery pattern decouples the client from the particular set of nodes where the replicated service is running. Following the Multicast-Based Replica Discovery pattern, a multicast service is used

Level Abstract


Key Concerns

Credits UPM



PoC Validation NO

Quality Attributes Replication Transparency +

Applicability +

Maintainability +




3.2.20 Multi-phase Discovery

Name Multi-phase Discovery

Abstract This pattern specifies a way to perform service discovery by applying different discovery algorithms in several phases, refining the list of candidate services in each phase

Level Abstract

Type Functional



András Micsik

INFRAWEBS



PoC Validation YES


Integrability +

Interoperability +

Modifiability +


Reliability -

Reusability +




3.2.21 Multi-Tenancy Enabler

Name Multi-Tenancy Enabler (MTE)

Abstract The pattern shown in this document (called Multi-Tenancy Enabler) describes the concept of multi-tenancy by using multiple instances of an application and an adapter layer in combination with virtualisation. In particular for depicting the principles used for the MTE pattern a solution is chosen, which requires a multi-tenant database. The pattern shows how a component like a single-tenant database can be used to implement a multi-tenant solution and how the usage of multiple instances of this database avoids the large effort of redesigning the database. The idea presented by the pattern in the context of databases can easily be transferred to other applications as well.

Level Abstract

Type Functional

Key Concerns Resources

Credits Gerald Kaefer

Siemens AG

Publications by IBM and Microsoft15 1617



PoC Validation NO


15 Germán Goldszmidt ([email protected]), Indrajit Poddar ([email protected]):

Develop and Deploy Multi-Tenant Web-delivered Solutions using IBM middleware: Part 1: Challenges and architectural patterns (http://www.ibm.com/developerworks/library/ws-middleware/)

16 Carl Osipov ([email protected]), Germán Goldszmidt ([email protected]), e.a.: Develop and Deploy Multi-Tenant Web-delivered Solutions using IBM middleware: Part 2: Approaches for enabling multi-tenancy (http://www.ibm.com/developerworks/webservices/library/ws-multitenantpart2/index.html)

17 Frederick Chong ([email protected]), Gianpaolo Carraro ([email protected]), e.a.: Multi-Tenant Data Architecture (http://msdn.microsoft.com/en-us/library/aa479086.aspx)





http://www.ibm.com/developerworks/library/ws-middleware/



http://www.ibm.com/developerworks/webservices/library/ws-multitenantpart2/index.html

http://www.ibm.com/developerworks/webservices/library/ws-multitenantpart2/index.html



http://msdn.microsoft.com/en-us/library/aa479086.aspx


Modifiability +

Availability +

Security (Isolation) +

Recoverability +

Buildability +

Resource efficiency -


3.2.22 Multi-Tier Transactional Service Runtime

Name Multi-Tier Transactional Service Runtime

Abstract This pattern describes the architecture of a multi-tier service runtime

Level Abstract


Key Concerns Services






PoC Validation NO

Quality Attributes

Buildability +

Maintainability +

Availability -

Scalability -

Reusability +

Usability +


Reliability +




3.2.23 Non-Repudiation

Name Non-Repudiation

Abstract The Non-Repudiation pattern brings a set of functionalities which permits to trust the ESOA and guarantee the data integrity

Level Abstract

Type Functional


Credits Nexof-RA WP4

Serenity

Security Principles

Security PoC of WP8



PoC Validation YES

Quality Attributes Integrity +

Authenticity +

Maintainability +





3.2.24 OSGi-based SCA-Container

Name OSGi-based SCA-Container

Abstract The pattern promotes a standardized way to dynamically extend a service runtime container with additional communication protocols and implementation types at run-time. OSGi is used as underlying technology providing dynamic extension mechanisms for an SCA container

Level Abstract

Type Functional

Key Concerns Services, Composition

Credits Oliver Arafat

Philipp Konradi

Nicole Wengatz

Contact Pfeuffer, Evelyn ([email protected])


PoC Validation YES

Quality Attributes Adaptation to new operating environments (Portability)

+


Interoperability +




3.2.25 Reflective Database Replication

Name Reflective Database Replication

Abstract It allows independent design and implementation of DBMS servers and replication protocols, allowing pluggable modules with different consistency and availability trade-offs, while at the same time fostering more efficient and maintainable implementations.

Level Abstract


Key Concerns

Credits José Pereira

Rui Oliveira

Nuno Carvalho

Luis Rodrigues

Contact J. Pereira


PoC Validation NO


Maintainability +



3.2.26 Registry-Based Replica Discovery

Name Registry-Based Replica Discovery

Abstract This replica discovery pattern decouples the client from the particular set of nodes where the replicated service is running. With this pattern, clients look up connection information in well-known registry or registries that are kept updated with the current list of available replicas

Level Abstract


Key Concerns







PoC Validation NO


Applicability +

Maintainability +




3.2.27 Security in Enterprise SOA

Name Security in Enterprise SOA

Abstract The Security in E-SOA brings a set of functionalities which, as a main goal, allow to guarantee the security in an E-SOA and so more.

Level Abstract

Type Functional



Serenity

Security Principles

Security PoC of WP8



PoC Validation NO

Quality Attributes Confidentiality +

Integrity +

Authenticity +

Accountability +

Maintainability +





3.2.28 Service Discovery

Name Service Discovery

Abstract Describes the main elements related to discovering services according to some requirements coming from users.

Level Abstract

Type Functional


Credits Fco. Javier Nieto



PoC Validation YES

Quality Attributes Integrability +

Interoperability +

Modifiability +


Reliability -

Reusability +

Portability +




3.2.29 Service Matchmaking and Ranking

Name Service Matchmaking and Ranking

Abstract This pattern defines those components involved in a simple discovery process which is divided in two tasks: matchmaking requirements and services and ranking candidate services

Level Abstract

Type Functional



Dimitrios Skoutas



PoC Validation YES


Integrability +

Interoperability +

Modifiability +


Reliability -

Reusability +




3.2.30 Session Replication with Multi-Tier Coordination

Name Session Replication with Multi-Tier Coordination

Abstract The Session Replication pattern is commonly used to achieve availability and scalability in the application server tier. The Multi-Tier Coordination pattern is useful to track executions that cross tier boundaries in a multi-tier architecture.

Level Abstract


Key Concerns






PoC Validation NO

Quality Attributes

Scalability +

Availability +

Applicability +



3.2.31 Template-based Discovery

Name Template-based Discovery

Abstract This pattern describes how to perform service discovery using as requirements a template which is filled-in by users who want to find services, as a way to support the requirements description

Level Abstract

Type Functional



András Micsik

INFRAWEBS



PoC Validation NO


Integrability +

Modifiability +


Reusability +




3.2.32 Transparent Replication Proxy

Name Transparent Replication Proxy

Abstract The Transparent Replication Proxy pattern is a specialization of the Proxy pattern. It can be used when the server is replicated in order to provide replication transparency and transparent failover.

Level Abstract


Key Concerns







PoC Validation NO


Scalability +

Availability +

Applicability +




3.2.33 Trigger Writeset Extraction

Name Trigger Writeset Extraction

Abstract Describes the trigger mechanism, a standard method in databases that can be used for writeset extraction in database replication

Level Abstract


Key Concerns







PoC Validation YES

Quality Attributes

Performance -

Applicability +

Maintainability +




3.2.34 Trusted Timestamping

Name Trusted Timestamping

Abstract The Trusted Timestamping pattern brings a set of functionalities which permits to trust the ESOA as well as other system families.

Level Abstract

Type Functional



Serenity

Security Principles

Security PoC of WP8



PoC Validation YES

Quality Attributes Integrity +

Accountability +

Maintainability +





3.2.35 Vertical Replication

Name Vertical Replication

Abstract The Vertical Replication pattern aims at providing high availability and scalability for applications deployed on multi-tier architectures

Level Abstract


Key Concerns







PoC Validation YES

Quality Attributes

Scalability +

Availability +

Applicability +




3.2.36 Virtual ESB

Name Virtual ESB

Abstract This pattern extends the Distributed ESB pattern in ESOA providing virtual Delivery Channels to bridge the communication among heterogeneous services

Level Abstract

Type Functional


Credits T. Szydlo

R. Szymacha

K. Zielinski

Contact T. Szydlo


PoC Validation NO


Integrability +

Interoperability +

Modifiability +


+


Recoverability +

Reusability +

Scalability +

Security +

Testability +



3.2.37 Virtualization of Computational Resources in E-SOA

Name Virtualization of Computational Resources in E-SOA

Abstract This document illustrates the pattern Virtualization of Computational Resources in E-SOA. It describes the characteristics of Virtualization of Computational Resources and its architecture.

Level Abstract

Type Functional


Credits Shimon Agassi

Project Reservoir

Contact Pfeuffer Evelyn ([email protected])


PoC Validation NO



+


Resource Efficiency +

Scalability +




3.2.38 White-Box Database Replication

Name White-Box Database Replication

Abstract Describes an efficient replication mechanism for databases implemented in the database kernel that needs access to the source code

Level Abstract


Key Concerns







PoC Validation NO


Availability +

Applicability -

Maintainability -




3.2.39 Writeset Extraction Based on Extended Interfaces

Name Writeset Extraction Based on Extended Interfaces

Abstract Describes the implementation of an extended interface for writeset extraction useful for database replication.

Level Abstract


Key Concerns







PoC Validation YES

Quality Attributes Performance +

Applicability -



Documents

NEXOF-RA - CORDIS › docs › projects › cnect › 6 › 216446 › ... · 2017-04-19 · NEXOF-RA • FP7-216446 • D7.5b • Version 0.4, dated 30/06/2010 • Page 3 of 91 EXECUTIVE