Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
SMILA/Project Concepts/OSGi service groupping (service registry concept)
Description
THIS PAGE SHOULD BE REMOVED - concept is obsolete
A concept of service registry for groupping services
Discussion
Juergen Schumacher: I have some questions about this: I think we should go for OSGi's Declarative Se... I have some questions about this:
I think we should go for OSGi's Declarative Services feature for managing service registrations and dependencies. Simple examples for service registration can be found in [[1]] and for service lookup in [[2]]. Even if you do not want to do this: Why not just use OSGi tools like ServiceTracker or implementing ServiceListener to locate services? See [[3]] or [[4]] for simple examples.
Ivan Churkin:
It was only a proposal. Maybe you are right and its unnecessary. My reasons was:... It was only a proposal. Maybe you are right and its unnecessary. My reasons was:
It was duplicated code in components - I only extract that code.
The "registry service" allows to encapsulate logic on choosing endpoint service => The usage is easier. In the example, for finding measure
IGeometryRegistry registry = (IGeometryRegistry)_context.getService(reference) Double measure = registry.getMeasure(o)
its not required to know the type of object to measure for choosing exact service.
Technical proposal
The eccenca structure should be flexible, some bundles/services may be installed/added on the fly, other may not present in installation. There are a lot of tasks that requires flexible access to services. For example to get a JMS queue (from some default and unknown exactly JMS service) or to apply some node transformer during search query processing.
In the exact program point service that should be used is unknown exactly but it is known some common characteristic. For example:
- "Its JMS engine"
- "Its Node Transformer"
- "Its Transformer"
It should be declared a common way how to create/access that groups The idea is very simple. Instead of calling (unknown) service directly it should be asked some (fixed) broker (or registry service) to delegate a task.
It was done a utility bundle that makes creating of that groups easy.
HOW to make a service registry and plugins step-by-step with the help of utility classes.
- Create a bundle for a registry service, for example its org.eclipse.eilf.geometry
- Add dependancy to org.eclipse.eilf.utils bundle
- Create an interface for plugins
IGeometry.java
public interface IGeometry{ Double getMeasure(Object object) }
- Create an interface for broker (here its inherited from plug-in interface)
IGeometryRegistry.java
public interface IGeometryRegistry extends IGeometry{ Double getMeasure(Object object) ... some other methods }
- do export that interfaces (make it visible to other plugins).
- write a realization of broker by extending abstract class org.eclipse.eilf.utils.service.AbstractRegistryService
public class GeometryRegistry extends AbstractRegistryService<IGeometry> implements IGeometryRegistry{ public GeometryRegistry(final BundleContext context) { super(context, IGeometry.class.getName()); } private String calculateObjectType(Object object); public Double getMeasure(Object object){ String objectType = calculateObjectType(object); ServiceReferebce reference = this.findFirstServiceReferenceByName(objectType) if(reference == null){ throw ...; } IGeometry plugin = this.getService(reference); Double measure = plugin.getMeasure(object); this.ungetService(reference); return measure; } }
- Activate it by extending org.eclipse.eilf.utils.service.AbstractServiceActivator
public final class Activator extends AbstractServiceActivator<IGeometryRegistry> { /* * (non-Javadoc) * * @see org.eclipse.eilf.utils.service.AbstractServiceActivator#getServiceGroupName() */ @Override protected final String getServiceGroupName() { return IGeometryRegistry.class.getName(); } /* * (non-Javadoc) * * @see org.eclipse.eilf.utils.service.AbstractServiceActivator#getServiceSubName() */ @Override protected final String getServiceSubName() { return null; } /* * (non-Javadoc) * * @see org.eclipse.eilf.utils.service.AbstractServiceActivator#newServiceInstance(org.osgi.framework.BundleContext) */ @Override protected IGeometryRegistry newServiceInstance(final BundleContext context) { return new GeometryRegistry(context); } }
- Create a bundle for plug-in service, for example its org.eclipse.eilf.geometry.square
- Add dependancy to org.eclipse.eilf.utils bundle
- write a realization of plug-in service
public class Square implements IGeometry{ public Double getMeasure(Object object){ Square square = (Square) object; return square.x * square.y; } }
- Activate it by extending org.eclipse.eilf.utils.service.AbstractServiceActivator
public final class Activator extends AbstractServiceActivator<Square> { /* * (non-Javadoc) * * @see org.eclipse.eilf.utils.service.AbstractServiceActivator#getServiceGroupName() */ @Override protected final String getServiceGroupName() { return IGeometry.class.getName(); } /* * (non-Javadoc) * * @see org.eclipse.eilf.utils.service.AbstractServiceActivator#getServiceSubName() */ @Override protected final String getServiceSubName() { return "square"; } /* * (non-Javadoc) * * @see org.eclipse.eilf.utils.service.AbstractServiceActivator#newServiceInstance(org.osgi.framework.BundleContext) */ @Override protected Square newServiceInstance(final BundleContext context) { return new Square(); } }
- example of usage
.... IGeometryRegistry registry = (IGeometryRegistry)_context.getService(reference) //it should exists otherwise its critical error Double measure = registry.getMeasure(o)
Sample bundles based on this idea implemented and located in "EILF/trunc"
Query processing sample
org.eclipse.eilf.query.processing (registry) org.eclipse.eilf.exampleplugin.query.processing (sample plug-in) org.eclipse.eilf.query.processing.test (test)
JMS access org.eclipse.eilf.jms (registry) org.apache.activemq (plug-in)