NEXOF-RA NESSI Open Framework Reference Architecture IST- FP

Transcription

1 NEXOF-RA NESSI Open Framework Reference Architecture IST- FP Deliverable D7.4 RA Specification Sample Siemens AG HP Engineering Thales Due date of deliverable: 01/03/2009 Actual submission date: 03/04/2009 This work is licensed under the Creative Commons Attribution 3.0 License. To view a copy of this license, visit 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-FP NEXOF-RA FP D7.4 RA Specification Sample Version 1.0, dated 03/04/2009 Page 1 of 28

2 Change History Version Date Status Author (Partner) Description /03/2009 Draft Oliver Arafat (SIE) First draft of structure and sample content /04/2009 Draft Piero Corte (ENG) The specification sample structure has been added /04/2009 Draf Oliver Arafat (SIE) Adapted figures to modified sample content /04/2009 Final All The document has been restructured and finalized NEXOF-RA FP D7.4 RA Specification Sample Version 1.0, dated 03/04/2009 Page 2 of 28

3 EXECUTIVE SUMMARY This deliverable contains a simple set of descriptions for standards, components and patterns, presented in a way which allows its usage as a template and guideline for the construction of the NEXOF-RA Specification. NEXOF-RA FP D7.4 RA Specification Sample Version 1.0, dated 03/04/2009 Page 3 of 28

4 Document Information IST Project Number Full title Project URL FP Acronym NEXOF-RA NESSI Open Framework Reference Architecture EU Project officer Arian Zwegers Deliverable Number D7.4 Title RA Specification Baseline (RS V0.0) Work package Number WP7 Title Service Centric Systems Engineering Date of delivery Contractual 01/03/2009 Actual 01/03/2009 Status Version 0.1, dated 23/03/2009 final Nature Abstract (for dissemination) Keywords Report Demonstrator Other Reference Architecture Internal reviewers Authors (Partner) All partners Responsible Author Reviewer1 (Organization) Reviewer2 (Organization) Oliver Arafat (SIE), Partner Siemens Phone NEXOF-RA FP D7.4 RA Specification Sample Version 1.0, dated 03/04/2009 Page 4 of 28

5 TABLE OF CONTENTS EXECUTIVE SUMMARY... 3 TABLE OF CONTENTS INTRODUCTION REFERENCE ARCHITECTURE SPECIFICATION GUIDELINE THE PATTERN TEMPLATE POSITIONING THE SAMPLE SET SPECIFICATION PIECES RELATIONSHIPS TO THE NEXOF REFERENCE ARCHITECTURE STRUCTURE RELATIONSHIPS TO THE NEXOF CONCEPTUAL MODEL STANDARDS SCA OSGI EXAMPLE PATTERNS EXAMPLE TOP-LEVEL PATTERN DESCRIPTION EXAMPLE ABSTRACT DESIGN PATTERN DESCRIPTION EXAMPLE IMPLEMENTATION TYPE PATTERN DESCRIPTION NEXOF-RA FP D7.4 RA Specification Sample Version 1.0, dated 03/04/2009 Page 5 of 28

6 1 INTRODUCTION This document provides a sample set of descriptions for standards, guidelines, components and patterns, so that it can be used as a template and guideline for the building of the NEXOF-RA Specification. Actually, the provided descriptions must be considered examples. Hence, they are not intended to be complete in breadth or depth. The achieved result, as well as the construction task of the sample set, has allowed us to validate the structure of the NEXOF Reference Architecture and to start experiencing the instantiation process of the specification. The different parts that constitute the Sample Set are summarized into the following picture. They are introduced and positioned with respect to the Structure of the NEXOF Reference Architecture (see section 2.3 of D6.2). Figure 1: The Specification Sample parts In more detail, the Sample Set specification will cover all the different parts of the reference architecture by providing examples of: Standard selection: SCA, OSGi Software components (building blocks): Service Repository, Service Bus, Service Runtime, Service Component Srchitectural/design patterns: Enterprise Service-Oriented Architecture Pattern, OSGi-based SCA-Container Pattern, Tuscany Interoperability Pattern. The remaining part of the document is organized as follow:

7 Section 2 provides the template for describing patterns Section 3 provides details about how the different pieces of the sample set specification are positioned into the NEXOF-RA structure and how they are related to the NEXOF-RA Conceptual Model Section 4 provides the references and a short description to the selected standards Section 5, finally, provides the description of the three sample patterns: the top-level pattern description, named Enterprise SOA Pattern, the abstract design pattern, named OSGi based SCA-container Pattern, and the implementation pattern, named Tuscany Interoperability Pattern.

8 2 REFERENCE ARCHITECTURE SPECIFICATION GUIDELINE 2.1 THE PATTERN TEMPLATE This section shows a template format for describing patterns. This template results from a little improvement of the template format already provided into a previous deliverable (see D7.2 for more details). The pattern template is composed of the following sections: Name It is the name of the pattern. Icon (optional) Each pattern description is represented by an icon image. It is the visual identifier of the pattern. Type It specifies the type of the pattern. It could be one of the following, as described in D6.2: Top-level: patterns which describe the characteristics of service based system families and express a fundamental structural organization schema. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. Abstract: patterns which only refer to abstract components Implementation: patterns which refer to at least one concrete component. Key concerns It specifies one or more NEXOF concerns the pattern is related to. As specified in D6.2 the concerns are: Services Messaging Discovery Composition Analysis Presentation Management Security

9 Resources. Problem This section describes the problem statement for which the pattern is expected to provide a solution (the main functional requirement). The description contains the issue causing a problem and the effects of it. The general problem statement is completed by a set of forces to denote any aspect of the problem that should be considered when solving it, such as Non-Functional Requirements the solution must meet (e.g. Security, Scalability) Constraints that have to be considered (e.g. transparent use of communication protocols, technology independent) Desirable properties the solution should have (Modular, Service oriented, etc.). Solution This part contains the design solution proposed by the pattern to solve the problem and fulfil the requirement. It contains statements and diagrams to communicate the final solution. Application This part describes how the pattern can be applied in a real case. It should provide a list of all known situations where a problem that is addressed by this particular pattern can occur. It can also include guidelines, best practises and sometimes even a suggested process. Conceptual model relationships This section should provide how the components that participate to the pattern are related to the NEXOF Conceptual Model. Relationships to Actors, Behaviours, and Information Entities must be provided. Pattern relationships This section is for documenting key pattern relationships. It highlights key relationships, with an emphasis on dependency among different patterns. It put into evidence the requirements and dependencies a pattern may have and the effects of its application upon other patterns. The content in this section is not exhaustive because not all possible relationships a given design pattern can have are covered. The following list shows the different type of pattern relationships. Uses relation, where a pattern "uses" another pattern

10 PartOf relation, where a pattern is part of another pattern Refines relation, where a pattern "refines" another pattern Conflicts relation, where a pattern "conflicts" with another pattern. Standard Relationships (optional) This section provides the list of standards the pattern is compliant to. External References List of standards, technologies and initiatives related to the pattern (not necessarily used in the pattern).

11 3 POSITIONING THE SAMPLE SET SPECIFICATION PIECES To better describe the different pieces of the Sample Set and to show how the description of patterns has to be related to the NEXOF Conceptual Model, some guidelines, such as a fragment of the description of the Structure of the NEXOF Reference Architecture, and a fragment of the NEXOF Conceptual Model is included and presented in the next sub-sections.

12 3.1 RELATIONSHIPS TO THE NEXOF REFERENCE ARCHITECTURE STRUCTURE This section provides a partial description of the NEXOF Reference Architecture Structure that is useful to position all the pieces of specification covered by the sample. Figure 2: Relationships to NEXOF-RA structure

13 3.2 RELATIONSHIPS TO THE NEXOF CONCEPTUAL MODEL This section provides a fragment of the NEXOF Conceptual Model (see D6.2) to show how the building blocks and the sample patterns are related to the concepts of the NEXOF Conceptual Model. Of course, it is important to consider that the purpose of this section is only demonstrative, that is it does not aim to be exhaustive. Figure 3: Relationships to NEXOF Conceptual Model

14 4 STANDARDS 4.1 SCA Name Service Component Architecture, Version 1.0 Description Service Component Architecture (SCA) ( defines a general approach to doing both of these things. It provides both a programming model for the creation of service components and a model for assembling service components into a business solution. SCA is a set of specifications which describe a model for building applications and systems using a Service Oriented Architecture. It is a cross-language, distributed component architecture supporting multiple communication mechanisms between components. It is comprised of several components that will be introduced here shortly. For a comprehensive description please refer to the specification itself. Assembly Model SCA models solutions as sets of service components offering services and making references to services supplied by others, which are combined together by (recursively defined) composites which wire references to services and which declaratively apply bindings for communication methods and also apply policies for aspects such as security and transactions. SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services. The assembly model referring to this circumstance is depicted in Figure 4. Figure 4: Assembly Model

15 Policy Framework The capture and expression of non-functional requirements such as security is an important aspect of service definition, and has impact on SCA throughout the lifecycle of components and compositions. SCA provides the Policy Framework to support specification of constraints, capabilities and Quality of Service (QoS) expectations, from component design through to concrete deployment. Bindings SCA Bindings apply to services and references. Bindings allow services to be provided, and references to be satisfied, via particular access methods or transports. 4.2 OSGI Name OSGi (formely known as Open Services Gateway initiative), Version 4.1 Description OSGi technology ( provides a service-oriented, component-based environment for managing relationships between modules, known as bundles. The driving force for OSGi is to provide a secure, pluggable system so that bundles can be hot deployed to the OSGi container. The container provides good isolation between bundles so that no bundle can interfere with another bundle unless that bundle explicitly exposes its services to the others.

16 5 EXAMPLE PATTERNS 5.1 EXAMPLE TOP-LEVEL PATTERN DESCRIPTION Name Enterprise Service-oriented Architecture Icon Type Top-Level Key concerns Services Messaging Discovery Composition Analysis Presentation Management Security Resources. Problem In recent years there has been a lot of attention regarding comparisons between loose coupling and tight coupling. In the business side, this was mainly driven by the growing need of enterprises to increase flexibility with respect to changes in their own business processes and how they interact with partner companies. Traditionally, business processes have been designed within the boundaries of an enterprise, or even within the different business units of an enterprise. In these kinds of scenarios one sees a much higher degree of uncertainty, a much more frequent change in terms of participants and their roles, and a constant evolution of the types of interaction required. For these types of in-flux operations, a loosely couples architecture is required because it helps to reduce the overall complexity and dependencies. Such an

17 architectural style makes the application landscape more agile, enables quicker change, and reduces risk. Especially in the B2B (Business to Business) world where business entities must be able to interact independently, loose coupling becomes more and more important. The relationships between business partners often change rapidly alliances are formed and cancelled, and business processes between trading partners are adapted to new market requirements. Two companies that are partners in one market segment may be competitors in another market segment. Therefore, it is essential that the underlying IT infrastructure reflects this need for flexibility, independence and especially security. It must also embrace the fact that most IT landscapes are heterogeneous by nature. Integration of these heterogeneous systems is basically the main challenge of a service-oriented Architecture. Software coupling can happen on many different levels. Starting from actual physical coupling (a direct physical link is required vs. Physical intermediary), through type system (interface semantics vs. payload semantics) up to platform dependencies (Strong OS and programming language dependencies vs. OSand programming language independent). When making architectural decisions, one must carefully analyze the advantages of the level of coupling. Within in the scope of a single business unit for example, a high degree of loose coupling may not be as important as in B2B scenarios. However, in most cases, the increased flexibility achieved through loose coupling comes at a price, due to increased complexity of the system. Thus, the building of such loosely coupled systems usually requires a high level of technical expertise. If the system is often rearranged, however, loose coupling will pay off in the long term. A modern architecture must be able to embrace all these technologies and concepts. Heterogeneity must be understood as a fundamental fact that cannot be fought but instead must be managed. Solution An Enterprise Service-oriented Architecture is based on four key abstractions: A user frontend is the active element of a SoA. It delivers the value of the SoA to the end user and enables user-interaction. A service repository provides facilities to discover services and acquires all information to use the services, particularly if these services must be discovered outside the functional and temporal scope of the project that created them. It can provide additional information such as physical location, information about the provider, usage fees, security issues and available service level. Repositories can have different requirements based on whether they are used within the boundaries of a company or across multiple companies, especially when it is made publicly available through the internet. Such requirements can comprise legal issues (terms and conditions of usage), user registration, security, billing and versioning.

18 A service registry in contrary holds actual references to services which are described and maintained in a repository. A service bus connects all participants of a SoA, services and user frontends with each other. If two participants need to communicate, for example if a user frontend needs to invoke some functionality offered by a particular service, the service bus makes it happen. It is important to note that a service bus is not necessarily composed of a single building block, but rather comprises a variety of concepts and thus building blocks. A service component provides a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service contract. It is usually hosted in a service-runtime. Application Enterprise domain Integration of legacy applications Technology-independent interoperability between services Integration of heterogeneous IT landscapes. It is recommended to comply to one single programming model where possible. A programming model ideally defines a unified paradigm for creating and accessing business logic and data. It may also define a component model that specifies how to compose and assemble several service components. Conceptual model relationships

19 The highlighted boxes indicate the relevant parts of the NEXOF conceptual model with respect to this pattern (User Front-End is missing). Service Runtime and Service Component are used by a Service Provider whereas a Service Discoverer uses the Service Repository. A mediator uses the Service Bus. Pattern relationships None (not yet). 5.2 EXAMPLE ABSTRACT DESIGN PATTERN DESCRIPTION Name OSGi based SCA-container Icon Type Abstract Key Concerns Services Messaging Discovery Composition. Problem SCA is designed for distributed and heterogeneous systems, whereas OSGi was originally designed for services running in a single JVM on mobile or embedded systems. Now OSGi is also being used for enterprise applications. Two of the main requirements for enterprise OSGi are distributed computing support (e.g. multi JVM/multi-process) and multi-language compatibility. Although the OSGi specification is not bound to a certain programming language, Java is currently the preferred (and most useful) implementation choice, while SCA is targeting a multi-language distributed environment. Apart from that, developers want to be able to deploy multiple versions of a module at the same time and interchange them without stopping or breaking the system.

20 For maintenance reasons, remote management of the whole system should also be supported. Solution SCA and OSGi are complementary. SCA provides a definition for components with services and references. It describes a separation between service implementation and service usage and promotes a model where complex detail about communication methods is kept out of the business code within the implementation. SCA describes service integration through composites and provides a declarative way to apply policies for infrastructure capabilities such as security. SCA supports a distributed environment potentially using a heterogeneous mixture of component technologies. The OSGi container is able to address a wide range of systems from embedded devices up to enterprise servers. Dependency handling, multiversion support and remote management are integral parts of OSGi. Software components and services can be installed, updated and removed on the fly. The combination of SCA and OSGi provides the best of both worlds including: A common Service Component model A standardized way to integrate a variety of communication mechanisms in a runtime container An OSGi based SCA container can run on a wide range of system and has a clear and simple extension mechanism for supporting new implementation types and new communication bindings Integration of different implementation types allows the use of the technology best suited to the job. There are several roles that OSGi can play with SCA which will be discussed in the remainder of this paragraph. OSGi can be used as underlying technology for an SCA container providing an extension mechanism, dependency resolution, remote management and service registry capabilities. An SCA OSGi implementation type allows deploying existing OSGi applications/bundles in an SCA domain and using them as SCA components. A SCA OSGi Binding enables interworking between SCA components and OSGi services. The deployment scenario assumed in the remainder of this document is an SCA container running inside an OSGi container. The SCA container is build from a set of OSGi bundles. OSGi is thus used by the SCA container as a means for extending it dynamically by new implementation and binding types, for example. Additional functionality of this kind is provided as OSGi bundles, too.

21 OSGi Binding An SCA component can access an OSGi service running outside of the SCA domain via a reference configured with an OSGi Binding as depicted in Figure 5. Likewise, an SCA component offering a service can be exposed as OSGi Service via a service configured with an OSGi Binding as depicted in Figure 6. Figure 5: OSGi Binding - SCA located service calls OSGi located service Figure 6: OSGi Binding - OSGi located service calls SCA located service

22 The OSGi binding enables the communication between SCA components and OSGi services inside an OSGi container, but it does not support distributed inter-container communication over VM or runtime node boundaries. The following abstract components are thus addressed in this pattern: Service Runtime Service Component Service Registry. Application Enterprise domain Embedded Domain A common service component model A standardized way to dynamically integrate a variety of communication mechanisms with a runtime container. Conceptual model relationships Figure 7: OSGi based SCA-container relationships to the model The highlighted boxes indicate the relevant parts of the NEXOF conceptual model with respect to this pattern. Service Runtime and Service Component are used by a Service Provider whereas a Service Discoverer uses the Service Registry.

23 Pattern relationships Refines: Enterprise Service-oriented Architecture It refines this pattern by means of a service runtime-container and a standardized way to dynamically integrate a variety of communication mechanisms with it. Standard Relationships Service Component Architecture (SCA), Version 1.0 OSGi Core Specification Version, Version 4.1. External References Java. 5.3 EXAMPLE IMPLEMENTATION TYPE PATTERN DESCRIPTION Name Tuscany Interoperability Pattern Type Implementation Key concerns Services Messaging Discovery Composition. Problem Apache Tuscany (an Open Source implementation of SCA standards) is designed for distributed and heterogeneous systems targeting a multi-language distributed environment. It is especially designed for dealing with the following common integration scenarios. Clear separation between business logic and infrastructure logic Declarative choice of communication protocols to use for service s connectivity

24 Technology-independent interoperability between services e.g. Java vs. C++ Easy integration of (legacy) applications. Figure 8: Overview of the application scenario Solution The integration issues will be discussed by means of an example. It is a security system consisting of two SCA-Services and two standalone applications (Java and C++-based). The application scenario is depicted in Figure 8. The execution flow is further annotated in Figure 9 using numbering and is explained in detail in the sequence diagram below (Figure 10). The dynamic wiring in steps 2 and 4 in the above picture is achieved by the auto wiring capability of SCA Tuscany runtime. Auto-wire enables component references to be automatically wired to component services which will satisfy those references, without the need to create explicit wires between the references and the services. When the autowire feature is used, a component reference which is not promoted and which is not explicitly wired to a service within a composite is automatically wired to a target service within the same composite. In step 3 in Figure 8 two services, a.net service and a SCA native service, are wired to the same reference. At this juncture this feature cannot be achieved in

25 Tuscany, for it being not supported. Hence one has to comment and uncomment the binding information for the reference in the SCA java composite file. The SCA spec Ver 1.0, a reference can have the attribute wiredbyimpl (optional) which indicates that an implementation wires this reference dynamically. If this attribute is set to TRUE, it indicates that the target of the reference is set at runtime by the implementation code. Then the reference should not be wired statically within a composite, but left unwired. The current version of the Tuscany runtime does not support this feature. While Figure 8 outlines the relationship between the prototype s services and applications especially in terms of technology and communication with respect to the current state of the prototype, Figure 9 shows the target scenario which is to be achieved in the near future. The reason for this being BPEL-engine running in Apache Tuscany runtime does not support the Java Messaging and OSGi support. BPEL engine currently included in Tuscany (Apache Tuscany 1.3.2) runtime uses the Apache ODE (Orchestration Director Engine) and the current version uses ode-bpel-runtime-1.1. The support for JMS is available in apache ODE for the version 1.3 and not in version 1.1. If the future version of Tuscany runtime gets integrated with this Apache ODE version 1.3 and the OSGi support is also available and both get integrated in Tuscany, the Figure 8 scenario can be achieved. Figure 9: Overview of target scenario.

26 The sequences of the invocations of the different services, as depicted in Figure 9, are further explained using the sequence diagram as depicted in Figure Figure 10: Invocation flow MotionSensorControllerComponent: A Java-based standalone application which manages a set of motion sensors and which notifies a client application about each detected motion. Interface: JMS-Queue MotionEvents : On every new motion which is detected in a zone (area, building) a JMS-Message is placed in this queue. The JMS- Message contains data of the motion sensor JMS-Queue MotionEventAck : JMS-Messages in this queue indicate motion sensors whose alarm has been viewed and acknowledged by an admin. i.e. the message in the previous queue(motionevents) has been consumed. MotionReactorComponent: A Java-based SCA-Service which knows securityrelevant areas and for those reasons monitors all motion-sensor activations. If motion in such an area is detected, the sensor location is translated to area coordinates by the ZoneInfoService of the ZoneInfoComponent and is forwarded to VideoMonitoring and Cam-Controller service.

27 onmotiondetected(motionsensor): implements the reaction to detected motions. acknowledgemotiondetection(zone): acknowledges any registered motions in an area. ZoneInfoComponent: An OSGi-based SCA-Service which knows the equipment of each zone e.g. which motion sensors are installed there etc.. getzone(motionsensor): returns the building zone the given motion sensor is located in. CamControllerComponent: A.Net Service which controls all video-cams and areas which they have to monitor. movecamera(zone): Chooses the appropriate cam to monitor the given zone and makes it move as required. MotionReactorWorkflowComponent: A BPEL Service which orchestrates a workflow involving the Video Monitoring service. shownewview(zone): A BPEL Workflow service which provides a valid zone information to call the videomonitoring service. VideoMonitoringComponent: A C++ Standalone application showing cam pictures to security staff. shownewview (Zone, Camera[]): Tells the application to display a new view of the given cams to the operator since some action was detected in that zone. Application Enterprise Domain. Industrial Domain. Pattern relationships Refines: OSGi based SCA-container Standard Relationships (optional) Service Component Architecture, Version 1.0 OSGi Core Specification, Version 4.1

28 External References Java C++ BPEL JMS Microsoft.NET