Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Review of Web Service Specifications for Long-running Conver

No description
by

Karthikeyan Umapathy

on 10 November 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Review of Web Service Specifications for Long-running Conver

Properties
A business transaction needs to handle exceptions or errors that are thrown at any stage during the execution.
Review of Web Service Specifications for Long-running Conversations
Analysis of Specification Support
CONISAR 2014
Conference on Information Systems Applied Research
Baltimore, Maryland, November 6-9, 2014

Web Service Standards Supporting Long-Running Conversations
Web Services Choreography Description Language
(WS-CDL)
Runoff Analysis Results
ACID Properties and 2 PC Protocol
Chirag N. Rana
Senior IT Developer at Florida Blue

Web Services and Conversations
Business conversations are sequences of message exchanges among software components within a distributed system.
Web service is primarily a technology to integrate software systems and support machine-to-machine interactions over a network.
Conversations are of two types:
Short-lived
Long-running
Short-lived conversations
contain atomic transaction with a single unit of task or activity.
Conversations are integral to system integration as they provide a means to model and implement the interactions between components to achieve interoperability.
Long-running conversations
can be a series of smaller transactions or activities.
Web service is an ideal technology for systems integration including implementation of business conversations.
Long-running Conversations
Associate Professor
School of Computing
University of North Florida

Karthikeyan Umapathy
Short-lived conversations are transactions that typically completed within few minutes.
Example: PayPal transactions
Supported by
Web Service Atomic Transactions (WS-AT)
Can take minutes, hours, or even days to complete the transactions.
Long-running conversations
consists of
Sequence of
sub-transactions
Each transaction can be implemented
or executed by a
service
Services need to
coordinate execution
of transactions and necessary
sharing of information
to successfully complete a business conversation and achieve intended objective
Amazon Desktop Product DevPay Authentication
Travel Booking Example
with multiple sub-transactions
Supported by several competing standards:
Web Service Choreography Description Language (WS-CDL)
Web Services Business Activity (WS-BA)
Business Transaction Protocol (BTP)
Web Service Composite Application Framework (WS-CAF)
Long-running Conversations Properties
Fault
Handling
2PC Protocol
Arbitrary Transaction Models and Semantics
Series of
Message Exchanges
State
Information
Relaxed
ACID
ACID Properties
Ensuring consistency of information shared amongst services despite of concurrent accesses and system failure
Coordination Support
Multi-
Participant Support
Complements
WS-BPEL specification
Tool Support
Long-running conversation properties was developed based on relevant literature and existing web service specifications.
Atomicity
- all activities completed successfully, or none succeeds

Consistency
- works on a consistent set of data and leaves a consistent state

Isolation
- concurrent access to the same data while maintaining integrity and correctness of data

Durability
- all changes made becomes persistent even if the system subsequently fails
ACID Properties
Relaxed ACID
NOT all long-running conversations need to maintain rigid ACID properties

A participant might be inactive for an extended time period as often waiting to receive messages from other participants (inconsistent states possible)

Data used within conversations might also be shared among participants, thus, it cannot be locked by a participant (isolation of data is not required)

Participants might be required to share partial results before sub-transactions being committed (atomicity not required)
Fault Handling
Failure can occur within a transaction for several reasons such as service unavailability, network disconnection, and application errors

There should be some mechanism which can revert back all the previous sub-transactions which are successful till the point of failure

Long-running transaction is an aggregation of sub-transactions, thus, there is likelihood that at some point a sub-transaction might fail

A business transaction needs to handle exceptions or errors that are thrown at any stage during the execution
Executions of sub-transactions need to be coordinated to ensure interactions among participants follow expected logical sequence

A centralized controller is required to manage distributed transactions in a loosely coupled manner

Ensure that the controller and the participating services are working together to complete transactions or cancel when it fails
Two phases
Prepare phase which involves participants preparing for the transaction (declaring dependencies and setting up the relationships)
Commit phase in which participants finalizes or aborts the transaction

2PC Protocol is not required for all long-running conversations
Required for complex distributed transactions with ACID like behaviors
Transaction processing policies vary from one business domain to another

Thus, transaction models and semantics supported within the specification should be independent of business domains
Business conversations are essentially series of message exchanges

Transactional operations are also performed via message exchanges

Exchanges occurs in sequential order in accordance to a business process

Support for coordinated message exchanges is critical
Multi-participant support is critical as most long-running conversations involve two or more service providers.
Transactional operation involves various states such as pre-prepare, preparing, committing, aborting, and done.

Co-ordination of message exchanges also requires managing relevant conversation state information.

Without state information, transaction systems could not track and report on the progress made within long-running conversations.
WS-BPEL specification provides ability to create a composite service from a set of individual services
WS-BPEL specifies and manages order of invocations of participating services
Any long-running specification should complement WS-BPEL without which its purposes might be meaningless for users.
Tool support
Modeling and designing conversations
Verifying and validating conversations
Executing conversations

Standards
Analysis &
Results

Web Service Coordination (WS-Coordination)
and
Web Service Business Activity (WS-BusinessActivity)
Business Transaction Protocol (BTP)
Web Service Composite Application Framework (WS-CAF)
Purpose of WS-CDL:
The WS-CDL specification is designed to describe collaborations between participants.
WS-CDL specifies a "global" definition of the ordering conditions and constraints under which messages are exchanged between collaborating participants.
WS-CDL is not an “executable business process description language” or an implementation language. The implementation is handled by the participants who are involved in the conversation.
The participants develop their solutions which comply with WS-CDL global definitions of rules in order to achieve successful messaging within or across their domains.
Implementation:
Main Elements of WS-CDL
Choreography (root element):
Defines rules regulating the ordering of message exchanges and pattern of collaborative behaviors agreed upon between interacting participants.
Collaborating participant -
RoleType, RelationshipType, ParticipantType
:
Defines how a participant is capable of engaging in collaborations with different participants. All interactions specified occur between roleTypes being exhibited by participantTypes and constrained by relationshipTypes.
Information driven collaborations -
variable, token, and informationType:
Defines observable collaborating behaviors (such as information exchanged) of participants within a choreography.
Activities -
basic activity, ordering structure, and workunit:
Activities describe actions performed within the choreography, such as order in which information exchanged and conditions when an action is performed.
WS-CDL specification is developed by W3C.

The current version is 1.0 with candidate recommendation status.

Last draft update was on November 9, 2005
Defines a coordinator and a set of coordination protocols for coordinating activities performed by participating web services.
WS-Coordination specification became an OASIS standard in 2009 and the current version is 1.2.
Main elements of WS-Coordination
CoordinationContext
element is used by applications to pass coordination information.
CoordinationService
: represents coordinator, which is essentially an aggregation of operations for creating activity, registering a service to an activity, and defining accepted coordination behavior within an activity.
Fault
: allows defining endpoints that can be used when preset fault conditions are met.
Security Model
: works in conjunction with WS-Security and WS-Trust specifications to secure message exchanges and other communications between participants.
WS-Coordination
WS-Business Activity
Defines protocols that enable existing business process and workflow systems to wrap their proprietary mechanisms and interoperate across trusted boundaries and different vendor implementations.
Builds its protocols based on the extensible coordination framework from WS-Coordination specification.
Business activities can be partitioned into hierarchical nested scopes.
WS-BuinessActivity specification became an OASIS standard on 2007 and the current version is 1.1.
Coordination Types
: Supports two coordination types -
AtomicOutcome and MixedOutcome
. For AtomicOutcome, the coordinator directs all participants to either close or compensate. For MixedOutcome, the coordinator directs individual participants to either close or compensate.

Coordination Protocols
: Supports two coordination protocols -
BusinessAgreementWithParticipantCompletion
(A participant knows when it has completed a business activity) and
BusinessAgreementWithCoordinatorCompletion
(A participant relies on coordinator to know when it has completed a business activity).
Main elements of WS-Business Activity
Business Transaction Protocol (BTP)
Defines possible roles within a transaction, message exchanges between roles, meanings of messages and their permitted ordering sequences.
Its purpose is to provide the interactions (or signaling) required to coordinate the effects of application protocols to achieve a business transaction.
Designed to allow coordination of web services using a two-phase coordination protocol to ensure that consistent results are achieved. BTP also provides the participants’ ability to record before or after images of a transaction operation.
It also provides flexibility for participants to compensate with rollfoward-rollbackward capability.
BTP specification is developed by OASIS and it is currently a committee specification as of June 2002. BTP is not yet a standard.
Main Elements of BTP
Elements
: Each participant in BTP has two elements:
application element
(holds the order of message exchange) and
BTP element
(sends and receives messages).
Actors and Roles
: BTP establishes bilateral relationships between two applications using
actors
(participating application) and
role
concepts. There are two key roles - superiors (nodes that coordinate a transaction) and inferiors (nodes that participate in a transaction coordinated by another node).
Atoms and Cohesions
: There are two kinds of transaction behaviors supported by BTP:
atoms
and
cohesive
. In transactions with atomic behavior (also called atoms) all elements contributing to a transaction must eventually reach the same conclusion about a transaction (confirm or cancel). Transaction with cohesive behavior (also called Cohesions) allows some sub elements to cancel while others confirm, which is useful in the case of different providers offering similar services.
The purpose of WS-CAF is to enable development of composite services encompassing range of transaction models, coordination of activities, and recoverable long-running activities.

WS-CAF defines a framework for composite services that needs to specify boundaries for activities, manage context information, and inform participants of changes to an activity (WS-CAF, 2005).

WS-CAF consists of three specifications:
Web Service Context (WS-Context)
- a framework for managing contextual information such as IDs, tokens, channels, and address
Web Service Coordination Framework (WS-CF)

- a sharable mechanism to manage context augmentation and lifecycle, and guarantee message delivery
Web Service Transaction Management (WS-TXM)
- comprising protocols for interoperability across multiple transaction managers and supporting two phase commit, long running actions, and business process flows transaction models
WS-CAF is developed by OASIS. WS-CF and WS-TXM were proposed but were not developed into standard specifications.

Only, WS-Context 1.0 was recommended as an OASIS standard in 2007.
WS-Context
Context structure
: defines nested structured models for organizing context information
Context service:
defines scope of an activity and how context information can be referenced and broadcasted
Context manager:
defines how applications can retrieve and set associated data with a context

Web Service Transaction Management (WS-TXM)
ACID transactions:
supports short-running transactions that require ACID properties
Long-running action transactions:
designed for transactions with long duration

Web Service Coordination Framework (WS-CF)

Registration service
(that allows a participant to register with a specific protocol)
Participant service
(allows defining operations performed by a participant as a part of the protocol)
Registration context
(allows a participant to join an activity group)
Recovery service
(provides capability for transaction systems recover from failures)
Main Elements of WS-CAF
We need runoff analysis to decide on a winner!
WS-AT provides full support for ACID and 2PC properties

WS-AT can be used along with WS-C and WS-BA
WS-C and WS-BA
Standardization and Tool Support
both are Oasis standards
updated tool support
BTP
Not a standard
outdated tool support
WS-C & WS-BA along with WS-AT provides the best option for supporting long-running conversations.
WS-CDL provides support for series of message exchange. There has been no work done in making WS-CDL work with WS-C and WS-BA.
Thank You!
ACID Properties
Tool Support
Ensuring consistency of information shared amongst services despite of concurrent accesses and system failure through well-known ACID properties of Atomicity, Consistency, Isolation and Durability.
Relaxed ACID
Not all long-running conversations need to maintain rigid ACID properties. Most long-running conversations may not be able to possess full atomicity and isolation properties. Provide support for relaxed ACID properties.
Fault Handling
Coordination Support
Executions of sub-transactions need to be coordinated to ensure interactions among participants follow expected logical sequence.
2PC Protocol
For conversations containing complex transactions with ACID like behaviors two-phase commit protocol is a necessity.
Arbitrary Transaction Models and Semantics
Transaction models and semantics supported within the specification should not be catered to a specific set of business domains.
Series of Message Exchanges
Multi-Participant Support
State Information
Complements
WS-BPEL specification
Participating entities share information with each other through message exchanges. Transactional operations are also performed via message exchanges.
A typical long-running conversation not only includes a series of message exchanges but also two or more participants.
Maintaining the current state of interactions is essential for monitoring progress of the transactions.
Any long-running specification should complement WS-BPEL without which its purposes might be meaningless for users.
Availability of tool support is critical for adoption of any standard specifications, without which a specification is just an abstract entity.
Long-running Conversation Properties
Long-running Conversations
Backup Slides
Full transcript