for CAISE researcherscaise07.idi.ntnu.no/files/SOA_Tutorial.pdf · Enterprise Service Bus...

SOA Mini tutorial, CAISE'07, June 13th, 2007, Trondheim, Norway 1

ICT

Service Oriented Architecture (SOA)- for CAISE researchers -

SOA - same shit, new wrapping, The emperor’s new clothes,

- or where’s the beef ?

Dr. Arne-Jørgen BerreChief Scientist, SINTEF ICT

Cooperative and Trusted systemsOslo, Norway

Phone: +47 9204 7452E.mail: [email protected]

Mini tutorial duringCAISE’07,

Trondheim, NorwayJune 13th, 2007

ICT

OutlinePart I: SOA principles and technologies

The client/server SOA evolution from 1982 to 2007 (25 years of SOA)SOA reference models (OASIS) (2006)Identification, Description, Publication, Discovery, ExecutionWSA and Web service standards (W3C, OASIS) (How!)HTTP, XML, REST, WSDL, UDDI, BPEL, WS-*SCA & SDO – OPEN CSA (26 March 2007)SOA Maturity Model & SOA GovernanceObjects, Components and Services – What’s new ?

Part II: Semantic SOA & ModellingOntologies, Semantic Web Services and SESAThe Conceptual/Semantic modeling evolution from 1982 to 2007 (25 years of CM)SAWSDL – Semantic Annotation of XML and WSDL (April 10th, 2007)Heterogeneous SOA (EDA, P2P, Grid, Agents, …)Enterprise Architecture & SOA (& BPM)BPMN and MDA for SOAUPMS – OMG standard for Service Modeling (June 4th, 2007)Some selected SOA Research challengesCAISE’07 SOA1 and SOA2 sessions – and final panel


ICT

SOA- Business/IT Alignment

ICT

Motivation for SOA

Enterprise• Challenges

– Business agility– Flexibility and adaptability

• Enterprise architecture frameworks+ Holistic approach+ Different views of an

enterprise as related (visual) knowledge models

- Current enterprise architectures are only blueprints

ICT• Challenges

– Inflexible and difficult to adapt

– Enterprise application integration (EAI)Requirements

Enterprises require operationalenterprise architecturesICT solutions must be designed to beinherently interoperable


ICT

Benefits of SOAMain drivers of SOA

to facilitate the manageable growth of large-scale enterprise systems;to facilitate Internet-scale provisioning and use of services; andto reduce costs in organization to organization cooperation.

The value of SOA is thatit provides a simple scalable paradigm for organizing large networks of systems that require interoperability to realize the value inherent in the individual components.

An architect using SOA principles is better equipped to develop systems that are scalable, evolvable and manageable. SOA enables an IT portfolio which is adaptable to the varied needs of a specific problem domain or process architecture.SOA infrastructures are more agile and responsive than one built on an exponential number of pair-wise interfaces and can provide a solid foundation for business agility and adaptability.

ICT

Part I

SOA principles and technologies


ICT

The Waves of Client/Server SOA Technology

Base Source: Client/Server Survival Guide, 1994Robert Orfali, Dan HarkeyOS/2 Edition, VNR Computer library + AJB update 1998, 2004, 2007

1982 1986 1990 1994 1998 2000 2002 2004 2006 2007

FileServersD

atabase Servers

Groupware

TP Monitors

DistributedObjects

FirstWave

SecondWave

ThirdWave

OMG CORBACOM/OLEWeb/InternettJava, ISO RM-ODP

J2EE/EJBCOM+Corba Comp

Server-sidecomponents MDA, Web

Services, .NetSOA(SOAP, XMLWSDL/BPEL)

FourthWave

FifthWave

P2PGrid

Agents,FIPA

SixthWave

RPC

MDE/DSL,Web 2.0OWL,SWSWeb 3.0SESAEDA/CEPHet. SOASCA/SDO

ICT

DeferredSynch request

Naming service

Persistence service

ServerComponents

Message

Transaction service

Concurrencyservice

XML

Synchron.request

Event - publish & subscribe

Data services &Legacy systems

Shared BusinessServices

User services(application/process)

Interaction/Presservices

Trading serviceSecurityservice

Workflowservice

Streaming

Integration service

User InterfaceDocument modelWeb interaction

System/Use Mngt

MultiMedia,QoS


ICT

CORBADynamic API

Naming service

Persistence service

CorbaComponents

(CCM)

Corba MessagingService

Transaction service

Concurrencyservice

XML, IIOPmapping

CORBA ORBw/IDL

Event &Notification

service






+ real-time/min. CORBA+ Firewall + QoS + ...

Workflowservice

ICT

Remote MethodInvocation (RMI, IIOP)

Naming andDirectory Interface

(JNDI)

DatabaseConnectivity

(JDBC+)

Servlets &Java Server Pages + XSL

(Servlets +JSP)

EnterpriseJava Beans

(EJB)

Java MessagingService (JMS)

Transaction API (JTA, JTS)

Connectors(CICS, SAP, ERP)

XML

Java IDL(JMI)

Java Mail &Java Activation

Framework (JMI + JAF)





JINI (Trading)


ICT

Web services and port 80It all started because of the need to have ubiquitous programmatic access across the Internet, and the fact that firewalls prevented use of CORBA IIOP and Java RMI – but tunneling descriptions/requests in HTML/XML through port 80 worked everywhere

Microsoft and IBM took the lead in the further development of technologies around this

ICT

Web services architecture• Web services can be

used to implement service-oriented solutions

• They adhere to the set of roles and operations specified by the service oriented model.

• They have also managed to establish a standardized protocol stack.


ICT

Identification, Description, Publication, Discovery, Execution

- with WSA – Web services Architecture

Identification - URIDescription – XML, WSDL and REST (Static, Dynamic), WS-*Publication – UDDI ?Discovery – UDDI ?Execution – HTTP, BPEL

ICT

Web services – a conceptual view

Underlying Protocols

Messaging Encoding

Business EntitiesWeb Service Interfaces

HTTP/WEB

VANsFTP

SMTP/EMAIL MQ-Series

SOAP

EDI“Binary”

Raw XML ebXML

BPEL____________________________________________________________

EGO-CentricWorkflow ProcessDescription

WSDL____________________________________________________________

(Syntactic) Web Service Interface Description

Bindings and Endpoint Descriptions

WS-CHOR____________________________________________________________

Interaction Sequencing

(Co)Constraints

XSD____________________________________________________________

XML MessageSchemaDefinition


ICT

Web services stack

Technologystack

Conceptualstack

This part of the course focuses on understanding the Web service technologies for messaging, description and composition such as XML, SOAP, UDDI, XSD,

WSDL and WS-BPEL.

ICT


ICT

WS-* stack to-beSimplified version of the to-be WS-* stack

Families of related specs not expandedCompeting spec families not shown“Historical” or abandoned specs not shown

XML

SOAP WSDL

BPEL

WS-CDLWS-Security

WS-Addressing

WS-ReliableMessagingWS-Coordination

WS-Policy

WS-MetadataExchange

WS-Notification

WS-ResourceWS-Transfer

UDDI

WS-Federation

ICT

WS-* stack as-isComplete version of the as-is WS-* stack

The 3 widely-accepted specs today are the same as 5 years agoBPEL and WS-Security is gaining momentumUDDI has been a failure, - from its initial goal of being a global registryNot much has changed since CORBA, however choreography and orchestration –and composition – has become more prominent through BPEL

XML

SOAP WSDL

BPEL

WS-CDLWS-Security

WS-Addressing

WS-ReliableMessagingWS-Coordination

WS-Policy

WS-MetadataExchange

WS-Notification

WS-ResourceWS-Transfer

UDDI

WS-Federation


ICT

IIS, ASP+XML/HTML

Web Transactions?

BTS

IntegrationServer, CICS ,..

XML/XSLT

WSDL




Interaction/PresservicesSOAP

WS SecuritySAML

UDDI-white

- yellow- greenpages

WebServices

HTTP

BPEL4WS

ICT

DeferredSynch request

Naming service

Persistence service

ServerComponents

Message

Transaction service

Concurrencyservice

XML

Synchron.request

Event - publish & subscribe






Process&Workflowservices

Streaming

Integration service

User InterfaceDocument modelWeb interaction

System/Use Mngt

ESB& IntegrationServices

Discovery

UserInteractionServices

InformationServices

BusinessProcessServices


ICT

ICT

WSRPJSR-168

EkstranettIntranettInternett

Fag-system ERP CRM Sak /

Arkiv

Web ServicesXMLSOAPWSDLUDDI

BPEL/Orkestrering BAM

Messaging

Enterprise Service BusRoutingTransformation Adapters

WS-BPELJCA WSIF

Ekstern organisasjon

Web SSO aksess

LDAP- Active Directory- SunOne- Novell- Oracle

Sikkerhet / Identitets-forvaltning

Provisioning

Oracle BPELProcess Manager

Oracle Portal

Oracle Web ServicesManager

COREid Accessand Identity

COREid Provisioning

COREidFederation

Oracle Fusion Middleware

WS-SecurityWS-PolicySAML

Web Services sikkerhet


ICT0 SOA on your terms and our expertise

Software

© 2005 IBM Corporation© 2005 IBM Corporation

App

s &

In

fo A

sset

s

Business Innovation & Optimization Services

Dev

elop

men

tSe

rvic

es

Interaction Services Information Services

Partner Services Access Services

ESB IT S

ervi

ceM

anag

emen

t

Infrastructure Services

Business App Services

Service Oriented Development

Process Services

Portal

App EJBs SAPAdapter

OracleAdapter

DBAccess

FederatedQuery

Community Manager

Business dashboard

IT impacton processes

ICT

SOA reference models


ICT

SOA definition

A set of components which can be invoked, and whose interface descriptions can be published and discovered (W3C).

The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface. (CBDI) (www.cbdiforum.com)

ICT

SOA definitionService-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/


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).

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

SOA Reference architecture – solution view (IBM)

ICT

SOA reference architecture (IBM)


ICT

OASIS Reference Model forService Oriented Architecture 1.0

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.

Limited to a basic SOA model, i.e. no events, etc. …

ICT

Scope of the reference model


ICT

What is an SOAService-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).

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

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.

ICT

SCA - Service Component Architecture

A vendor-, technology-, language-neutral model for the creation of business systems using SOA by the composition and deployment of new and existing service components

SCA/SDO handed over to OASIS for further standardisation in March 2007

OASIS Open Composite Services Architecture (CSA)


ICT

SCA: Simplified Programming Model for SOA

What is SCA:model for assembly of service components into business solutionssimplified component programming model for implementation of services:

Business services implemented in any of a variety of technologies • e.g. EJBs, Java POJOs, BPEL process, COBOL, C++, PHP …

Key Benefits of SCA:Loose Coupling: Components integrate with other components without needing to know how other components are implemented

Loose coupling - KEY requirement for SOAFlexibility: Components can easily be replaced by other components

Flexibility - KEY requirement for SOAServices can be easily invoked either synchronously or asynchronously Composition of solutions: clearly described

Composition of services - KEY requirement for SOAProductivity: Easier to integrate components to form composite application

SCA simplifies development experience for all developers, integrators and application deployers

ICT

WarehouseService

WarehouseComposite

WarehouseBroker

ComponentWarehouseComponent

EventLogComponent

OrderProcessingService

OrderProcessingComponent

EventLogReference

ExternalWarehouse

Reference

PaymentsComponent

PaymentService

AccountsCompositeExternalBanking

Reference

AccountsLedger

Component

Example SCA assembly


ICT

Composite

Composite A

ComponentAService

BindingWeb ServiceSCAJCAJMSSLSB…

BindingWeb ServiceSCAJCAJMSSLSB…

ComponentB

Service- Java interface- WSDL PortType

Reference- Java interface- WSDL PortType

Wire WireWire

Reference

Propertysetting

Properties

ICT

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"

name="bigbank.accountcomposite" >

<service name="AccountService">

<interface.java interface="services.account.AccountService"/>

<binding.ws port="http://www.bigbank.com/AccountService#

wsdl.endpoint(AccountService/AccountServiceSOAP)"/>

<reference>AccountServiceComponent</reference>

</service>

<component name="AccountServiceComponent">

<implementation.java class="services.account.AccountServiceImpl"/>

<property name=“currency”>EURO</property>

<reference name="accountDataService" target="AccountDataServiceComponent"/>

<reference name="stockQuoteService" target="StockQuoteService"/></component>

<component name="AccountDataServiceComponent">

<implementation.java class="services.accountdata.AccountDataServiceImpl"/>

</component>

<reference name="StockQuoteService">

<interface.java interface="services.stockquote.StockQuoteService"/>

<binding.ws port="http://www.quickstockquote.com/StockQuoteService#

wsdl.endpoint(StockQuoteService/StockQuoteServiceSOAP)"/>

</reference>

</composite>


ICT

Demo: Fabric Runtime (SCA 0.95) Overview

JCA…

JMS

HTTP SCA Runtime

“Fabric”Normalized message busComponent lifecycle managementInter-component “wiring”Policy enforcement (binding independent)Monitoring

MDS

UDDI

BPEL Routing Rules Scheduler…

J2EE + Spring

Bindings

Service Engines

ICT

Intents

Intents are abstract specifications of requirements independent of implementation technology or binding. The SCA developer uses intents to specify what he needs independent of deployment details which are added later in the process.For example, he may specify ‘confidentiality’ or ‘reliability’ without specifying:

- How to achieve?- Detailed characteristics?


ICT

Intents (continued)

In fact, he can say a little bit more ---Intents can be qualified – so he can say, for example, ‘confidentiality.transport’ or ‘confidentiality.message’These are called qualified intents.

<intent name="sca:confidentiality“constrains="sca:binding"

<description>Protect messages from unauthorized reading.

</description></intent>

<intent name="sca:confidentiality.transport" />

ICT

Information as a ServiceVirtualizing the IT Infrastructure

Business Processes

Monitoring WorkflowsBusiness Applications

Portals

Composite Applications

Workflows

Rich client

Browser

MobileClients

Information Services

Data & ContentAnalysis Integration

Application Adapters

Quality

SDO SDO

SDO

SDO


ICT

SOA (SCA) is the component modelComponents may be wired togetherSDO DataObjects are the data flowing on wires between Components

SOA and SDO

MyValueModule

SCAMyValue

Web

Web

SCACustomerInfo

ExportMyValue

ImportStockQuote

Other AppsModules

Other AppsModulesSDO SDO

SDO

SDOSDO

ICT

SDO Data Transfer Objects (DTO’s)

Client

ChangeSummary

Data GraphDataObject

: EJB: InvoiceEJB: Customer

JDBC

XPath / XQuery

Local

XML/HTTP

CCI / Proprietary

Data Access Service

RDB

XML DB

Web service

JCA


ICT

SOA Maturity ModelsOpen Group – OSIMM

Gartner Group SOA Maturity ModelSONIC vendor group SOA Maturity Model…

ICT

Silo

Level 1

Services

Level 4

Composite Services

Level 5

VirtualizedServices

Level 6 Level 7

DynamicallyRe-Configurable

ServicesComponentized

Level 3

Integrated

Level 2

Modules Services Process Integration via Services

Dynamic Application AssemblyComponentsObjectsApplications

Structured Analysis & Design

Service OrientedModeling

Service OrientedModeling

Grammar OrientedModeling

Component Based Development

Object OrientedModelingMethods

Function Oriented

ServiceOriented

ServiceOriented

ServiceOriented

Function Oriented

Function Oriented

Business View ServiceOriented

Service Oriented Modeling

Process Integration via Services

Platform Specific

PlatformSpecific Technology Neutral

DynamicSense & Respond

PlatformSpecific

PlatformSpecificInfrastructure

Monolithic Architecture

Emerging SOA Grid Enabled SOA

Dynamically Re-Configurable Architecture

ComponentArchitectureLayered ArchitectureArchitecture SOA

PlatformIndependent

Application Specific Skills Technology Adoption Cultural & behavioral

Transformation Human Service BusIT GovernanceIT TransformationGovernance & Organization

Organizational Transformation

Application specific data solution

LOB wide standardized Data

vocabularies

Flexible Data vocabularies for

expansion

Data vocabularies are Standards

based

Business Data can be shared outside

the Silo.

Data Subject Areas establishedInformation

Enterprise wide standardized Data

vocabularies

Service Foundation Levels

Open Group Service Integration Maturity Model – Matrix 2.1.07


ICT

How is SOA different (1)Object-orientation (OO) vs. service-orientation (SO)

FocusOO: 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 – (but where is it ? ref. part II)

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

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

ICT

The UDDI failure

Web service publicationand discovery

Why ? - Too simplistic, need to move into more comprehensive federated

model management


ICT

UDDI Registry

UDDI Business Registry

3. UBR assigns a programmatically unique identifier to each service and business registration

Marketplaces, search Marketplaces, search engines, and business apps engines, and business apps query the registry to query the registry to discover services at other discover services at other companiescompanies

44..

Service TypeRegistrations

SW companies, standards SW companies, standards bodies, and programmers bodies, and programmers populate the registry withpopulate the registry withdescriptions of different types descriptions of different types of servicesof services

11..

BusinessRegistrationsBusinesses Businesses

populate populate the registry withthe registry withdescriptions of descriptions of the services they the services they supportsupport

22..

Business uses this Business uses this data to facilitate easier data to facilitate easier integration with each integration with each other over the Webother over the Web

55..

Universal Description, Discovery and Integration

ICT

UDDI - Four information types

<businessEntity>name, contacts,description, indentifiers, categories

<businessService> sService> (1..n)

namedescription, categories

<bindingTemplate>(1..n)technical information

<tModel>namedescriptionURL pointers to specificaitons


ICT

Part II

Semantic SOA & Modelling

ICT

The Waves of Semantics/Conceptual Modeling

Base Source: own experience

Ref. more on this during the final CAISE panel on Friday,“ISE research from 1977, in 2007, and how it will be in 2037 “

1976 1983 1987 1996 2004 2007 2010

ER

Data Modeling

Structured Design

ISO CM TR

Object-orientedModeling

FirstWave

SecondWave

ThirdWave

OOAD,OMT

UML, Req.Eng.

Ontologies !OIL, DAML,

OWL,WSMO,

Standards andOntologies

BPMN,UPMS,

FourthWave

FifthWave

NIAM

SixthWave

Unification?

Web 2.0,Web 3.0

The semanticweb

Web 4.0ORMIFIP WG8.1


ICT

PhaseClass

TraditionalSA/SD/ERA

SA-based OO

ERA-based OO

Hybrid SA/ER-based OO

SA - Yordon SD - Page Jones

ERA - Chen ER-Rel.db - 3NF

OO RT SA - Wards

OOA/OOD - Coad/Yordon

OMT - Rumbaugh et. al

Fusion - HP

OOAD - Booch (93 w/C++)

HOOD - ESAOOSD - Wasserman

SD-basert OO

OO-based

RDOOD - Wirfs-Brock et. al

CRC-cards - Cunningham

OOram - Reenskaug et. al

ANALYSIS DESIGN DETAILED DESIGN

OOAD - Martin/Odell

OSDL-92 - CCITT/Bræk et. alOOSE/ObjectOry - Jacobson

Ada(C++)-based

SDL-based OO

UML (96)Booch/OMT/ObjectOry

OOAD methodsOOAD methods

Catalysis, Syntropy, SOMA, OBA, BHS, ...

ICT

Evolution of the UMLEvolution of the UML

Booch ´91

Booch ´93

Unified Method 0.8

UML 1.0

OMT - 2

OMT - 1 OOSE

UML 0.9 & 0.91

OOPSLA ´95

June ´96 & Oct ´96

Submission of UML 1.1 to OMGfor adoption, Sept ´97

Other methods

publicfeedback UML Partners’

Expertise

UML 1.1 (Sept. 1997)

Taskon,SINTEF

UML 1.4UML 2.0

(2004)


ICT

Evolution of OAD methodologies

UML1.0

UML1.1

UML1.2

UML1.3

UML1.4

OMT

Objectory

Booch

UML Components

Catalysis

OOram

KobrA

COMET

UML4EDOC

UML2

Pulse

UP

RUP

Notation

Process 2002

2001

1995-1999

2000

SOMA

ICT

Internet Evolution


ICT

Evolution of the semantic layer vision

ICT

The Tree of Knowledge Technologies (Extended from figure by Top Quadrant)

SAWSDL

EXPRESSISO 15926

CC

WSMO/WSMF

OWL-S


ICT

Semantic Web Service languages

WSDL-S

OWL-S WSMO SWSF

no ontology language andlogic pre-defined

describtion logic(DL)

first-order logic /higher order logic

(FOL / HOL)

sing

le-s

tep

proc

esse

sm

ulti-

step

proc

esse

s

WSDL-S

OWL-S WSMO SWSF

no ontology language andlogic pre-defined

describtion logic(DL)

first-order logic /higher order logic

(FOL / HOL)

sing

le-s

tep

proc

esse

sm

ulti-

step

proc

esse

s

ICT

Web Service Modeling Framework (WSMF)


ICT

From SOA to SESA : Semantically Enabled Service Architectures

+ semantic data integration

+ semantic services

+ semantic processes

ICT

Semantically-Enabled Service-oriented Architecture


ICT

Run-time

SemAnnot

Set#2

InternetSemRec

Rules#2

Local

Software &

Data

SwApp#1

Local

Software &

Data

SwApp#2Sem

AnnotSet#1

SemRec

Rules#1

ReferenceOntology

Semantic annotation Objectives

Reconciliation

Design-time

ICT

SAWSDL - Semantic Annotations for WSDL and XML Schema

W3C Working Draft 10 April 2007

This specification defines a set of extension attributes for the Web Services Description Language and XML Schema definition language that allows description of additional semantics of WSDL components. The specification defines how such semantic annotation is accomplished using references to semantic models, e.g. ontologies

3 constructs: modelReference, liftingSchemaMapping, loweringSchemaMapping


ICT

A Web Service Composition Scenario with Ontology Reasoning

ICT

Semantic SOA: Discovery / SelectionEnterprise SOA Vision

Application Composition basedon existing building blocks (services)Business Process Flexibility

RequirementsDiscovery of appropriate candidate services Selection of the best matching service

An Approach for SolutionSemantic annotation of service capabilities and requestor’ goals

Unambiguous, machine-interpretable formalizationsBusiness context & data ontologies

Advantages(Semi-)automatic discovery of candidate services(Semi-)automatic integration of new servicesSelf-adaptable business processes through automatic selection of services

Service YGoal

Potential candidate

Service X Goal

No match

Discovery

Service Y

Service Z

Potential candidatesConcreteTask

Ranking/Composition

Selection

- examples from SAP research


ICT

Semantic SOA : MediationEnterprise SOA Vision

Application Compositionbased on existing building blocks

RequirementsIntegration of differentservices Mapping between differentmessage formats

An Approach for SolutionSemantic annotation of messageformats using ontologies

Unambiguous, machine-interpretable formalizationsBusiness data ontologies

AdvantagesSemi-automatic creation of necessary transformationsReduced development effortSimplified integration of legacy systems/applications

Business Collaboration OntologyBusiness Collaboration OntologyBusiness Collaboration OntologyPerson

First nameSurnameAddress

AddressStreetCityPostal Code

hasType

ClientClient codeCase worker…

Is a

…<CLT>

<CLTCD>1234</CLTCD><NAME>Joe Doe</NAME> <CITY>WDF</CITY><POCODE>12345<POCODE>

</CLT>…

…<Customer>

<FirstName>Joe</FirstName><SurName>Doe</SurName> <Address>

<City>WDF</City></Address>

</Customer>…

1234

JoeDoe

WDF12345

Sourcemessage

Targetmessage

AutomaticData Mediation

Creating ontology instance from source message

Creating target message instance from ontology instance

Business Collaboration OntologyBusiness Collaboration OntologyBusiness Collaboration OntologyPerson

First nameSurnameAddress

PersonFirst nameSurnameAddress



hasType



Is a

…<CLT>

<CLTCD>1234</CLTCD><NAME>Joe Doe</NAME> <CITY>WDF</CITY><POCODE>12345<POCODE>

</CLT>…

…<Customer>

<FirstName>Joe</FirstName><SurName>Doe</SurName> <Address>

<City>WDF</City></Address>

</Customer>…

1234

JoeDoe

WDF12345

Sourcemessage

Targetmessage

AutomaticData Mediation

Creating ontology instance from source message

Creating target message instance from ontology instance

ICT

Semantic SOA : CompositionEnterprise SOA Vision

Business ProcessFlexibility

RequirementsDefining placeholdersfor process stepsMatching of business contextsDescribing data compatibility

An Approach for SolutionGoals as placeholdersService semantics described by ontologies

Unambiguous, machine-interpretable formalizationsBusiness context & data ontologies (static aspects)Business collaboration ontology (behavioral semantics)

Sales Order Processing

OrderOrder

Business Collaboration OntologyBusiness Collaboration OntologyBusiness Collaboration Ontology

Invoice Processing

InvoiceInvoice

Web Service

Capability I

Capability

Web Service

Capability II

Purchase Order

Processing II

PurchasePurchaseOrder IIOrder II

Purchase Order

Processing I

PurchasePurchaseOrder IOrder I

Goal

Process Matching & Process Matching & MediationMediation

Purchase Order Processing Goal

AdvantagesReasoning allows for automatic composition of processesAutomatic integration of new servicesSelf-adjusting business by using placeholders


ICT

Enterprise architecture and SOA

ICT

BPMI.org Hourglass

Business Environment

Technology Implementation

BP

BPMN

BPEL

Focus Scope

Strategy Consultants

Process Designers

System Architects

Software Engineers

Business Analysts

Audiences: Purposes:

Execution

Modeling


ICT

Core Set of Diagram Elements

The core set of modeling elements enable the easy

development simple Business Process

Diagrams that will look familiar to most Business

Analysts (a flowchart diagram)

ICT

Complete Set of Diagram Elements, Events

An Event is something that “happens” during the course of a business process. These Events affect the flow of the Process and usually have a trigger or a result. They can start, interrupt, or end the flow.


ICT

Complete Set of Diagram Elements, Activities, Cont.

A Sub-Process can be in an expanded form that shows the process details of the a lower-level set of activities.

ICT

Complete Set of Diagram Elements, Gateways

Gateways are modeling elements that are used to control how Sequence Flows interact as they converge and diverge within a Process. If the flow does not need to be controlled, then a Gateway is not needed.


ICT

OMG Model Driven Architecture (MDA)

Platform Independent Model

Platform Specific Model

Executable Code

Transformation

Code Generation

QVTSpecify

Transformations

UMLSpecify

Applications

MOFSpecify

Languages

Computation Independent Model

TransformationBusinessEnterprise

models

Ref. also Microsoft DSL Domain Specific Languages

ICT

Current MDA Architecture with Semantic annotations

CIM/EMmodels

PIMSystemmodels

PSMSystemmodels

System

ADM

QVT

QVT

MOF2Txt

ADM

ADM

Enterprisemodeling

expert

Systemmodeling

expert

Systemrealisationinstallation

expert

Ref.ontology

Semanticannotation

Semanticannotation

Semanticannotation


ICT

UPMS standardisation process in OMGOMG Service Oriented Architecture SIG

http://soa.omg.org/UML Profile and Metamodel for Services (UPMS) "SOA" RFP

http://www.omg.org/cgi-bin/doc?soa/06-09-09The 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

ICT

BPMN example


ICT

UPMS example 1/4

ICT

UPMS example 2/4


ICT

UPMS example 3/4

ICT

UPMS example 4/4


ICT

UPMS (core)

Service Variabilityand Configuration

UPMSWSA/SCA

UPM forSWS/SESA

UPM forAgents

UPM for P2P/Grid/EDA/Components

UPMS-HA

WS, WSMO, OWL-S, JACK, JADE, JXTA, OGSA, J2EE, CORBA

J2EE, SCA, .Net ,…

BPMN BPDM BMM SBVR

PIMs for differentArchitecturalStyles

RealisationTechnologies

PSMModels

CIMBusinessModels

PIMModels

UPMS-HA – UML Profile and Metamodel for Services – for Heterogeneous Architectures

OMG UPMS RFP submission from SINTEF et. al, June 4th, 2007

ICT

UPMS-HA appendixes

Appendix A: UPM for Semantic Web Services - (was Contribution from DERI/Augsburg)

Appendix A: UPM for WSMO (or included above) ? - (was Contribution from DERI)

Appendix A: UPM for WS/P2P/Grid (GeSMO) - (was Contribution from NKUA)

Appendix A: UPM for Agents - (was Contribution from DFKI)

Appendix A: UPM for Event modeling - (was Contribution from DFKI)

Appendix A: UPM for Services (PIM4SOA) - (was Contribution from ESI/SINTEF)

Appendix A: UPM for Services (MID/Augsburg) - (was Contribution from MID/Augsburg)

Appendix A: UPM for Services (SEA) - (was Contribution from Softteam)

Appendix A: UPM for Semantic Interfaces - (was Contribution from SINTEF SIMS)


ICT

SOA Trends and Challenges

ICT

TrendsConsolidation ➪ 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 + SOAInclusion of semantics – towards SESA, Semantically-Enabled Service Architectures


ICT

Ontologies and semantics – what is new ?Not much, - but enough:

Internet as a global infrastructure for sharing of concepts

URI’s will provide unique identifiers for concepts

We can build an infrastructure around this – to provide operational support for semantics

ICT

9 SOA challenges1. Service identification. What is a service? What is the business functionality to be

provided by a given service? What is the optimal granularity of the service? 2. Service location. Where should a service be located within the enterprise? 3. Service domain definition. How should services be grouped together into logical

domains? 4. Service packaging. How is existing functionality within legacy mainframe systems to

be re-engineered or wrapped into reusable services? 5. Service orchestration. How are composite services to be orchestrated? 6. Service routing. How are requests from service consumers to be routed to the

appropriate service and/or service domain? 7. Service governance. How will the enterprise exercise governance processes to

administer and maintain services? 8. Service messaging standards adoption. How will the enterprise adopt a given

standard consistently? 9. Service publication and discovery: How can we find the services we need ?


ICT

8 Selected Service Architecture challengesService-based unification for heterogeneous architectures, including Web services, Grid, P2P, Agents, Sensors and Mobile devicesContext-based Adaptive & self-adaptive systems Dynamic Service Discovery - in heterogeneous architecturesDynamic composition, service choreography and collaborative services – in heterogeneous architectures Semantic service-oriented architectures and semantic services (Ref. semantic web services)Service mediation – dealing with mismatchesScalability in service environmentsCultural, Language, Social and Legal Obstacles in Services-Centric Business Models, “software as a service” (ref. UDDI failure !)

ICT

8 Selected Service Engineering challengesModel Driven Engineering and Domain Specific languages for services and business modelingUnified Process modeling, Service composition, choreography, collaboration and workflow modeling Active and Executable Models – for Simulation and EnactmentModel-based “active” Service level agreements (SLAs)Quality of Service (QoS) and Cost of Service (CoS) and NFA (Security, Performance, Reliability, …) Analysis and Quality assessment support for Service modelsSupport for Security, Privacy and Trust for service computingUnification with the Requirements Engineering and Information System Engineering communities


ICT

CAISE SOA sessionsService Oriented Architecture 1 Session Chair Neil Maiden Wednesday, 1330-1500

Discovering Web Services To Specify More Complete System Requirements, by Zachos, Maiden, Zhu, Jones – page 142 On ISOA Intentional Services Oriented Architecture, by Rolland, Kaabi, Kraiem – page 158 WSXplorer: Searching for Desired Web Services, by Hao, Zhang, Cao- page 173

Service Oriented Architecture 2 Session Chair Neil MaidenWednesday, 1530-1700

Conceptual Modeling of Privacy-Aware Web Service Protocols, by Hamadi, Paik, Benatallah – page 233 Policies for Context-Driven Transactional Web Services, by Maamar, Narendra, Benslimane, Subramanian - page 249 On Automated Generation of Web Service Level Agreements, by Cappiello, Comuzzi, Plebani – page 264

Friday, 1330-1500, ISE research from 1977, in 2007, and how it will be in 2037

for CAISE researcherscaise07.idi.ntnu.no/files/SOA_Tutorial.pdf · Enterprise Service Bus...

Documents

Transcript of for CAISE researcherscaise07.idi.ntnu.no/files/SOA_Tutorial.pdf · Enterprise Service Bus...