Hi, I have the following requirements/specification where I want to write web service client : - It should integrate in spring framework. - I am calling methods that I think will need transaction.I have not explored yet but most of the methods are saving operations. which should I use for client ? Axis 2 or XFire or Spring Web Service .. Also send me any link/example if you have for consuming web service in spring framework.
Given that you are working from within Spring I'd give it a shot first. However working with Spring is a bit of a pain because they don't provide a WSDL-to-Java code generator. They rely on a more general XML messaging framework that isn't focused on SOAP. It revolves around the WebServiceTemplate which can use a variety of message factories (SaajSoapMessageFactory, AxiomSoapMessageFactory, DomPoxMessageFactory). There is a client and server side example in Spring In Action 2e (Chapter 9). Using Spring Web Services to create a web service How to call a WebService with Spring-WS through a Proxy
I am calling methods that I think will need transaction.
The service is free to use transactions on its side - but propagating transactions from client to the service is an entirely different matter. That requires additional specialized protocols on top of SOAP (Web services transactions) which requires additional infrastructure. Furthermore JTA focuses on enabling 2PC (Two-Phase Commit) but 2PC is a form of tight coupling. In order to stay loosely coupled web services favor compensation (Your Coffee Shop Doesn�t Use Two-Phase Commit (PDF)).
User's looking to use XFire on a new project, should use CXF instead. CXF is a continuation of the XFire project and is considered XFire 2.0. It has many new features, a ton of bug fixes, and is now JAX-WS compliant! XFire will continue to be maintained through bug fix releases, but most development will occur on CXF now. For more information see the XFire/Celtix merge FAQ and the CXF website.
CXF concentrates on developer ergonomics and embeddability. Most configuration is done via the API instead of cumbersome XML files, Spring integration is heavily emphasized, including support for Spring 2.0, and CXF's APIs and Spring configuration mirror one another fairly closely. CXF emphasizes code-first design, using simple APIs to make development of services from existing applications easier (and its embeddability helps too).
However this part of CXF should be cause for serious concern:
CXF emphasizes code-first design, using simple APIs to make development of services from existing applications easier.
Now "code first design" is of little consequence when you are simply consuming web services, i.e. you are acting as a web service client. However if you ever are going to provide a web service then you should strongly favor the contract first approach.
"Code first" is usually supported because developers like it. Developers like it because they can "build a web service" without having to invest too heavily into learning about web services and it lets them stay inside the comfort zone of their implementation language. However this approach tends to lead to web service interfaces that are polluted by concepts from the implementation language. This "pollution" creates the risk that at best the web service isn't as easy to use from clients that may be using a different web services stack and/or implementation language, at worse limit its interoperability. For example, even though XML Schema officially supports "inheritance" some experts recommend that it should not be used in a web services contract as there is no guarantee that the client implementation can adequately support the concept. Then of course there is the entire matter of the object-hierarchical impedance mismatch (pdf). [ February 06, 2008: Message edited by: Peer Reynders ]