What to learn to do Java web services?_问答_开发者

The last time I did Java web development was in 2004 with Java Servlets and JSP. I never really got anywhere with EJBs. I recall my experience in developing web services\dynamic web sites with these to be slow (in terms of development time) and painful (in terms of easy deployment).

What do most businesses use to develop Java based websites these days? Do you use AXIS or some other 开发者_JS百科framework to do web services? Do you use JSP or some other technology for the front end?

The current standards are to use a JAX-WS (for SOAP web services) and JAX-RS (for RESTful web services).

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

I would learn these in order

REST
XSD
WSDL
JAX-*
Alternatives? (Thrift, Avro, Protocol Buffers, etc)

The tooling support and also the ease of development, has also come a long way from 2004. With increased focus on lightweight frameworks (thanks partly to spring), implementing web services in java could not be easier.

Before you decide on implementing web services, you need to answer a simple question. Soap or REST.I suggest that you form your own opinion, but here is what I could think, on the top of my head.

Pros of SOAP:

Excellent tooling support.
Most prevalent technology.
JAX-WS standard is very mature.
Ease of development. (Annotation support to convert a POJO to webservice).
Example METRO, Axis...

Cons Of SOAP. (Ask Roy Fielding..)

Bloated Protocol.
Customization of protocol is possible but complicated. (using wsdl binding etc..)
Client needs complex library to serialize and deserialize soap messages.
Platforms like Android does not support SOAP natively.

After Roy Fieldings rant on bloated web service protocols webservices and he putting forth the common sense argument to use the back bone of internet for SOA, there was a gradual motion towards REST. More agile companies like Google and Amazon have adopted REST and are championing the cause for the REST based web services.

Pros of REST:

Very lightweight protocol.
Mostly Based on HTTP and hence most clients know how to consume. ( 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's own Jersey is an excellent Jax-RS reference implementation and there is Restlet, Jboss Rest Framework and Spring REST (although not compliant with JAX-RS).

Cons of REST:

Relatively bad tooling support.
Security Implementation in REST is slightly difficult.
Resource Oriented design and Implementation could be new for some traditional programmers and architects.

My preference is REST with Jersey. Its an amazing framework, excellent support, excellent documentation, good support libraries for testing.

Either way I will download Netbeans IDE and use it to develop the skeletol code for either REST or SOAP based web service. Netbeans makes it very easy to get started. Once you are comfortable 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 badly.. its my opinion anyway)

My preference is Apache Avro (mentioned in @rodrigoap's answer). Where I work now, we have a service oriented architecture and use Avro for internal services. We chose it because it is fast, stable, can run over http (easily served out of Tomcat), can generate client classes automatically, and works with several languages. The generation of client classes was a big feature for us as it means we only deal with Java objects and let Avro deal with serialization and sending things across the network. It's also nice not to have to deal with lots of different url's. An Avro webservice is hosted from a single servlet and Avro takes care of how to map each request to the appropriate method in your implementation class.

To reference @rodrigoap's answer again though, he placed several other options before Avro in his list, and for web services that are accessed externally, I'd agree that those are better choices, as your external service users probably aren't interested in using Avro just because you may have chosen it.

In the case that you're interested in an example, here's a sample Avro web service project to poke through and see how it works.