1

ICT

INF5120Modellbasert systemutvikling

SOA architectures and platformsCOMET architecture modellingPIM4SOA and UPMS

Forelesning 19.03.2007Brian Elvesæter

brian.elvesater@sintef.no

ICT

Outline

SOA architecture and platformsService-oriented architecture (SOA)SOA reference modelsSOA platforms

COMET architecture modellingPIM4SOA and UPMS

2

ICT

Service-oriented architecture (SOA)

ICT

SOA definition

Service-oriented architecture (SOA)

“A set of components which can be invoked, and whose interface descriptions can be published, discovered and invoked over a network.” (W3C)

http://www.w3.org/

3

ICT

Architectural style

Service-oriented architecture (SOA)architectural paradigm for organizing and utilizingdistributed system capabilities that may be under the control of different ownership domains.

Evolution of architectural styles to designing software systems

Data-orientationProcedure-orientationObject-orientationComponent- and message-orientationService-orientation

ICT

How is SOA different (1)

Object-orientation (OO) vs. service-orientation (SO)Focus

OO: Focuses on packaging data with operations.SO: Focuses on the task or business function – getting something done.

MethodOO: Intentional melding of methods to a given data object, where methods are a property of the object.SO: Services represents access to methods, but the actual existence of methods and any connection to objects is incidental.

UsageOO: To use an object, it must first be instantiated.SO: One interacts with a service where it exists.

SemanticsOO: An object exposes structure but there is no way to express semantics other than what can be captured as comments in the class definition.SO: SOA emphasizes the need for clear semantics.

4

ICT

How is SOA different (2)

Organizing and understanding information communication technology (ICT)

SOA reflects the reality that ownership boundaries are a motivating consideration in the architecture and design of systems.SOA applies the lessons learned from commerce to the organization of ICT assets to facilitate the matching of capabilities and needs.

Two or more entities come together within the context of a single interaction implies the exchange of some type of value.Evolve away from interactions defined in a point-to-point manner to a marketplace of services.

ICT

SOA concepts

Key conceptsServiceHigh interoperabilityLoose coupling

SOA is not a specific technology

5

ICT

Service

IT representation of business functionality

Implemented via (multiple messages) thatreturn information and/orchange the state of an associated entity

Syntactically described with a (service) interface

Semantically described using (service) contracts

ICT

Service properties

Self-containedindependent, autonomous

Course-grainedone call to change multiple attributes instead of a call for each attribute

Visible/discoverablemechanisms to find the right service

Statelessresults/effects don’t depend on previous calls

Idempotentmultiple identical calls have one effect

Reusabledesigned to be used by multiple consumers

ComposableCoordination and assembling of collection of services

Non-functional attributesSLAs (Service-Level Agreements)QoS (Quality of Service)…

6

ICT

Large distributed systems

Key characteristicsLegacy, legacy, legacyCan’t start from scratchHighly heterogeneousLong lifetime of business data and contentsLarge companies with political environmentsBottlenecks are suicide (technical and organizational)Perfectionism is to expensive

Key requirementsScalabilityFlexibilityFault tolerance

ICT

Forms of loose coupling

asynchronoussynchronousDeployment

compensation2PC (two-phase commit)Transactionally

platform-independentstrong dependenciesPlatform

dynamicallystaticallyBinding

distributed controlcentral controlControl of process logic

data-centric, self contained messages

navigate through complex object trees

Interaction pattern

weakstrongType system

common basic typescommon complex typesData model

asynchronoussynchronousCommunication style

intermediatorpoint-to-pointPhysical

Loose couplingTight coupling

7

ICT

SOA reference models

ICT

Basic service-oriented model

Service providerProvides software applications for specific needs as services.

Service requesterA requester could be a human user/application program/another service accessing the service through a desktop or a wireless browser; it could be an application program.

Service broker:A service broker provides a searchable repository of service descriptions.Examples of service brokers are UDDI (Universal Description, Discovery, and Integration).

8

ICT

Extended service-oriented architecture

Composition

Description & Basic Operations

Mana-gement

•Capability•Inteface•Behavior•QoS

•Coordination•Conformance•Monitoring•QoS

•Publication•Discovery•Selection•Binding

Service provider

Service client

Service aggregator

performs

publishes

uses

Role actions

becomes

Operations•Assurance•Support

Market•Certification•Rating•SLAs

Service operator

Market maker

Managed services

Composite services

Basic services

Composition

Description & Basic Operations

Mana-gement

•Capability•Inteface•Behavior•QoS

•Coordination•Conformance•Monitoring•QoS

•Publication•Discovery•Selection•Binding

Service provider

Service client

Service aggregator

performs

publishes

uses

Role actions

becomes

Operations•Assurance•Support

Market•Certification•Rating•SLAs

Service operator

Market maker

Managed services

Composite services

Basic services

Papazoglou and GeorgakopoulosCACM,Oct. 2003

ICT

OASIS Reference Model forService Oriented Architecture 1.0

OASIShttp://www.oasis-open.org/home/index.php

Abstract framework.Understanding significant entities and relationships between them within a service-oriented environment.Development of consistent standards or specifications supporting service-oriented environment.

Based on unifying concepts of SOA and may be used byarchitects developing specific service-oriented architecturesin training and explaining SOA.

Reference model not directly tied to any standards, technologies or other concrete implementation detailsProvide a common semantics that can be used unambiguously acrossand between different implementations. The reference model focuses on the field of software architecture.

9

ICT

Scope of the reference model

ICT

What is an SOA

Service-oriented architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.

Visibility, interaction, and effect are key concepts for describing the SOA paradigm.

Visibility refers to the capacity for those with needs and those with capabilities to be able to see each other.Whereas visibility introduces the possibilities for matching needs to capabilities (and vice versa), interaction is the activity of using a capability.The purpose of using a capability is to realize one or more real worldeffects. At its core, an interaction is “an act” as opposed to “an object”and the result of an interaction is an effect (or a set/series of effects).

10

ICT

Principal concepts

Service: The means by which the needs of a consumer are brought together with the capabilities of a provider.

Visibility: The capacity for those with needs and those with capabilities to be able to interact with each other.

Service description: The information needed in order to use, or consider using, a service.

Execution context: The set of technical and business elements that form a path between those with needs and those with capabilities and that permit service providers and consumers to interact.

Interaction: The activity involved in making using of a capability offered, usually across an ownership boundary, in order to achieve a particular desired real-world effect.

Real world effect: The actual result of using a service, rather than merely the capability offered by a service provider.

Policy: A statement of obligations, constraints or other conditions of use of an owned entity as defined by a participant.

ICT

Dynamics of services

From a dynamic perspective, there are three fundamental concepts that are important in understanding what is involved in interacting with services: the visibility between service providers and consumers, the interaction between them, and the real world effect of interacting with a service.

11

ICT

Visibility

For a service provider and consumer to interact with each other they have to be able to ‘see’ each other. Visibility is the relationship between service consumers and providers that is satisfied when they are able to interact with each other. Preconditions to visibility are awareness, willingness and reachability.

Both the service provider and the service consumer MUST have information that would lead them to know of the other’s existence. Service awareness requires that the service description and policy – or at least a suitable subset thereof – be available.

Associated with all service interactions is intent – it is an intentional act to initiate and to participate in a service interaction. The extent of a service participant’s willingness to engage in service interactions may be the subject of policies.

Reachability is the relationship between service participants where they are able to interact; possibly by exchanging information. Reachability is an essential pre-requisite for service interaction – participants MUST be able to communicate with each other.

ICT

Interacting with services

Interacting with a service involves performing actions against the service. In many cases, this is accomplished by sending and receiving messages. Key concepts that are important in understanding what it is involved in interacting with services revolve around the service description – which references a information model and a behavior model.

The information model of a service is a characterization of the information that may be exchanged with the service.

Knowing the representation, structure, and form of information required is a key initial step in ensuring effective interactions with a service.

The formal descriptions of terms and the relationships between them (e.g., an ontology) provides a firm basis for selecting correct interpretations for elements of information exchanged.

The second key requirement for successful interactions with services is knowledge of the actions invoked against the service and the process or temporal aspects of interacting with the service.

The action model of a service is the characterization of the actions that may be invoked against the service.

The process model characterizes the temporal relationships and temporal properties of actions and events associated with interacting with the service.

12

ICT

Real world effect

A real world effect can be the response to a request for information or the change in the state of some defined entities shared by the service participants.

In this context, the shared state does not necessarily refer to specific state variables being saved in physical storage but rather represents shared information about the affected entities. In addition, the internal actions that service providers and consumers perform as a result of participation in service interactions are, by definition, private and fundamentally unknowable. By unknowable we mean both that external parties cannot see others’ private actions and, furthermore, SHOULD NOT have explicit knowledge of them.

ICT

Service descriptionThe service description represents the information needed in order to use a service.

A service description SHOULD include sufficient data to enable a service consumer and service provider to interact with each other. This MAY include metadata such as the location of the service and what information protocols it supports and requires. It MAY also include dynamic information about the service, such as whether it is currently available.

A service description SHOULD unambiguously express the function(s) of the service and the real world effects that result from it being invoked.

A service description MAY include support for associating policies with a service and providing necessary information for prospective consumers to evaluate if a service will act in a manner consistent with the consumer’s constraints.

The service interface is the means for interacting with a service. It includes the specific protocols, commands, and information exchange by which actions are initiated that result in the real world effects as specified through the service functionality portion of the service description.

13

ICT

Policies and contractsA policy represents some constraint or condition on the use, deployment or description of an owned entity as defined by any participant. A contract, on the other hand, represents an agreement by two or more parties. Conceptually, there are three aspects of policies: the policy assertion, the policy owner (sometimes referred to as the policy subject) and policy enforcement.

Whereas a policy is associated with the point of view of individual participants, a contract represents an agreement between two or more participants. Like policies, contracts can cover a wide range of aspects of services: quality of service agreements, interface and choreography agreements and commercial agreements.

ICT

Execution context

The execution context of a service interaction is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities.

14

ICT

SOA platforms

ICT

15

ICT

Enterprise Service Bus (ESB) Core

New technology: SOA generation EAI + MOM + …Core SOA infrastructure for service-to-service communication, mediation and other SOA / Web service functionsAll integration types including infrastructureVendors: 20 and growing

GARTNER

ICT

SOA platform consolidation

Data and information integration ➪ Information FabricEII: Enterprise information integrationETL: Extract, transform and load

Application integration ➪ Integration SuiteEAI: Enterprise application integrationB2Bg: Business-to-business gatewayESB: Enterprise service bus

Applications and Processes ➪ Business Process Management Suite

BPM: Business process managementB2Bi: Business-to-business integration

Enterprise workplace ➪ Interaction Platform

16

ICT

ICT

Goal: Composite applicationsComponents: EAI, BPM, B2B, B2BiExtensions: Adapter, collaboration, analysis, reporting, development, monitoring, contracts, SOA standards, …

Integration suite services

17

ICT

Business process management suite& interaction services

Goal: Continuous process improvementComponents: BPM

human-centric: people-intensive processesIntegration-centric: system-intensive processes

ICT

Information fabric services

Goal: Holistic view of data (information virtualisation)Components: DBMS, EII + ETL + replicationExtensions: Distributed meta-data repository, distributed data access, integrated data management

18

ICT

Trends

Consolidation ➪ comprehensive platformsMerging of Human Workflow and System Orchestration/Process servicesIntegration of Business Rules EnginesSupport for Event Notification services (publish and subscribe)Integration of Model-generated workplaces and role/task-oriented user interfaces, user interaction services, portals, and multi-device interfacesExplicit use of models (Enterprise and System)Enterprise architecture + SOA

ICT

COMET architecture modelling

19

ICT

ICT

4+2 tier reference architecture

User ServiceTierUser ResourceService Tier LS

Legacy

BusinessServiceTier

ResourceServiceTier

Presentation Tier

User Dialog Tier Com

ponentInfrastructure

Key

Component

Inter-componentcommunication

UserS

erviceD

omain

Business Service

Dom

ain

UserInterfaceTier

LS

Resource AdapterRARA

LA

RA

LA Local Adapter

Local Storage

Database

ToolApplication

20

ICT

System boundary model

ICT

Architecture model (1/2)

The architecture model describes the overall architecture of the system and its partitioning into components

The collaborations of components are described in terms of component interactions, component interfaces and protocols.

The architecture model describes two aspects of the system; the static (structure) and dynamic (behaviour).

The structural model describes the components, their dependencies, and internal component designthe dynamic model describes the component interfaces, interactions and protocols.

The architecture model is a platform independent system specification.

To keep platform independence there is a need to be able to also specify the data types in a platform independent way.

21

ICT

Architecture model (2/2)

Component Structure and Internal Design describes the static aspect of the system.

It includes the overall architecture and the partitioning into components as well as the internal design of the components.

Interface and Interaction Specification describes the dynamic aspect of the system.

It specifies the interfaces and related protocols as well as defining the interactions between sets of components necessary to provide therequired services.The abstract object model provided through an interface are alsodescribed

PIM data types contains the platform independent data-types used in the architecture model.

ICT

Component structure metamodel

22

ICT

Survey booking model structure

ICT

Architecture model template in RSM

23

ICT

Reference architecture analysis

Recall the Reference Architecture with associated tiers and component types.Analyse the System Boundary part of the Use Case Model with regards to the Reference Architecture.

The System Boundary correspond to the boundaries of the component of concern for the actual project, typically an Application Component.

After the identification of this "main" component the next step is to analyze the System Boundary Model with respect to its set of use cases and actors.Divide the System Boundary Model into a set of subsystems.

Each subsystem will cover a collection of the System Boundary use cases.The subsystems are non-exclusive, implying that a use case might be part of more than one subsystem.The result of this task is a functional decomposition of the main component, with reiterated versions of the use cases.

ICT

Subsystem grouping

24

ICT

Component identification

Component Infrastructure

BookingEditor BookingViewer

BookingService

ActivityInfo

SubscriptionService

SubscriptionEditor

SubscriptionInfo

ICT

Component structure andinternal design

Use the reference architecture to define components.The following factors might be considered when dividing into components:

Functionality and usage Technology. This includes for instance network, component infrastructure, reference architecture, distribution mechanisms, operating system, data storage frameworks and standards that should be followed.Organization. This might be how the development team is organized or how theend users are organized.Distribution. This includes distribution of people, equipment and systems; both at build time (development environment) and run time (end user environment).Use case actors. Grouping of functionality based on the actors of the use cases.Physical nodes. What nodes are available, and where are the locations.Parallel work. How to subdivide to maximize parallel work, this might be during in build time and/or run time.Non-functional requirements such as availability, performance, security, scalability etc.

25

ICT

Application component (AC) structure

BookingEditor BookingViewer SubscriptionEditor

SubscriptionService

ISubscription

SubscriptionInfo

ISubscriptionInfo

EmailBrowser

BookingService

IBookingService

ActivityInfo

IActivityInfo

INotifyEmailServer

SMTP

POP

Survey Booking AC Subscription Management AC

Existing Email Service

ICT

Component model in RSM

26

ICT

Booking editor tool in RSM

ICT

Interface and interactionspecification

GoalsCapture and describe component interface and interactions.The behaviours of the architectural elements should be understood and described, i.e. how components collaborate.

Methods and techniquesInputs are the Business Model the Requirements Model (including the Reference Architecture Analysis and the work element analysis).In addition the Component Structure and Internal Design defines the component structure and interface dependencies and is obviously an important input to this model.Vice versa the Interface and Interaction Specification is key input to the Component Structure and Internal design as these models forms different viewpoints of the same part of the full model and thus, have to be fully consistent.

27

ICT

Booking editor tool: Component structure

ICT

Booking editor tool:Business resource analysis

Identify the business resources that should be available through the tool by:

Examining theuse casesfor the toolExamining the screen-mockups(developed for the prototype)

Old GUI Prototype GUI

28

ICT

Booking editor tool:Business resource analysis result

ICT

Booking editor tool: User service interface specificationIUserServ ice

+O PERA T ION _A : integer=1

+createSchedule(In subRegionsList [*] string ,In vesselList [*] st ring ,In startT ime:D ate ,In endT ime:D ate):P roject

+imp ortSchedule(In schedule:Project ,In subregionList [*] string ,In vesselList [*] string ,In includeOw nA ctivit ies:boolean ,In includeComp etitorA ctivit ies:boolean):Exp ortResult

+startBrow ser(In scheduleData:Project )+login(In username:string ,In p assword:string ,In url:U RL):LoginStatus+exit ()+hasA ccessRights(In op erat ion:integer):boolean

+getUsername(In loginStatus:LoginStatus):string+isN ew (In scheduleD ata:Project):boolean+isM odified(In scheduleD ata:Project)+checkD irectory (In dir:string):st ring+getScheduleBufferN ames(): [*] string+getScheduleFileNames(): [*] st ring+getScheduleFileNames(In directory :string): [*] string+getSchedule(In name:string):Project+closeSchedule(In scheduleD ata:Project )+getScheduleD irectory (In scheduleD ata:P roject):string+getScheduleFileName(In scheduleD ata:Project):string+op enSchedule(In directory :string):Project+saveSchedule(In directory :string ,In filename:st ring ,In stealLock:boolean):boolean

+mergeSchedule(In schedule:Project ,In data:Exp ortResult ,In localID s [*] string):Project+exp ortSchedule(In schedule:Project ,In localID [*] st ring ,In force:boolean):Exp ortResult

+getCountry List (): [*] O rgU nit+getRegions(): [*] O rgU nit+getCorp orat ionCodes(): [*] OrgU nit+getComp anies(In only Comp etitors:boolean): [*] O rgU nit+getOw nComp any ():O rgUnit+getAllVessels(): [*] OrgU nit+getVessels(In comp any N ame:string): [*] OrgU nit

+createO rgU nit (In scheduleD ata:P roject ,In ty p e:string ,In name:st ring):O rgU nit+createProject(In scheduleD ata:P roject ,In ty p e:string ,In name:string):Project

+getVessels(In comp any N ames [*] string): [*] OrgU nit+createPreferences():ParameterSet+getPreferences():ParameterSet+savePreferences(In data:ParameterSet):boolean

+O PERA T ION _A : integer=1

+createSchedule(In subRegionsList [*] string ,In vesselList [*] st ring ,In startT ime:D ate ,In endT ime:D ate):P roject

+imp ortSchedule(In schedule:Project ,In subregionList [*] string ,In vesselList [*] string ,In includeOw nA ctivit ies:boolean ,In includeComp etitorA ctivit ies:boolean):Exp ortResult

+getVessels(In comp any N ame:string): [*] OrgU nit+getVessels(In comp any N ames [*] string): [*] OrgU nit

+startBrow ser(In scheduleData:Project )+login(In username:string ,In p assword:string ,In url:U RL):LoginStatus+exit ()+hasA ccessRights(In op erat ion:integer):boolean

+getUsername(In loginStatus:LoginStatus):string+isN ew (In scheduleD ata:Project):boolean+isM odified(In scheduleD ata:Project)+checkD irectory (In dir:string):st ring+getScheduleBufferN ames(): [*] string+getScheduleFileNames(): [*] st ring+getScheduleFileNames(In directory :string): [*] string+getSchedule(In name:string):Project+closeSchedule(In scheduleD ata:Project )+getScheduleD irectory (In scheduleD ata:P roject):string+getScheduleFileName(In scheduleD ata:Project):string+op enSchedule(In directory :string):Project+saveSchedule(In directory :string ,In filename:st ring ,In stealLock:boolean):boolean

+mergeSchedule(In schedule:Project ,In data:Exp ortResult ,In localID s [*] string):Project+exp ortSchedule(In schedule:Project ,In localID [*] st ring ,In force:boolean):Exp ortResult

+getCountry List (): [*] O rgU nit+getRegions(): [*] O rgU nit+getCorp orat ionCodes(): [*] OrgU nit+getComp anies(In only Comp etitors:boolean): [*] O rgU nit+getOw nComp any ():O rgUnit+getAllVessels(): [*] OrgU nit

+createO rgU nit (In scheduleD ata:P roject ,In ty p e:string ,In name:st ring):O rgU nit+createProject(In scheduleD ata:P roject ,In ty p e:string ,In name:string):Project

+createPreferences():ParameterSet+getPreferences():ParameterSet+savePreferences(In data:ParameterSet):boolean

29

ICT

Booking service business service: Component structure

BookingService

IBookingService

IActivityInfo

ISubscription

INotify

ICT

Booking service business service:Interface specification

IBookingService

+userName : string+userEMailAddress : string

+importSchedule(In subregionList [*] List(string) ,In vesselList:List(string) ,In startTime:Date ,In endTime:Date ,In existingGlobalIds:Vector ,In companyFilter:CompanyEnum):ExportResult+exportSchedule(In _scheduleProperties:Vector ,In _force:boolean):ExportResult

+userName : string+userEMailAddress : string

+importSchedule(In subregionList [*] List(string) ,In vesselList:List(string) ,In startTime:Date ,In endTime:Date ,In existingGlobalIds:Vector ,In companyFilter:CompanyEnum):ExportResult+exportSchedule(In _scheduleProperties:Vector ,In _force:boolean):ExportResult

<<CompositeData>>ExportResult

GLOBAL_ID : stringLOCAL_ID : stringLAST_UPDATED : stringscheduleProperties : VectorconflictProperties : Vector

GLOBAL_ID : stringLOCAL_ID : stringLAST_UPDATED : stringscheduleProperties : VectorconflictProperties : Vector

30

ICT

PIM4SOA and UPMS

ICT

UPMS standardisation process in OMG

OMG Service Oriented Architecture SIGhttp://soa.omg.org/

UML Profile and Metamodel for Services (UPMS) "SOA" RFPhttp://www.omg.org/cgi-bin/doc?soa/06-09-09

The purpose of the RFP is to address service modelling, not methodologies for SOA

A common vocabulary and metamodel to unify the diverse service definitions that exist in the industry.Clarify UML semantics concerned with services modellingEstablish modelling best practices.Complement existing UML metamodel by defining an extension to UML for servicesIntegrate with and complement standards developed by other organizations such as W3C and OASISSupport a service contract describing the collaboration between participating service consumers and service providersEnable traceability between contract specifications and realization of servicesFacilitate the adoption of SOA through more abstract and platform independent services modelsThe ability to exchange services models between tools using XMI

31

ICT

PIM4SOAMetamodel

Web ServicesMetamodel

Agent Metamodel(AgentMM)

P2PMetamodel

GridMetamodel

PIM

PSM

s

Symbols

Metamodel

Concept

RelationshipCorrespondence

PIM4SOA → platform specific models

ICT

Metamodel for (software) services Metamodel for (automated software) processes

Metamodel for information Metamodel for quality of service (QoS)

PIM4SOA addresses four system aspects

Services are an abstraction and an encapsulation of the functionality provided by an autonomous entity. Service architectures are composed of functions provided by a system or a set of systems to achieve a shared goal.

Web Services Architecture as proposed by W3C (W3C 2004)UML Profile for Enterprise Distributed Object Computing (OMG 2002)

Information is related to the messages or structures exchanged, processed and stored by software systems or software components.

Structural constructs for class modelling in UML 2.0 (OMG 2003)UML Profile for Enterprise Distributed Object Computing (OMG 2002)

Processes describe sequencing of work in terms of actions, control flows, information flows, interactions, protocols, etc.

Business Process Definition Metamodel(BPDM) (IBM et al. 2004)UML Profile for Enterprise Distributed Object Computing (OMG 2002)

Extra-functional qualities that can be applied to services, information and processes.

UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms (OMG 2004)

32

ICT

PIM4SOA: Metamodel for (software) services

ICT

PIM4SOA: Order process

33

ICT

PIM4SOA: Services interfaces

ICT

PIM4SOA: Delivery and invoicing collaborations

34

ICT

PIM4SOA: Furniture procurement collaboration

Three roles “Retailer”,”Manufacturer”“Supplier”

Two usage of collaboration “Goods Supply”“Materials Supply”

Relationshipsbetween role and collaboration use

“RoleBinding”

ICT

PIM4SOA: Goods supply collaboration