|
| Re: Make an service that is already registered remote? [message #1292417 is a reply to message #1292357] |
Fri, 11 April 2014 16:05   |
Eclipse User |
|
|
|
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.
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04093 seconds
Home
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.