Java Web Services - Is Axis Necessary?

Question

Is AXIS or CXF necessary for Java web services? Can it be all done via the JDK (1.6)?

Solution 1

Is AXIS or CXF necessary for Java web services?

No. Although Axis2 is the most popular framework to work with Web Services is not the only way to do them.

Can it be all done via the JDK (1.6)?

Yes, but it is way much harder. You will benefit tremendously from using a framework used by others apps and from the bug fixes the development team provide. Doing all by hand is like reinventing the wheel.

If you want to have full control of what's happening underneath, probably you could go with: JAX-WS

or if the application is very simple, directly with socket.

But again, Axis2 is the canonical way to do WS ( but not the only one )

Solution 2

The following is based on an all to true and personal story:

So you want to consume a web service in your Java web application, and you don't want to add 10MiB of JARs to your lean 1.3 MiB .war file, and besides you are great at parsing XML (you can hand code XPath Queries, and XSLT files), you totally understand HTTP, and the client you are interfacing with has great documentation. You download the WSDL look at your endpoints and your methods and start creating a Java class that maps to the features you are going to need. You feel great already.

They you start reading up on how to send a SOAP request and you think well this looks a little verbose but what they hey it's all just a string, so you start building a utility that takes your Java request object and converts it to a SOAP request. You send your clear SOAP request to the server but it gets denied (missing a signature).

So now you start adding encryption JARs to your project and you start looking at how to calculate a signature of part of an XML document and include both it and the document in the request. This takes you a while but with enough hacking you get a message that you can send to your soap service and you are now dealing with the SOAP response. Now you are feeling great...

Until the admin at your client changes their security requirements, issues new public keys, and updates the soap interface with some custom types, and your next client who is running a similar service (but on a Windows Server) wants you to implement with them as well.

At this point I gave up trying to implement this in a pure Java way and just started using standard libraries. They deal with stuff like encryption, marshaling, deviations form the standards and they let you focus on stuff that is closer to your problem domain. I hope you can save yourself the lost month it took me to learn this lesson.

Solution 3

An update on the landscape of web services in 2013.

Web services used to be SOAP and XML-based. Web services were standardized into JAX-WS. Some of the more popular frameworks are (were):

• Axis 1.x
• Axis 2
• Apache CXF - CXF also includes other protocols. It is a much broader framework
• Metro Web Services which includes the JAX-WS Reference Implementation.
• Java 6 and Java 7 include the JAX-WS RI by default. It means that frameworks are no longer needed except to generate client and service stubs / skeletons

There are other implementations not listed here that are vendor-specific e.g. IBM Websphere's WS implementation and Weblogic's WS implementation.

Generally though, to create web services, I would recommend Metro and the JAX-WS RI.

Note that there are many WS-* standards e.g. WS-Security which may not be part of all WS implementations.

Since web services have been around for a while, other alternatives have come up both in terms of architectural style, protocol, and encoding.

For instance, XML used to be the de-facto encoding. JSON is now more prevalent. It is worth looking into Jackson, a JSON parser, or Google GSON. The main arguments in favor of JSON are that it is easy to use, lightweight, and developer-friendly.

Along with JSON came REST. REST is an architectural style. With REST, you can still implement "web services" in the sense of remote services that can be easily consumed over a network. REST has also been standardized in the Java family of standards as JAX-RS. Some of the popular JAX-RS implementations include CXF, Jersey, and RESTLet.

Finally, there are some new kids on the block that use binary encodings. Those are Google Protocol Buffers and Apache Thrift. Their main goal is performance as well as broader support for other languages (Java, C#, Erland, Perl...).

When developing a web service today, the question should be: - do I care about performance? - do I want to access the service from many different languages? - do I want mobile-friendly?

These should help you guide your choice. Also, I prefer to keep my dependencies to a minimum. This means I would rather take something that is native to the JRE or JDK e.g. the JAX-WS or JAX-RS reference implementation.

Solution 4

As an alternative to Axis, you can use the Spring WebServices framework to run your webservices application within a J2EE container like Tomcat or anything similar. I've found it very easy to use and setup, and if you want to integrate your webservices into another web application later, it's quite easy to do (I've done so myself on two separate occasions).

Solution 5

You can use the http streams provided by the webserver as you whish, but using a framework and some jars (which are proven to work) will save you a lot of headaches and a lot of time in the long run.

View more solutions

Comments

[Yishai]

Are you talking about calling or providing a web service?

[William Brendel]

Just a guess, but he probably wants a little more detail than that.

[OscarRyz]

@Willliam: Edited to add more detail. I thinking that no matter what else is added at the end the answer will be the same. Is Axis necessary? No, Can be done with JDK? Yes, but it is much harder. : )

[duffymo]

Axis1? Bad. Axis2? Even worse. +1 for Spring web services.

[gonephishing]

Can you please update this answer for 2016? What has changed and what are the new standards? Do you have any blog posts that goes into more details on the same?

[David Brossard]

I would say that JSON, REST, and Jersey are the way to go: it is more lightweight and easier to use.