Asynchronous Remote Services - The future or the callback

In previous postings I described how ECF is now making it very easy for OSGi service developers to expose asynchronous/non-blocking remote method calls to clients.

In short, all that's now required is to create an asynchronous version of the service's OSGi service interface. See this documentation for example and source. Just declaring this asynchronous interface is all that's needed. At proxy discovery time, ECF's implementation of OSGi remote services will provide the implementation of this asynchronous interface.

Future or Callback

There are various approaches to doing asynchronous remote method invocation, and two common ones are callbacks and futures. For example, GWT uses callbacks, while Amazon EC2 uses futures for exposing asynchronous access to their APIs (like SNS, SQS, etc). ECF's asynchronous remote services supports both of these approaches (futures and callbacks). The asynchronous service interface declaration can, for a given synchronous method declaration, use either a callback, or a future, or both.

For example, let's say we have the following synchronous service interface method:

String foo(String bar);

The async declaration for this method using a callback would look like this:

void fooAsync(String bar, IAsyncCallback);

The async declaration for thie method using a future would look like this:

IFuture fooAsync(String bar);

And that's it. The remote service client can then use either/both of these fooAsync methods (if they are declared, of course), simply by casting the proxy to the async service interface type and calling the appropriate fooAsync method with the necessary params.

In this way, the remote service designer can determine what asynchronous style the client will have available...by declaring fooAsync using callback, future, both, or neither.

Asynchronous Remote Services - part 2

In a previous posting, I described how ECF has introduced a simplified approach for allowing OSGi remote services to be accessed asynchronously.

In contrast to my recent postings, that have been getting rather long, I'll just redirect you to a wiki page describing how to use asynchronous services...and leave it at that. Happy Friday.

OSGi Remote Services and ECF - Asynchronous services

In a previous posting, I discussed/presented some of the support for asynchronous access to OSGi remote services that currently exists in ECF's implementation.

In a blog posting earlier this week, Peter Kriens discussed some of the efforts going on in the EEG on adding asynchronous support for remote (and even local) services. One of his comments in that blog posting was that ECF's asynchronous support could be considered awkward, because of the complexity/unfamiliarity of using the API.

I've been intending to add easier/more natural mechanisms for asynchronous remote access than what we already have, and what's going on in the EEG and Peter's blog was great incentive to complete some more of that work. The existing mechanisms are somewhat awkward, but they also make a very strong/flexible foundation...and so it's possible to build new mechanisms on the existing mechanisms.

Normal/Synchronous Proxies

In our 'hello' remote services example, we have this service interface:

public interface IHello {
    public void hello(String from); 
}

Consumers of this remote service receive a proxy that implements the IHello interface, and then clients can synchronously invoke the hello method to make a remote call:

proxy.hello{"slewis");

Since in java method calls are blocking, the thread that calls the hello method will block if (e.g.) the network is slow, the service host is slow (or blocks). It would be nice if we had a way (on the consumer/client) to call the hello method and guarantee that it will not block...while still somehow getting the result (if any)...when the remote call is successful...or getting information about the failure if things fail/go wrong (e.g. because of network failure).

Asynchronous Proxies

We've just added support for asynchronous proxies in ECF're remote services implementation. What this means is that if an interface is declared like this (and in the same package as the IHello interface):

public interface IHelloAsync extends IAsyncRemoteServiceProxy {

    public void helloAsync(String from, IAsyncCallback callback);

    public IFuture helloAsync(String from);

}

the ECF remote service distribution system will automatically create a proxy that implements the IHelloAsync interface on the consumer/client.

If the helloAsync(String,IAsyncCallback) method is called by the consumer:

proxy.helloAsync("slewis",new IAsyncCallback() {
    void onSuccess(Object result) {
        System.out.println("we got result="+result);
    }
    void onFailure(Throwable exception) {
        System.out.println("oh no!");
        exception.printStackTrace();
    }
});

the consumer thread will not block, and success/result or failure will be asynchronously communicated to the caller via proxy calling the appropriate method on IAsyncCallback.

In addition to using the callback, futures (IFuture) are also supported. All that must be done to allow the consumer to use a future result is to declare a helloAsync method that returns an IFuture:

    public IFuture helloAsync(String from);

The only thing required to get this to happen on the consumer/client is to declare the *Async interface (IHelloAsync). Then, at proxy creation time on the remote service consumer, if this *Async interface exists, it will be implemented by the proxy, and usable by the client.

Note that the *Async interface declaration is the only thing that's needed to get this to work with any service interface. The service host implementation doesn't need to actually implement the *Async interface, and the ECF remote services distribution will create a proxy that implements the *Async interface automatically. Further, like other things ECF, this is all done in a transport-independent way, so all the existing providers (JMS, XMPP, ECF generic, JavaGroups, Skype, REST, SOAP, etc., etc.) support this addition immediately with no further work.

Google Web Toolkit uses a very similar approach to support asynchronous remote procedure call. In addition to callbacks, however, ECF's asynchronous proxy also has support for futures. This allows the consumer/client to choose the desired invocation style: synchronous, asynchronous-callback, or asynchronous-futures.

OSGi Remote Services from ECF - Distribution

In a previous posting, I discussed the use of the ECF discovery API as part of our implementation of the OSGi 4.2 remote services specification.

The second major part of ECF's implementation of OSGi 4.2 remote services is distribution.

What is Distribution?

Distribution is what happens to actually invoke a remote service and optionally return some result. Here's a brief summary of the essential functions of distribution:

Remote Service Consumer

[Prior to caller actually using service]
1. Create a proxy for the remote service
[When caller actually uses remote service]
2. Marshal/Serial any arguments for the remote call
3. Put call request (method and serialized parameter) on the wire using some protocol

Remote Service Host

1. Take request off the wire (using same protocol)
2. Un-marshal method and arguments
3. Lookup corresponding service/method
4. Invoke appropriate service with given arguments
5. Marshal return value
6. Put result on the wire using some protocol

Remote Service Consumer

4. Take response off the wire (using same protocol)
5. Un-marshal result
6. Return result to caller

One way to think of it is that distribution is responsible for making what looks like a local method call to a local OSGi service actually be a remote call.

Two of the critical functions of distribution...for both Consumer and Host are

1) Marshaling/Serialization...of arguments and return values
2) Use some protocol to communicate request/response over network

As with discovery, the ECF project has created an abstract API for distribution, which is called the ECF remote services API. Like other ECF APIs, this is a transport-independent API, which exposes a programmatic way to accomplish the functions of distribution (as described above), but does not imply/require any particular implementation of marshaling/serialization, nor imply/require any particular network protocol.

ECF has providers that define specific implementations of marshaling and network protocol. For example, we have a REST-API, that supports the creation of specific REST providers. This REST API includes JSON and/or xml-based serialization, and uses HTTP as the protocol. We also have a similar SOAP API for SOAP-based services.

We also have a number of other providers that are complete and available...e.g. ones based upon XMPP, JMS, ECF generic, Skype's app protocol, JavaGroups/multicast. Further, since all of these providers are open source, if desired they can be extended or copied to implement custom providers based upon whatever serialization and wire protocol (e.g. an existing system) is desired...with our without the ECF team's involvement.

Note the ECF implementation of the OSGi 4.2 remote services specification is guaranteed to work with any of these providers...no matter who writes it. This because our implementation of the OSGi 4.2 remote services spec simply uses any all implementations of the ECF remote service API (no matter what the serialization and/or networking protocol).

The flexibility here is extremely useful when selecting serialization formats and/or network protocols, because there are/will always be so many serialization formats and/or network protocols to choose from...their appropriateness will always depend upon the use case...as well as the need for integration with existing systems. For example...e.g. json over http, custom xml over http, object serialization over tcp, xml over jms, soap over http, etc, etc...which makes sense depends upon the use case and things like networking/interoperability requirements.

Since this distribution function is separated out into a distinct, abstract, module (i.e. the ECF remote services API), it makes it possible to mix and match existing protocols and new protocols...both closed and open...with existing serialization formats or new serialization formats...crossed with whatever discovery protocol is appropriate and/or desired.

OSGi Remote Services from ECF - Discovery

Released in Feb, ECF 3.2 has full support for the OSGi 4.2 remote services specification.

As with any general technology, there are potentially many use cases for remoting OSGi services, and any given implementation won't support all those use cases. It's therefore very important that any technology be extensible to support use cases that were not envisioned originally.

OSGi Remote Services: A tale of discovery and distribution

In providing access to a remote service there are at least two network-created issues that must be addressed for any remoting technology to work. In this post I'll discuss discovery, and in subsequent posts talk about distribution.

Modularity for Network Discovery

When a new service is made available...via a server, or a peer, or a device, etc...any consumers/clients of that service must somehow be made aware of that service, and given sufficient information to be able to access that service. A very common example of being made 'aware' of a web service is receiving (via email, or a web page, or twitter, or whatever) the URL for that service...e.g. the twitter user status service URL is http://twitter.com/statuses/user_timeline.json.

With OSGi remote services the notion of a URL is generalized to an endpoint. As with all OSGi services, service properties provide metadata about the remote service (including but not limited to the endpoint)...and this metadata is sufficient for a consumer to actually access/use the service.

There are potentially many ways to discover a remote service. There are network discovery protocols (e.g. zeroconf/bonjour, Service Location Protocol (SLP), Apache Zookeeper), as well as static xml or other formatted files, custom http-based service registries, etc., etc.

To deal with the required flexibility, ECF has an abstract discovery API (org.eclipse.ecf.discovery). This is a network-protocol-independent API for discovering things over the network. I use 'things' because the discovery API isn't only for discovering remote OSGi services, and it can also be used to discover devices, other applications (an example of this is that since Apple's iTunes uses zeroconf to publish itself, it's possible to interoperate with iTunes and/or other iMac and iPhone applications from within an OSGi runtime).

The providers/protocols that we ship with ECF now are zeroconf/bonjour, SLP, and we have a pending contribution for Apache Zookeeper. We also currently have support for static xml-file-based discovery of remote services and are working on support for use of DNS-SD for wide-area dns-based discovery.

The ECF discovery API effectively separates network discovery into a distinct module, and allows the reuse of existing network protocol implementations, OR substitution of one's own approach to discovery to meet custom use cases (such as discovering remote services only behind a firewall, etc).

This modularization enables reuse, since all the other parts of ECF's remote services implementation (e.g. the distribution...i.e. remote method marshalling/unmarshalling, etc) can be reused without modification. This is so because ECF's OSGi remote services implementation simply uses any/all discovery API providers at runtime to publish the remote service. This makes any new discovery API provider automatically and immediately compliant with the OSGi remote services specification.

The reuse and extensibility is a positive side effect of the modularity provided inherently by OSGi, along with the separation of concerns built into ECF's implementation of OSGi remote services. In a future posting(s) I'll discuss the distribution module of ECF's remote services implementation...referred to as the ECF remote services API.

Reference:

OSGi 4.2 Remote Services
ecf-dev mailing list