I'd like to add a few things here.

Jersey is an implementation of JAX-RS. It has 3 major pieces: jersey-core, jersey-client, jersey-server. (The name should be obvious what they are for).

If you're writing JAX-RS services, you can return a few different formats: XML, JSON, ATOM. All you need to do is to annotate the method with the following annotation:

  // will return XML or JSON depending on the request from the client.

  @Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON }) 

This is a big win if you need to support both.

  - Object to XML conversion is done by JAXB.
  - Object to JSON conversion is done by Jackson via JAXB.

Jersey is part of JavaEE 6 standard (part of your Application Server if it supports it).

What's lacking from JavaEE 6 is an MVC framework which is targeted for JavaEE 7.

Another key feature is JAX-WS (the plain old SOAP WebService). The nice thing about JavaEE 6 is that the minimum differences in the programming style between JAX-RS and JAX-WS.

JAX-RS operates according to resources (e.g.: give me all students, give me student with id=1, delete student with id=1, etc). So some of the examples would be:

  // Rough pseudo-code, omitting a few JAX-RS annotation

  public class StudentResource{

  @Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })

  public <List> all(){}

  @Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })

  public Student get(long id){}
  }

JAX-WS operates according to services (e.g.: initiateInvoiceWorkflow, performPayment, etc).

  public interface AccountingService{

    @WebMethod(operationName="initiateInvoiceWorkflow" ...)

    Invoice initiateInvoiceWorkFlow();

  }

  // have your implementation...

So in theory, you can have something that's called StudentRepository where you can use that repository with both JAX-RS (REST) and JAX-WS (WebService) implementation easily (I've done this and it's quite straightforward) if your "Enterprise client" forces you to do so.

The important bit here is testing. You can easily test both JAX-RS and JAX-WS implementation in both unit-test or integration-test. You can easily do unit-test because you don't need to deploy them to the server: they're just normal Java classes. You can do integration test by deploying them to the server and generates the client implementation (in which I'll cover next).

The client-side implementation of JAX-RS is also similar to that of JAX-WS programming style.

In JAX-WS, you grab a WSDL, throw it to a generator tool that comes with JDK to generate the model (Invoice, Student, etc) and the proxy client-side to call the server-side. Very very straightforward, 5 minute job.

In JAX-RS, you'd use jersey-client to perform HTTP call as follow:

  // url  => is a string that points to JAX-RS end-point e.g.: student/1
  // header => json? xml? atom?
  // type => (typeof Student) (well... it's Java).
  Student student = Client.create().resource(url).accept(header).get(type);

Keep in mind that in the client-side, your Student class must have roughly the same structure and must be annotated using JAXB XML annotation (the client-side also relies on JAXB -> Jackson -> Java object conversion for the case of JSON, or just JAXB -> JAva object for the case of XML).

So no hacking using XPath or something like that (I work in Ruby once in a while and when I read some of the 3rd-party libraries/gems that implement client-side API against popular service provider, most of the implementations do brute force using XPath querying node element and stuff).

PS: Excuse me for the poor formatting, where can I learn to format my comment?

UPDATE: fix the format.

Oh and one more thing: JAX-RS (Jersey) is just an implementation on top of Servlet. So all of your previous knowledge regarding to Servlet (Context, deployment, URL, Filter) will be definitely useful.