Wednesday, October 17, 2007

Remote OSGi Services: Questions of Transparency

Recently, I've been having discussions with various folks about whether network transparency for remote OSGi services is a 'good thing'.

I think a reasonable summary of the discussion is that under the right conditions, it can be a good thing, because it makes it possible to easily create distributed applications using consistent APIs...without learning network specific service APIs.

OTOH, under the wrong conditions and assumptions, too much network transparency can make it very hard or impossible to build reliable distributed components or applications (for details see the classic Note on Distributed Computing Paper).

With our own Remote Services API in ECF, we've tried to create an API so that it's easy to use either approach...and attempt to steer clear of the religious wars. So, for example, in ECF here's how you register a remote service (for the 'server' of that service) to be accessed ...either transparently or not-transparently:

IConcatService serviceImpl = new ServiceImpl();
Dictionary props = new Hashtable();
props.put(Constants.LOCAL_SERVICE_REGISTRATION, "true");
// Register serviceImpl
context.registerRemoteService(new String[] {IConcatService.class.getName()}, serviceImpl, props);

And then on the service client, you can access it like any other OSGi service...and underneath a proxy is created (this looks exactly the same whether the service is local or remote):

ServiceReference ref = bc.getServiceReference(IConcatService.class.getName());
IConcatService concatService = (IConcatService) bc.getService(ref);;
// call concatService...calls proxy and sends the call to remote serviceImpl

Alternatively, clients can also access a IRemoteService instance via a service property, and do things like send an asynchronous message to invoke the service...for example:

ServiceReference ref = bc.getServiceReference(IConcatService.class.getName());
IRemoteService remoteService = (IRemoteService) ref.getProperty(Constants.REMOTE_SERVICE);
// Call it with listener for return/result. This returns immediately and then later
// calls the remoteCallListener
remoteService.callAsynch(remoteCall, remoteCallListener);

Of course you could claim that is chickening out on the transparency battles, but I tend to think of it as simply recognizing that there are lots of distributed applications out there that can (and should and will) be implemented on OSGi runtimes, and they all differ in their needs...e.g. for synch vs. asynch, or handling of partial failure, or in their timing/performance requirements.


AlBlue said...

An excellent post. I wish I had the time to devote to doing more work like this.

Peter said...

What is the reason to use your own registry for remote services? It seems you would not lose anything if you registered the IConcatService in the OSGi service registry instead of your private registry, with a special remote flag. This flag is then detected by another bundle who will then make the service available in other places.

Config Admin already recommends that you register the service with configuration properties, allowing someone in runtime to make the choice if it is remoteable or not.

The nice thing is that this model does not require to link to any ECF specific classes but get more than the goodies? Or do I miss something?

Kind regards,

Peter Kriens

Scott Lewis said...

Hi Peter,

> What is the reason to use your
> own registry for remote services?

So that if a remote service publisher would like to make the service accessible via remote-specific (non-transparent) interfaces (i.e. IRemoteService), they can do so and are not forced
into network transparency by
the services API.

RE: configuration properties...yes, we basically use configuration properties to expose 'transparent' remoteness as well.

The ECF-specific interfaces ( impl) are still needed if the service publisher and client *want* to expose a non-proxy interface (i.e. IRemoteService).
Why not allow those/applications that need/want explicitness in remote access to
have it?