27/05/2015

Advanced Web Service Technologies

Dr. Amor Lazzez

Office location: Tarbia Campus (C/ 306)

Phone: 0549071465 (cell)
Email: a.lazzez@gmail.com

502510-3/Systems-Integration
Week 12
Source: These slides are largely prepared based on Chapter 4 from textbook “Service-Oriented Architecture: A Field Guide to
Integrating XML and Web Services” by Thomas Erl

Key and Basic Web service standards

1
1. Use UDDI to search for
services
2
– Use SOAP to access UDDI 3
– Search using key words
2. Download WSDL
document from UDDI for
selected service 4
3. Use URI information from
WSDL document to
invoke the service using
SOAP
4. After the services accepts
your request, then your First Generation
application and the Web Service Standards:
service can exchange WSDL, SOAP, and UDDI
data using SOAP

1
 27/05/2015

High-level Relationships between First- and

Second-Generation Web Service Standards
• Business Processes
– WS-BPEL
• Context and transaction
management
– WS-Coordination and WS-
Transaction
• Security
– WS-Security
• Reliable messaging
– WS-Reliable Messaging
• Policies
– WS-Policy

WS-BPEL Specifications

2
 27/05/2015

Business Processes
• Business Processes not only play a key role in Business-to-
Business (B2B) and Enterprise Application Integration (EAI)
scenarios by exposing the appropriate invocation and
interaction patterns but they are the fundamental basis for
building heterogeneous and distributed applications
(workflow-based applications).
• In order to compose Web services into a structured workflow,
a standard vocabulary is required.
• WS-BPEL provides a process description vocabulary that can
be compiled into runtime scripts, executable by middleware
products that support orchestration.
• WS-BPEL along with other business process vocabularies,
brings Web services into the realm of systems integration.

WS-BPEL Specification
• Web Services Business Process Execution Language (WS-
BPEL) provides the language to specify business processes
that are composed of Web services as well as exposed as
Web services.
• Business Processes specified via WS-BPEL are portable;
they can be carried out by every WS-BPEL compliant
execution environment.
• BPEL processes can automate both simple and complex
interactions between Web services
– Supporting business transactions
– Correlating message exchanges
– Implementing parallel processing of activities
– Mapping data between partner interactions
– Providing consistent exception and recovery handling

3
 27/05/2015

BPEL Historical Timeline

• BPEL is the Web Services Orchestration standard from OASIS
– http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
• December 2000
– Microsoft publishes XLANG
• March 2001
– IBM publishes WSFL
• July 2002
– IBM, Microsoft and BEA converge WSFL & XLANG into BPEL4WS 1.0
• March 2003
– BPEL4WS is submitted to OASIS
• May 2003
– OASIS publishes BPEL4WS 1.1
• April 2007
– WS-BPEL 2.0 released

WS-BPEL Language Structure

• Process
• Partner links
• Data handling
• Properties and correlation
• Basic and structured activities
• Scopes

4
 27/05/2015

WS-BPEL Process Definition

process
Declare dependencies on Declare namespaces of
external XML Schema or WS-BPEL extension
WSDL definitions imports extensions attributes and elements

Relationships that a WS- Relationship between

BPEL process will employ partner message inbound and outbound
in its behavior links exchanges message activities

Data holding state of a Application data fields

correlation
business process or variables that together identify a
sets
exchanged with partners conversation

Concurrently process
event fault Deal with exceptional
inbound messages or
handlers handlers situations in a process
timer alarms

Perform the process logic primary

– any number of activities activity
may be recursively
nested

Basic Activities
process

Do a blocking wait for a Immediately terminate

matching message to arrive / receive reply exit execution of a business
send a message in reply process instance
Invoke compensation on
Invoke a one-way or invoke compensate all completed child scopes
request-response operation in default order

Update the values of Invoke compensation on

assign compensateScope
variables or partner links one completed child scope
with new data
Validate XML data stored Wait for a given time
validate wait period or until a certain
in variables
time has passed

Generate a fault from inside throw empty No-op instruction for

the business process a business process

Forward a fault from inside Wrapper for language

rethrow extensionActivity
a fault handler extensions

5
 27/05/2015

Structured Activities
process

Contained activities are flow pick Block and wait for a

executed in parallel, A suitable message to arrive
partially ordered through
B C M1 M2 … A (or time out)
control links

Contained activities are sequence forEach Contained activity is

performed sequentially in performed sequentially or
lexical order 1. 2. … N. 1. 2. … N. in parallel, controlled by a
specified counter variable

Contained activity is while if-elseif-else Select exactly one branch

repeated while a predicate of activity from a set of
c1 c2
holds c … choices

Contained activity is repeatUntil scope Associate contained activity

repeated until a predicate with its own local variables,
holds c partner links, etc.,
and handlers

Nesting Structured Activities

sequence
<sequence>
<receive .../>
receive
<flow>
<sequence> flow

<invoke .../>
sequence sequence
<while ... >
<assign>...</assign>
</while> invoke receive

</sequence>
<sequence> while invoke
<receive .../>
<invoke ... /> assign
</sequence>
</flow>
<reply .../>
reply
</sequence>

6
 27/05/2015

Scopes
Scopes provide a context process
which influences the
execution behavior of its scope
enclosed activities scope

Local declarations –
partner links, message scope
exchanges, variables, scope

correlation sets
Local handlers – event
handlers, fault handlers, a
termination handler, and a
primary activity
compensation handler scope

Isolated scopes provide

control of concurrent scope scope
access to shared scope Termination handler to deal
resources scope with forced scope termination
(external faults)
Compensation handler to
undo persisted effects of
already completed activities

BPEL Process Service orchestrates

invocation of internal Services

After being accessed by the external

An external partner service accessing
partner service, the process service
a process service.
invokes another service.

7
 27/05/2015

Basic activities involved in a simple

interaction scenario

Composition of Web Services

Travel Agent Service P
Flight Service B

Hotel Service A receive

Car Rental
sequence
invoke Service C
invoke

invoke

reply

A’s WSDL P’s WSDL P’s WSDL B’s WSDL

Partner Link Type

Partner Link Type
P’s WSDL C’s WSDL

Partner Link Type

8
 27/05/2015

Flight Reservation - Example

Traveler Process Agent Process Airline Process

plan get get

trip itinerary order

submit select reserve

to agent airline seats

order charge
tickets credit card

receive receive receive confirm

confirmation tickets confirmation flight

send send
confirmation tickets

Loan Processing Example

flow
riskAssessmentPT loanApprovalPT
amount < 10000 amount >= 10000
receive

risk = "high"
loan invoke invoke loan
assessor approver
assign
risk = "low" approved = "true"

approved = "false"
reply

1. A customer asks for a loan, providing name and amount info

2. Two services are involved:
a) A risk assessor which can approve the loan if the risk is low
b) A loan approver which checks the name and approves/disapproves the loan
3. The reply is returned to the customer

9
 27/05/2015

WS-BPEL Adoption: Products

• Active Endpoints ActiveBPEL
• BEA WebLogic
• Cape Clear Orchestrator
• Intalio/Apache Orchestration Director Engine (Ode)
• IBM WebSphere Process Server
• Microsoft BizTalk Server
• MidOffice BPEL Engine (open source)
• OpenLink Virtuoso Universal Server
• Oracle BPEL Process Manager
• Parasoft BPEL Maestro
• Progress Sonic BPEL Server
• SAP NetWeaver
• Sun eInsight BPM

BPEL4People & WS-HumanTask

• Integration of human-executed activities in Web services-
based business processes
• Integration of human-executed activities in SOA-based
applications
• Standard-based solution to support interoperability and
portability scenarios
• BPEL4People
– Definition of human interactions within WS-BPEL processes
– Specification built on top of WS-BPEL 2.0
• WS-HumanTask
– Definition of service-enabled human tasks and notifications
– Coordination protocol used to control autonomy and life cycle of
service-enabled human tasks in an interoperable manner
– Interoperable programming interface enabling task client applications
to work with human tasks

10
 27/05/2015

BPEL4People: Web Service vs. Human Task

Translation Process

receive document

automatic manual
translation translation

Web Service Endpoint Abstract Organizational Group

reply translation

BPEL4People: People Links and People Resolution

Brochure Creation Process

Org Database

create Deployment Descriptor Departments

Select staff Department1
Where Member1
"Authors"
qualification Member2
= ...
"tech writer" Department2
...
Users
approve Group1
Member1
Deployment Descriptor Member2
...
Select staff Group2
"Approvers" Where ...
responsibility Roles
= Role1
revise "marketing" Member1
Member2
...
Role2
...

11
 27/05/2015

BPEL4People & WS-HumanTask – Benefits

• BPEL4People
– Enable unified design tools for automated Web services-based
business processes and human-centric processes
– Enable unified monitoring environments for automated Web services-
based business processes and human-centric processes
– Interoperate and integrate with BPEL4People-aware environments

• WS-HumanTask
– Leverage UI technology that can consume and execute tasks from
different task engines
– Build and leverage vendor neutral task-aware applications
– Interoperate and exchange work with other WS-HumanTask-aware
environments

Context and Transaction Management

• Without an active, stateful context, Web services act
independently and cannot support distributed transaction.
• Loosely coupled nature of Web services requires an
approach to maintaining a persistent activity context.
– Structured protocols are required to dictate behavioral aspects of
services that participate in the activity.
• When a group of services collectively interact to execute a
unit of programming logic, it will often be required for these
services to share a common context.
– Each activity receives an identity that is propagated to participating
services.
• WS-Coordination standard provides a context management
system, which is applied to support atomic and long-running
transactions, using protocol described in the WS-Transaction
specification.

12
 27/05/2015

WS-Coordination Specification

A WS-Coordination service
keeping track of an
activity’s coordination
context

A coordinator service used to manage a

coordination context.

WS-Transaction specification

• WS-Transaction specification defines two

coordination types
– Atomic transactions
• ACID type functionality – commit and rollback mechanisms, where
the activity either successfully completes as a whole, or is returned
to its original state.
• During execution, resources involved with the activity are often
locked and remain in suspension until the transaction finishes.
• Execution duration lasts maximum few minutes.
– Business activities
• Used for context to be preserved for long-running transactions.
• Transactions that can last hours or even days to complete.
• Resources typically are not locked.

13
 27/05/2015

Security

• Organizations are reluctant to expose their business

process over the Internet without security.
• WS-Security framework institutes a thorough
security model consisting of a stack of
complementary standards.
• WS-Security framework establishes security
measures to protect SOAP messages throughout a
message path, and supports the creation of policies
and the unification of trust boundaries.
• The core WS-Security specifications are further
supplemented by a series of established XML
security standards.

Security Concepts – Identification and

Authentication

Identification of the sender by the recipient.

Authentication of the sender by the recipient.

14
 27/05/2015

Security Concepts – Authorization, Integrity and

Confidentiality

Recipient assesses the authorization level of the sender.

The integrity of a message is questioned by the recipient.

The confidentiality of a message is questioned by the recipient.

WS-Security allows for claims to be

represented within standard security tokens

15
 27/05/2015

Security Roles and Specifications

Identification WS-Security Framework
Authentication Extensible Access Control Markup Language (XACML)
Authorization Extensible Rights Markup Language (XrML)
XML Key Management Systems (XKMS)
Security Assertion Markup Language (SAML)
.NET Passport
Confidentiality WS-Security Framework
XML-Encryption
Secure-Sockets Layer (SSL)
Integrity WS-Security Framework
XML-Signature

Reliable Messaging
• In order for a solution to be truly robust, its communications
framework must be fail safe.
• This requires a system for the guaranteed delivery of a
message, which includes a way of communicating delivery
failures.
• WS-Reliable Messaging provides such a system, along with
a set of policies that can be used to support delivery-related
business rules.
– Reliable messaging exists within SOAP header blocks, which are
processed by SOAP receivers along a message path
– Can be used in conjunction with WS-Security, WS-Policy, WS-
Coordination, and WS-Transaction

16
 27/05/2015

WS-ReliableMessaging mechanism for guaranteed delivery of

a SOAP message

WS-ReliableMessaging establishes a
standard method of notifying the message
sender of the success or failure of the
delivery.
This notification is accomplished through an acknowledgement that is sent either as
a separate message that is sent either as a separate message, or as an embedded
within the response generated by the message recipient.

Failed delivery is followed by another

delivery attempt

17
 27/05/2015

Successful delivery of a message being

confirmed with an acknowledgement

WS-ReliableMessaging
can also guarantee that
sequence of messages
are delivered in the order
in which they are sent.

Policies
• For organizations using SOA, it would be useful to be able to
abstract high-level business rules, security rules, and
descriptive properties so that they can be applied to groups
of services as policies.
• WS-Policy framework consists of a set of specifications that
allow for the description of such policies, as well as a
standard means of attaching them to Web services.
• WS-Policy framework relies on the WS-PolicyAssertions and
WS-PolicyAttachments specifications as a means of defining
and associating a policy assertion to a message
• Other standards, such as WS-Security and WS-
ReliableMessaging depend on the use WS-Policy features

18
 27/05/2015

Service-Oriented Enterprise (SOE)

• The driving motivation behind extending the capabilities of
the first-generation Web services framework is to empower
service-oriented architecture to represent and even improve
upon the range of business functions required for
contemporary enterprises.
• The army of second-generation Web service specifications
that have emerged position SOA as a viable successor to
prior distributed platforms.
• Their feature sets continue to broaden, as do vendor-
sponsored variations of the specifications themselves.
• The continuing maturity of these standards and their
implementations set the stage for the viable evolution of a
service-oriented enterprise.

19