7 Replies Latest reply on Mar 22, 2009 5:49 AM by adinn

    BusinessAgreementWithParticipantCompletition advantage?

    gllambi

      Hi, I've been using WS-BA for a while with great success, but I've got some design decisions that maybe you could answer me. Is there any advantage in using BusinessAgreementWithParticipantCompletition over BusinessAgreementWithCoordinatorCompletition?

      Thank you very much!
      Guzman

        • 1. Re: BusinessAgreementWithParticipantCompletition advantage?
          adinn

           


          Is there any advantage in using BusinessAgreementWithParticipantCompletition over BusinessAgreementWithCoordinatorCompletition


          Yes, there is one very obvious advantage. At completion the web service makes its changes permanent and relies on a compensation record written to disk if it needs to undo them. This means the changes are allowed to become visible to other activities just as if a transaction had completed.

          So, wIth the ParticipantCommpletion protocol the web service can release any locks it is holding as soon as it knows it is ready to do so. With the CoordinatorCompletion protocol the web service has to wait until the client sends a close request to the coordinator. Well, actually, with our API the client can send a complete before the close but that's a detail. Either way the participant has to wait for the client to let it complete and that means, in general, that it will p[robably have to hold locks for longer.

          Of course, using the ParticipantCompletion protocol is not always an option. It requires your web services to have a clear termination criterion which determines when it is appropriate to send the completed message to the coordinator. In some cases it may be appropriate to do this as soon as a web service request is completed, in other cases it may happen at some point in a sequence of requests from the client, e.g. the client may send several service requests and then a confirmation request. It all depends upon the semantics of your application.


          • 2. Re: BusinessAgreementWithParticipantCompletition advantage?
            gllambi

            Thank you very much for your answer!!! :) That's what I was exactly looking for

            Best regards
            Guzman

            • 3. Re: BusinessAgreementWithParticipantCompletition advantage?
              gllambi

               

              "adinn" wrote:

              So, wIth the ParticipantCommpletion protocol the web service can release any locks it is holding as soon as it knows it is ready to do so. With the CoordinatorCompletion protocol the web service has to wait until the client sends a close request to the coordinator. Well, actually, with our API the client can send a complete before the close but that's a detail. Either way the participant has to wait for the client to let it complete and that means, in general, that it will p[robably have to hold locks for longer.


              Sorry, at a first glance I understand the difference and the purpose of both of them. But, after taking another read, I don't understand well the difference between using WS-BA or WS-AT as the scenario will be the same. Both have to wait for the coordinator to unlock their resources. Why not doing a rollback if the resources are locked? Sorry, I'm missing something here. I don't understand well why the participant doesn't unlocks the resources :(

              Thank you again
              Guzmán

              • 4. Re: BusinessAgreementWithParticipantCompletition advantage?
                marklittle

                If you are using either of the WS-BA protocols then you are using a forward compensation based model. In that case your resources don't have to maintain locks for the duration of the "business transaction": they can release them immediately that the response returns from the business logic (web service). This is completely different to the way in which WS-AT works because it's assumptions are based around traditional ACID semantics where locks are held for the duration of the transaction.

                Check out the copious numbers of papers (and books) that have been written over the past 10 years on why Web Services transactions are different to traditional transactions. You'll find many of them on the JBossTS labs pages.

                • 5. Re: BusinessAgreementWithParticipantCompletition advantage?
                  adinn

                   


                  I don't understand well the difference between using WS-BA or WS-AT as the scenario will be the same. Both have to wait for the coordinator to unlock their resources.


                  No, they don't always have to wait.. Even when they do it will not usually be as long.

                  The BA protocol expects each participant to release all locks when it sends completed. At some later point it gets told to close or compensate depending on whether the client decides to close or cancel and whether all the other participants completed successfully.

                  A ParticipantCompletion participant can complete whenever it decides it is appropriate to do so. This may happen a long time before the client decides to close or cancel the activity. The client may still call other web services after a participant has completed. This could take a very long time (maybe days in some cases). So there may be a very long gap between the participant sending completed and it receiving a close or compensate request.

                  A CoordinatorCompletion participant will only be told to complete when the client initiates the close process. The coordinator forwards a complete message to each client and then, if they all reply with a completed message it tells them to close. If one of them fails to complete it sends a compensate to all completed participants and a cancel to any uncompleted ones.

                  Now this is very different to AT because the completed clients release their locks as soon as they are completed. So, if there are several participants the first ones can still be told to complete well before they are told to close or compensate. Imagine that participant A sends completed and then messages to participant B are delayed by network traffic. Participant B might take a long time to respond with its completed message. The server might even crash which means the close message to participant A would only get sent after B's server rebooted and re-established contact with the coordinator. Participant A can still go ahead and serve other requests while it is waiting.

                  With AT participant A would have to hold its locks until both web services had sent prepared and it received a commit message. The difference is that the BA participant can make its change early and then carry on serving new requests. This is only possible because it can also undo the change if it finds there is a problem.


                  • 6. Re: BusinessAgreementWithParticipantCompletition advantage?
                    gllambi

                    Thanks again for the explanation! I'll be using ParticipantCompletition, but could you give me an example of CoordinatorCompletition?

                    Thanks
                    Guzman

                    • 7. Re: BusinessAgreementWithParticipantCompletition advantage?
                      adinn

                       


                      I'll be using ParticipantCompletition, but could you give me an example of CoordinatorCompletition?


                      I suggest you search the web for examples or look for a good book. You have to do some of the work yourself :-)