Differences between revisions 4 and 5
Revision 4 as of 2005-10-03 00:46:09
Size: 2452
Comment:
Revision 5 as of 2009-09-20 22:48:48
Size: 2462
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
http://people.apache.org/~thilina/images/kandula2Coordinator.jpg {{http://people.apache.org/~thilina/images/kandula2Coordinator.jpg}}
Line 26: Line 26:
http://people.apache.org/~thilina/images/participant.jpg {{http://people.apache.org/~thilina/images/participant.jpg}}
Line 40: Line 40:
[http://svn.apache.org/repos/asf/webservices/kandula/trunk/java/] [[http://svn.apache.org/repos/asf/webservices/kandula/trunk/java/]]

Kandula2

Proposal for Kandula2, a web services project for implementing WS-Coordination, WS-Atomic Transaction & WS-Business Activity on top of Axis2.

Rationale

The target of Kandula project was to implement WS-Coordination, WS-Atomic Transaction & WS-Business Activity for Axis 1.x. Kandula implementation lacks the mandatory asynchronous support due to axis 1.x not supporting one way messaging. Since Axis2 is about to make 1.0 release, we believe it is the time to start working on a Kandula implementation using axis2's asynchronous support.

This implementation will have a simple participant implementation, which will be indepedent of the participant's backend transaction implementation, and an initiator implementation which will use simple axis server to host services needed for the asynchronous communication.

Proposed Coordinator Architecture (WS-AT only)

Kandula2 coordinator implementation will be a stateless coordinator with a context hierarchy.

http://people.apache.org/~thilina/images/kandula2Coordinator.jpg

  • The core of the coordinator will be independent of Axis2.
  • All the logic needed for transaction processing will be in stateless coordinators, which makes the implementation much more scalable.
  • Data binding layer will provide the extensibility to plug-in code generated, using diffrent data binding tools.
  • Storage layer will take care of storing the contexts through out the life span of the transaction. This will be either Axis2 service context or a choice of a user (even a database).

Proposed Participant Architecture (WS-AT)

This will be a simple standalone participant impl which can be used with any native transaction implementation.

http://people.apache.org/~thilina/images/participant.jpg

  • The user needs to provide implementations of the 2PhaseCommit interface for each and every operation he wishes to provide transactional support.
  • Transaction handler will take care of registering the coordinator when receiving an application message with a coordination context.

Proposed Initiator Architecture

This will use Simple Axis Server to host the services needed for the asynchronous messaging.

This implementation will be followed by the WS-Business Activity Implementation, which will have an architecture similar to above.

Svn Repository http://svn.apache.org/repos/asf/webservices/kandula/trunk/java/

FrontPage/ws-kandula/kandula2 (last edited 2009-09-20 22:48:48 by localhost)