Hva er SOA og Web services?

ICT

Hva er SOA og Web services?(SOA: Service-oriented architecture / Tjenesteorientert arkitektur)

Brian Elvesæter, SINTEF IKTAvdeling for samvirkende og tiltrodde systemer, Oslo

[email protected]

NorStella-DND Web services seminar, Oslo, 9. juni09:00-09:30

ICT

Tjenesteorientert arkitektur Web services Oversikt over utviklingen innen EU på dette området? Hvilke krav bør stilles til grunnleggende IT-arkitektur? Hva er hensikten med denne nye teknologien, og hvilke

muligheter åpner seg? Towards an Integrated Enterprise Service Architecture

ICT

Tjenesteorientert arkitektur

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/

Evolution of styles/approaches to designing software systems Data-orientation Functional-orientation Object-orientation Component- and message-orientation Service-orientation

ICT

MS SOA “Definition”

The goal of a SOA is to allow business activities to be orchestrated as components in applications targeting both internal and extra-organizational actors, ultimately enhancing business agility

- Knowledge about the business- What are they?

- Notion of business process

Business and IT alignment: mapping between business activities and components

- Value chains traversal- Beyond the firewall- Cross “trust boundaries”- Autonomous / Independent actors

- Flexibility - “Re-wire” as needed

Andreas S. T. Brunvoll, “From EAI to SOA”,Presentation given at The Roots Conference, April 2005, Bergen

ICT

SOA characteristics

The service concept applies equally well to the business as it does to software applications. Services can be seen as business capabilities that support the enterprise

Services usually represent a business function or domain. Services provide the ‘units of business’ that represent value propositions

within a value chain or within business processes Modular design

Compositions and granularity Services are loosely coupled

From compile-time and deployment-time dependencies to run-time dependencies (services)

Dynamic discovery and binding Services are standardized (“platform independent”)

Using Internet/Web protocols and standards as the common “glue” provide “syntactical interoperability”

ICT

This image cannot currently be displayed.

This image cannot currently be displayed.

System A System DSystem CSystem B

Fra monolittiske systemer til en tjenesteorientert arkitektur

ICT

Web services

ICT

Web service definition

Web service “Applications identified by a URI, whose interfaces and bindings

are capable of being defined, described and discovered as XML artefacts. A Web service supports direct interactions with other software agents using XML-based messages exchanged via Internet-based protocols.” (W3C)

http://www.w3.org/

SOA ~ architectural style Web services stack ~ technology/protocol standards SOA =/= Web services

ICT

The Waves of Client/Server Technology

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

1982 1986 1990 1994 1998 1999 2000 2001 2002 2003

FileServers

DistributedObjects

FirstWave

SecondWave

ThirdWave

OMG CORBACOM/OLEWeb/InternettJava

J2EE/EJBCOM+Corba Comp

Server-sidecomponentsc

MDA, WebServices, .NetService-orientedArchitectureSOAP, XML

WSDL/WSFL

FourthWave

FifthWave

P2PGrid

Agents,FIPA

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

OMG (Object Management Group) OMA (Object Management Architecture)

LifecycleEventsNamingPersistenceTransactionsConcurrency

ExternalizationSecurityTimePropertiesQueryLicensing

ApplicationObjects

HorizontalCORBA Facilities

Object Request Broker (CORBA)

CORBA Services

VerticalCORBA Facilities

ICT

Web services og port 80

Interessen for Web-tjenester har mye av sitt utgangspunkt i problemet for CORBA, MS DCOM og Java RMI med å slippe igjennom for kommunikasjon med ukjente klienter, på grunn av sperrer i brannmurer.

Det ble raskt oppdaget at port 80 (for http Web-browser) kommunikasjon var åpen i de fleste brannmurer, og man begynte å pakke inn informasjon (tunneling) i meldinger som ble sendt gjennom port 80, først innpakket i HTML, deretter i XML.

Dette gav både en teknologi- og markedsmulighet som først Microsoft, deretter IBM var tidlig ute med å utnytte og promotere.

ICT

Web services

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

WS-* stack to-be

Simplified version of the to-be WS-* stack Families of related specs not expanded Competing 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-is

Complete version of the as-is WS-* stack The 3 widely-accepted specs today are the same as 5 years ago Everything else is considered not mature enough Orchestration, discovery and brokering do not exist in today’s world In terms of development process, nothing has changed since CORBA

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-* specifications / metamodels

Registry<<Metamodel>>

+ UDDI.

Endpoint Description<<Metamodel>>

+ WS-MetadataExchange.+ WS-Policy.

+ WS-PolicyAttachement.

Service Interface Description

<<Metamodel>>

+ WSDL 1.1.+ WSDL 2.0.

Reliability<<Metamodel>>

+ WS-ReliableMessaging.Coordination

<<Metamodel>>

+ WS-Coordination.

Eventing<<Metamodel>>

+ WS-BaseNotification.+ WS-BrokeredNotification.

+ WS-Eventing.+ WS-Topics.

Resource Access and Management

<<Metamodel>>

+ WS-Enumeration.+ WS-Resource.

+ WS-ResourceLifetime.+ WS-ResourceProperty.

+ WS-Transfer.

Transport<<Metamodel>>

+ HTTP.

Messaging<<Metamodel>>

+ SOAP.+ WS-Addressing.

XML<<Metamodel>>

+ XML Core / XSD.+ XML Encryption.+ XML Signature.

+ XPATH.

Security<<Metamodel>>

+ WS-Security.

eContract<<Metamodel>>

Composition<<Metamodel>>

ICT

Web Service Description Language (WSDL) XML-based language for describing functional properties of Web

services. A service consists of a collection of message exchange end points. An end point contains an abstract description of a service interface

and implementation binding. The abstract description of a service contains:

(i) definitions of messages which are consumed and generated by the service

(ii) signatures of service operations. The implementation binding provides a means to map abstract

operations to concrete service implementations. It essentially contains information about the location of a binding and the

communication protocol to use (e.g., SOAP over HTTP) for exchanging messages

ICT

WSDL 1.1 metamodelWSDL DocumentWSDL Component

0..10..1

Port+ Name

Operation+ Name

Part+ Name+ Type+ Element

Service

+ Name

1..*1..*

Binding

+ Name

1

1

1

1

Port Type

+ Name11 11

Message+ Name

1..*

0..1

1..*

+input

0..1 0..1+output

0..10..1+fault 0..1

0..*0..*

Import

+ NameSpace+ Location

Include

+ Location

Element+ Name+ BaseType+ MinOccurs+ MaxOccurs

Definition

+ Name+ TargetNameSpace0..*0..*

0..*0..*0..*0..*

0..*0..*

0..*0..*

Schema+ TargetNameSpace

Types

0..10..1

A collection of related endpoints

A single endpoint defined as a combination of a binding and a network address

A concrete protocol and data format specification for a particular port type

An abstract set of operations supported by one or more endpoints

An abstract, typed definition of the data being communicated

An abstract, description of an action supported by the service

A container for data type definitions

ICT

WSDL 2.0 metamodel

Definitions Interface Fault+ name : wsdls_NCName

+ target namespace : wsdls_anyURI

Interface Operation+ name : wsdls_NCName

+ target namespace : wsdls_anyURI+ message exchange pattern : wsdls_anyURI+ style [0..*] : wsdls_anyURI+ safety : wsdls_boolean

Message Reference+ message label : wsdls_NCName

+ direction : wsdls_token+ message content model : wsdls_token

0..*

+message references

0..*Fault Reference

+ message label : wsdls_NCName+ direction : wsdls_token

1+fault reference1

0..*+fault references0..*

Interface+ name : wsdls_NCName

+ target namespace : wsdls_anyURI0..*

+interfaces

0..*

0..*

+extended interfaces

0..*

0..*

+faults

0..*

0..*+operations0..*Binding Fault

1+fault reference

1

Binding Operation

1

+operation reference

1

Binding Message Reference+ message label : wsdls_NCName

+ direction : wsdls_token

0..*+message references

0..*

Service+ name : wsdls_NCName

+ target namespace : wsdls_anyURI

0..*+services 0..*

1+interface

1Binding

+ name : wsdls_NCName+ target namespace : wsdls_anyURI+ type : wsdls_anyURI

0..*

+bindings

0..*

0..1+interface

0..1

0..*+faults

0..*

0..*+operations

0..*

Property+ name : wsdls_anyURI+ required : wsdls_boolean

0..*+properties

0..*

0..*+properties

0..* 0..*+properties0..*0..*+properties0..*

0..*

+properties

0..*

0..*

+properties

0..*

0..*

+properties

0..*0..*

+properties0..*

0..*+properties

0..* 0..*+properties0..*

Feature+ name : wsdls_anyURI+ required : wsdls_boolean

0..*+features

0..*

0..*

+features

0..*

0..*+features

0..* 0..*+features

0..*

0..*

+features

0..*

0..*

+features

0..*

0..*

+features

0..*0..*

+features

0..*0..*

+features0..*0..*

+features0..*

Endpoint+ name : wsdls_NCName+ address : wsdls_anyURI1..*

+endpoints

1..*

1

+binding

1

0..*+properties0..*

0..*+features

0..*

ICT

Oversikt over utviklingen innen EU på dette området

ICT

Interoperability Research

Project type: Network of Excellence (NoE)

Full title: Interoperability Research for Networked Enterprises Applications and Software

Project duration: 3 years Project budget: 12.0 M€ Project funding: 6.5 M€ Partners/contractors: 50 Start date: Nov 1, 2003

Web page: www.interop-noe.org

Project type: Integrated Project (IP)

Full title: Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications

Project duration: 3 years Project budget: 26.5 M€ Project funding: 14.4 M€ Partners/contractors: 19 Start date: Feb 1, 2004

Web page: www.athena-ip.org

ICT

Rationale

System implementation budgetApplication integration license revenue

B$

(Source: the Yankee Group 2001)

Integration40%

Imp. Services

20%

Software10%

Hardware10%

Misc.20%

Interoperability, key to increase competitiveness of enterprises

The cost of non-interoperability are estimated to 40% of

enterprises IT budget.

ICT

Approach

The originality of the project is to take a multidisciplinary approach by merging three research areas supporting the development of Interoperability of Enterprise Applications and Software: Architecture & Platforms: to provide implementation frameworks, Enterprise Modelling: to define Interoperability requirements and to support

solution implementation, Ontology: to identify Interoperability semantics in the enterprise.

Architectures & Platforms

EnterpriseModelling Ontology

Knowledge integration for Interoperability research

INTEROP

ICT 25

ATHENA - Partners• AIDIMA• COMPUTAS• CRF• DFKI• EADS• ESI• FORMULA• FHG/IPK• GRAISOFT• IBM

• IC FOCUS• INTRACOM• LEKS/IASI-CNR• SAP • SIEMENS • SINTEF• TXT• UNI.BORDEAUX I• UNINOVA

Contacts: Rainer RUGGABER; [email protected] PLATTE, [email protected]

ICT

Hvilke krav bør stilles til grunnleggende IT-arkitektur?

ICT

Interoperability point of view Enterprises

Constantly faced with expectations to change Adapt more quickly to changes in the business and economic market Business agility

Current ICT solutions Inflexible and difficult to adapt to meet the requirements of those changing

enterprises Future ICT infrastructures

Need to separate out knowledge from non-interoperable application systems – from application systems to design services

Capture knowledge as formalised models that can be used to configure and adapt the ICT systems

Integration through metamodelling and different views pertinent to stakeholders of an enterprise

Sustainable and inherently adaptive and interoperable infrastructures User-interaction Trust and confidence

SOA and Web services – a step in the right direction

ICT

4-layered view of an enterpriseBusiness Operational Architecture

Enterprise Knowledge Architecture (EKA)

Information and Communication Technology (ICT) Architecture

Sem

antic

s

Laws, rules, principles

Agreed norms and practices

Operations

Enterprise models

Metamodels and languages

Enterprise templates

Strategy

Procedures and routines

Enterprise methodology

Software platforms

EKA servicesBusiness and user services

Modelingtools

Infrastructure services

Management tools

Reference ontology

Ontologytools

Ontologyservices

Ontology methodology

Business terms

Reference architectures

Governance

Product models

ICT

Holistic Approach to Interoperability

To achieve meaningful interoperability between enterprises,interoperability must be achieved on all layers: Business layer: business environment and business processes Knowledge layer: organisational roles, skills and competencies of

employees and knowledge assets Applications, data and communication components Semantics: support mutual understanding on all layers

Application

Data

Business

Knowledge

Application

Sem

antic

s

Business

Knowledge

Sem

antics

Enterprise A Enterprise B

Data

Communication

ICTSystems

Use SOA principlesand Web services tore-architectapplication systems

ICT

8 SOA challenges

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?

Service location. Where should a service be located within the enterprise? Service domain definition. How should services be grouped together into

logical domains? Service packaging. How is existing functionality within legacy mainframe

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

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

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

given standard consistently?

ICT

MDD

GRID

“Adaptive” service-oriented architecture (ASOA)

SOA ASA

ASOA

(Web)Service Agent P2P

ASOA: “Adaptive” service-oriented architectureSOA: Service-oriented architectureASA: Adaptive software architectureMDD: Model-driven developmentPIM: Platform-independent modelPSM: Platform-specific model

GRIDAgent

ASOA

Service

P2P

“PIM”

“PSM”

ICT

Granularity of services

Shared andnetwork-visible

service layer(fine/coarse-grained

reusable services)

User-composableservice layer(use-case-driven

compositionof services)

ab c

r

st

xy

z1

at

zyr

z2

a

Too fine-grained services => Scalability problem (performance)Too coarse-grained services => Adaptability/interoperability problem (flexibility)

Cost, performance, flexibility – choose any two!

ICT

eContract, grey-box, …

Service(consumer)

Service(provider)

eContractMutual agreement

Black-box vs. White-box vs. Grey-box (autonomous)

3rd partyservice

local service

local service

3rd partydependency

ICT

Hva er hensikten med denne nye teknologien, og hvilke muligheter åpner seg?

Towards an Integrated Enterprise Service Architecture

ICT

New mode of collaboration

?

Privateview

Publicview

Business services

Internal services

Enterprise Service Bus

?

Enterprise A

Enterprise X Enterprise Y

Knowledge model

Service

Collaboration space

Composed business services

Shared business model

ICT

Integrated Enterprise Service Architecture

Service infrastructure ATHENA Integrated Execution Infrastructure Infrastructure services

Enterprise services Business services (providing the ‘units’ of business operations) EKA services for managing knowledge assets (including models and

metamodels) MUP services for developing model-generated workplaces

User platforms Model-generated workplaces and Web portals Modelling tools and rich clients

B. Elvesæter, R. K. Rolfsen, F. Lillehagen, D. Karlsen, “Integrated Enterprise Service Architecture”, Paper to be presented at CE 2005, http://www.ce2005.org