Web Services Composite Application Framework

1
Web Services Composite Application Framework

• Eric Newcomer, WS-CAF Co-Chair
• April 26, 2004

2
What is WS-CAF?

• Collection of 3 specifications
• WS-Context generic context management
• WS-Coordination Framework - for pluggable
  coordination protocols
• WS Transaction Management - three transaction
  models for Web services
• ACID Transaction focus on interoperability
• Long Running Action compensation based
• Business Process - Coordination of arbitrary
  runtimes and transaction models
• Extensible
• Updated with new models as and when required
• WS-Ctx and WS-CF can be used independently

3
WS-CAF (cont)

• Intended to complement MSFT/IBM/BEA work
• Submitted to OASIS by Arjuna, Fujitsu, IONA,
  Oracle, and Sun in October
• Now progressing in WS-CAF TC
• 62 members
• Spec update/interop demo roadmap for 2004
• WS-Context April
• WS-Coordination Framework August
• WS-Transaction Management December

4
WS-Context specification

• Context and life-cycle service
• Basic 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
  activity
• May be co-located or separate service

5
WS-Context Goals

• To provide a basic context service for Web
  services
• Lots of different specifications need one
• 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
• Basic context management to complex systems

6
Business process model

• Aimed at long running interactions that span
  different domains and models
• Workflow
• Messaging
• Database, ERP, etc.
• Federated systems that cant/wont expose
  back-end implementations
• Assign coordinators per domain
• Adds a coordinator-coordinator protocol

7
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

8
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 necessary
• 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

9
WS-Coordination Framework

• The Coordinator Service
• Provides a participant registration endpoint
• Coordination status and identity
• Can be driven at arbitrary points during activity
• Subordinate coordinator
• Participant as far as coordinator is concerned
• Coordinator as far as participant is concerned
• Can be used to resolve protocol differences
• Provide basic interoperability
• Bridge disparate transaction models

10
Business process architecture
Database schemas and stored procedures
Web services
.Net Server or App Server with Web service APIs
Adapters to ERP, CRM, Accounting, etc.
Flow
Message queuing system A2A/B2B Integration broker