1 2 Previous Next 27 Replies Latest reply on Sep 1, 2007 2:18 PM by maciej.machulak

    Metadata Support for Transactional Web Services

    maciej.machulak

      Hi,

      I have been working on support for transactional Web Services (with accordance to the Business Activity model described in the WS-BusinessActivity specification) for some time and I am close to releasing the first version of my framework. The framework is built on top of the XML Transaction Service (XTS) component of the JBoss Transaction Service. I will be setting up a Web site with the source code, documentation and some examples but first I would like to give you an overview of what and why has been done.

      At this moment writing transaction-aware Web Services is relatively problematic and requires a lot of support from business programmers. Developers need to manually wire up original services with their compensation actions and must ensure the correctness of those links (e.g. in terms of data that needs to be shared). Moreover, it is necessary to follow transaction-related patterns where a developer must code not only the business logic but a participant as well. The latter one is an entity, which is capable of responding to transaction protocol messages (such as commit or compensate messages). Typically, a third component is also developed ? this component usually links participants with the business logic and is often referred to as the manager.

      My aim was to facilitate development of transaction-aware Web Services and provide a comprehensive framework which would release programmers from mixing transaction-related code with business logic of their applications. The framework has a very clean API, which can be easily learnt and used. I will briefly describe it and show an example of how it can be used to expose an EJB component as a transaction-aware Web Service.


      Programmer?s API
      The API has been designed following the conventions proposed by the JSR-181 specification for exposing EJB components as Web Services. It consists of the following annotations:

      @BAService ? specifies the service in terms of its state management;
      @BAAgreementType ? specifies the agreement protocol the service wants to participate in;
      @BACompensatedBy ? specifies the compensation action and a type of compensation;
      @BAParam ? annotates the service?s parameter so that it can be processed by the compensation mechanism;
      @BAResult ? annotates the service?s return value to be processed by the compensation mechanism;
      @BACompensationManagement ? annotates a BA compensation manager object to enable transparent dependency injection.

      Moreover, the programmer may use put(id,Object) and get(id) methods, which are invoked on the previously mentioned compensation manager to store and retrieve any additional data, which might be used for compensation.


      Example
      To understand how those annotations and methods can be used I will present an example of an EJB component (stateless session bean), which is exposed as a transaction-aware Web Service.

      To expose a method as a transaction-aware Web Service, the business programmer must mark it with previously mentioned annotations as shown in the example below. If no additional data must be stored, then annotations are enough. The framework will transparently apply all necessary transaction mechanisms. If more flexibility needs to be achieved, the programmer may use additional methods (put() and get()) to store and retrieve any data that could be potentially used during compensation. The compensation action must only have its parameters annotated so that middleware mechanisms can match them with any data remembered during the execution of the original service (additional support for numerical identifiers is currently being developed so that the compensation action will not need to have any annotations). As shown in the example, the compensation action does not need to be transaction-aware. Moreover, it does not need to be exposed as a Web Service at all.

      @Stateless
      @Remote(HotelBA.class)
      @WebService(name="HotelBA")
      @SOAPBinding(style = SOAPBinding.Style.RPC)
      @HandlerChain(file = "jaxws-ba-handler-server.xml")
      public class HotelBAImpl implements HotelBA
      {
       @BACompensationManagement
       private CompensationManager cm;
      
       @WebMethod
       @BAService(BAServiceType.MODIFY)
       @BAAgreement(BAAgreementType.PARTICIPANT_COMPLETION)
       @BACompensatedBy(value="cancel",type = BACompensationType.CUSTOM)
       @BAResult("resNo")
       public Integer book(@BAParam("user")String user, @BAParam("pass")String pass, Integer room)
       {
       // ... business logic
       cm.put("charge",5);
       // ... business logic
       return reservationNumber;
       }
      
       @WebMethod
       public void cancel(@BAParam("user")String user, @BAParam("pass")String pass, @BAParam("resNo")Integer rNumber)
       {
       // ... business logic
       Integer refund = (Integer) cm.get("refund");
       if (refund != null)
       {
       // ... business logic
       }
       // ... business logic
       }
      }
      


      Future releases of the framework will provide support for remote compensation and will allow specifying transaction-related requirements in XML files (to allow exposing existing components).

      I hope that the overview and example provided enough information to give a flavour of what the framework is aiming to achieve. Information about the first release and a link to the website will be posted here as soon as everything is ready.

      Maciej Machulak

        • 1. Re: Metadata Support for Transactional Web Services
          marklittle

          Nice work Maciej.

          • 2. Re: Metadata Support for Transactional Web Services
            maciej.machulak

            Hi,

            The framework has been released and all information can be found on the following web site:
            http://labs.jboss.com/jbosstm/baframework
            All comments and questions are highly appreciated and can be sent directly to the author.

            Cheers,
            Maciej M.

            • 3. Re: Metadata Support for Transactional Web Services
              marklittle

              Comments and questions to the forum please, so everyone can see them. Thanks.

              • 4. Re: Metadata Support for Transactional Web Services
                bill.burke

                This is really really cool.

                How much work is it to decouple it from web services?

                • 5. Re: Metadata Support for Transactional Web Services
                  jhalliday

                  Umm, it's called 'Metadata Support for Transactional Web Services' for a reason Bill :-) Decoupling the annotations would not be too bad, but the transaction protocol they relate to is inherently web services based. What would you replace it with?

                  • 6. Re: Metadata Support for Transactional Web Services
                    bill.burke

                    What would I replace it with? Our regular EJB protocol over raw sockets. There's also no reason this can't be used in a non-distributed environment as well.

                    • 7. Re: Metadata Support for Transactional Web Services
                      jhalliday

                      Ahh, I think I see what you are getting at: using the annotations as a general purpose system for expressing the relationship between work and its compensation, regardless of the application framework (WS, EJB, ...) or even the transaction coordination protocol (WS-BA, ...)

                      Although the annotations are designed to work within the context of WS-BusinessActivity, the approach can certainly be generalised to any application where work may need to be undone. As long as you have some way to intercept the business method calls and a way of interacting with the transaction coordinator you should be fine. The annotations themselves should be suitable for more or less any compensation based protocol, although some variations may be needed here and there. Making the framework implementation truly pluggable in this way is outside the scope of the current effort, but it's certainly something worth looking at in the future.

                      • 8. Re: Metadata Support for Transactional Web Services
                        bill.burke

                        so, you're saying there's no API the TM exposes? This is all WS specific? No abstractions at all?

                        • 9. Re: Metadata Support for Transactional Web Services
                          maciej.machulak

                          Hi,

                          Yes. As Jonathan said the proposed approach might be generalised and decoupled from Web Services
                          as long as it is possible to provide mechanisms to interact with the transaction coordinator.

                          What I would like to achieve at this moment is to slightly restructure the code and decouple it
                          from the XTS (XML Transaction Service) implementation - by providing some sort of a Transaction
                          Factory. In general it would also make the code easier to apply support for transactions not
                          dependent on Web Services.

                          BTW, thank you for the first comment:)

                          Cheers,
                          Maciej M.

                          • 10. Re: Metadata Support for Transactional Web Services
                            marklittle

                            Bill, is this more in line with what you're after?

                            The BA compensation implementation is entirely de-coupled from the Web Services protocol/SOAP stack and has been since it was first developed in 2002. So that's what makes JBTM-248 possible.

                            However, Jonathan's right in that Maciej's MSc dissertation is much more narrowly focussed. So it makes sense that his annotations are at the Web Services level. But generalizing it is something I'd like us to do at some point. Since the underlying transaction implementation is deployment agnostic, it makes sense. Back in HP in 2000, there were no such things as Java annotations, but we had a similar approach based on XML definitions that were processed concurrently with the business objects and service definitions. Same concept, just a bit more clunky.

                            • 11. Re: Metadata Support for Transactional Web Services
                              marklittle

                               

                              "maciej.machulak" wrote:
                              Yes. As Jonathan said the proposed approach might be generalised and decoupled from Web Services
                              as long as it is possible to provide mechanisms to interact with the transaction coordinator.


                              It is. However, one step at a time. I think we all agree that what you've done so far is cool. Maybe Jonathan can even feed it into JSR 156 development?


                              What I would like to achieve at this moment is to slightly restructure the code and decouple it
                              from the XTS (XML Transaction Service) implementation - by providing some sort of a Transaction
                              Factory.


                              I'm not entirely sure what you mean by this.

                              • 12. Re: Metadata Support for Transactional Web Services
                                maciej.machulak

                                Hello,



                                What I would like to achieve at this moment is to slightly restructure the code and decouple it
                                from the XTS (XML Transaction Service) implementation - by providing some sort of a Transaction
                                Factory.


                                I'm not entirely sure what you mean by this.


                                At this moment my code relies on the API provided by XTS. What I thought of is that it might be nice to have some sort of a transaction factory which would provide me with common methods for creating and enlisting participants in Business Activities. It would hide details of the underlying transaction service. I could then encapsulate implementation specific code and make the overall framework easier to extend.

                                Cheers,
                                Maciej M.

                                • 13. Re: Metadata Support for Transactional Web Services
                                  maciej.machulak

                                   

                                  "maciej.machulak" wrote:
                                  Hello,

                                  At this moment my code relies on the API provided by XTS. What I thought of is that it might be nice to have some sort of a transaction factory which would provide me with common methods for creating and enlisting participants in Business Activities. It would hide details of the underlying transaction service. I could then encapsulate implementation specific code and make the overall framework easier to extend.


                                  But of course the framework would still rely on XTS. It will be just much easier to replace XTS with some other transaction service - possibly not related to Web Services.

                                  Maciej M.

                                  • 14. Re: Metadata Support for Transactional Web Services
                                    marklittle

                                     

                                    "maciej.machulak" wrote:
                                    Hello,



                                    What I would like to achieve at this moment is to slightly restructure the code and decouple it
                                    from the XTS (XML Transaction Service) implementation - by providing some sort of a Transaction
                                    Factory.


                                    I'm not entirely sure what you mean by this.


                                    At this moment my code relies on the API provided by XTS. What I thought of is that it might be nice to have some sort of a transaction factory which would provide me with common methods for creating and enlisting participants in Business Activities. It would hide details of the underlying transaction service. I could then encapsulate implementation specific code and make the overall framework easier to extend.


                                    There are no common methods/interfaces. With the exception of JSR 156 none of the compensation transaction API work has ever been standardized. WS-BA is a standard for the on-the-wire protocol (as are other WS-* standards/specifications). It doesn't define an API.

                                    1 2 Previous Next