Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Consuming existing REST and dynamically changing the endpoint URL
On 10/5/2015 5:46 AM, Marin Orlić wrote:
Hi,

what would be the preferred method of dynamically changing the endpoint URL registered for a remote REST service?


I can register the service with an EDEF initially, but the requirement is that the endpoint must be changeable via workspace preferences. My guess is that a listener on preference change could trigger service registration using dynamically generated EDEF properties? How to start with that and what properties need to be changed along with endpoint URI (endpoint.service.id?).

I think what you've outlined above is basically right.  Before discussing this in detail though I need to check an assumption:  I assume that when you say 'dynamically changing the endpoint URL' you essentially mean:  

1) Unregistering the existing remote service (i.e. at the old endpoint URL)
2) Registering the remote service at the new endpoint URL

If this isn't a correct interpretation of what you've described as 'changing the endpoint URL' then please correct and detail.

Assuming this is what you want to do then I can think of two ways to do it:

1) Calling ServiceRegistration.unregister() on first remote service registered
2) Registering the remote service with the new endpoint URL

The above assumes that you are using the (default) BasicTopologyManager (in the org.eclipse.ecf.osgi.services.distribution bundle).   The other way it so *bypass* the BasicTopologyManager and do the same thing by calling the RemoteServiceAdmin API direct...e.g.

1) Call org.osgi.service.remoteserviceadmin.ExportRegistration.unregister()
2) Call org.osgi.service.remoteserviceadmin.RemoteServiceAdmin.exportService()

The difference between these two methods is that in the first case the *local* service will be unregistered and then reregistered (because the BasicTopologyManager has a service hook that calls the underlying RSA methods), while in the second case the local service will remain active during the possibly short period between unregister() and the registration of the new service.  Another difference is that the service discovery (i.e. unpublish, publish) will be done automatically by the BasicTopologyManager in the first case, but will not be done automatically in the second case.

As you can see the first approach uses just the BTM and the OSGi service registry, the second uses the OSGi RSA api.  Neither use any ECF-specific API and I don't see any reasons why these couldn't be called in response to a workspace preference change (although if that's called by the UI thread you might need to do in some other thread).

>How to start with that and what properties need to be changed along with endpoint URI (endpoint.service.id?).

I would suggest that rather than trying to create the new EDEF by hand, that you get the new EndpointDescription from the ExportRegistration (returned from RemoteServiceAdmin.exportService() via getExportReference().getExportedEndpoint()) and use that.   If you ultimately decide that you would like to manipulate the EDEF by hand then we can discuss further the properties that need/should be changed (there are only ~3), but no reason to go to that trouble unless necessary.

Scott


Thanks,
 Marin


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev

Back to the top