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);
concatService.call();
// 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.