IV.1RPC requirements

The RPC framework we want to build will provide a tool to automatically generate a set of Java and PHP5 classes to handle the service's calls between client and server. The approach is the classic with stub classes:

• Client stub: provide a service proxy, in order to give to the programmer the abstraction that he is making a local call. These classes are generated in Java and then translated in Javascript by the GWT compiler;

• Server stub: provide a service skeleton that the programmer completes giving the service implementation. These classes are generated in PHP5.

Figure 5: RPC architecture

The framework uses a custom RPC protocol to makes calls. We will not give deep informations on this protocol because it is designed only for sample purpose and is not a really good protocol. Anyway, the main goals of an RPC protocol are the next:

• to provide a way to identify the service to call;

• to provide a way to make a service call;

• to provide a way to identify the request and so to associate the responses to their requests.

While the first two requirements are quite simple to satisfy and there is not much more to say than what was already said (for example in [25]), the third requirement is slightly more interesting.

An RPC protocol based on HTTP is basically asynchronous, so we can't use a simple request serialization to identify requests and their responses. The approach we used for our sample protocol is to provide a separate request channels abstraction. In other words, every request is done on a dedicated channel, where only the request and its response are exchanged. This way the identification is simplified also for the programmer, that will use a simple callback pattern to handle the response to a request.