Enterprise Application
Integration
4. Service Oriented Architecture
2008/2009
4.1. An Introduction
Paulo Marques
Informatics Engineering Department
University of Coimbra
pmarques@dei.uc.pt
SOA = Service Oriented Architecture
Web Services
Enterprise Service Bus (ESB)

SOA = Service Oriented Architecture
The services on the ESB are: a) thought to be integrated – “service oriented”;
b) registered on a directory server; c) typically orchestrated.
2
SOA


Service Oriented Architecture

A system is made up of autonomous entities (sub-systems)
which act independently of each other. All systems have
interfaces which were thought explicitly for system integration.

Sub-systems have a course granularity (e.g. billing, warehouse,
purchasing, etc.), typically being capable of executing
independently of each other. These subsystems, and in particular
their integration interfaces, are called services.
A possible way of implementing a SOA is using Web
Services and related technologies.
«An SOA is an orchestrated sequence of
messaging, transformation, routing and
processing events in which XML technologies
expose the message content and the
components that operate on the messages.»
3
SOA in a nutshell
System
A
System
B
System
C
System
D
Service
Interface
Service
Interface
Service
Interface
Service
Interface
Enterprise
Service Bus
Process
Orchestrator
Service
Directory
A Service Oriented
Architecture
4
Services != Distributed Objects

Different Deployment Model







Services are “hosted” instead of distributed based on their
computational function
Encapsulation is made at the interface level (business driver) and
not at implementation level
Interception and chaining of services is natural
Routing is performed based on content and context
High level of granularity
High autonomy
Integration Structure


Integration interfaces (services) where thought explicitly for that
Common business models among partners
5
Why use a SOA?

Future, Scalability and Evolution!

An organization is made up of many different systems. Sooner or
later they will have to talk to each other.
(typically, sooner than latter!)

If systems are not thought from the beginning for integration, the
solutions found for doing so will be ad-hoc, without possibility
of evolution, and with high development and maintenance
costs

Using a Service Bus and a Service Oriented Architecture allows for
future evolution, both by easily adding new services and, if
necessary, replacing existing service implementations

A SOA allows to do so with minimal disruption of the business
processes of an organization.
6
The importance of Open Standards

It’s absolutely important that a SOA is based on Open
Standards




It allows the architecture to stay in place on the long-run
Allows external services to be easily integrated into the
organization’s infrastructure
Allows for the substitution of existing systems by better ones (e.g.
better technology, with a lower cost of ownership, or that are
more adequate to the organization’s strategy)
Technologies like XML, HTTP, SOAP e 1st generation Web
Services and 2nd generation WS play a vital role
«It allows applications to bind to services
that evolve and improve over time without
requiring modification to the applications
that consume them»
7
Moving into Services
To
From




Connections = cost
Function oriented
Build to last
Prolonged development

Application silos
Tightly coupled

Object oriented

(c) Microsoft







Connections = value
Process oriented
Build for change
Incrementally deployed
Orchestrated solutions
Loosely coupled
Message oriented
8
Business Process View
Coarse
Grained Web
Service
Operations
Finer Grained
Internal
Service
Operations
Fine Grained
Object and
database calls
Business
Component
Business
Component
Consumer
Application
Business
Process
9
SOA based on Web Services

First Generation Web Services



HTTP, XML, XSD, WSDL, SOAP  Web Services
UDDI
Second Generation Web Services
 Allow for a Service Oriented Architecture
 WS-* Specifications
WS-Routing
WS-Referral
WS-Inspection
WS-Security
WS-Attachments
WS-Coordination
WS-Transaction
WS-SecureConversation
WS-SecurityPolicy
WS-Policy
WS-PolicyAttachment
WS-PolicyAssertions
WS-Addressing
WS-ReliableMessaging
10
What does it look like?
S4
Autonomous systems,
viewed as services
S5
S2
S7
They are capable of
sending and receiving
messages
Orchestration Logic
S1
S8
User Interfaces
UI2
UI3
11
BizTalk Server 2003
12
Enterprise Application
Integration
4. Service Oriented Architecture
2008/2009
4.2. Web Services
Paulo Marques
Informatics Engineering Department
University of Coimbra
pmarques@dei.uc.pt
Web Services?
Warehouse
Java/J2EE
JavaRMI
?$#%$#
?$#%$#
Portal
Billing
CORBA
VB/ASP
DCOM
COBOL
?$#%$#
14
Web Services!
Warehouse
Java/J2EE
WS
SOAP
XML
SOAP
XML
Portal
Billing
WS
VB/ASP


WS
COBOL
SOAP
XML
The first step to have interoperable systems is to based them
on open standards, de facto supported by industry
All systems must be able to talk a common language
15
Web Services

What’s a web service?
«A web service consists in an
application identified by a URI which
can be accessed over the internet
using open standards like SOAP/XML»
16
Evolution of the Web
Connectivity
Presentation
Programmability
1
Browse
the Web
2
Program
the Web
3
17
Web Services

XML


SOAP = Simple Object Access Protocol




Allows to transport XML messages between systems in a simple an
middleware-independent way.
The underlying protocol is normally HTTP. But, others can be used
(SMTP, FTP, ...)
HTTP  Port 80 is good  [Well, sort of... ]
WSDL = Web Services Definition Language


Representing messages using a platform-independent universal
format.
Describes web services (i.e. the service contract)
UDDI = Universal Description, Discovery, and Integration

Directory service which allows to register and discover web services
18
Web Service Model
Service
Registry
FIND
WSDL, UDDI
Service
Requester
Service
Description
2
3
4
BIND
PUBLICATION
WSDL, UDDI
Service
Provider
Service
Service
Description
SOAP
1
(1) Web service is installed
(2) Web service is registered
(3) Client(s) lookup web service
(4) Web service is instantiated (n times), possibly by many clients
19
Web Services Stack?
UDDI
WSDL
SOAP
XML
HTTP/FTP/SMTP
20
SOAP

XML based protocol for
exchange of information



Designed for looselycoupled distributed
computing




Encoding rules for datatype
instances
Convention for representing
RPC invocations
No remote references
Used with XML Schema
Transport independent
SOAP with Attachments
allow arbitrary data to be
SOAP1.1 Message
Structure
SOAP
Envelope
Header
Entries
[Header
Element]
Body
Element
[Fault
Element]
packaged.
21
Node types

SOAP Sender
SOAP Intermediary
Service
Requester
Intermediary
Service
Service
Provider
Three node types: sender nodes, intermediate nodes, receiver nodes



SOAP Receiver
Destination nodes (i.e. intermediate or final nodes) are identified on the
Header of the messages (env:role)
Typical values of env:role are “next” (processed by the intermediate and
final nodes) and “ultimateReceiver” (only processed by the final node)
Messages (payload) exchanged between SOAP nodes can be:



RPC-based (i.e. method invocation)
Document-based (i.e. you send/receive an XML document)
It’s also possible to exchange messages containing BLOBs of binary data
(SOAP Messages with Attachments)
22
Web Services Types

Document/Literal (Wrapped)


Document/Literal (Bare)



Bare is an implementation detail from the Java domain. Neither in
the abstract contract (i.e. wsdl+schema) nor at the SOAP message level
is a bare endpoint recognizable.
A bare endpoint or client uses a Java bean that represents the entire
document payload.
RPC/Literal (Wrapped)



The payload of the SOAP message is an XML document that can be
validated against XML schema. The document itself is represented as
method parameters (Wrapped approach).
With RPC there is a wrapper element that names the endpoint operation.
Child elements of the RPC parent are the individual parameters. It’s
“calling methods” using XML, not passing documents.
Note: there is no complex type in XML schema that could validate the
entire SOAP message payload.
RPC/Encoded

Shouldn’t be used! “SOAP encodeding style is defined by the infamous
chapter 5 of the SOAP-1.1 specification. It has inherent interoperability
issues that cannot be fixed. The Basic Profile-1.0 prohibits this encoding
style”
23
Web Services Types

JBoss extends available web services types to include a
very useful mechanism: direct XML Elements.


“You may come to the point where RPC/literal or Document/literal
is not what you are looking for. This may be the case for instance,
when you want to do the XML processing yourself instead of
deferring it to the SOAP stack. JBossWS offers the possiblity to
setup message style endpoints that do exchange raw XML
documents mapped to DOM elements or SOAPElements”
(JBoss Web Services Guide)
This means that you can pass directly an XML tree created
in memory as parameter.

Called “Message Style Endpoints”
public interface Shop extends Remote
{
public Element getInvoice(Element client)
throws RemoteException;
}
http://labs.jboss.com/jbossws/user-guide/en/html/1.0.4/en/html/getting-started.html
24
SOAP Messages
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetails xmlns="http://warehouse.example.com/ws">
<productID>827635</productID>
</getProductDetails>
</soap:Body>
</soap:Envelope>
Request
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetailsResponse
xmlns="http://warehouse.example.com/ws">
<getProductDetailsResult>
<productName>Toptimate 3-Piece Set</productName>
<productID>827635</productID>
<description>3-Piece luggage set.</description>
<price>96.50</price>
<inStock>true</inStock>
</getProductDetailsResult>
</getProductDetailsResponse>
</soap:Body>
</soap:Envelope>
Response
25
What’s the problem with all this?



Computationally heavy and data heavy!
1 byte of information  many bytes of context
1 byte of information  many CPU cycles of processing
HTTP Request
HTTP Body
XML Syntax
SOAP Envelope
SOAP Body
SOAP Body Block
Textual Integer
Sender
0x0b66
Receiver
26
WSDL = Web Services Description Language

Used for describing SERVICE INTERFACES




Which are the SERVICE IMPLEMENTATIONS available



Datatypes used by the web service
What methods are available for invocation
What are the input and output parameters
Which are the endpoints (bindings)
Which are the supported transport protocols
WSDL is the Interface Definition Language of Web
Services
27
What does a WSDL document looks like?

A WSDL document describes





What the service can do
Where it resides
How to invoke it
WSDL are like IDL but lot more
flexible and extensible
Defines binding for SOAP1.1,
HTTP GET/POST and MIME
WSDL1.1 Document
Structure
WSDL
Document
[Types]
{Messages}
{Port Types}
{Bindings}

WSDL descriptions can be made
available from an UDDI registry
{Services}
28
Format of a WSDL document
<definitions>
<types>
<schema></schema>
</types>
<message>
<part></part>
</message>
<portType>
<operation></operation>
</portType>
<binding>
<operation></operation>
</binding>
<service>
<port></port>
</service>
</definitions>
XML-Schema of all data types
Parameters of a service
Listing of available services
Maps services to protocols:
SOAP, HTTP, etc.
The service’s URL
29
WSDL example
<?xml version="1.0" encoding="utf-8"?>
<definitions name=“BookStore" ... > ... </definitions>
<types> <schema> ... </schema> </types>
<message name="ISBN_Number">
<part name="isbn" type="xs:string"/>
</message>
<message name="BookInfo">
<part name="title" type="xs:string"/>
<part name="author" type="xs:string"/>
</message>
<portType name="Catalog">
<operation name="GetBookByISBN">
<input name="isbn_number" message="ISBN_Number"/>
<output name=“result" message="BookInfo"/>
</operation>
</portType>
Data types
Messages
used by the
service
Abstract
service
definition
...
30
WSDL example (2)
<binding name="BookByISBN_SOAP_Binding" type="Catalog">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation>
<soap:operation
soapAction="/GetBookByISBN"/>
<input> <soap:body use="literal"/> </input>
<output> <soap:body use="literal"/> </output>
</operation>
</binding>
Maps the
service into
the HTTP
protocol
<service name="ACME_Book_Service">
<documentation>ACME BOOKS CATALOG</documentation>
<port name="BookByISBN_Port" binding="BookByISBN_SOAP_Binding">
<soap:address location="http://acmebooks.com/webservices"/>
</port>
</service>
Binds the
service
</definitions>
mapping into
an address
endpoint
31
Luckly...

In many cases you don’t need to know the details behind
WSDL. (But some times you do!)

There are tools to automatically generate all the necessary classes
for the target programming language you are using
32
UDDI

A directory service for web services
1.
3.
SW companies, standards bodies, and
programmers populate the registry with
descriptions of different types of
services
Marketplaces, search engines, and
business apps query the registry
to discover services at other
companies
2.
UDDI Business Registry
Businesses populate
the registry with
descriptions of the
services they support
Business
Registrations
4.
Service Type
Registrations
Business uses this data to
facilitate easier integration
with each other over the
Web
33
UDDI (2)

The initial objective was that different organizations and
companies would register their businesses on a central
directory. Other companies looking for functionality would
look them up.

Didn’t happen!


Organizations and companies don’t work that way!
Even so, UDDI is extremely useful when implementing a
SOA. It can serve as a centralized repository for all
services available in an organization!

Easy lookup and orchestration
34
1st Generation Web Services
35
Problems
Interoperability!!!
?
36
Interoperability

With so many specifications (XML, XSD, SOAP, WSDL,
UDDI), it’s really hard to setup a system that is able to
talk with another system on a different platform

Different versions, different implementation, different
interpretations of standards…

Web Services Interoperability
Organization


Supervises the process of having
compatible WS stacks among
players
Strategy: Profiles and Tests
37
WS-I Basic Profile 1.1

A WS stack implementation is compliant with WS-I Basic
Profile 1.1 if it correctly supports:













SOAP 1.1
HTTP/1.1
HTTP State Management Mechanism (RFC2965)
XML 1.0 (2nd Edition)
XML Schema (Part I+II)
WSDL 1.1
UDDI 2.0 (2.04 API, 2.03 Data Structure, 2 XML Schema)
HTTP over TLS (RFC2818)
TLS 1.0
SSL 3.0
X.509 (RFC2459)
... with some extensions and amendments...
WS-I Basic Profile 1.2 was issued on March 2007
38
Suppliers...
39
Enterprise Application
Integration
4. Service Oriented Architecture
2008/2009
4.3. APIs for Web Services
Paulo Marques
Informatics Engineering Department
University of Coimbra
pmarques@dei.uc.pt
APIs for Web Services

For developing web services you can use a number of
platforms, application servers, and APIs





Sun J2EE Application Server
AXIS + Tomcat
BEA WebLogic
Microsoft.NET + IIS
JBoss WS
Seen in SD
We’ll see it as an example...
Recommended for the 2nd assignment
(but not compulsory)
41
A simple web service
Algoritmos.asmx
<%@ WebService Language="C#" Class="Algoritmos" %>
using System;
using System.Web.Services;
public class Algoritmos : WebService
{
[WebMethod]
public int Soma(int a, int b)
{
return a + b;
}
}
42
Example of a web service
Says that the web service
is written in C#
Says which class corresponds to the
web service
<%@ WebService Language="C#" Class="Algoritmos" %>
using System;
using System.Web.Services;
public class Algoritmos : WebService
{
[WebMethod]
public int Soma(int a, int b)
{
return a + b;
}
}
Algoritmos.asmx
43
How to deploy it?

Using MS Internet Information Server (IIS)...

You just have to create a new folder in the IIS web document
directory and copy the file there.
c:\Inetput\wwwroot\Matematica\Algoritmos.asmx
http://localhost/Matematica/Algoritmos.asmx
44
Test it using a web browser...
45
Service Description... (?wsdl)
46
Calling a particular operation...
47
Manually testing the web service
Calling...
Which results
in...
48
tempuri.org?

“tempuri.org” is a temporary namespace. To change it,
define it at the web service level.
<%@ WebService Language="C#" Class="Algoritmos" %>
using System;
using System.Web.Services;
[WebService(Namespace="http://www.dei.uc.pt/Algoritmos")]
public class Algoritmos : WebService
{
[WebMethod]
public int Soma(int a, int b)
{
return a + b;
}
}
49
How can I use the service?


Obviously, the idea is to use the web service from an
application, not through a web browser.
The wsdl.exe application generates the necessary files for
including the service into your code.
50
A simple application that uses the web service...
using System;
public class Somador
{
public static void Main(string[] args)
{
// Cria um objecto que representa o web service no servidor
Algoritmos algoritmos = new Algoritmos();
// Chama o web service e imprime o resultado
int a = ConvertTo.Int32(args[0]);
int b = ConvertTo.Int32(args[1]);
int resultado = algoritmos.Soma(a, b);
Console.WriteLine("O resultado é: {0}", resultado);
}
}
51
Compiling and executing the client application
52
Separate Compilation

Many times, it’s not a good idea to place the web service source code
of the on the document directory of the web server!


You want to pre-compile and deploy it
Steps:




Create a .CS file with the source code of the web service
(Algoritmos.asmx.cs)
Compile this file into a library (DLL)
csc /t:library /out:Algoritmos.asmx.dll Algoritmos.asmx.cs
Create a folder named bin on the web server’s deployment directory and
copy the DLL there
copy Algoritmos.asmx.dll c:\Inetput\wwwroot\Matematica\bin
Remove the class definition from the Algoritmos.asmx file and state that
the correspondign implementation lives in the compiled class
<%@ WebService Language="C#“
Class="Algoritmos,Algoritmos.asmx" %>
53
What’s the problem with this code?
Note: we want to create a web service that keeps track of
how many invocations are being made

using System;
using System.Web.Services;
public class Contador : WebService
{
private int totalPings = 0;
[WebMethod]
public int Ping()
{
return totalPings++;
}
}
In .NET, every time Ping() is called a new object is created to take care
of the request! [Note: the same thing happens in JSP.]
54
The solution...

Since the web service class is derived from WebService, it
inherits some very interesting properties:





Application: Represents the application as a whole. It’s not
associated to any client in particular nor any session.
Context: Encapsulates all information present in the current HTTP
request. In particular, this object contains the information
submitted on current HTTP header and the object to be used as
response.
Server: Represents the server where the request is being
processed. You can find out the name of the machine, current
time, create COM objects, etc.
Session: Represents the current session with the client. A session
corresponds to all the invocations performed by a single client,
since the first invocation takes place until the connection is closed.
User: represents the user currently corrected, containing its
security credentials.
55
So, to save the ping() information...
using System;
using System.Web.Services;
public class Contador : WebService
{
private const int TOTAL_INVOCACOES = “Invocações”;
public Contador() {
if (Application[TOTAL_INVOCACOES] == null)
Application[TOTAL_INVOCACOES] = 0;
}
[WebMethod]
public int Ping()
{
int totalInvocacoes = (int) Application[TOTAL_INVOCACOES];
++totalInvocacoes;
Application[TOTAL_INVOCACOES] = totalInvocacoes;
return totalInvocacoes;
}
}
56
But...
using System;
using System.Web.Services;
public class Contador : WebService
{
private const int TOTAL_INVOCACOES = “Invocações”;
public Contador() {
if (Application[TOTAL_INVOCACOES] == null)
Application[TOTAL_INVOCACOES] = 0;
}
[WebMethod]
public int Ping()
{
int totalInvocacoes = (int) Application[TOTAL_INVOCACOES];
++totalInvocacoes;
Application[TOTAL_INVOCACOES] = totalInvocacoes;
return totalInvocacoes;
}
}
57
You must synchronize your code!
using System;
using System.Web.Services;
public class Contador : WebService
{
private const int TOTAL_INVOCACOES = “Invocações”;
public Contador() {
Application.Lock();
if (Application[TOTAL_INVOCACOES] == null)
Application[TOTAL_INVOCACOES] = 0;
Application.UnLock();
}
[WebMethod]
public int Ping() {
Application.Lock();
int totalInvocacoes = (int) Application[TOTAL_INVOCACOES];
Application[TOTAL_INVOCACOES] = ++totalInvocacoes;
Application.UnLock();
return totalInvocacoes;
}
}
58
To know more...

Service-Oriented Architecture:
A Field Guide to Integrating XML
and Web Services
by Thomas Erl
 Chapter 3

Developing Java Web Services:
Architecting and Developing Secure
Web Services Using Java
by Ramesh Nagappan et. al.
 Chapters 1, 2 and 3
59
Enterprise Application
Integration
4. Service Oriented Architecture
2008/2009
4.4. 2nd Generation Web Services
Paulo Marques
Informatics Engineering Department
University of Coimbra
pmarques@dei.uc.pt
2nd Generation Web Services
61
Needs

HTTP, XML, WSDL, UDDI



Allows to exchange information between endpoints on a platformindependent format
Allows to discover services and their interfaces
But, we need more! We need, at least, to:







Name the endpoints and route messages between them
Have reliability when sending messages
Provide for security
Transactional support
Asynchronous messaging
Metadata for policies and capabilities of systems
Support for binary data
62
Web Services Stack?
Foundation
Transports
63
Web Services Stack
SOAP
SwA ou
WS-Attachments
URI
WS-Addressing
64
How can we do this with SOAP??
WS-Attachments
SOAP with Attachments (SwA)
WS-Addressing
From: A
To: B
Company_Proxy
send_image(“joke.jpg”)
A
B
65
Attachments e WS-Addressing

SOAP with Attachments (SwA):



WS-Attachments:


Used for including binary data in SOAP messages (XML)
Different message parts are encapsulated using MIME
(Multipurpose Internet Mail Extensions)
Same objective as SwA but the encapsulation is done using DIME
(Direct Internet Message Encapsulation)
WS-Addressing:

Specifies how to identify services independently of the transport
protocol
66
SOAP with Attachments
67
SOAP with Attachments (2)
--MIME_boundary
Content-Type: application/xop+xml;
charset=UTF-8;
type="application/soap+xml; action=\"ProcessData\""
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>
<soap:Envelope>
<soap:Body>
<m:photo xmlmime:contentType='image/png'>
<xop:Include href='cid:http://example.org/me.png'/>
</m:photo>
</soap:Body>
</soap:Envelope>
--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/me.png>
// binary octets for png
--MIME_boundary-68
WS-Addressing
<soap:Envelope xmlns:soap="http://www.w3.org/2002/12/soap-envelope"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">
<soap:Header>
<wsa:ReplyTo>
<wsa:Address>http://ws.dei.uc.pt/is/client</wsa:Address>
</wsa:ReplyTo>
<wsa:To>http://ws.dei.uc.pt/is/server</wsa:To>
<wsa:Action>http://ws.dei.uc.pt/is/server/gradeStu</wsa:Action>
</soap:Header>
<soap:Body>
...
</soap:Body>
</soap:Envelope>
69
Web Services Stack
WS-Reliability
ou
WS-ReliableMessaging
70
Let’s consider some problems
WS-ReliableMessaging
WS-Reliability
BankService
transfer(amount, from, to)
invoke(“transfer”, 5000, “joao”, “jose”)
ok
? invoke again
71
WS-ReliableMessaging e WS-Reliability

Objective: to exchange messages asynchronously having
different delivery guaranties


Uses the Header field of SOAP messages



Message identifiers, sequence numbers, response information, etc.
Remember: those fields are optional
Supporters



at-most-once, at-least-once, exactly-once, in-order
WS-ReliableMessaging: BEA + Microsoft + IBM
WS-Reliability: Sun + Oracle  OASIS
Biggest Differences:

WS-ReliableMessaging uses other standards (WS-Security, WSAddressing); WS-Reliability doesn’t.
72
Example of WS-ReliableMessaging
73
Web Services Stack
WS-Atomic WS-Business
WS-Security
WS-Trust
Transaction
Activity
WS-Secure
WS-Security
Conversation
Policy
WS-Coordination
74
So, what happens in this case?
widraw(5000, #4598)
(Application Server)
“Transfer 5000€ from the
CGD account to the MG
account”
(DB Server)
deposit(5000, #7653)
deposit(5000, #7653)
(Application Server)
(DB Server)
75
So, what happens in this case?
WS-Coordination
WS-Transaction
The server cashes after having
taken the money out, but before
the money has been deposited.
What now?
(DB Server)
“Transfer 5000€ from the
CGD account to the MG
account”
deposit(5000, #7653)
(Application Server)
(BD Server)
(DB
76
WS-Coordination and WS-Transaction

For solving this type of issues, it’s necessary to use a distributed
“Two-Phase Commit” protocol.


WS-Coordination: Specifies how to create and propagate context
information to all entities participating in the workflow of web services




Careful: on your DB course you’ve only studied transactions that take
place on a single server
Including asynchronous interactions and over long periods of time
Proposed by BEA, Microsoft and IBM
WS-Transaction: Uses WS-Coordination to support distributed
transactions
WS-Atomic Transaction: Similar semantic to distributed transactions in
database servers (locking during the whole transaction)

WS-Business Activity: Long duration activities. If it’s necessary to abort,
the system takes “compensatory actions” (the system doesn’t lock all
participates during the whole transaction)
77
WS-Coordination
Web service
Web service
Web service
coordinator
(a) central coordination
Web service
Web service
Web service
coordinator
coordinator
coordinator
(b) distributed coordination
78
WS-Coordination (2)
79
WS-AtomicTransaction
Phase 2
Phase 1
Rollback
Aborting
Aborted
Prepare
Active
Committed
Prepared
Commit
Preparing
Prepared
Committing
Ended
ReadOnly
or
Aborted
Coordinator generated
Participant generated
80
Web Services Stack
WS-Security
WS-Secure
Conversation
WS-Trust
WS-Security
WS-Federation
Policy
81
Hum, and what about this?
WS-Security
WS-Secure
Converstation
WS-Trust
WS-Federation
Trust Domain A
Encryption?
Digital Signatures?
Trust Domain B
82
Web Services Security

WS-Security





WS-SecureConversation


Systems want to exchange more than one message. WSSecureConversation establishes a context for exchanging several
messages in a secure way (i.e. session keys, identifiers, timeouts...)
WS-Trust


Basic Security Framework
Message integrity (digital signatures – XMLSIG)
Message confidentiality (encryption – XMLENC)
Propagation of security tokens (typically binary)
Allows to establish trust relationships between different systems
according to management policies
WS-Federation

Allows to use different systems using the same set of credentials (e.g. for
single-sign-on systems)
83
WS-Federation

WS-Federation:




Allows to establish security domains
All systems belonging to a domain are called “federated”
Federated systems can belong to different organizations
Main Objective:

“Single Sign-On” over security domains
Resource
2
2
1
Requestor
…
2
IP/STS
84
Web Services Stack
WS-Metadata
Exchange
WS-Policy
Assertions
WS-Policy
Attachment
WS-Policy
WSDL
85
How to ensure policies?
I will only deposit money on
systems supporting data
encryption and transactions!
I support
transactions
deposit(5000, #7653)
I support
encryption
86
Other WS-Specifications

WS-Policy:


WS-PolicyAttachment:


Offers a syntax for describing policies associated to different web
services (e.g. service requirements, capabilities, preferences, etc.)
Mechanism for associating policies to endpoints
WS-PolicyAssertions:

Mechanism for validating that an endpoint supports a certain
policy
87
Web Services Stack
88
How do I specify this?
89
BPEL

BPEL: Business Process Execution Language for Web
Services




Resulted from merging the proposals of IBM (WSFL) and Microsoft
(XLANG). It’s widely supported by companies, including IBM,
Microsoft, BEA, among others.
Provides means for specifying data workflows between services
and composed business services. It also provides the means to
describe business process interfaces so that they can be reused on
larger systems.
Interconnects partners which publish and remove XML messages
from containers. Business process is the name given to a workflow
that combines partners, containers and activities together.
Business Processes execute on a “process manager”
(e.g Biztalk Server, BEA Weblogic Integration Server).
90
BPEL

In terms of extensibility, the two most important concepts are
encapsulation and composition. A business process has a set of
inputs and outputs. But, internally, the way it achieves its results is
by invoking different web services
91
BPEL (3)

In terms of implementation, a business
process is a workflow


Each step is called an activity
Basic activities:
<invoke> calls a web service
<receive> waits for the invocation of a web
service
<reply> generates a response as a result of a
web service invocation
<wait> suspends the process execution
<assign> copies information
<throw> throws an exception
<terminate> terminates the service
<switch> conditional choice
<while> repetition
(etc.)

It’s supported by visual tools
92
BPEL (4)

Fault Handling (problems)



In general, it’s based on <throw> and <catch>
Also supports compensatory actions
A “compensatory action” allows the programmer to specify
a number of activities that should take place if something
goes wrong. In general, this corresponds to something
that is not recoverable by “normal” actions.

Example: Up to a certain amount, a store has to accept a check as
a form of payment. But, when the check is deposited, the
originator’s bank account may not have any money left! There’s no
automatic process that can be performed to collect the money in
this case. So, a “compensatory action” may correspond to a
notification to the bank manager that he should deal with the
problem by calling the client.
93
BPEL vs. Java

BPELJ: BPEL for Java technology

There are some efforts on standardizing BPEL on top of J2EE. But…
their future doesn’t look bright.

E.g. “JSR 94: Java Rule Engine API”, “JSR 207: Process Definition for
Java”, “JSR 208: JavaTM Business Integration (JBI)”, JBOSS jBPM
94
2nd Generation Web Services?
95
Do not forget: the Header!

All these protocols are typically implemented at the SOAP
header!
<S:Envelope … >
<S:Header>
Addressing
Security
Reliability
<wsa:ReplyTo xmlns:wsa=“>
<wsa:Address>http://business456.com/User12</wsa:Address>
</wsa:ReplyTo>
<wsa:To>http://fabrikam123.com/Traffic</wsa:To>
<wsa:Action>http://fabrikam123.com/Traffic/Status</wsa:Action>
<wssec:Security>
<wssec:BinarySecurityToken
ValueType="wssec:X509v3"
EncodingType=“wssec:Base64Binary">
dWJzY3JpYmVyLVBlc…..eFw0wMTEwMTAwMD
</wssec:BinarySecurityToken>
</wssec:Security>
<wsrm:Sequence>
<wsu:Identifier>http://fabrikam123.com/seq1234</wsu:Identifier>
<wsrm:MessageNumber>10</wsrm:MessageNumber>
</wsrm:Sequence>
</S:Header>
<S:Body>
<app:TrafficStatus xmlns:app="http://highwaymon.org/payloads">
<road>520W</road><speed>3MPH</speed>
</app:TrafficStatus>
</S:Body>
</S:Envelope>
96
Standard or not standard... ?
<soap:Envelope
xmlns:soap="...">
<soap:Header>
<!-- pluggable headers -->
</soap:Header>
<soap:Body>
<!-- payload -->
</soap:Body>
</soap:Envelope>
Ugh???
SOAP Message
97
Advice... 
« (...) Still, the emerging standards stories are
occasionally conflicting and can be confusing.
They’re certainly not ready for prime time. When
applying a pattern, an application developer
should avoid getting bogged down by standards
and stay focused instead on the particular use
cases at hand. (...)
As standards mature, architects are wise to
consider how their use might extend enterprise
integration solutions to broader, less risky, less
costly, and more powerful levels of sophistication »
98
Bibliography

Service-Oriented Architecture:
A Field Guide to Integrating XML
and Web Services
by Thomas Erl
 Chapter 5
 http://www.specifications.ws/

Microsoft’s MSDN site on
Web Services:

http://msdn.microsoft.com/webservices/we
bservices/understanding
99
IMPORTANT NOTICE
YOU ARE FREE TO USE THIS MATERIAL FOR YOUR
PERSONAL LERNING OR REFERENCE, DISTRIBUTE IT
AMONG COLLEGUES OR EVEN USE IT FOR TEACHING
CLASSES. YOU MAY EVEN MODIFY IT, INCLUDING MORE
INFORMATION OR CORRECTING STANDING ERRORS.
THIS RIGHT IS GIVEN TO YOU AS LONG AS YOU KEEP
THIS NOTICE AND GIVE PROPER CREDIT TO THE
AUTHOR. YOU CANNOT REMOVE THE REFERENCES TO
THE AUTHOR OR TO THE INFORMATICS ENGINEERING
DEPARTMENT OF THE UNIVERSITY OF COIMBRA.
(c) 2007 – Paulo Marques, pmarques@dei.uc.pt
100