Getting Started with ECF's RFC119 Implementation

Outdated and/or duplicate informationThis page seems to contain information which is also available at EIG:Getting Started with OSGi Remote Services. It also seems to be related to ECF 3.0 whereby the other page references a target platform using ECF 3.5. Please help us clarifying by verifying both pages and provide comments!

You should ignore the warning...this just indicates that the server discovered it's own published service and did not create a proxy for it.

If, however, you get the following warning when starting the host:

osgi> WARNING: Port 9278 already in use. This instance of R-OSGi is running on port 9279

This means that there is some other R-OSGi instance running on that same system, and that port 9278 is not available for use by the host. In this case, you need to stop the host, and disable the other R-OSGi instance before running the host again. To disable R-OSGI, see Disabling R-OSGi and R-OSGi_Properties.

Using the Service (Consumer)

The service consumer first discovers the published service, and then when discovered it creates a proxy and registers the proxy in the local service registry.

Here is code from org.eclipse.ecf.internal.examples.remoteservices.hello.consumer.Activator

Like the service host, this code also must create an R-OSGi peer container instance. Note that to switch to another/different provider (than R-OSGi), all that must be changed is the string "ecf.r_osgi.peer" in both the host and consumer.

After creating the container, a ServiceTracker is created to track the discovery and registration of remotely published services. This allows discovery to happen asynchronously, and when the remote service matching the filter returned from createRemoteFilter(), the 'serviceAdded' method will be called by the service tracker sometime after the service tracker is created. Here is the serviceAdded method:

Calls hello() on the hello instance, just like it was a local service.

Asynchronous Remote Method Invocation

Sometimes it's desirable to invoke remote methods asynchronously, without blocking until the remote method call completes. This is sometimes desirable, for example, if your user interface thread is doing the calling, as remote methods can/could block for a much longer time than would be acceptable for users.

ECF provides an API to invoke remote methods with a guarantee that they will be executed asynchronously, in some other thread, and allowing the calling thread not to be blocked.

For ECF the value of the REMOTE property (i.e. 'osgi.remote') is a non-null instance of IRemoteService. IREmoteService provides the consumer with more flexibility in how they can remotely call methods exposed by the IHello service interface.

Here's an example that fires an asynchronous message to invoke the 'hello' method on the remote service.

Notice that it is not necessary to have even the IHello service interface class present to use this technique.

For another example, here's code that uses the IRemoteService to return a future result. The future result is provided immediately, without blocking, and then sometime later can be accessed to either get the result (if already complete) or wait for the result to complete.