This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Spring WS vs Axis2

Mar 14th, 2011, 11:47 PM

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.

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 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.

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).

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!

Comment

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

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!

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.

Comment

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

Comment

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

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 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.

Comment

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