“Hva er SOA og Web services?”, NorStella and DND seminar, Oslo, Norway, 9 June 2005.

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

2. 




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

3. Tjenesteorientert arkitektur
ICT

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

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

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

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

8. Web services
ICT

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

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

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

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

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

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

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

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

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

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

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

20. 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
+ name : wsdls_NCName
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
+ name : wsdls_NCName
0..*
+ required : wsdls_boolean
Binding Operation
+ target namespace : wsdls_anyURI
+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 label : wsdls_NCName
+ direction : wsdls_token
+ message content model : wsdls_token
Fault Reference
+ message label : wsdls_NCName
+ direction : wsdls_token
0..*
Service
+ name : wsdls_NCName
+ target namespace : wsdls_anyURI
Endpoint
+endpointsname : wsdls_NCName
+
1..* + address : wsdls_anyURI
ICT

21. Oversikt over utviklingen innen EU
på dette området
ICT

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

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

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

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

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

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

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

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

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

31. “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

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

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

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

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

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