Web Services - IONA Blogs

Document Sample
Web Services - IONA Blogs Powered By Docstoc
					Web Services Composite Application
                       An Introduction

                         Eric Newcomer, CTO
                            February 24, 2004
• Web services transactions
  – TP background
  – Evolution of Web services transaction proposals
• What is WS-CAF?
• Summary of WS-CAF specifications:
  – WS-Context
  – WS-Coordination Framework
  – WS-Transaction Management
• Current TC status and roadmap
WS-CAF Problem space
• Transactions are fundamental to business:
  – Exchange of goods for money
  – Records of investments, insurance, health care
• Transaction implementations vary:
  – Synchronous, RPC oriented
  – Asynchronous, message-oriented
  – Long running process orchestrations
• Web services present new challenges:
  – HTTP, XML, emergence of loosely coupled paradigm
  – Unify or bridge transaction models to achieve
    interoperation and reuse
What’s a Transaction?
• The execution of a program that performs an
  administrative function by accessing a shared
  database, usually on behalf of an on-line user.
•   Reserve an airline seat. Buy an airline ticket
•   Withdraw money from an ATM.
•   Verify a credit card sale.
•   Place an order using an on-line catalog
•   Fire a missile
•   Download a video clip
What are Web services?
• N-tier interfaces that use Web technology to describe
  executable software agents of any type
   – Typically XML and HTTP (but not necessarily HTTP)
• Interfaces have at least one URI that identifies:
   – Its description
   – Its network address
• It returns an XML representation of the result
• Web services are instances of Service Oriented
  Architecture (SOA)
   – Typically SOAP, WSDL, UDDI (+ lots of WS- specs)
• Encompasses direct and queued processing models
Web Services: Implications for TP
• Persistent sessions are missing from HTTP
  – Need to define a common context sharing mechanism
  – Transport “agnostic” means LCD
• Suited for document-oriented transactions
  – Compensation, transactional “queues” needed
  – Reliable messaging needed
• Business process orchestration
  – Cancel/adjust transactions in long-running flight
  – Mixture of existing and new technologies
The needed solution will deliver
• A generic mechanism designed for:
  – Compatibility with loosely coupled, asynchronous
    Web services styles
  – Interoperability across existing systems and
• Start with the simple problem and build up:
  –   Generic context management
  –   Add QOS through software “agent”
  –   Pluggable transaction protocols
  –   Asynch run to completion capability
Current status of standardization
• First attempt – SOAP-TIP – didn’t work for
  obvious reasons
  – No persistent sessions in HTTP for “two-pipe” model
• XAML died
  – No one really wanted World Wide XA
• BTP not widely implemented
  – A bit complex and hard to map to existing systems
• WS-Coordination and WS-Transaction not open
  – No interoperability across transaction models
WS-CAF is the new proposal
• Collection of 3 specifications
   – Designed to be used independently or together
   – Superset of WS-C, WS-T, and WS-BA
• Separates context management as a generic
   – Handle various system contexts in a standard way
• Innovative business process transaction model
• Submitted to OASIS by Arjuna, Fujitsu, IONA,
  Oracle, and Sun – now in WS-CAF TC
What are the specifications?
• WS-Context (WS-CAF innovation)
  – Generic context service
• WS-Coordination Framework
  – Framework for pluggable coordination protocols
• WS-Transaction Management
  – Three transaction models for Web services
     • Interoperability with existing implementations is important
     • Coordination of arbitrary runtimes in a business process
  – Extensible
     • Updated with new models as and when required
Positioning relative to other specs
What is a context?
• A way of doing correlation of messages
• For example
  –   Web browser cookie
  –   Single-session sign-on
  –   Transactions
  –   Database session identifier
• A mechanism for sharing persistent data
  – Application documents
  – Temporary working data
WS-Context specification
• Context and “life-cycle” service
   – Most fundamental aspect of WS architecture
• Defines notion of an activity
   – Unit of work
   – Shared scope of persistent data
   – Basic context associated with activity
• Context Service maintains context for each
   – May be co-located or separate service
WS-Context Goals
• To provide a basic context service for Web
  – Lots of different services (and specifications!) need
     •   WS-Security
     •   WS-BPEL
     •   WS-Resource Framework
     •   WS-Distributed Management
• Provide ability to do correlation at a minimum
  – No augmentation of framework required to use it
• Build up from basic context mechanism to TP
Context Example
WS-Coordination Framework
• The Coordinator Service
  – Provides a participant registration endpoint
  – Coordination status and identity
  – Can be driven at arbitrary points during activity
• Participant
  – The operations performed as part of coordination
    sequence processing
     • Works in terms of AssertionTypes
  – status
Interposition benefits
• Important for security and performance reasons
  – Part of most distributed transaction protocols
• Subordinate coordinator
  – Participant as far as coordinator is concerned
  – Coordinator as far as participant is concerned
• Can resolve protocol differences
  – At the endpoints (invasive solution)
  – By extending the coordinator (non-invasive)
• Provides basic interoperability
• Bridges disparate transaction models
Example of interposition
    Domain A:
 Root Coordinator

                              Domain B:
                           Proxy Coordinator


WS-Transaction Management
• Transactions for a variety of Web services
• Builds on WS-Context and WS-CF
• Adds recovery protocols
   – Known outcome following failure(s)
• Based on experience of using Web service transactions
   – Roll-your-own
• Intended as a live document
   – New models can be added as required
• Scope of activity becomes scope of transaction
WS-TXM Defines
• Three transaction models
  – ACID transaction
     • For interoperability and high-cost services where ACID
       transactions are a requirement
  – Long running action
     • Loosely coupled, long duration work that uses
  – Business process (WS-CAF innovation)
     • For treating all steps in an automated business process as
       part of a single logical transaction
ACID Transaction
• Traditional ACID transaction with two sub-
  protocols (different URIs)
   – Two-phase commit
   – Synchronizations
• Interoperability across different vendor
  implementations and standards
   – Bridge WS-T to OTS/JTS
   – Bridge RRMS on the mainframe to DTC on Window
• Useful for co-located Web services
Long running action
• Specifically for long duration interactions
• Where ACID transactions are not appropriate
  – Can’t lock resources for the duration
  – No assumed trust relationships
• Compensation actions used
  – Forward work to return the business state to
     • E.g., credit your credit card and give you back interest
Business process model
• Aimed at long running interactions that span
  different domains and models
  – Workflow
  – Messaging
  – Database, ERP, etc.
• Federated systems that can’t/won’t expose
  back-end implementations
• Assign coordinators per domain
• Adds a coordinator-coordinator protocol
                                                     Transaction model
architecture              Database schemas            bridging: domain
  example                        and                 coordinators talk to
                          stored procedures
                                                         each other

     .Net Server
       Server                                             Adapters to
        with                     Flow                     ERP, CRM,
        Web                                             Accounting, etc.

               Message queuing system –A2A/B2B Integration broker
Business process approach
• All operations reside within business domains
  – Recursive structure is allowed
  – Each may represent a different transaction model
• Business process is split into business tasks
  – Execute within domains
  – Compensatable units of work
     • Forward compensation during activity is allowed
        – Keep business process making forward progress

• Coordinator can invoke synchpoint to discover
  current state of transaction
Business Process Model
• Supports synchronous and asynchronous interactions
   – Users can submit work and call back later
   – Or interact synchronously (traditionally)
• Optimistic rather than pessimistic
   – Assumes failures are rare and can be handled offline if
• Each domain is exposed as a subordinate coordinator
   – Responsible for mapping incoming BP requests to domain
     specific protocol
• Protocol messages
   – checkpoint, confirm, cancel, restart, workStatus
TC Status and Roadmap
• 62 members
• Bi-weekly concalls
• Spec/interop demo roadmap for 2004
  – WS-Context – April
  – WS-Coordination Framework – August
  – WS-Transaction Management – December

Shared By: