Spring WS vs Axis2

[MikeOliverAZ]

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

[Grzegorz Grzybek]

@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

[MikeOliverAZ]

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

[subashini]

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

[MikeOliverAZ]

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