Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Communications Framework (ECF) » Make an service that is already registered remote?
Make an service that is already registered remote? [message #1292357] Fri, 11 April 2014 14:59 Go to next message
Craig Ching is currently offline Craig Ching
Messages: 12
Registered: July 2009
Junior Member
Ok, as you can see, I'm a bit of a newb with ECF Wink Let's say I have a third-party service that isn't ECF or remote OSGi aware. Can I use ECF to make that service available remotely? I actually do own the service, but I'd like to use it un-changed if at all possible.

Cheers,
Re: Make an service that is already registered remote? [message #1292417 is a reply to message #1292357] Fri, 11 April 2014 16:05 Go to previous messageGo to next message
Scott Lewis is currently offline Scott Lewis
Messages: 964
Registered: July 2009
Senior Member
Hi Craig,

Quote:
Ok, as you can see, I'm a bit of a newb with ECF Let's say I have a third-party service that isn't ECF or remote OSGi aware. Can I use ECF to make that service available remotely?


Yes, absolutely. That's entirely the point of OSGi Remote Services...and ECF's implementation.

The example presented in the tutorial (timeservice) is presented such that all of the code that makes up the example (in com.mycorp.examples.timeservice.* projects/bundles) are entirely without reference to either ECF classes or even classes that are OSGi Remote Services specific...e.g. the RSA classes).

As an example of what I mean, the ITimeService is declared as such:

public interface ITimeService {

/**
* Get current time.
*
* @return Long current time in milliseconds since Jan 1, 1970. Will not
* return <code>null</code>.
*/
public Long getCurrentTime();
}

Like other OSGi services...this is just a java interface declaration...with no references to ECF, OSGi Remote Services, or even OSGi classes.

There is, of course an implementation of this interface...in TimeServiceImpl class in /com.mycorp.examples.timeservice.host/src/com/mycorp/examples/timeservice/host/TimeServiceImpl.java, but this impl class also has no references to ECF or OSGi code. This is true for all service interfaces and impls (i.e. your own)...these are defined and implemented by you...to meet you/your consumer's needs.

What the OSGi Remote Services specification says (summarizing) is essentially that *when ITimeService impls are registered by the service host*, *iff they have a few standardized service properties set* then they will be exported for remote access..by *some* implementation. What service properties need to be set, and what does that look like? Well, here's an example (that's similar to the time service host code...available in this class

/com.mycorp.examples.timeservice.host/src/com/mycorp/examples/timeservice/host/Activator.java

The relevant code from the above, for registering (and exporting) the remote service is:

// Create remote service properties...see createRemoteServiceProperties()
Dictionary<String, Object> props = createRemoteServiceProperties();

// Create MyTimeService impl and register/export as a remote service
ServiceRegistration<ITimeService> timeServiceRegistration = context
.registerService(ITimeService.class, new TimeServiceImpl(),props);

The 'magic' for remote services is in the createRemoteServiceProperties() method. What this does is set the standard service property:

result.put("service.exported.interfaces","*");

The service.exported.interfaces property is specified by chapter 100 in the OSGi enterprise specification. What the above means is that for this service registration, all the interfaces that the service impl exposes ('*' == ITimeService in this case) should be exported...i.e. made available for remote access.

What ECF (or other RS impls as well) then does is *during the call to registerService...before it returns* the service is exported using some distribution provider. ECF also publishes the remote service via 0 or more discovery mechanisms (e.g. zeroconf).

Returning to your question...if you register a service interface and impl of your own creation...and setting the service.exported.interfaces service property as per the OSGi Remote service spec...and you have ECF or some other standard-compliant RS implementation bundles running in your framework, the service will be exported for remote access.

This is true no matter what the service is/does, or what interfaces/classes are involved...as long as it follows a few simple restrictions: a) the service interface and all referenced classes must be accessible on both the host and the remote consumers (note that the service implementation must only be on the host). b) the return value and the method arguments can be serialized...i.e. method arguments are passed by value (rather than by reference).

Quote:

I actually do own the service, but I'd like to use it un-changed if at all possible.


Right...that's completely possible...and that's really much of the point of using OSGi Remote Services...it's just like 'normal' (local) OSGi services...except for the use of standardized service properties, and the presence of an implementation of the standard (ECF).

One additional comment: As you may have seen from looking at

https://wiki.eclipse.org/ECF/Asynchronous_Remote_Services

ECF provides a way for remote service consumers to access the remote service asynchronously...guaranteed not to block. This is useful for many use cases, as often consumers which to invoke a service and be guaranteed that it won't block (which it could do, given that it's a remote service...i.e. communicating over a network to access the service). But asynchronous remote service access is not *required*...if synchronous remote service access is sufficient then there is no need to use the asynchronous features at all.

Does this help? We are trying to provide more tutorials about how to create/build/use remote services...and we are also working on tooling (for Eclipse, naturally) to help in the creation/implementation/registration/discovery/use of OSGi Remote Services (and ECF's impl of course). But...we are somewhat resource limited, and so have to depend upon community participation and contribution to do this.

Re: Make an service that is already registered remote? [message #1292422 is a reply to message #1292357] Fri, 11 April 2014 16:12 Go to previous messageGo to next message
Scott Lewis is currently offline Scott Lewis
Messages: 964
Registered: July 2009
Senior Member
One other comment about your use case of make a service that's *already registered* accessible for remote access.

There are several ways to do this...probably the easiest is to simply create a new service class that is based upon/wraps the existing service...e.g.:

public MyTimeService implements ITimeService {

private ITimeService existing;

public MyTimeService(ITimeService impl) {
this.existing = impl;
}

public Long getCurrentTime() {
// call underlying existing ITimeService
return this.existing.getCurrentTime();
}

}

And then simply register your service...when you want to export/make it remotely accessible...by registering with the OSGi standard service properties set...e.g.

props.put("service.exported.interfaces","*");

// register a new instance of MyTimeService and export as remote service.
bundleContext.registerService(ITimeService.class,new MyTimeService(existingImpl),props);

Sorry if I previously misinterpreted your question.


Re: Make an service that is already registered remote? [message #1292431 is a reply to message #1292422] Fri, 11 April 2014 16:25 Go to previous messageGo to next message
Craig Ching is currently offline Craig Ching
Messages: 12
Registered: July 2009
Junior Member
Scott Lewis wrote on Fri, 11 April 2014 16:12
One other comment about your use case of make a service that's *already registered* accessible for remote access.

There are several ways to do this...probably the easiest is to simply create a new service class that is based upon/wraps the existing service...e.g.:

...

And then simply register your service...when you want to export/make it remotely accessible...by registering with the OSGi standard service properties set...e.g.

props.put("service.exported.interfaces","*");

// register a new instance of MyTimeService and export as remote service.
bundleContext.registerService(ITimeService.class,new MyTimeService(existingImpl),props);

Sorry if I previously misinterpreted your question.


Ok, so I have two instances of the same service registered locally, but only one of those services will be available remotely. I think that makes sense, thanks!
Re: Make an service that is already registered remote? [message #1313402 is a reply to message #1292431] Thu, 24 April 2014 17:42 Go to previous message
Wim Jongman is currently offline Wim Jongman
Messages: 275
Registered: July 2009
Senior Member

Hi Craig,

They should both be available remotely.

Cheers,

Wim
Previous Topic:Hello example over network
Next Topic:Problem getting Hello DS example to work
Goto Forum:
  


Current Time: Tue Jul 22 11:43:43 EDT 2014

Powered by FUDForum. Page generated in 0.03236 seconds