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 can’t/won’t expose back-end implementations • Assign coordinators per domain • Adds a coordinator-coordinator protocol

7. Business process approach • All operations reside within businessdomains • 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. Database schemas and stored procedures Business process architecture 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