Showing posts with label XML. Show all posts
Showing posts with label XML. Show all posts

Monday, January 2, 2012

GWT with JAX-RS (aka RPC/REST) Part 2


Come unto me all ye who are weary of heavy-laden clients and I will give you REST.

Continued from GWT with JAX-RS (aka RPC/REST) Part 1


We define the lower level REST API on an interface commonly shared between the client and server. We should consider the REST API as the lower level API, while considering the plain old Java object API (POJO-API) as the higher level API. For the purpose being lazy, I would like to use the acronym POJO-API henceforth.

Since the Java interface of the REST API is shared, both client and server share the same javadoc and json object documentation.

For example, in the interface declaration:

@Path("/hello/info")
interface RemoteCall{
  @Path ("/services/greet")
  @POST
  Person getGreeting(String userName, Message msg );
}

The client invokes the call by
Person veraswamy = getGreeting(String userName, Message msg );

The server listens for the path signature of `/hello/info/services/greet` and maps it to executing the mapped POJO-API by obtaining an instance of RemoteCall from the jax-rs-ware:

remotecalls.getGreeting(String userName, Message msg );

The server-side jax-rs-ware executes the impl of the method and returns Person as a response. The client-side of the jax-rs-ware decodes the response and the variable obama is assigned the value of Person as executed on the server-side.

See -no hands-

The programmer consuming the Java API is oblivious to the underlying REST API, but simply uses the POJO methods with a purely RPC attitude. Meanwhile, the REST API is designed by the developer providing the API, who would need to ensure uniqueness of the polymorphic signature of the API.

For async calls, we run a simple text utility script over the interface methods to produce the reciprocal async-client interface. So that the getGreeting method becomes

interface AsyncRemoteCall{
  @Path ("/services/greet")
  @POST
  void getGreeting(String userName, Message msg, CallBack<person> callback );
}

So, not only do the client and server share the interface, they also share the POJO DTOs, as long as the DTOs are serializable.

This is not exactly json-rpc as JSON-RPC has usually been done. But, this is RPC nonetheless. And the POJOs are carried as JSON over the wire. OTH, this is also a form of XML-RPC over JAX-RS, because we can switch the codec from JSON to XML. In fact, we can mix both XML-RPC and JSON-RPC together on the same server, using REST as the transport. May be, what I am doing should be called JSON-RPC (or XML-RPC) over REST-RPC.

I can say that my implementation of JSON-RPC over JAX_RS allows me to share the same set of POJO interfaces, DTO and documentation between client and server.

I could run enunciate over the interface to obtain the json object documentation (or the XML-schema). So, if you choose to, you could use PHP on the server side servicing the remote procedure call.


Saturday, December 3, 2011

GWT with JAX-RS (aka RPC/REST) Part 1


Come unto me all ye who are weary of heavy-laden clients and I will give you REST.

Continued from GWT with JAX-RS (aka RPC/REST) Part 0 (preamble ramble)


JAX-RS REST with GWT is equivalent in mechanism to GWT-RPC. The similarity lies in the requirement for
  • a common Data Transfer Object interface (DTO) between client and server
  • a common Remote Procedure API, using the shared DTO definitions are arguments, between client and server;
    where REST calls it Remote Service API (rSAPI), GWT-RPC calls it Remote Procedure Call.
    where the Remote Service API specifies a return type;
  • server implementation which follows the rSAPI interface.
  • a client version of the service API (cSAPI) which includes a callback; where return_type is the return type specified in the rSAPI; so that the cSAPI returns void, translating return_type as an argument to the callback
  • client implementation which follows the cSAPI interface.

RPC over REST
JAX-RS had been invented/concocted as a server-side API definition facility. I heard that JAX-RS 2.0 is under formulation to address JAX-RS being used as a client-side facility too.

However, this series of articles centre on sharing JAX-RS definition between the client and server, using currently available frameworks, allowing the client to use REST as the RPC mechanism. Hence, if you are completely comfortable with GWT-RPC, you would also be completely comfortable with GWT-REST-RPC.

In http://h2g2java.blessedgeek.com/2009/08/gwt-rpc.html, I discussed that GWT-RPC is technically RPC over HTTP. REST is SOA embedded in HTTP transported over HTTP. (Whilst SOAP is SOA transported over http without being embedded with HTTP). Therefore,

GWT+JAX-RS = RPC over REST{SOA over HTTP}.

Frameworks involved
The frameworks involved in making RPC/REST possible are
  • JAX-RS, aka JSR-311, aka Java API for RESTful Web Services
  • JAX-B, aka JSR-222, aka Java Architecture for XML Binding
  • Jackson JSON Object schema
  • RestyGWT

JAX-RS presents two layers of API.
  • The URL schema
  • The Java API layer, which is the enabling feature for RPC over REST.

JAX-RS provides a Java annotation convention that maps the REST URL API to its Java API. There are two implementations of JAX-RS.

What is REST
REST = Representational state transfer. What's that? Never bother, just call it REST. Like SOAP, nice sounding short-form, incongruent long-form.

In a short but not too complete description REST mandates that
  • All communication with a web application should be made through a set of unique URLs.
  • That set of unique URLs is known as the API of the web service offered by the web application as a communication facade.
  • You are allowed to use the HTTP Methods of GET, POST, PUT, DELETE.
  • You are allowed to pass data either as form parameters, URL path parameters, QueryString parameters, as content or as HTTP header values.
JAX-RS is a Java language formalisation of REST.
  • @Path annotation to a class, interface, or method to map a set of URL API to their respective Java API.
    The server implementation is to monitor for requests through those URL paths to call their respective Java API method to process the request.
  • @GET, @POST, @PUT, @DELETE annotations to signify HTTP method through which a particular API should accept request.
  • The arguments to the Java API is mapped to the HTTP parameters using parametric annotations such as @PathParam, @QueryParam, @MatrixParam, @FormParam, as well as through HTTP content which are unannotated arguments.
  • @Path annotation combined with the parametric arguments and HTTP method annotation defines the unique polymorphic signature of the API.

The following are two different unique polymorphic API signatures.
  • @Path ("/services/greet")
    @GET

  • @Path ("/services/greet")
    @POST
because one accepts GET while the other accepts POST.

Again, the following are two different unique polymorphic signatures
  • @Path ("/services/greet/{userName}")
    @GET
    String getGreeting(@PathParam String userName);

  • @Path ("/services/greet/{userName}")
    @GET
    String getGreeting(@QueryParam int count, @PathParam String userName);


Tuesday, November 29, 2011

GWT with JAX-RS (aka RPC/REST) Part 0 (preamble ramble)

This is a preamble ramble about deploying REST with GWT. To skip this GWT/REST advertisement, you should proceed to the next post.

What is the purpose of deploying REST when GWT-RPC suffices? Why REST with GWT?

There is an oft cited motivation for doing REST.
  • so that you could reimplement your client using Fortran, Cobol, PHP, Python, other whatnots.
  • OTH, so that you could reimplement your server using the above stated whatnots.

Honestly, those are insufficient excuses to do REST with GWT. The purpose of having a door on your house is not "so that I could have many locks on the door". Being able to have many locks is not the direct motivation, but is simply an enabler. Therefore, the above reasons combined with the following  reasons complete the motivation why you should deploy REST instead of GWT-RPC or XML-RPC or SOAP.
  • Scalability = Mashup-ability - multi-providers, multi war, application mash-up scenarios.
  • Scalability - loose coupling between client and server.
  • Visibility = Debugability - knowing exactly the data formats and schemata that are passed between client and server.
  • Standards = Visibility - I have no idea how to decode the transported data in GWT-RPC; however, JAX-RS allows you to employ established standards of JSON and XML object schemata - namely, Jackson JSON and JAX-B XML have become popular modes of object schemata.
  • Flexibility and Simplicity = Plugin-ability - loose coupling and visibility promote ease of development, enhancement and maintenance.
  • Flexibility and Simplicity does ensure that your application can be reimplemented in a more capable future language that would one day replace Java's popularity as a business enterprise language - just as Java had replaced Cobol. It's good to plan in advance for future contingencies - but having many locks is not the motivation for having a door.
  • Diversity and MVP-friendly - you could have a diversity of clients: Desktop heavy clients such as Swing, non-ASP .NET, Qt and light clients such as GWT, Qt. Qt is an interesting technology in that the same C++ code can be recompiled on Linux, Windows, and various mobile devices.
  • Agile - Visibility, Simplicity and Flexibility allows rapid prototyping using scripts, Fiddler2 (or its FireFox equivalent), to be replaced by proper Java code when the DTO and SAPI hierarchies become more complex and entwined.
  • Agile - allow a mishmash of services written mostly in Java but supplemented with script-based service providers.
  • Simplicity, Diversity, Flexibility, Scalability, Mashup-ability = Agile and gradual technology renewal. When it is time to upgrade any part of your service framework, a RESTful implementation would allow you to do it piece-meal. 
  • Bookmarkability. This is the strongest motivation in many projects to use REST. When a bank sends you an email letting you reset your password, it is probably a URL link to a REST service. REST APIs are convenient as bookmarks and actions links. For example, your grandma does not know how to update her profile but she asks you to do it for her. Fortunately that particular web site operates on REST. So you crafted a URL and mailed/skyped it to her, telling her to click on the link after logging in to her account she wishes to update.
  • RPC-ability. I don't think it is a hyperbole to say that many, if not most, RPC and XML-RPC proponents do not realise that REST can function as RPC. In fact, this series of posts focus on using REST as the RPC mechanism.
  • XMLRPC-ability. Using the right framework, REST is XMLRPC+the advantages of REST.
  • Terminologically SOAP - If you have used SOAP (Simple Object Access Protocol), you would agree that SOAP is a total misnomer because SOAP is not simple. Technically, REST is the actual simple object access protocol.

As long as your services or JEE server contexts reside within the same SLD-SOP restriction, REST would allow your GWT application to subscribe to multiple independently deployed server-side services. In fact, most enterprise GWT apps would need to subscribe to multiple independent services. For one, logging-in and user authentication should be a service of its own. Especially when you are using OAuth or OpenID.

You should see that GWT-RPC by itself is ill-equipped as a proper enterprise level enabler. GWT-RPC constrains you to only one service provider - the same service that serves the GWT UI itself has to serve the RPC service. Whereas REST would allow your GWT UI to communicate with another application context (i.e., deployed on a different war).

And then, if your service is on a different SLD origin, you could write a simple http proxy to forward-the-request/return-the-response, which invariably would run on its own war. In ancient terminology, a HTTP tunnel.


Continue next GWT with JAX-RS (aka RPC/REST) Part 1