Note the type of the service is 'remotesvcs', a '''new''' type. For those interested, the publicly registered types for RFC 2782 are listed [http://www.dns-sd.org/ServiceTypes.html here].

Note the type of the service is 'remotesvcs', a '''new''' type. For those interested, the publicly registered types for RFC 2782 are listed [http://www.dns-sd.org/ServiceTypes.html here].

−

Note that in this case the discovery is being done by the ECF zeroconf/bonjour/rendevous provider. The UI and the code that uses the discovery, is, however, discovery protocol independent, so that it can (and will) also be used with [https://bugs.eclipse.org/bugs/show_bug.cgi?id=200804 SLP discovery]...with no changes to the middleware or application code.

+

Note that in this case the discovery is being done by the ECF zeroconf/bonjour/rendevous provider. The UI and the code that uses the discovery is discovery protocol independent, so that it can (and will) also be used with [https://bugs.eclipse.org/bugs/show_bug.cgi?id=200804 SLP discovery]...with no changes to the middleware or application code.

Here is an expanded view of the info about the service provided by service host via the discovery API:

Here is an expanded view of the info about the service provided by service host via the discovery API:

Line 32:

Line 32:

These access methods are made available via the ECF [http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/remoteservice/IRemoteService.html IRemoteService].

These access methods are made available via the ECF [http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/remoteservice/IRemoteService.html IRemoteService].

−

'''Note that the proxy can also be accessed directly in the OSGi service registry via BundleContext.getServiceReference() or a ServiceTracker.''' In this way, if complete API transparency is desired, then it can be done this way.

+

'''Note that the proxy can also be accessed directly in the OSGi service registry via BundleContext.getServiceReference() or a ServiceTracker.''' In this way, if complete API transparency is desired by the programmer, then the service can be transparently accessed.

−

So, if the proxy is selected it brings up an example UI for getting the relevant parameter

+

If the proxy invocation is selected it brings up an example UI for getting the relevant parameter

[[Image:rs5.png]]

[[Image:rs5.png]]

Latest revision as of 13:42, 7 February 2008

Screen Shots

There's been some more work on examples...this time an example that combines the use of the ECF discovery API with the use of the ECF remote services API. This makes it possible to automatically discover and remotely access arbitrary OSGi services.

Here is a screen shot of the ECF service discovery view, after having discovered a remote service:

Note the type of the service is 'remotesvcs', a new type. For those interested, the publicly registered types for RFC 2782 are listed here.

Note that in this case the discovery is being done by the ECF zeroconf/bonjour/rendevous provider. The UI and the code that uses the discovery is discovery protocol independent, so that it can (and will) also be used with SLP discovery...with no changes to the middleware or application code.

Here is an expanded view of the info about the service provided by service host via the discovery API:

Now, the ECF discovery view UI has an extension point called 'serviceAccessHandler' that allows context menu contributions to be optionally added by extensions, based upon the discovered service info. For the client there is a serviceAccessHandler defined for the 'remotesvcs' type (defined in the schema here as extension point org.eclipse.ecf.discovery.ui.serviceAccessHandler) that presents the following when the user opens the context menu for the service

If the user is not already connected to the given service, then it allows the connection to be established as above. If already connected, however, the context menu presents options for invoking a remote 'getProperty' method (part of the Equinox EnvironmentInfo service)

This menu provides access to four different ways of invoking the 'getProperty' method remotely...and is just an example UI (a better UI for selecting a remote method and providing parameters is forthcoming). The four ways are

Note that the proxy can also be accessed directly in the OSGi service registry via BundleContext.getServiceReference() or a ServiceTracker. In this way, if complete API transparency is desired by the programmer, then the service can be transparently accessed.

If the proxy invocation is selected it brings up an example UI for getting the relevant parameter

The remote call is then actually made, and presents the result in another ugly UI (the result is the 'user.dir' directory on the remote service host)

Here's another example, just to show that the key provided as a parameter to the getProperty call is doing it's thing

Note that the client gets/receives all the information necessary to connect to and access the remote service via the service discovery (i.e. via the ECF discovery API)...the user doesn't have to provide any extra information in order to find and use the remote service. Further, the middleware and UI code is completely transport independent...allowing the use of ECF generic, r-OSGi, JMS, javagroups, XMPP, or other/proprietary providers without the need to modify the middleware and/or UI.

Code Pointers

This example consists of three bundles

org.eclipse.ecf.examples.remoteservices.common. This bundle has the service interface class org.eclipse.ecf.examples.remoteservices.common.IRemoteEnvironmentInfo. Note that this interface is very much like the Equinox EnvironmentInfo service, and essentially all the service host implementation does is turn around and call the local EnvironmentInfo service.

org.eclipse.ecf.examples.remoteservices.server. An extremely simple Equinox-based server that registers the remote service, publishes the service discovery info, and implements the remote requests. Source is here.