Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "ECF/Asynchronous Remote Services"

< ECF
(New page: ECF's Remote Services API, which is used to implement OSGi 4.2 remote services, has had the ability for consumers/clients to use asynchronous/non-block remote method calls for at least the...)
 
Line 26: Line 26:
 
With OSGi remote services, this 'helloService' may actually be a proxy.  If invoked as above, under the covers, a proxy will marshall the method arguments (i.e. 'slewis' String in this case), and then communicate with the remote service host via some network (i.e. via some protocol).  If there is a result of the call, then it will then be unmarshalled and return to the caller thread.  With '''synchronous''' invocation the thread that calls 'hello' will block until this entire process is complete.   
 
With OSGi remote services, this 'helloService' may actually be a proxy.  If invoked as above, under the covers, a proxy will marshall the method arguments (i.e. 'slewis' String in this case), and then communicate with the remote service host via some network (i.e. via some protocol).  If there is a result of the call, then it will then be unmarshalled and return to the caller thread.  With '''synchronous''' invocation the thread that calls 'hello' will block until this entire process is complete.   
  
Asynchronous Proxies
+
===Asynchronous Proxies===
  
 
ECF has just added the ability to declare asynchronous access to a remote method, so that the consumer can ge guaranteed that calling the service will not block indefinitely.  So, for example, it's now possible to make a call to the hello service like this
 
ECF has just added the ability to declare asynchronous access to a remote method, so that the consumer can ge guaranteed that calling the service will not block indefinitely.  So, for example, it's now possible to make a call to the hello service like this
Line 41: Line 41:
 
});
 
});
 
</source>
 
</source>
 +
 +
<Under Construction>

Revision as of 15:24, 15 April 2010

ECF's Remote Services API, which is used to implement OSGi 4.2 remote services, has had the ability for consumers/clients to use asynchronous/non-block remote method calls for at least the last 2 years.

For background on the discussion about asynchronous remote services invocation in general and possible future standardization by the OSGI standards organization see Peter Kriens blog entry, and Scott Lewis' blog entry.

Normal/Synchronous Proxies

When an OSGi service is actually invoked today, this is done by the caller calling a method on the service. For example, consider a simple 'hello' service:

package org.eclipse.ecf.examples.remoteservices.hello;
 
public interface IHello {
 
	public void hello(String from);
 
}

Once a consumer of this service gets a valid service reference (i.e. through ServiceTracker, declarative services, getServiceReference or however), it can actually invoke/use the service via a method call on 'hello':

helloService.hello("slewis");

With OSGi remote services, this 'helloService' may actually be a proxy. If invoked as above, under the covers, a proxy will marshall the method arguments (i.e. 'slewis' String in this case), and then communicate with the remote service host via some network (i.e. via some protocol). If there is a result of the call, then it will then be unmarshalled and return to the caller thread. With synchronous invocation the thread that calls 'hello' will block until this entire process is complete.

Asynchronous Proxies

ECF has just added the ability to declare asynchronous access to a remote method, so that the consumer can ge guaranteed that calling the service will not block indefinitely. So, for example, it's now possible to make a call to the hello service like this

helloAsyncService.helloAsync("slewis", new IAsyncCallback() {
    public void onSuccess(Object result) {
        // Do something with result
    }
    public void onFailure(Throwable t) {
        // Deal with network failure in appropriate manner
    }
});

<Under Construction>

Back to the top