What do you usually use to connect to a Web Service when you are developing a Java project?
There are different API-s that can do the job. From different books and tutorials I have read about: JAX-WS, JAXB, JAXM, JAXR, JAX-RPC, Axis ans so on.
I'm interested in what exactly are you using and how much? Take this as a survey if you wish :)
Because we have quite heavy investment in Spring, we use Spring-WS with JAXB.
you can use, apache axis. This will generate the java stubs automatically if you provide the WSDL. once the stubs are generated its just like calling a normal java class.
I've used both JAX-WS RI and Apache CXF. If you are using Spring then CXF is a very good option. As Phill mentioned, there is Spring-WS as well, but CXF builds upon the JAX-WS spec. If you are not using Spring then I would say that the RI is the way to go, especially since it is bundled with Java 6.
For POX+HTTP or RESTful web services, Restlet or a decent HTTP client implementation are completely sufficient.
I think the most common use is with Apache Axis2. It's very easy to create services with it and you will find a lot of tutorials.
Axis proponents here need to be precise.
The Axis 1.x project was abandoned after Axis 1.4 was released in April 2006, over three years ago. We've recently encountered several very critical thread safety bugs in the Axis 1.4 client libraries, including 100% CPU spins and deadlocks. These are well documented (and still unresolved) in the Axis 1.x bug database. Needless to say we are giving up on Axis 1.x and just using raw Apache HTTP client code.
Axis 2 is an entirely new code base ... perhaps someone else can comment on it.
Based on our experience we'd consider Metro, CXF, hand-coding, and (maybe) Axis 2 for SOAP web services. (We recommend REST-based approaches over SOAP whenever you have a choice, and love Restlet.)
IMO, you'd be absolutely nuts to go with Axis 1.x
To answer your question, we first need to differentiate between the tools you listed.
JAX-WS, JAXB, JAXM, JAXR, JAX-RPC are XML and Web service related APIs while Axis 1 and 2 are implementations of zero, one, or more of these APIs depending on the version.
JAX-B 1 and 2 are XML to object binding APIs, JAX-WS is a WSDL and SOAP based Web service API and the predecessor of JAX-RPC, JAX-M is an older XML messaging API and JAX-R is an abstraction API for interacting with registries such as UDDI and ebXML.
From the Java.net JAX-RPC page:
The JAX-RPC expert group has wide industry participation with Sun Microsystems as the EG lead. The initial specification (JAX-RPC 1.0) was JSR-101 and was released in June 2002. A maintenance release followed in October 2003 providing better integration with JAXB 1.0 as well as better support for doc/literal.
The next version of the spec was renamed from JAX-RPC 2.0 to JAX-WS 2.0 and is being developed as JSR-224; this release will address a number of additional requirements in the area, and will increase the synergy between the JAXB and JAX-WS specifications. You can access the JAX-WS project page here.
Since SOAP stacks have come a long way since JAX-B 1.0 and JAX-RPC 1.0 I recommend staying far away from Axis 1.0 and XFire (which if I recall correctly doesn't even implement JAX-RPC 1). There are numerous SOAP stacks out there that implement the newer APIs (JAX-WS 2.x and JAX-B 2.x).
As others have mentioned, Axis 2, JAX-WS RI, and CXF are all valid choices. These SOAP stacks are far more mature and support many modern WS-* specifications.
A word of caution about the comments regarding using your IDE to auto-generate client code. While I am a big proponent of generating XML data binding code and JAX-WS interfaces from XSDs and WSDLs, respectively, I caution using a built-in wizard in your IDE to perform the auto-generation. If you work on a team with more than one developer or plan to modify the generated code you should consider the maintainability of such an approach.
If you have more than one developer, there will come a time when one of them is using a different version of the auto-generation tool, a different IDE, or has a different configuration in their tool. Additionally, if you auto-generate from a wizard, it is up to the developers to remember how they generated the code in the event that you need to re-generate it in the future. If you change the XSD and don't remember your configuration from the last time you auto-generated, the generated code may not align with the existing code that is already used throughout your program.
If you plan to modify the generated code, make sure that you only ever need to do it once and that from then on you are comfortable maintaining the code by hand or merging the regenerated code with your modifications on a regular basis.
Both of these issues can be avoided by scripting the code generation in your build process. JAX-WS and JAX-B both come with Ant tasks and/or Maven 2 plug-ins that are easy to use in your builds. Take these warnings seriously as I have seen multiple projects suffer through these issues when they needed to modify code that was generated 5 years ago by an employee that had since left the firm.
My final words of caution are to be careful when allowing a tool to auto-generate your Web service interfaces from your WSDLs. The JAX-WS RI WSDL2Java tool likes to place hard-coded paths to the WSDL in the generated interfaces. It is my opinion that you should auto-generate the interfaces once and then remove the hard-coded URLs and QName references to make the interface applicable to all Web services that implement the WSDL Binding that the interface represents and not just the one endpoint that your WSDL describes.