Announcement Announcement Module
Collapse
No announcement yet.
Spring WS vs Axis2 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring WS vs Axis2

    My last application had Axis2 web service and used contract last approach. We had a new requirement for creating a web service and I used Spring Web service. A discussion came up in the meeting that why use Spring WS when we already have the required Axis2 libraries to create new web service. I was convincing my team because Spring has Contract first approach which is the best way of creating and all other best points mention in the chapter 2 of the documentation.

    But their point was Axis 2 also has contract first.

    I would really appreciate anyone since I am really new to web services and still learning what is the difference between Axis 2 and Spring WS. I like an elaborate answer for our better understanding.

    Thanks in advance.

  • #2
    Hi

    Here's my short answer:

    Although Axis2 supports JAX-WS standard, it has many proprietary quirks you have to deal with. Axis2 is an attempt to modernize Axis1 - it has developed it's own Object Model (OMElements), it's own deployment descriptors, generators, etc. The most important aspect of Axis2 (from the developer's/deployer's perspective) is that it is a Web Application (WAR) on it's own and web services are deployed into WEB-INF/services directory as AAR archives. Without judging this approach, I can say that this introduces many problems with testing, packaging (Maven), deploying, upgrading and versioning.

    My real-life problems with Axis2 were:
    • accessing JNDI datasources (two or more AARs had the same jndi resource name)
    • logging (logj/logback) configuration
    • classloaders (Axis2 has it's own WEB-INF/lib/*.jars and AARs have their own JARs)
    • testing without Axis2 servlet running
    • reading generated service skeleton classes (aah! my eyes!)

    The advantage of Axis2 is that it gives you access to several modules (MARs): WS-Security, WS-RM, ... but the same you can find in CXF.

    Generally you should not decide between Axis2 and Spring-WS, but between CXF and Spring-WS and the latter is the choice between sticking (generally) to JAX-WS 2 API and Spring's clean and elegant approach to contract-first web services.

    I won't give you comparison between Spring-WS and CXF. I'll just give you advantages of Spring-WS:
    • very (very, very, very, very ^100) clean API, model and configuration of WebServices
    • very thin layer of the core webservices (by the term I mean the code which is invoked after receipt of SOAP message and invocation of your code)
    • very clean mapping of SOAP messages to methods (WS-Addressing with @Action, SOAP mapping with @SoapAction, @PayloadMapping, ...)
    • what's very important is that the general flow of WebService message handling is analogous to the way HttpServletRequests are routed to your Controller classes in Spring MVC.
    • lack of dedicated "SpringWS web application" - it's just ordinary servlet or (even) ordinary SpringMVC controller.
    • very easy and clean way of mixing WebService endpoints and SpringMVC controllers (when you want to WebService-enable your existing SpringMVC application)
    • very easy unit/integration testing
    • no generated code
    • no generated, unreadable deployment descriptors
    • use of different XML marshalling libraries (Axis2 does that too)

    So - if you want clean and elegant solution (if you're sensitive to that aspect of development), choose SpringWS. If you like JAX-WS API, choose CXF, if you want problems with debugging weird behaviors - choose Axis2.

    regards
    Grzegorz Grzybek

    Comment


    • #3
      And one more thing: if you want WS-Reliable Messaging, WS-Coordination, WS-Atomic Transaction, WS-Policy, WS-Eat My Shorts, choose CXF.

      If you don't want this crap (do you imagine that Microsoft's implementation of WS-RM doesn't conform to Microsoft's specification? do you imagine that WS Adressing Metadata's XSD uses incorrect version of WS-Policy's XSD?, do you imagine that once I had to use WebService for retrieving high volume of data regarding energy-meters readings, which used WS-RM (slowing the process by 100x factor?)) then choose Spring WS.

      Speaking reasonably: WS-* are not as useful as they seem (especially WS-RM and WS-Transactions).

      regards
      Grzegorz Grzybek
      Last edited by Grzegorz Grzybek; Mar 15th, 2011, 01:56 AM.

      Comment


      • #4
        I believe jeccia's post is nonsense and a scam. Mods please delete the post

        Comment


        • #5
          Originally posted by Grzegorz Grzybek View Post
          And one more thing: if you want WS-Reliable Messaging, WS-Coordination, WS-Atomic Transaction, WS-Policy, WS-Eat My Shorts, choose CXF.

          If you don't want this crap (do you imagine that Microsoft's implementation of WS-RM doesn't conform to Microsoft's specification? do you imagine that WS Adressing Metadata's XSD uses incorrect version of WS-Policy's XSD?, do you imagine that once I had to use WebService for retrieving high volume of data regarding energy-meters readings, which used WS-RM (slowing the process by 100x factor?)) then choose Spring WS.

          Speaking reasonably: WS-* are not as useful as they seem (especially WS-RM and WS-Transactions).

          regards
          Grzegorz Grzybek
          Hi Grzegorz, which alternatives do we have instead of WS-Atomic Transaction for Distributed Transactional web services?
          Thanks!

          Leandro

          Comment


          • #6
            Hi

            Hi Grzegorz, which alternatives do we have instead of WS-Atomic Transaction for Distributed Transactional web services?
            Thanks!
            Sorry for me being rather rude about (among others) WS-Atomic Transactions. I'd rather like to say that distributed web services transactions should be last resort. It's better (in terms of scaling, performance and maintenance) to demarcate transactions at single services level - and not including multiple WS invocations in one transaction. But if you must use distributed web services transaction, use WS-Coordination + WS-Atomic Transactions, because ... they're standard way to do that sort of processing.

            There are many articles about using compensation techniques instead of "old school" distributed XA transactions (see an example pattern at http://www.soapatterns.org/compensat...ransaction.php). Sorry for not giving you some links, but you should easily find some articles about how Amazon, Facebook and others use transactions, ACID in high-performance applications.

            regards
            Grzegorz Grzybek

            Comment


            • #7
              Thanks Grzegorz for the reply, in our case it's impossible to use a compensation strategy because we need this for some financial operations. So I think we don't have a better alternative than WS Atomic Transaction.

              Do you think it could be easy to use WS-AT in Spring?
              Do you think that WSIT could be easily integrated with Spring? or suggest any other implementation of WS-AT?
              Thanks!

              Leandro

              Comment


              • #8
                Hi

                I must say I don't have much experience with WSIT (Metro). There's a chapter in Metro's User Guide (http://metro.java.net/guide/Using_WS...th_Spring.html) about integration with Spring but it refers to other chapters.

                I think it should not be that hard to integrate WSIT and Spring, because in simpliest case, Spring would not be a part of transaction management. But if you want to have Spring manage WebServices transaction as part of PlatformTransactionManager ... I can't tell because I haven't done that.

                regards
                Grzegorz Grzybek

                Comment


                • #9
                  So if you already have your java POJOs and you want to expose their methods via Web Services, isn't Contract Last and CXF the only option?

                  Comment


                  • #10
                    thanks for this posting, this is really helpful
                    Last edited by WEBparul; May 21st, 2011, 03:16 AM.

                    Comment


                    • #11
                      At least I asked a legitimate question, what did you contribute?

                      Comment


                      • #12
                        @MikeOliverAZ

                        If you have POJOs, than contract doesn't have choice - it has to come last

                        I also like another approach (it works in enterprise project, which was developed in several days, but it has to be maintained forever) - I call it "contract first and implementation first) - I write WSDLs/XSDs and POJOs with JAXB annotations and interfaces with Spring-WS (@Action) annotations. All by hand. It gives me freedom, control and satisfaction

                        regards
                        Grzegorz Grzybek

                        Comment


                        • #13
                          Originally posted by Grzegorz Grzybek View Post
                          @MikeOliverAZ

                          If you have POJOs, than contract doesn't have choice - it has to come last

                          I also like another approach (it works in enterprise project, which was developed in several days, but it has to be maintained forever) - I call it "contract first and implementation first) - I write WSDLs/XSDs and POJOs with JAXB annotations and interfaces with Spring-WS (@Action) annotations. All by hand. It gives me freedom, control and satisfaction

                          regards
                          Grzegorz Grzybek
                          Fully agree Grzegorz. Many of the Rapid Application Development Tools can save a bunch of time and many like Roo actually adhere to some pretty decent practices. But your "maintained forever" often leads me to spend the time to do it "by hand" which at least lets me touch all the code and put it in memory (my brain) for later. I was asking just in case someone had a tool or technique with Spring WS that was as good or better than the Apache CXF tools to go from Pojo to basic WSDL. Then use Spring WS to implement services from that.

                          Comment


                          • #14
                            Originally posted by Grzegorz Grzybek View Post
                            Hi

                            Here's my short answer:

                            Although Axis2 supports JAX-WS standard, it has many proprietary quirks you have to deal with. Axis2 is an attempt to modernize Axis1 - it has developed it's own Object Model (OMElements), it's own deployment descriptors, generators, etc. The most important aspect of Axis2 (from the developer's/deployer's perspective) is that it is a Web Application (WAR) on it's own and web services are deployed into WEB-INF/services directory as AAR archives. Without judging this approach, I can say that this introduces many problems with testing, packaging (Maven), deploying, upgrading and versioning.

                            My real-life problems with Axis2 were:
                            • accessing JNDI datasources (two or more AARs had the same jndi resource name)
                            • logging (logj/logback) configuration
                            • classloaders (Axis2 has it's own WEB-INF/lib/*.jars and AARs have their own JARs)
                            • testing without Axis2 servlet running
                            • reading generated service skeleton classes (aah! my eyes!)

                            The advantage of Axis2 is that it gives you access to several modules (MARs): WS-Security, WS-RM, ... but the same you can find in CXF.

                            Generally you should not decide between Axis2 and Spring-WS, but between CXF and Spring-WS and the latter is the choice between sticking (generally) to JAX-WS 2 API and Spring's clean and elegant approach to contract-first web services.

                            I won't give you comparison between Spring-WS and CXF. I'll just give you advantages of Spring-WS:
                            • very (very, very, very, very ^100) clean API, model and configuration of WebServices
                            • very thin layer of the core webservices (by the term I mean the code which is invoked after receipt of SOAP message and invocation of your code)
                            • very clean mapping of SOAP messages to methods (WS-Addressing with @Action, SOAP mapping with @SoapAction, @PayloadMapping, ...)
                            • what's very important is that the general flow of WebService message handling is analogous to the way HttpServletRequests are routed to your Controller classes in Spring MVC.
                            • lack of dedicated "SpringWS web application" - it's just ordinary servlet or (even) ordinary SpringMVC controller.
                            • very easy and clean way of mixing WebService endpoints and SpringMVC controllers (when you want to WebService-enable your existing SpringMVC application)
                            • very easy unit/integration testing
                            • no generated code
                            • no generated, unreadable deployment descriptors
                            • use of different XML marshalling libraries (Axis2 does that too)

                            So - if you want clean and elegant solution (if you're sensitive to that aspect of development), choose SpringWS. If you like JAX-WS API, choose CXF, if you want problems with debugging weird behaviors - choose Axis2.

                            regards
                            Grzegorz Grzybek


                            thanks for sharing nice information






                            __________________________________________________ _______________________________

                            Plc Training In Chennai

                            Comment


                            • #15
                              Anyone have any insight into using Spring WS with Spring Roo DBRE? Since the Entity class is empty from the DBRE, and all the fields are in the DBManaged.aj aspect, I don't quite know where to start to generate a WSDL/SOAP interface into the CRUD operations of the Entity.

                              I suppose I can hand code the WSDL but i have many complex Entities so that seams daunting. I thought of mocking up the entity classes then using CXF to generate the code against the mockups, test and then change the reference from the mock to the DBRE generated entity, but I get an uneasy feeling thinking about it. I thought about using CXF to generate the code, then change the code into an Aspect and adding an annotation to that aspect to the DBRE generated entities.

                              It would be wonderful if someone had a Roo plugin for Spring WS to add a command like

                              springws --class ~.model.SomeClass --package ~.service --wsdl c:/temp/SomeClass.wsdl

                              or a Roo plugin for CXF

                              cxfjava2wsdl --class ~.model.SomeClass --package ~.service --operations CRUD
                              cxfwsdl2java --file c:/temp/SomeClass.wsdl --package ~.service

                              Comment

                              Working...
                              X