Those Leaky Networks

In previous blog posts I’ve blogged about ECF’s upcoming implementation of RFC 119.

In this post, I would like to jump out of the description of RFC 119 and talk about how the implementation of RFC 119 and ECF remote services fit together…as our implementation of RFC119 is layered on top of the ECF remote services API.

I think of remote procedure call as a leaky abstraction.  For those that haven’t read Joel Spolsky’s The Law of Leaky Abstractions, I highly recommend it.  The reason I would say that it’s a leaky abstraction is that although transparent RPC *looks* like a local method call, it’s clearly not under some situations:

  1. The remote call is very slow (or blocks) because of a network problem
  2. The remote call cannot complete because the network fails/goes down
  3. A parameter to the remote method call cannot be serialized…e.g. trying to make a remote call e.g. like this:  serviceProxy.setWorkspace(IWorkspace workspace…why would passing a workspace to a method call be a problem?)

There are others, but I think these are the most compelling.

Note that all three of the above are runtime issues…i.e. they can happen at runtime for lots of reasons that have nothing to do with the semantics of the RPC itself.  In the case of 1 and 2 they cannot be prevented.  And they are likely to happen for non-trivial procedures.

Note also that since OSGi services are method calls on some service interface (a pojo), that remote services will also have the above issues.  It doesn’t matter what your remoting implementation is, they will all be subject to such problems.  Unfortunately, we (the distribution system implementers) can’t prevent it.

So, to me this means remote procedure call is a leaky abstraction…because even though it looks like normal/local/in memory method call, there are occasions where the ‘truth’ about networks leaks out.

So what to do?   Well, I think there are several things to do, both from the service designer’s viewpoint (i.e. those defining the service to be remoted) and the distribution system implementer’s viewpoint (i.e. people that implement distribution infrastructures…like me).

From the service designer’s viewpoint you could design all of your services to prepared for 1, 2, 3 above…and/or document them as having these properties.  This can/does definately help.  But it is a major pain, and you can end up having services that are more complex (especially if they are used locally as well as remotely).

From the distribution system implementer’s viewpoint I feel one thing to do is what Joel describes in his paper as what TCP did for IP..layering.

That is the approach we’ve taken with implementing RFC 119…as the implementation of transparent remoting as specified in RFC119 is implemented on a non-transparent/explicit remoting API (ECF remote services).  I think this is nice, because it allows/supports more use cases:

“I want to create a simple remote service, as easily as I can and have it work”  (use RFC 119)

“I want to create a remote service that knows about or at least responds properly to the remoting leaks (1, 2, 3, etc above), and not simply crash/block/fail when the service is used”  (use ECF remote services)

So, we’ve implemented RFC119 itself using ECF remote services…and layered transparent remoting on top of a non-transparent remoting runtime API.  This gives choices to both service designers and service consumers about how much they want/need to care about the network leaking into remote OSGi services.   That is, if they care about the leaks they can do something about them, but if they (or the service consumers) don’t care about such leaks they can have a standard way of publishing, discovering, and receiving remote OSGi services.

You may also like...

Share this Post

Twitter0
Google+0
LinkedIn
Facebook

Tags

2 Responses to “Those Leaky Networks”

  1. Adrian Sampaleanu says:

    Scott,

    When developing for OSGi with an abstraction layer such as Spring DM (and others), your points 1 and 2 apply even to local services due to the indirection implied by the proxying involved and the dynamic nature of the environment. So, I suppose that when properly handling the lifecycle events in an OSGi environment wrt dependencies, the differences between local and remote services are not so great. I’m curious if Spring DM’s type of abstraction (which to a large degree will be part of the 4.2 spec) could not be extended to provide the transparent layer that you say you’ve implemented. Are you, in fact, using spec compliant dependency management?

    Thanks for any insight,
    Adrian

  2. Scott Lewis says:

    Adrian…RE: Spring DM…I would imagine that it could be used to implement RFC 119…although I don’t know Spring DM well enough to say for sure. RE: your points about OSGi’s dynamic environment support…yes, OSGi’s support for dynamic services is, I believe, helpful in dealing with network ‘leakyness’. But, I don’t believe that it actually makes remoting completely solid/non-leaky. I say this because even dynamic service arrival/departure doesn’t actually capture/totally hide points 1 and 2. Yes, some version of network induced problems like 1 and 2 can be mapped to service departure, but I don’t think service departure is an perfect abstraction for (e.g.) network-induced blocking (or widely varying timing/performance issues) in RPC. My $0.02.

    RE: dependency management…no, not as part of the ECF/RFC119 work. I am using DS in other work contexts though, and I find it very helpful/useful for local service dependency mgmt. I’ve not yet come to any conclusions about remote service mgmt as I haven’t played around with it enough.

2 responses so far

Written by . Published in Categories: Planet Eclipse

Author:
Published:
May 6th, 2009