Hva er SOA og Web services?

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

Brian Elvesæter, SINTEF IKT
Avdeling for samvirkende og tiltrodde systemer, Oslo
brian.elvesater@sintef.no
NorStella-DND Web services seminar, Oslo, 9. juni
09: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”

- Knowledge about
the business

- What are they?

 The goal of a SOA is to allow
business activities to be orchestrated
as components in applications
targeting both internal and extra-of business
- Notion
process
organizational actors, ultimately
enhancing business agility chains traversal
- Value
Business and IT alignment:
mapping between business
- components
activities andFlexibility
- “Re-wire” as needed

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

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

Fra monolittiske systemer til en
tjenesteorientert arkitektur
This image cannot currently be display ed.

This image cannot currently be display ed.

System A

System B

System C

System D
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
First
Wave

Second
Wave

Third
Wave

Fourth
Wave

Fifth
Wave

MDA, Web
Services, .Net
Server-side
Distributed
Service-oriented
componentsc
Objects
Architecture
J2EE/EJB SOAP, XML
OMG CORBA
COM+
COM/OLE
WSDL/WSFL
Corba Comp
Web/Internett
Agents, P2P
Java

File
Servers

FIPA

1982

1986

1990

1994

Grid

1998 1999 2000 2001 2002 2003

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

ICT

User Interface
Document model
Web interaction

Synchron.
request
Deferred
Synch request

Interaction/Pres
services

XML

Message
Streaming

Multi
Media,
QoS

Event - publish &
subscribe

Workflow
service

User services
(application/process)

System/Use Mngt
Server
Components

Shared Business
Services

Concurrency
service

Naming service
Security
Trading service service

Data services &
Legacy systems
Integration service

Transaction
service
Persistence service
ICT

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

Vertical
CORBA Facilities

Horizontal
CORBA Facilities

Object Request Broker (CORBA)
Lifecycle
Events
Naming
Persistence
Transactions
Concurrency

Externalization
Security
Time
Properties
Query
Licensing

CORBA Services

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

WS-Addressing
WS-Notification
WSDL

SOAP
WS-Coordination
XML
WS-Security

BPEL

WS-CDL

WS-Federation

UDDI

WS-Policy

WS-ReliableMessaging
WS-MetadataExchange
WS-Resource

WS-Transfer

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
WS-Addressing

WS-Notification
WSDL

SOAP
WS-Coordination
XML
WS-Security

BPEL

WS-CDL

WS-Federation

UDDI

WS-Policy

WS-ReliableMessaging
WS-MetadataExchange
WS-Resource

WS-Transfer

ICT

WS-* specifications / metamodels
<<Metamodel>>
Eventing

<<Metamodel>>
Coordination

<<Metamodel>>
Registry
+ UDDI.

<<Metamodel>>
Reliability

+ WS-Coordination.

+ WS-BaseNotification.
+ WS-BrokeredNotification.
+ WS-Eventing.
+ WS-Topics.

+ WS-ReliableMessaging.

<<Metamodel>>
Endpoint Description
+ WS-MetadataExchange.
+ WS-Policy.
+ WS-PolicyAttachement.

<<Metamodel>>
Service Interface
Description
+ WSDL 1.1.
+ WSDL 2.0.

<<Metamodel>>
eContract

<<Metamodel>>
Messaging
+ SOAP.
+ WS-Addressing.

<<Metamodel>>
Security
+ WS-Security.

<<Metamodel>>
Transport
+ HTTP.

<<Metamodel>>
XML
+ XML Core / XSD.
+ XML Encryption.
+ XML Signature.
+ XPATH.

<<Metamodel>>
Composition

ICT

<<Metamodel>>
Resource Access and
Management
+ WS-Enumeration.
+ WS-Resource.
+ WS-ResourceLifetime.
+ WS-ResourceProperty.
+ WS-Transfer.

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 metamodel
WSDL Component

A container
for data
type
definitions

WSDL Document
0..1

Include
+ Location

Import
+ NameSpace
+ Location

A collection of
related
endpoints

0..1

Definition

Element

+ Name
+ TargetNameSpace

+ Name
0..*

+ Name
An abstract, + BaseType
+
typed definitionMinOccurs
+ MaxOccurs
of the data

being
communicated

1..*
Port

0..*

Part

+ Name
0..*

Message
1

+ Name
0..1

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

+ TargetNameSpace

0..*

Service

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

Schema

Types

1
Binding

0..*

0..*

Port Type

+ Name

0..1
+fault 0..1

+ Name
+ Type
+ Element

+output

+input

+ Name
1

1

An abstract set
of operations
supported by
one or more
endpoints

1..*

Operation
+ Name

An abstract,
description of
an action
supported by
the service

ICT

WSDL 2.0 metamodel
+extended interfaces
0..*
Interface
+interfaces+ name : wsdls_NCName
0..* + target namespace : wsdls_anyURI

Definitions

+bindings
0..*

+interface
0..1
1

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

+faults
Interface Fault
0..* target namespace : wsdls_anyURI
+

+fault reference
1

1
+fault reference

0..*

+properties
0..*
+properties
Property
+properties
1
+properties + name : wsdls_anyURI
0..*
+faults
+binding
+ required : wsdls_boolean
0..*
+properties
0..*
Binding Fault
0..*
+properties
+features
+properties 0..*
0..*
+operations0..*
+properties +properties
0..*
0..*
+properties
0..* 0..* 0..*
0..*
+properties
+features
+features
+features0..*
Feature
Interface Operation
+operations
+features
+features
+ name : wsdls_anyURI
0..* +operation reference
0..*
+ required : wsdls_boolean
Binding Operation
+features 0..*
0..*
+ message exchange pattern : wsdls_anyURI
+features +features
0..*
1+ style [0..*] : wsdls_anyURI
+features
+features
0..*
0..* 0..* 0..*
+ safety : wsdls_boolean
+message references
0..*
Binding Message Reference
+ message label : wsdls_NCName
+ direction : wsdls_token

+services

+fault references
0..*
+message references
0..*
Message Reference
+ message content model : wsdls_token

Fault Reference

0..*

Service

Endpoint
+endpointsname : wsdls_NCName
+
1..* + address : wsdls_anyURI

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
Interoperability, key to increase competitiveness of enterprises
 The cost of non-interoperability are estimated to 40% of

enterprises IT budget.
Application integration license revenue

System implementation budget
Misc.
20%

B$

Integration
40%

Hardware
10%
Imp.
Services
20%

Software
10%

(Source: the Yankee Group 2001)

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.
Knowledge integration for Interoperability research
Architectures & Platforms

Enterprise
Modelling

INTEROP
Ontology

ICT

ATHENA - Partners
•
•
•
•
•
•
•
•
•
•

AIDIMA
COMPUTAS
CRF
DFKI
EADS
ESI
FORMULA
FHG/IPK
GRAISOFT
IBM
Contacts:

•
•
•
•
•
•
•
•
•

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

Rainer RUGGABER; rainer.ruggaber@sap.com
Klaus-Dieter PLATTE, kdplatte@platteconsult.com

ICT

25

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 enterprise
Business Operational Architecture
Operations

Strategy

Governance

Laws, rules,
principles

Agreed norms
and practices

Procedures
and routines

Business terms

Enterprise
methodology

Enterprise
models

Enterprise
templates

Metamodels
and languages

Product
models

Reference
architectures

Semantics

Enterprise Knowledge Architecture (EKA)
Ontology
methodology
Reference
ontology

Information and Communication Technology (ICT) Architecture
Business and
user services

Infrastructure
services

EKA services

Ontology
tools

Software
platforms

Modeling
tools

Management
tools

Ontology
services

ICT

Holistic Approach to Interoperability
Enterprise A

ICT
Systems

Application

Knowledge
Application
Data

Data

Semantics

Knowledge

Business
Semantics

Business

Enterprise B

Use SOA principles
and Web services to
re-architect
application systems

Communication

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

“Adaptive” service-oriented architecture
(ASOA)
MDD

“PIM”

ASOA

SOA

ASOA

ASA
“PSM”

Service Agent
(Web)

Service

Agent

P2P

GRID

ASOA: “Adaptive” service-oriented architecture
SOA: Service-oriented architecture
ASA: Adaptive software architecture
MDD: Model-driven development
PIM: Platform-independent model
PSM: Platform-specific model

P2P

ICT

GRID

Granularity of services
User-composable
service layer

a

(use-case-driven
composition
of services)

Shared and
network-visible
service layer
(fine/coarse-grained
reusable services)

a

r

y

a

r
b

c

t

s

t

z

y

x

z1

z2

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, …
eContract
Mutual agreement

Service

Service

(consumer)

(provider)

Black-box vs. White-box vs. Grey-box (autonomous)
local service
3rd party
service
local service

3rd party
dependency

ICT

Hva er hensikten med denne nye
teknologien, og hvilke muligheter
åpner seg?
Towards an Integrated Enterprise Service
Architecture

ICT

New mode of collaboration
Enterprise X

?

Enterprise Y

Collaboration space

?

Composed business services

Shared business model

Business
services

Public
view
Enterprise Service Bus

Internal
services

Private
view
Knowledge model
Service

Enterprise A
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

ICT

Hva er SOA og Web services?

More Related Content

What's hot (11)

Similar to Hva er SOA og Web services? (20)

More from Brian Elvesæter (17)

Recently uploaded (20)

Hva er SOA og Web services?