sowarearchitecturevo/ku(707.023/707.024)...
TRANSCRIPT
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Service ArchitecturesSo ware Architecture VO/KU (707.023/707.024)
Roman Kern
ISDS, TU Graz
2017-12-06
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 1 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Outline
1 Web Services
2 Web Service Architectures
3 Resource Oriented Architectures
4 Service Oriented Architectures
5 So ware as a Service
6 Microservices
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 2 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Sec on
Web ServicesService Architecture for the Web
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 3 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Web as a database
The Web we use is full of dataBook informa on, opinions, prices, arrival mes, blogs, tags, tweets,etc.
The data is organized around a simple data model: node-link modelEach node is a data item that has a unique address and arepresenta on
Representa on formats are e.g. HTML, PDF,... for humans, or e.gXML, JSON for programs
Nodes can be interlinked using their unique addresses
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 4 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Web as a pla orm for distributed systems
The Web is full of services that allow humans and programs to usethe Web dataServices also have unique addressesThey use a par cular representa on for data exchange, e.g. XML,SOAP, WSDLServices follow a par cular architecture that defines how servicesare usedProgrammers combine a number of services to achieve a desiredfunc onality and create a distributed system, e.g. mashups
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 5 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Types of services
What is the Google search engine?It is a service for querying a massive database (Web search index)
What is a given Web applica on?It is a service offering (remotely) a specific func onality
What is a Web site?It is a service offering specific human consumable informa on
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 6 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Types of services
All of these services are for usersHowever, we are interested in services for programmersSuch services provide an APIProgrammers use the API, unique addresses, representa ons ofservicesProgrammers follow the arch. style to integrate and combineservices to achieve a desired func onalityWe will call this part of the Web: the programmable Web
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 7 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Kind of Things on the Programmable Web
There are numerous approaches to web services in all areasThe programmable Web is based on HTTP for data transport and inmost cases XML or JSON for data representa onHowever, some services serve HTML, plain text, binary data, etc.Also, other things such as addressability or APIs are differentWe need a classifica on!
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 8 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Classifica on based on architectural design
Which opera on should a service execute?This is method informa onWhat data should be manipulated?This is scoping informa on
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 9 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Method informa on
Ques on: how the client conveys its inten on to the server?How does a server know a certain request is a request to retrievesome data?Instead of a request to delete the same data?Why should the server do this instead of doing that
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 10 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Sec on
Web Service ArchitecturesREST & Web-Services
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 11 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Compe ng Architectures
Resource-Oriented Architectures (RESTful)RPC-Style Architectures (SOA)REST-RPC Hybrid Architectures
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 12 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Resource-Oriented Architectures
Resource-Oriented ArchitecturesDescrip ve URLsURLs reflect the applica on stateInherit seman c from HTTP methodsShould be statelessLimited by its simplicity (limited HTTP methods, ...)
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 13 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
RPC-Style Architectures
RPC - Remote Procedure CallAn RPC style service receives an envelope full of data from theclientThe service answers with a similar envelope again full of data tothe clientBoth method and scoping informa on are inside of the envelopeHTTP methods typically POST but some mes also GET
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 14 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
RPC-Style Architectures
The best example of the envelope format is SOAPThere exist other envelope formats like XML-RPCEvery RPC-style service defines a completely new vocabularyE.g. the way how method informa on and scoping informa on arerepresentedYou need another language to define the representa on: e.g.WSDL
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 15 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Problems of RPC-Style Architectures
RPC implies an APIAPIs tend to enforce ght coupling of modules and systemsWe use declara ve XML to describe APIsThis introduces processing overhead
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 16 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
REST-RPC Hybrid Architectures
REST-RPC Hybrid ArchitecturesInherit parts from REST and RPC style architecturesUsed by many Web Site for their API (e.g. Flickr, del.icio.us, ...)
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 17 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Sec on
Resource OrientedArchitectures
Theory Behind REST
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 18 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Resource Oriented Architectures
4 defining features of ROAAddressability: the scoping informa on is kept in the URLUniform interface: the method informa on is kept in the HTTPmethodStatelessness: every HTTP request is isolated from other requestsConnectedness: you link resources into the Web of resources
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 19 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Addressability
Resources are exposed through URLs - an applica on exposes anumber of URLsWhen you have URLs you bookmark, cache responses, chain URLs,...Many Web applica ons do not work this way, i.e. they are notaddressable, e.g. GMail
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 20 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Uniform interface
Standardized HTTP methods: CRUD opera ons (Create, Retreive,Update & Delete)Two principlesSafety: GET only reads dataIdempotence: the same opera on has the same effect whetheryou apply it once or mul ple mes
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 21 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Statelessness
Every request contains all necessary informa onThere is no state managed on the server sideIn fact, there are two kinds of stateYou should dis nguish between the applica on state and resourcestateApplica on state lives on the clientResource state lives on the server
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 22 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Statelessness
When you use a search engine your current query and your currentpage belongs to applica on stateThey are different for every clientResource state is same for every client, i.e. search indexA crawler can update the search index
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 23 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Links and connectedness
Representa ons of resources, i.e. HTML or XML might have linksto other resourcesAxiom for ROA services: Hypermedia as the engine of applica onstateThe current applica on state is not stored on the server as aresource stateIt is tracked by the client as an applica on state and created by thepath that client takes through the Web
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 24 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Links and connectedness
For example http://www.google.com/search?q=jellyfishThe first page is the star ng applica on stateYou have links to other applica on statesObvious for the human Web
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 25 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Links and connectedness
<Buckets><Bucket>
<Name>crummy.com</Name><URL>https://s3.amazonaws.com/crummy.com</URL><CreationDate>...</CreationDate>
</Bucket>...
</Buckets>
Following the link in the URL element takes the client to a newapplica on stateUse links, links, and then use more links, ...
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 26 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Designing ROA
Figure out data setSplit the data set into resourcesThen, for each resourceName the resources with URLsExpose a subset of the uniform interface
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 27 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Designing ROA
Design representa ons accepted from the clientDesign representa ons served to the clientIntegrate this resource into other resources using linksConsider possible applica on statesConsider possible error states
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 28 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Example
Applica on similar google maps: maps of ci es, streets, planets,...Data set: Maps, points, ci es, planets, ....Resources: list of resources, individual resources, results ofalgorithms applied to the data setExample resources: the list of planets, Mars, Earth, San Francisco,Inffeldgasse, ...An algorithmic resource: a list of places that match certain criteria -all ci es with more than 1 million of people
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 29 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Example
Name the resources: create meaningful URLsh p://maps.example.com/Earthh p://maps.example.com/Earth/France/Parish p://maps.example.com/Earth/Austria/Ci esh p://maps.example.com/Earth/Germany/Ci es?pop=1000000
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 30 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Example
Design representa onsA representa on talks about resource stateA representa on links to other (applica on and resource) statesh p://maps.example.com/Earth/Austria→h p://maps.example.com/Earth/Austria/Ci esh p://maps.example.com/Earth/Austria/Ci es→h p://maps.example.com/Earth/Austria/Vienna
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 31 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Read/Write ROA systems
User accounts should be resourcesTo access these resources you need to use HTTP authen ca onh ps://maps.example.com/user/rkernConnect with the previous resources: e.g. custom places on a maph ps://maps.example.com/user/rkern/Earth/Graz/Inffeldgasse/office
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 32 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Method Seman c in ROA systems
The HTTP method implies the seman csUse GET to retrieve (read the content)
GET https://maps.example.com/user/rkern
Use PUT to write (modify the content)PUT https://maps.example.com/user/rkern+ Content
Use DELETE to write (remove the resource)DELETE https://maps.example.com/user/rkern
⇒ limited to the methods supported by HTTP
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 33 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
REST
REST (Representa onal State Transfer)No strict typingTypically XML as data formatConcepts (RESTful) describes constrains: client-server, stateless,cacheable, layered system, code on demand, uniformityNowadays, REST is o en used a umbrella terms for relatedarchitectures
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 34 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
RESTful frameworks
Ruby on Rails with a pluginDjango in PythonRestlet in Java (h p://www.restlet.org/)
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 35 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Sec on
Service Oriented Architectures- SOA
Technological Infrastructure
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 36 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Facts about SOA
SOA is the only thing Chuck Norris can’t kill.SOA invented the internet, and the internet was invented for SOA.The first rule of SOA is you do not talk about SOA.One person successfully described SOA completely, andimmediately died.
Taken from: http://soafacts.com/
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 37 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Mo va on for Services
Loose coupling→ separa on of service and clientService has a contract and a schemaOrchestra on→ a service is part of a bigger systemReuse by language independent and pla orm independentprotocols
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 38 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Components of SOA
Components of SOAServices - basic components which provide func onalityService repository - used for discovery of servicesService bus - interconnect the components of SOAWorkflow engine - o en used in SOA to orchestrate services
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 39 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Standards for Web Services
Standards are managed byTheW3C consor umWS-I, an organisa on to promote the interoperability of webservices (pla orm independent, vendor independent)OASIS (The Organiza on for the Advancement of StructuredInforma on Standards)
WSDL (Web Service Descrip on/Defini on Language) - XMLformat to specify the opera ons of a serviceSOAP (Simple Object Access Protocol) - one-way, statelessprotocol to transfer XML data to a single receiver (since SOAP 1.2there can be more receivers)
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 40 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Standards for Web Services
Addi onal standards (of lesser importance)UDDI (Universal Descrip on, Discovery and Integra on) - registryservice for servicesSAML (Security Asser on Markup Language) - XML basedframework for user authen ca on, descrip on of authoriza ondataXKMS (XML Key Management Specifica on) - management andregistry of public keys
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 41 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Standards for Web Services
Web Services Standards Overview
innoQ Deutschland GmbH innoQ Schweiz GmbHHalskestraße 17 Gewerbestrasse 11D-40880 Ratingen CH-6330 ChamPhone +49 21 02 77 162-100 Phone +41 41 743 [email protected] · www.innoq.com
This
pos
ter
is n
ot t
o be
repr
oduc
ed o
r tr
ansm
itted
in a
ny f
orm
or
for
any
purp
ose
with
out
the
expr
ess
perm
issi
on o
f in
noQ
Deu
tsch
land
Gm
bH.·
Copy
right
©in
noQ
Deu
tsch
land
Gm
bH. A
ll Ri
ghts
Res
erve
d. T
he p
oste
r m
ay a
lso
cont
ain
refe
renc
es t
o ot
her
com
pany
, org
anis
atio
n, b
rand
and
pro
duct
nam
es. T
hese
com
pany
, org
anis
atio
n, b
rand
and
pro
duct
nam
es a
re u
sed
here
in f
or id
entif
icat
ion
purp
oses
onl
y an
d m
ay b
e th
e tr
adem
arks
of
thei
r re
spec
tive
owne
rs.
InteroperabilityIssues
Metadata Specifications Reliability Specifications
Security Specifications TransactionSpecifications
Messaging Specifications SOAP
Management Specifications PresentationSpecifications
Messaging Specifications
WS-Notification
SOAP Message Transmission Optimization Mechanism
SOAP 1.2
SOAP 1.1
WS-Addressing – Core
WS-Addressing – WSDL Binding
WS-Addressing – SOAP Binding
WS-Topics
WS-BrokeredNotification
WS-Eventing
WS-Enumeration
WS-BaseNotification
Met
adat
a
Secu
rity
Res
ourc
e
Metadata SpecificationsWS-Policy
WS-Discovery
WS-PolicyAttachment
WS-MetadataExchange
Universal Description, Discovery and Integration
Web Service Description Language 1.1
Web Service Description Language 2.0 Core
Web Service Description Language 2.0 SOAP Binding
Mes
sagi
ng
Secu
rity
WS-Security
WS-Security: SOAP Message Security
WS-Security: Kerberos Binding
WS-Security: SAML Token Profile
WS-Security: X.509 Certificate Token Profile
WS-Security: Username Token Profile
WS-SecurityPolicy
WS-Trust
WS-Federation
WS-SecureConversation
Security Specifications
Met
adat
a
Mes
sagi
ng
Rel
iabi
lity
Dependencies
Basic Profile1.1
WS-IFinal Specification
� Basic Profile – The Basic Profile 1.1 providesimplementation guidelines for how related set of non-proprietary Web Service specifications should be usedtogether for best interoperability.
Basic Profile1.2
WS-IWorking Group Draft
� Basic Profile – The Basic Profile 1.2 builds on Basic Profile1.1 by incorporating Basic Profile 1.1 errata, requirementsfrom Simple SOAP Binding Profile 1.0, and adding supportfor WS-Addressing and MTOM.
Basic Profile2.0
WS-IWorking Group Draft
� Basic Profile – The Basic Profile 2.0 is an update of WS-IBP that includes a profile of SOAP 1.2.
Basic Security Profile1.0
WS-IBoard Approval Draft
� Basic Security Profile defines the WS-I Basic SecurityProfile 1.0, based on a set of non-proprietary Web servicesspecifications, along with clarifications and amendmentsto those specifications which promote interoperability.
REL Token Profile1.0
WS-IWorking Group Draft
� REL Token Profile is based on a non-proprietary Web services specification, along with clarifications andamendments to that specification which promoteinteroperability.
SAML Token Profile1.0
WS-IWorking Group Draft
� SAML Token Profile is based on a non-proprietary Web services specification, along with clarifications andamendments to that specification which promoteinteroperability.
Conformance ClaimAttachment Mechanism (CCAM)
1.0WS-I
Final Specification
� Conformance Claim Attachment Mechanism (CCAM)catalogues mechanisms that can be used to attach WS-IProfile Conformance Claims to Web services artefacts(e.g., WSDL descriptions, UDDI registries).
Reliable AsynchronousMessaging Profile (RAMP)
1.0WS-I
Working Draft
� Reliable Asynchronous Messaging Profile (RAMP) is aprofile, in the fashion of the WS-I profiles, that enables,among other things, basic B2B integration scenarios usingWeb services technologies.
� XML – Extensible MarkupLanguage is a pared-downversion of SGML, designedespecially for Webdocuments. It allows one tocreate own customized tags,enabling the definition,transmission, validation, andinterpretation of databetween applications andbetween organizations.
� XML – Extensible Markup Language is a pared-downversion of SGML, designedespecially for Webdocuments. It allows one tocreate own customized tags,enabling the definition,transmission, validation, andinterpretation of databetween applications andbetween organizations.
� Namespaces in XMLprovides a simple methodfor qualifying element andattribute names used in XMLdocuments by associatingthem with namespacesidentified by IRI references.
� XML Information Set is an abstract data set toprovide a consistent set ofdefinitions for use in otherspecifications that need torefer to the information in a well-formed XMLdocument.
� XML Schema – XMLSchema Definition Languageis an XML language fordescribing and constrainingthe content of XMLdocuments.
� XML binary OptimizedPackaging (XOP) is an XMLlanguage for describing andconstraining the content ofXML documents.
WS-Security1.1
OASISOASIS-Standard
WS-Security: Username Token Profile
1.1OASIS
Public Review Draft
� WS-Security is a communications protocol providing ameans for applying security to Web Services.
WS-Security: SOAP Message Security
1.1OASIS
Public Review Draft
� WS-Security: SOAP Message Security describesenhancements to SOAP messaging to provide messageintegrity and confidentiality. Specifically, this specificationprovides support for multiple security token formats, trustdomains, signature formats and encryption technologies.The token formats and semantics for using these aredefined in the associated profile documents.
WS-Security:Kerberos Binding
1.0Microsoft, IBM, OASIS
Working Draft
WS-Security: X.509Certificate Token Profile
1.1OASIS
Public Review Draft
� WS-Security: X.509 Certificate Token Profile describesthe use of the X.509 authentication framework with theWS-Security: SOAP Message Security specification.
� WS-Security: Username Token Profile describes how a Web Service consumer can supply a Username Token as ameans of identifying the requestor by username, andoptionally using a password (or shared secret, etc.) toauthenticate that identity to the Web Service producer.
WS-SecurityPolicy1.1
IBM, Microsoft, RSA Security, VeriSign
Public Draft
� WS-SecurityPolicy defines how to describe policies related to various features defined in the WS-Security specification.
WS-TrustBEA Systems, Computer Associates, IBM, Layer 7
Technologies, Microsoft, Netegrity, Oblix,OpenNetwork, Ping Identity Corporation,
Reactivity, RSA Security, VeriSign and WestbridgeTechnology · Initial Draft
WS-Security: SAML Token Profile
1.1OASIS
Public Review Draft
� WS-Security: SAML Token Profile defines the use ofSecurity Assertion Markup Language (SAML) v1.1 assertionsin the context of WSS: SOAP Message Security includingfor the purpose of securing SOAP messages and SOAPmessage exchanges.
WS-Federation1.0
IBM, Microsoft, BEA Systems, RSA Security, and VeriSign
Initial Draft
� WS-Federation describes how to manage and broker thetrust relationships in a heterogeneous federatedenvironment including support for federated identities.
WS-SecureConversationBEA Systems, Computer Associates, IBM,
Layer 7 Technologies, Microsoft, Netegrity,Oblix, OpenNetwork,
Ping Identity Corporation, Reactivity, RSA Security, VeriSign and Westbridge
Technology ·Public Draft
� WS-SecureConversation specifies how to manage andauthenticate message exchanges between parties includingsecurity context exchange and establishing and deriving session keys.
WS-PolicyAssertions1.1
BEA Systems, IBM, Microsoft, SAP
Public Draft
WS-Policy1.5
W3CWorking Draft
WS-PolicyAttachment1.2
W3CW3C Member Submission
WS-DiscoveryMicrosoft, BEA Systems, Canon,
Intel and webMethodsDraft
WS-MetadataExchange1.1
BEA Systems, Computer Associates, IBM, Microsoft, SAP, Sun Microsystems and
webMethodsPublic Draft
� WS-Policy describes the capabilities and constraints of the policies on intermediaries and endpoints (e.g. businessrules, required security tokens, supported encryptionalgorithms, privacy rules).
� WS-PolicyAssertions provides an initial set of assertionsto address some common needs of Web Servicesapplications.
� WS-PolicyAttachment defines two general-purposemechanisms for associating policies with the subjects towhich they apply; the policies may be defined as part of existing metadata about the subject or the policies may be defined independently and associated through an external binding to the subject.
� WS-Discovery defines a multicast discovery protocol fordynamic discovery of services on ad-hoc and managednetworks.
� WS-MetadataExchange enables a service to providemetadata to others through a Web services interface. Givenonly a reference to a Web service, a user can access a set of WSDL /SOAP operations to retrieve the metadata thatdescribes the service.
Universal Description,Discovery and Integration (UDDI)
3.0.2OASIS
OASIS-Standard
� Universal Description, Discovery and Integration (UDDI)defines a set of services supporting the description and discovery of businesses, organizations, and other Webservices providers, the Web services they make available,and the technical interfaces which may be used to accessthose services.
Management Of Web Services (WSDM-MOWS)
1.0OASIS
OASIS-Standard
WS-ManagementAMD, Dell, Intel, Microsoft and Sun
MicrosystemsPublished Specification
Management Using WebServices (WSDM-MUWS)
1.0OASIS
OASIS-StandardWeb Services for Remote
Portlets (WSRP)2.0
OASISCommittee Draft
� Web Service Distributed Management: Management OfWeb Services (WSDM-MOWS) addresses management ofthe components that form the network, the Web servicesendpoints, using Web services protocols.
� WS-Management describes a general SOAP-basedprotocol for managing systems such as PCs, servers,devices, Web services and other applications, and othermanageable entities.
Service Modeling LanguageIBM, BEA, BMC, Cisco, Dell, HP, Intel,
Microsoft, SunDraft Specification
� Servcie Modeling Language (SML) is used to modelcomplex IT services and systems, including their structure,constraints, policies, and best practices.
� Web Service Distributed Management: Management UsingWeb Services (WSDM-MUWS) defines how an IT resourceconnected to a network provides manageability interfacessuch that the IT resource can be managed locally and fromremote locations using Web services technologies.
� Web Services for Remote Portlets (WSRP) defines a set of interfaces and related semantics which standardizeinteractions with components providing user-facingmarkup, including the processing of user interactions withthat markup.
Web Service DescriptionLanguage 2.0 Core
2.0W3C
Candidate Recommendation
Web Service DescriptionLanguage 1.1
1.1W3CNote
Web Service DescriptionLanguage 2.0 SOAP Binding
2.0W3C · Working Draft
� WS-Business Activity provides the definition of the business activitycoordination type that is to be used with the extensible coordinationframework described in the WS-Coordination specification.
WS-Coordination1.1
OASISWorking Draft
� WS-Atomic Transaction defines protocols that enable existingtransaction processing systems to wrap their proprietary protocolsand interoperate across different hardware and software vendors.
� WS-Coordination describes an extensible framework for providingprotocols that coordinate the actions of distributed applications.
WS-Composite ApplicationFramework (WS-CAF)
1.0 · Arjuna Technologies, Fujitsu, IONA,Oracle and Sun Microsystems
Committee Specification� WS-Composite Application Framework (WS-CAF) is a
collection of three specifications aimed at solving problemsthat arise when multiple Web Services are used in combina-tion. It proposes standard, interoperable mechanisms formanaging shared context and ensuring business processesachieve predictable results and recovery from failure.
WS-Context (WS-CTX)1.0
Arjuna Technologies, Fujitsu, IONA, Oracleand Sun Microsystems
Committee Draft
� WS-Context (WS-CTX) is intended as a lightweight mechanismfor allowing multiple Web Services to share a common context.
WS-Coordination Framework (WS-CF)
1.0 · Arjuna Technologies, Fujitsu, IONA,Oracle and Sun Microsystems
Committee Draft� WS-Coordination Framework (WS-CF) allows the
management and coordination in a Web Services interactionof a number of activities related to an overall application.
WS-Transaction Management (WS-TXM)
1.0 · Arjuna Technologies, Fujitsu, IONA,Oracle and Sun Microsystems
Committee Draft� WS-Transaction Management (WS-TXM) defines a core infrastructure
service consisting of a Transaction Service for Web Services.
WS-Business Activity1.1
OASISWorking Draft
WS-Atomic Transaction1.1
OASISCommittee Draft
ResourceSpecifications
SOAP Message Transmission Optimization
Mechanism (MTOM)1.0 · W3C
Recommendation
SOAP1.2
W3CRecommendation
SOAP1.1
W3CNote
XML 1.11.1
W3CRecommendation
XML 1.01.0
W3CRecommendation
Namespaces in XML1.1
W3CRecommendation
XML Information Set1.0
W3CRecommendation
XML Schema1.1
W3CWorking Draft
XML binary OptimizedPackaging (XOP)
1.0W3C
Recommendation
� Describing Media Contentof Binary Data in XML(DMCBDX) specifies how toindicate the content-typeassociated with binaryelement content in an XMLdocument and to specify, inXML Schema, the expectedcontent-type(s) associatedwith binary elementcontent.
Describing Media Contentof Binary Data in XML
(DMCBDX)W3CNote
XML Specifications
� WS-Trust describes a framework for trust models that enablesWeb Services to securely interoperate. It uses WS-Security basemechanisms and defines additional primitives and extensionsfor security token exchange to enable the issuance anddissemination of credentials within different trust domains.
� WS-Security: Kerberos Binding defines how to encodeKerberos tickets and attach them to SOAP messages. Aswell, it specifies how to add signatures and encryption to theSOAP message, in accordance with WS-Security, which uses and references the Kerberos tokens.
WS-Addressing – Core1.0
W3CRecommendation
WS-EventingW3C
Public Draft
� WS-Addressing – Coreprovides transport-neutralmechanisms to addressWeb services and messages.This specification definesXML elements to identifyWeb service endpoints andto secure end-to-endendpoint identification inmessages.
WS-Addressing – WSDLBinding
1.0W3C
Candidate Recommendation
� WS-Addressing – WSDLBinding defines how theabstract properties definedin Web Services Addressing– Core are described usingWSDL.
WS-Addressing – SOAP Binding
1.0W3C
Recommendation
� WS-Addressing – SOAPBinding provides transport-neutral mechanisms toaddress Web services andmessages.
� WS-BaseNotificationstandardizes the terminology,concepts, operations, WSDLand XML needed to expressthe basic roles involved inWeb services publish andsubscribe for notificationmessage exchange.
WS-EnumerationSystinet, Microsoft, Sonic Software, BEA
Systems and Computer Associates
Public Draft
� WS-Enumeration describes a general SOAP-basedprotocol for enumerating a sequence of XMLelements that is suitablefor traversing logs, messagequeues, or other linearinformation models.
WS-Notification1.3
OASISOASIS-Standard
� WS-Notification is afamily of related whitepapers and specificationsthat define a standard Web services approach tonotification using a topic-based publish/subscribepattern.
WS-BaseNotification1.3
OASISOASIS-Standard
� WS-Eventing defines abaseline set of operationsthat allow Web services toprovide asynchronousnotifications to interestedparties.
WS-Topics1.3
OASISOASIS-Standard
� WS-Topics defines threetopic expression dialectsthat can be used as sub-scription expressions insubscribe request messagesand other parts of the WS-Notification system.
WS-BrokeredNotification1.3
OASISOASIS-Standard
� WS-BrokeredNotificationdefines the interface forthe NotificationBroker. A NotificationBroker is anintermediary, which, amongother things, allowspublication of messagesfrom entities that are notthemselves service providers.
� SOAP MessageTransmissionOptimizationMechanismdescribes anabstract feature foroptimizing thetransmission and/orwire format of aSOAP message.
� SOAP is a lightweight,XML-based protocol forexchange of informationin a decentralized,distributed environment.
WS-PolicyAssertions
Vers
ion
3.0
· Feb
ruar
y 20
07
Reliability SpecificationsWS-ReliableMessaging
WS-Reliability
WS-Reliable Messaging Policy Assertion
Tran
sact
ion
Resource SpecificationsWeb Service Resource Framework
WS-BaseFaults
WS-ResourceLifetime
WS-Transfer
Resource Representation SOAP Header Block (RRSHB)
WS-ServiceGroup
Mes
sagi
ng
Secu
rity
Tran
sact
ion
WS-ResourceProperties
Met
adat
a
Secu
rity
Basi
cPr
ofile
Presentation SpecificationsWeb Services for Remote Portlets
Mes
s.
Secu
r.
Relia
b.
Mes
sagi
ng
Secu
rity
Management Specifications
Reso
urce
Met
a
WS-Management
Management Of Web Services
Management Using Web Services
Service Modeling Language
Business Process Specifications
WS-Choreography Model Overview
Web Service Choreography Description Language
Web Service Choreography Interface
Business Process Management Language
Business Process Execution Language for Web Serv. 2.0
XML Process Definition Language
Business Process Execution Language for Web Services
Mes
sagi
ng
Tran
sact
ion
Secu
rity
Rel
iabi
lity
Transaction Specifications
Mes
sagi
ng
Secu
rity
Rel
iabi
lity
Met
adat
a
WS-Composite Application Framework
WS-Transaction Management
WS-Context
WS-Coordination Framework
WS-Business Activity
WS-Atomic Transaction
WS-Coordination
Standards BodiesThe Organization for the Advancement of Structured Information Standards (OASIS) is a not-for-profit, international consortium
that drives the development, convergence, and adoption of e-business standards. Theconsortium produces more Web services standards than any other organization along with stan-dards for security, e-business, and standardization efforts in the public sector and for applica-tion-specific markets. Founded in 1993, OASIS has more than 4,000 participants representingover 600 organizations and individual members in 100 countries.
The World Wide Web Consortium (W3C) was created in October 1994 to lead the World Wide Web to its full potential by developing common protocols that promoteits evolution and ensure its interoperability. W3C has over 350 Member organiza-
tions from all over the world and has earned international recognition for its contributions to thegrowth of the Web. W3C is designing the infrastructure, and defining the architecture and the coretechnologies for Web services. In September 2000, W3C started the XML Protocol Activity to addressthe need for an XML-based protocol for application-to-application messaging. In January 2002, theWeb Services Activity was launched, subsuming the XML Protocol Activity and extending its scope.
The Web Services Interoperability Organization (WS-I) is an open industry organization chartered to promote Web services interoperability across platforms,
operating systems and programming languages. The organization’s diverse community of Webservices leaders helps customers to develop interoperable Web services by providing guidance,recommended practices and supporting resources. Specifically, WS-I creates, promotes andsupports generic protocols for the interoperable exchange of messages between Web services.
The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet.
Attachments Profile1.0
WS-IFinal Specification
� Attachments Profile – The Attachment Profile 1.0complements the Basic Profile 1.1 to add support for interoperable SOAP Messages with attachments-basedWeb Services.
Simple SOAP Binding Profile
1.0WS-I
Final Specification
� Simple SOAP Binding Profile – The Simple SOAP BindingProfile consists of those Basic Profile 1.0 requirementsrelated to the serialization of the envelope and itsrepresentation in the message.
Business Process ExecutionLanguage for Web Services 1.1
(BPEL4WS) · 1.1 · BEA Systems, IBM,Microsoft, SAP,
Siebel Systems · OASIS-Standard
� WS-Choreography Model Overview defines the formatand structure of the (SOAP) messages that are exchanged,and the sequence and conditions in which the messagesare exchanged.
� Business Process Execution Language for Web Services1.1(BPEL4WS) provides a language for the formalspecification of business processes and business interactionprotocols using Web Services.
� Web Service Choreography Interface (WSCI) describeshow Web Service operations can be choreographed in thecontext of a message exchange in which the Web Serviceparticipates.
WS-Choreography ModelOverview
1.0 · W3CWorking Draft
Web Service ChoreographyInterface
(WSCI) · 1.0 · W3CSun Microsystems, SAP, BEA Systems
and Intalio · Note
Business Process Specifications
Business Process ExecutionLanguage for Web Services 2.0
(BPEL4WS) · 2.0OASIS, BEA Systems, IBM, Microsoft, SAP,
Siebel Systems · Committee Draft
� Business Process Execution Language for Web Services2.0 (BPEL4WS) provides a language for the formalspecification of business processes and business interactionprotocols using Web Services.
� Business Process Management Language (BPML)provides a meta-language for expressing businessprocesses and supporting entities.
Business Process ManagementLanguage (BPML)
1.1BPMI.org
Final Draft
� Web Service Choreography Description Language(CDL4WS) is to specify a declarative, XML based languagethat defines from a global viewpoint the common andcomplementary observable behaviour, where messageexchanges occur, and when the jointly agreed orderingrules are satisfied.
Web Service ChoreographyDescription Language
(CDL4WS) · 1.0 · W3CCandidate Recommendation
� XML Process Definition Language (XPDL) provides anXML file format that can be used to interchange processmodels between tools.
XML Process DefinitionLanguage (XPDL)
2.0Final
WS-ReliableMessaging1.1
OASISCommittee Draft
� WS-ReliableMessaging describes a protocol that allowsWeb services to communicate reliable in the presence ofsoftware component, system, or network failures. It definesa SOAP binding that is required for interoperability.
WS-Reliability1.1
OASISOASIS-Standard
� WS-Reliability is a SOAP-based protocol for exchangingSOAP messages with guaranteed delivery, no duplicates,and guaranteed message ordering. WS-Reliability isdefined as SOAP header extensions and is independent ofthe underlying protocol. This specification contains abinding to HTTP.
WS-Reliable Messaging Policy Assertion (WS-RM Policy)
1.1OASIS
Committee Draft
� Web Services ReliableMessaging Policy Assertion(WS-RM Policy) describes a domain-specific policy assertionfor WS-ReliableMessaging that that can be specified withina policy alternative as defined in WS-Policy Framework.
� Web Service Description Language 2.0 Core is an XML-based language for describing Web services and how toaccess them. It specifies the location of the service and theoperations (or methods) the service exposes.
� Web Service Description Language 1.1 is an XML-basedlanguage for describing Web services and how to accessthem. It specifies the location of the service and theoperations (or methods) the service exposes.
� Web Service Description Language SOAP Bindingdescribes the concrete details for using WSDL 2.0 inconjunction with SOAP 1.1 protocol.
WS-BaseFaults (WSRF)1.2
OASISWorking Draft
Web Services Resource Framework (WSRF)
1.2OASIS
OASIS-Standard
WS-ServiceGroup (WSRF)1.2
OASISWorking Draft
� WS-BaseFaults (WSRF) defines a base set of informationthat may appear in fault messages. WS-BaseFaults defines anXML schema type for base faults, along with rules for howthis base fault type is used and extended by Web Services.
� Web Services Resource Framework (WSRF) defines a family ofspecifications for accessing stateful resources using Web Services.
� WS-ServiceGroup (WSRF) defines a means by which WebServices and WS-Resources can be aggregated or groupedtogether for a domain specific purpose.
WS-ResourceProperties1.2
OASISWorking Draft
� WS-ResourceProperties specifies the means by which thedefinition of the properties of a WS-Resource may be declaredas part of the Web Service interface. The declaration of theWS-Resource properties represents a projection of or a viewon the WS-Resource state.
� WS-ResourceLifetime is to standardize the terminology,concepts, message exchanges, WSDL and XML needed tomonitor the lifetime of, and destroy WS-Resources.Additionally, it defines resource properties that may be usedto inspect and monitor the lifetime of a WS-Resource.
� WS-Transfer describes a general SOAP-based protocol foraccessing XML representations of Web service-based resources.
WS-ResourceLifetime1.2
OASISWorking Draft
WS-TransferW3C
W3C Member Submission
Resource RepresentationSOAP Header Block (RRSHB)
W3CRecommendation
� Resource Representation SOAP Header Block (RRSHB)complements MTOM by defining mechanisms fordescribing and conveying non-XML resource representationsin a SOAP 1.2 message.
h p://www.innoq.com/resources/ws-standards-poster/
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 42 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Example of WSDL & SOAP
Defini on of an opera on: GetUserDataThe opera on has an input and an outputThe input is defined via GetUserDataRequestThe output is defined via GetUserDataResponse
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 43 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Example of WSDL
<wsdl><wsdl:operation name="GetUserData">
<wsdl:input message="es:GetUserDataRequest"/><wsdl:output message="es:GetUserDataResponse"/>
</wsdl:operation><xsd:element name="GetUserDataRequest">
<xsd:complexType><xsd:sequence>
<xsd:element name="username" type="string"/><xsd:element name="role" type="string"/>
</xsd:sequence></xsd:complexType>
</xsd:element><xsd:element name="GetUserDataResponse">
<xsd:complexType><xsd:all>
<xsd:element name="email" type="string"/></xsd:all>
</xsd:complexType></xsd:element>
<wsdl>
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 44 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Example of SOAP
<soap:Envelope><soap:Body xmlns:m="http://www.example.org/userdata">
<m:GetUserData><m:email>[email protected]</m:email>
</m:GetUserData></soap:Body>
</soap:Envelope>
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 45 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Orchestra on of Services
How are services interconnected with each other?Applica ons are realized by a combina on of servicesOrchestra on takes care which services interact and whenControl flow can be automated via workflow enginesShould help reuse by loose coupling and flexibility
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 46 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Binding of Services
Development- me binding vs. run me bindingDevelopment- me binding is far simplerThe services, their API and address are fixed during developmentme
Run me binding is more complexThe exact services and addresses are found during run meLookup by service name o en the best approach
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 47 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Discovery of Services
How do I find the service for my needs?UDDI aimed at a lookup service for businesses, organisa on andservicesUDDI as yellow pages for web servicesNo widespread useShould help addressability
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 48 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Service Types
Typical service (component) types in SOA systems:Applica on frontend - typically not a service, ini ate opera onand receive resultsBasic services - they build the founda onIntermediary services - adapters and facades to add func onality,typically statelessProcess centric services - implement the business logic, typicallymanage the process statePublic services - for integra on, higher level func onality
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 49 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
SOA and So ware Architecture
SOA aims to decouple the system from the so ware architectureNo alignment between the system layers and the service layers
system layers: browser, applica on server, web server, opera onsystemservice layers: applica on, process, intermediary, basic
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 50 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Example: Simple SOA Architecture
In the most simple case the SOA architecture consists of two layersThe applica on layer, which uses the basic servicesThe layer for the basic servicesFor example: A web site of an airline
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 51 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Example: Simple SOA Architecture
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 52 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Facade Pa ern
Intermediary services o en serve as facade for basic servicesThey aggregate the func onalityExample for a n- er architecture
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 53 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Example: Facade Pa ern
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 54 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Process-centric Services
Op onal component in SOA systemsProcess-centric services encapsulate process logic and applica onstateAn applica on frontend may delegate the process control to such acomponentAdvantage: reuse when the process-centric services is shared bymul ple clientsDisadvantage: more complex system, process control might besplit into mul ple components
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 55 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Example: Process-centric Services
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 56 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Sec on
SaaSSo ware as a Service
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 57 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
SaaS
SaaS IdeaAn applica on is made available via a service interface. The applica onis hosted by a service provider via the internet (commonly referred to asthe Cloud).
If the service is hosted within an organisa on (instead of the cloud), it iscalled “on premises so ware”.
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 58 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
SaaS
Proper es of SaaSAdvantages: One has not worry about applica on deployment,maintainance, securityDisadvantages: Loose control over the applica on, the serviceprovider may conduct unwanted changesThe billing is o en done on per request basis and low entry pricesExamples: Salesforce.com, Sensium.io
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 59 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Sec on
MicroservicesArchitecture for Enterprise Applica ons
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 60 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Mo va on for Microservices
Tradi onal service architecturesServices has o en been used to decouple the UI from the servercomponentsAnd services have been envisioned to provide high levelfunc onality
MicroservicesExpose finer grained func onali es in form of servicesServices are developed and deployed independently from eachother
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 61 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Microservices Advantages
Advantages of microservicesSmaller services
Easier to maintain and be er learnability
Deployment can be conducted independently for each serviceMore explicit separa on of concernsServices can be developed using different technology stacksImproved fault isola onImplementa ons of services can be swapped
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 62 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Microservices Disadvantages
Disadvantages of microservicesComplexity inherited due to distributed system
Transac on support (very complex or not possible)Use-cases spawning mul ple service are complexHigher latency due to communica on overheadHigher risk or errors due to distributed natureMore computa onal resources needed (e.g. more memory)
Tes ng is more demandingDeployment needs to be conducted for each service
Deployment of mul ple services need to be necessary at the sameme
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 63 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Best prac ces
Limit access to dataHave a single service to manage the dataFor example, instead of two services with two interfaces provide asingle service with two interfaces
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 64 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Example of Cross-Cu ng Concerns
Example of how to tackle cross-cu ng concerns withmicroservices:Logging of informa on, warning, failures, etc.⇒ Log locally, but view globallyEach service uses a local logging func onality, logs are thenaggregated
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 65 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Security with Microservices
Addi onal security considera ons for servicesHow to protected against a acks?Trusted domain vs. securing every serviceTrust domains usually in use for base servicesUse unified security framework
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 66 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Microservices Challenges
Challenges of microservicesWhen does it make sense to switch from monolithic tomicroservices
For small systems the overhead might be too bigIn case the system grows over me, it need to be already bedesigned to allow being split into individual parts/services
Level of granularity of services (might not be clear how to par on)
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 67 / 68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
The EndNext: Architectural styles I
Roman Kern (ISDS, TU Graz) Service Architectures 2017-12-06 68 / 68