2 Replies Latest reply on Nov 11, 2005 10:24 AM by Ivan Neto

    WS-Coordination, WS-Policy

    Thomas Diesler Master

      Heiko wrote:

      Maybe we should stick closer to the notions introduced by the specs.

      - WS-Coordination specifies a ?coordination framework?
      - The framework supports coordination types
      - Each coordination type supports several coordination protocols
      - WS-AtomicTransaction actually is a coordination type
      - 2PC is one of it?s supported protocols

      What we end up with is a coordination framework implementation (Thomas calls it API),
      that delegates to specific coordinator implementations according to the coordination type (strategy).

      In order to test drive the coordination framework, we need a coordination type implementation.
      It doesn?t need to a WS-AT implementation though; it can be something much simpler to begin with.

        • 1. Re: WS-Coordination, WS-Policy
          Thomas Diesler Master

          Exactly, this is what I am aiming at.

          As a consequence we can progress (get started) with WS-Coordination independent of WS-AtomicTransaction. In fact WS-Coordination has a dependency on WS-Policy, so I would like to get started with that. Normal policies are sufficient (initially), compact policies can come later.

          With WS-Policy we need

          - A set of interfaces that the client/endpoint can access to define policies dynamically
          - A set of annotations that can be used to define policies on the client/endpoint
          - A protocal handler that enforces policies
          - Maybe an XML override mechanism that mirrors the policy annotations

          • 2. Re: WS-Coordination, WS-Policy
            Ivan Neto Newbie

            Hi all,

            As Reverbel stated, my work is still using axis-based handles, both on client and server sides. I'll turn my attention now to port the Axis dependent code to JBossWS. In fact, I think that even thought


            is not resolved, I can do something similar to what was done in WSSE. When the issue is resolved, then it'll be needed to refactor ws-tx to use protocol handlers.

            I remember having problems to deploy the partial implementation of ws-tx on JBossWS, even though it deployed sucessfully on JBoss Axis. As I said, I'll focus on the porting now and see if it depends on any other JIRA issue(s).

            About my work, as Reverbel said, I'm finishing the simple part (the UserTransaction implementation for SOAP/WS clients that want to do explicit transaction demarcation). The "fully distributed case" (the hard part) is not implemented yet. So, based on the specs, I have a partial WS-Coordination Activation endpoint (that doesn't support iterposed coordination) and a WS-AtomicTransaction Completion endpoint. The remaining endpoints , like WS-Coordination Register endpoint, are still not implemented.

            To finish, I agree with Reverbel that WS-Coordination doesn't stand for its own. Certainly we'll need a service on top of WS-Coordination, and a mock service is a good solution. However, IMHO, WS-AtomicTransaction is still the way to go. We'll need to "plug" a service on WS-Coordination, so I thik that it would be better to implement a "real" service for WS-Coordination. An intermediate solution could be a mock ws-tx service. Anyway, it's just an opinion.