Best approach for creating new RPC/web services in the Java world?

Question

I think this question may end up being a bit subjective so I'm marking it as CW.

My team is interested in developing a new set of "web services" for our projects to use. I put "web services" in air-quotes since the term can mean so many different things. The only thing we really need it to mean is that we can expose some set of APIs to cross-platform clients to consume our data and take action on it.

I'm attempting to do some research to understand what the current "state of the art" is when it comes to creating services for exposing your data to lots of other (internal) applications and even other services. I've been researching things like Thrift, Protocol Buffers, JAX-WS, RMI, etc., and I'm kind of lost as far as figuring out what kind of approach we should take in designing a new set of services. I'd like for us to be able to essentially create an "infrastructure" for services, which is why I'm taking a bit of a survey of all current approaches.

For building brand-new-from-scratch web services, where does the current best practice / state of the art lie?

Our only real requirements are:

• The data format/encoding should be platform independent (this rules out RMI).
• Services should work well over HTTP
• Writing the actual server-side services in Java should not be a problem.
• Being able to generate client proxies would be a nice plus.
• I'd like each service to be light-weight, where we could conceivably deploy services for different functionality as completely separate deployments.

We currently use some combination of SOAP and Axis/JAXRPC services and honestly these are a giant pain to work with - the messages sent back and forth are huge and overly verbose.

Answer 1

Have you considered a REST service ? Here's a useful introduction from InfoQ.

It works over HTTP, and you use the standard HTTP commands of GET/PUT/POST/DELETE to manipulate data (you can query using browsers and clients are simple HTTP clients). The actual data content is not mandated or specified - often it's XML but that's not a requirement.

You can build REST services trivially under Java using Jersey. Because the clients just need to talk HTTP they can be language-independent. Java clients can be written using HTTPClient.

Answer 2

Probably too late but I'll try anyway. SOAP has long lost its first letter (Simple). It never stood up to its second one (Object), either.

That's why I am leaning towards JSON-based services, either REST or JSON-RPC ones. You got quite a few recommentations for the former already. For the latter you may want to look into Jabsorb.org. As an example, OpenSocial standard uses both with the preference towards the JSON-RPC.