ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Ws Wiki] Update of "SummerOfCode/2005/kandula" by thilinagunarathne
Date Wed, 13 Jul 2005 08:36:36 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.

The following page has been changed by thilinagunarathne:
http://wiki.apache.org/ws/SummerOfCode/2005/kandula

New page:
##language:en
== Summer of Code 2005 Proposal for Apache Kandula ==


==== Name ====

  Thilina Gunarathne

==== Mentors ====

  Dasarath Weeratunge

  Sanjiva Weerawarana

==== Email ====

  thilina@apache.org

  csethil@gmail.com


==== 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 [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 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/

Mime
View raw message