Final presentation Simon Zambrovski Tutor: Muhammad Farhat Kaleem Design choices and strategies for implementing WS-BusinessActivity Framework

Agenda  Motivation  Goals of the work  Analysis  Solutions  Implementation  Demo  Outlook

Motivation  Web Services offers a wide adopted, platform independent communication tier for distributed systems  Further tiers are in development to improve the offered services (e.G. Security, Addressing, Transactions, ReliableMessages)  The ability of transactional communication is important for usage in the real world  Orthogonality of different tiers has to be supported by the protocol architecture

Motivation  WS-* protocol family offers pluggable protocols for different services  WS-Coordination, WS-AtomicTransactions and WS- BusinessActivity cover transactional behaviour  WS-BusinessActivity(WS-BA) is designed to replace Business Transaction Protocol(BTP)

Goals of the work  Analysis of WS-C and WS-BA specifications and preparing them for implementation  Design of the framework that supports WS-C and WS-BA  Design constraints  Minimize the adaptation changes of existing Web Services needed to support WS-BA  Decouple the coordination and transaction components from the business application  Implementation of the framework  Implementation of sample scenario

 Tightly coupled components  Responsibility for context on the client  Not enough information contained in messages used  Direct client-to-service communication (no central turning point)  No delivery of decisions described (no API) Analysis: specificated overview

Analysis  Entities:  Initiator (client application)  Coordinator (tightly coupled to the client)  Participant (monolith encapsulating the business Web Service)  Requirements:  Ability to participate on demand  Decoupling of components  Separation of application-specific from transaction- specific components

Solutions  Extension of messages with IDs from Context  Assignment to BA becomes possible  Applying Message Interceptor Concept  Components can be decoupled  No addition API is needed  Applying Proxy concept  Message interceptor on the client side (Proxy Client)  Proxy Service for delivery to destination  WS-C workflow placed to Middleware  Introduction of Transactor Entity  Begin() and End() for on-demand support  Confirm() and Cancel() for decision delivery  Introduction of Decision Engine  Coordinator becomes independent from business logic

Solutions: implementation overview  Initiator (client)  WS-C workflow removed  Participant  Independent service  Configurable  Transactor  Context propagation  Delivery of decisions  Coordinator  Decoupled service  Business independent

Implementation  Message Interceptor  Apache AXIS handler  Proxy Service  Message-based Web Service  Decision Engine  XQuery with Saxon  Asynchronous with J2EE JMS  Monitoring  Coordination logic exposes JMX interfaces  JMX Client implemented (RMI)  Sample scenario  J2EE Application (EJB) with Apache AXIS for WS

Demo

Outlook  A paper about this work has been submitted to ICSOC 2004 conference.  Further work could be done on implementing another approach of decision delivering to Coordinator (e.G. integration of BPEL)  The recovery from written system logs has been deferred  Project artefacts available on the SourceForge for educational and research purpose.

Thank You for Your Attention Questions?  Further information:  Contact: