What do you need to learn Java web services?

Question

The last time I was doing Java web development, I was in 2004 using Java Servlets and JSPs. I've never been anywhere with EJB. I recall my experience in developing web services \ dynamic websites with their slow (in terms of development time) and painful (in terms of simple deployment).

What do most companies use to develop Java-based websites these days? Do you use AXIS or any other infrastructure for working with web services? Are you using JSP or some other technology for the interface?

Answer 1

Current standards use JAX-WS (for SOAP web services) and JAX-RS (for RESTful web services).

These are standards that have many implementations. JAX-WS has Metro, CXF, etc. JAX-RS has Jersey, RESTEasy, etc.

Answer 2

I would recognize them in order

• REST
• Xsd
• Wsdl
• JAX - *
• Alternatives? (Thrift, Avro, protocol buffers, etc.).

Answer 3

Tool support, as well as ease of development, have also come a long way since 2004. With an increased focus on lightweight frameworks (thanks in part to spring), implementing web services in java could not be easier.

Before you decide to implement web services, you need to answer a simple question. Soap or REST.I guess you are forming your own opinion, but here's what I could think on my head.

Pros of SOAP:

• Great tool support.
• The most common technology.
• The JAX-WS standard is very mature.
• Ease of development. (Annotation support for converting POJO to webservice).
• Example METRO, Axis ...

Against SOAP. (Ask Roy Fielding ..)

• Untied Protocol.
• Protocol configuration is possible, but complex. (using wsdl binding, etc.).
• The client needs a sophisticated library for serializing and deserializing soap messages.
• Platforms such as Android do not natively support SOAP.

After Roy Fieldings exposes the bloated web services protocols webservices , and he puts forward the argument of common sense to use the back of the Internet for SOA, there has been a gradual move to REST. More flexible companies, such as Google and Amazon, have adopted REST and advocate for REST-based web services.

REST Pros:

• Very lightweight protocol.
• Mostly based on HTTP, and therefore most clients know how to consume them. (but REST does not have to be HTTP).
• Error management and ideas like Cache are based on proven Internet technologies.
• Java has excellent REST libraries. Sun own Jersey is an excellent implementation of Jax-RS, and there are Restlet, Jboss Rest Framework and Spring REST (although not compatible with JAX-RS).

Against REST:

• Relatively poor tool support.
• Implementing security in REST is a bit difficult.
• Resource-oriented design and implementation may be new to some traditional programmers and architects.

My preference is REST with Jersey. Its awesome structure, excellent support, excellent documentation, good support libraries for testing.

In any case, I will download the Netbeans IDE and use it to develop skeleton code for the REST or SOAP web service. Netbeans is very easy to get started. Once you are happy with the code, you can switch to your favorite IDE. (By the way, I do not use Netbeans for anything other than prototyping, it tries to do a lot and does most of them poorly .. his opinion is mine anyway)

Answer 4

My preferences are Apache Avro (mentioned in @rodrigoap's answer). Where I work now, we have a service-oriented architecture and use of Avro for internal services. We chose it because it is fast, stable, it can work via http (easily maintained by Tomcat), it can automatically generate client classes and work with several languages. The generation of client classes was a big feature for us, as this means that we only deal with Java objects and allow Avro to serialize and send things over the network. It's also nice not to deal with many different URLs. The Avro web service is hosted on a single servlet, and Avro takes care of how to map each request to the appropriate method in your implementation class.

To refer to @rodrigoap again, he placed several other options in front of Avro on his list, and for web services that are accessed from the outside, I would agree that this is the best choice, since your external service users are probably not interested in using Avro just because you might have chosen it.

In case you are interested in an example, here is a sample of the Avro web service to break through and see how it works.