Revision as of 05:06, 29 December 2008

Riena Project > Riena Remote Services

Riena Remote Services

Introduction

Riena has inside itself own Remote Services component that we encourage people to use when they are building applications based on Riena. Since there are also other projects that have their own Remote Services component, we sometimes confuse people what distinguishes our implementation from others and why we implemented our own.

This page intends to highlight the goals and reasons for what we are doing.

Goals

There are multiple goals that we indentified from past project experience that we wanted to be able to do with a Remote Service layer in OSGI.

Service oriented

All components identify themselves by exposing an interface and registering in some kind of registry. That is true for local as well as for remote components. For local components that is pretty much what OSGi Services does. For remote components that is OSGi Services plus something more to do the remoting. Still local and remote components are Services.

Transparency

We want to be able to access services no matter whether they are local or remote. We want to use the same APIs, the same way of getting a reference or making a call. The reason is that we want to be able to shift services from the remote to the local JVM without changing the code of the caller. A good example here is the use case is whether the Riena Client has an internet connection or not. If it has call the remote service, if it hasnt call the local service. So a detection component could detect the availability of an internet connection and start/stop the required services. The calling components remain unchanged.

Connection less

Riena is made for enterprise applications and it is highly likely that there are thousands of clients running at the same time. The Riena Client does not need to connect at starting time until it makes the first call that calls a Remote Service and it shouldnt. Open connections into the server infrastructur not only block ressources (i.e. threads) but they are also a danger for attackers and for that reason normally a server farm would and should disconnect a caller after the call is finished.

State less

There is a little difference between calling a local and a remote service. While with a local service you always call that service directly (by getting the instance of the service) for a remote service you call the proxy which then calls the Remote Service. It turns out is most effective if you assume that you are not always getting the same remote service instance in each call. That is pretty much like the paradigma that Webservices are following. On the first look that distinguishes them from local services but its more complicated than that. Say you use a local service, you can get a service reference and a service instance from the registry the service instance could hold a state. But what if the service is going down and a new service instance comes up. Would you still call the original instance (which I consider to be wrong) or would you then call the new service instance and then all the state is gone ? I think because of the dynamic structure of OSGi Service we often treat local OSGi Service as if they cannot hold a state. And that is good because in another scenario the service could be called by multiple components and that would certainly confuse the state because services cannot distinguish the various callers. For Remote Service it is good if they keep no state because than they can go down at any time and the remote service call is routed to another hardware box which also hosts this Remote Service.