Spring WS vs Axis2

[srisris]

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.

[Grzegorz Grzybek]

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

[Grzegorz Grzybek]

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

[skram]

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

[leaqui]

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

[Grzegorz Grzybek]

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

[leaqui]

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

[Grzegorz Grzybek]

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

[MikeOliverAZ]

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?

[WEBparul]

thanks for this posting, this is really helpful