Differences between revisions 2 and 3
Revision 2 as of 2005-07-14 08:38:36
Size: 9378
Comment:
Revision 3 as of 2009-09-20 22:47:44
Size: 9382
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 123: Line 123:
I am a student on the [http://www.cse.mrt.ac.lk/ Computer Sceince & Engineering Department] at [http://www.mrt.ac.lk/ University of Moratuwa], Sri Lanka. I am currently in Level 3. I am a student on the [[http://www.cse.mrt.ac.lk/|Computer Sceince & Engineering Department]] at [[http://www.mrt.ac.lk/|University of Moratuwa]], Sri Lanka. I am currently in Level 3.

Summer of Code 2005 Proposal for Apache Kandula

Name

  • NK Thilina Gunarathne

Email

Mentors

Project Title

  • Apache Kandula

Synopsis

Kandula is a project aimed to provide an open-source implementation of WS-Coordination, WS-AtomicTransaction and WS-BusinessActivity based on Apache Axis. Currently Kandula has a basic implementation for WS-Coordination & WS-Atomic Transaction using Axis Java 1.2. It has a participant side implementation tightly coupled with JTA. Current implementation lacks the support for some criterias mentioned in the specifications.

This project will mainly focus on re-structuring WS-Coordination & WS-Atomic Transaction specifications with the support for Axis 1.2 & Axis2. First phase of this project will be to deliver a fully interoperable web service transaction coordinator which will support WS-Atomic transactions. This part will be redesigned to a new architecture, keeping mind the support for a future WS-Business Activity implementation. Second is to come up with a participant implementation which will wrap the local transaction mechanisms. It will be designed not to rely on JTA implementations for the client side.

Transaction support is an absolute necessity in a distributed computing architecture if needs to be used in real business scenarios. When this project is completed Apache Kandula will become the first open source web services transaction implementation in the world. This will help a lot to maintain the leadership of the Apache web services project in the web services arena.

Deliverables

  1. Completely redesign & re-implement WS-Atomic Transaction & WS-Coordination implementation making sure that it is interoperable & supports Apache Axis2 & support for a future WS-BusinessActivity implementation.

  2. Standalone participant implementation, which will not depend on participants local transaction implementation.
  3. Appropriate documentation to guarantee the continuation of the project.
  4. Setting up Apache Kandula web-site
  5. Releasing an M1 release (virtually it will be version 1.0 release for Ws-Atomic transaction & Ws-Coordination impls)

Project Details

In a Web services world, applications are constructed from the interconnection and operation of Web services. To obtain a reliable outcome, the various services that constitute the application must universally agree on an undisputed resolution. Transactions are a well-understood approach used widely in commercial systems that meet this requirement.

The Web service specifications WS-Coordination, WS-Atomic Transaction, and WS-Business Activity Framework, define the protocols required to build reliable Web service applications. The WS-Coordination specification provides the generic foundation for coordinating outcome agreements between interoperating Web services. WS-Atomic Transaction and WS-Business Activity specifications contain definitions of atomic and business transaction protocols, respectively, that you can use with WS-Coordination and jointly provide agreement coordination infrastructure for tightly and loosely coupled activities, whether short- or long-lived. Together, these specifications address the more general requirement to guarantee the reliable coordination of operations across Web services, which is a major requirement in web services world when it comes to business transactions.

In particular, activities that require the traditional atomic, consistent, isolated and durable (ACID) properties of transactions are natural users of WS-AtomicTransaction. Also WS-Atomic Transaction can be used to coordinate intra-enterprise transactions between heterogeneous systems (Eg. Java clients & a Legacy app running on a Main Frame). WS-Atomic transaction defines two protocols.

  • 1.Which the initiator application uses to inform the final outcome to coordinator. It defines two operations namely commit, rollback. 2.Two phase commit protocol which happens between the coordinator and the participant applications. This further breaks in to two protocols namely Volatile 2PC , Durable 2PC. Generally in the first phase coordinator sends the ballot request "prepare" message to all the participants giving priority to "volatile" participants. Then depending on the outcome of the "vote" messages the participants are sending coordinator sends the appropriate "commit" or "rollback"message to participants.

However, in a Web services environment, the services that are the component parts of an application are typically loosely coupled and distributed across various independent systems spanning a network. You need more flexible forms of outcome coordination processing that have more relaxed forms of transaction to accommodate collaborations, workflow, real-time processing, and so on. you might have to apply some of the properties of atomic transactions less strictly.

WS-BusinessActivity defines two protocols.

  • 1.BusinessAgreementWithParticipantCompletion - a child activity is initially created in the Active state. After a child task finishes, it must be able to compensate for the work that was performed.

    2.BusinessAgreementWithCoordinatorCompletion \endash this is pretty much similar to the above except that the child cannot unilaterally decide to end its participation in the business activity. The child task relies on the parent to send a "Complete" message.

Project Plan

My objective is to provide a complete Coordinator implementation for WS-Atomic Transaction alone with a standalone participant Transaction Manager which will support the above implementations independent of the back end transaction implementation, by re-structuring the WS-Atomic Transaction & WS-Coordinator specifications. The main motivation for re-structuring came with the need of interoperability & the need to implement WS-BusinessActivity on top of it.

Currently Apache Kandula has basic implementations for WS-Coordination & WS-Atomic Transactions. It does not support some requirements mentioned in the specifications. Also it doesn't support plug-in additional protocols like WS-BusinessActivity. Implementing WS-BusinessActivity heavily depends on the WS-Atomic transaction & WS-Coordination implementations. The current coordinator has a unnecessary dependency on JTA also. The current participant implementation heavily depends on the JTA implementations which restricts it to be used only with JTA enabled clients.

I'll be focusing on re-structuring WS-AtomicTransaction & WS-Coordination with a new architecture with the support for Axis1.2 & Axis2 and support to plug-in WS-BusinessActivity. Also I'm planning to implement a standalone client for participant applications, which will work independently of the local back end transaction system. This will give Kandula the ability to work with any backend transaction implementations.

With the completion of this project I'll be starting to implement WS-BusinessActivity on top of it. After completion this will become the world's first full web services transaction implementation.

Project Schedule

  • Weeks ending on June 11th & 18th Setting up Kandula Web Site

  • June 26th & July 2nd Research and come up with a new architecture.

  • July 9th & 16th & 23rd Implement the coordinator part of the new design.

  • July 30th

    Implement interop scenarios and test them & do necessary changes.

  • August 6th Design the Standalone participant.
  • August 13th & 20th Implement Standalone participant.

  • August 27th

    Test the participant & overall system.

  • September 3rd M1 release + documentation.

Bio

I am a student on the Computer Sceince & Engineering Department at University of Moratuwa, Sri Lanka. I am currently in Level 3.

I have implemented Message Transmission Optimisation Mechanism & SOAP With Attachments specifications for Axis2 (Attachments for Axis 2). I was accepted as a apache committer in March this year for that contribution. Then I started working on Kandula project with the request from it's initail committer. I find this project really interesting and very much rewarding to me as a student. I wrote test-cases to make sure the Kandula implementation is interoperable by making it conforming to Interop scenerio's. I have also fixed some bugs. I was given committer rights for this projects last month. Then I understood the need for re-structuring to make this interoperable. Also with my understanding in Axis 2, i also decided to port this to Axis2 also.

I have a good understanding about Web Services and Trasactions.

References

Kandula http://ws.apache.org/ws-fx/kandula/

University of Moratuwa http://www.mrt.ac.lk/

Computer Science & Engineering Department http://www.cse.mrt.ac.lk/

http://msdn.microsoft.com/ws/2004/10/ws-coordination/

http://msdn.microsoft.com/ws/2004/10/ws-atomictransaction/

http://msdn.microsoft.com/ws/2004/10/ws-businessactivity/

SummerOfCode/2005/kandula (last edited 2009-09-20 22:47:44 by localhost)