7

I've in mind an intelligent system which can choose among available OSGi services dynamically. That is, choose an implementation or another depending of some runtime parameter. For example, notify to a running algorithm that change an operator after several iterations, or depending of load balancing in a system or whatever.

while(stopCriterion){
    operator.doSomething(); //There exist many operator implementations
}

My first approach is to use DS to expose the services and bind services with 0..n and dynamic policy. Then, from an external intelligent component, notify the algorithm which service use in every iteration (using EventAdmin, maybe?). 

operator[selected].doSomething();

This could help me to reduce complexity when many experiments with a lot of different service implementations must be executed. Also, I am planning to use Remote Services specification with Eclipse Communication Framework to make research in distributed algorithms and that stuff, so dynamically appearing of new implementations in execution time also could be possible

However, I don't know if is this a good idea or there exist another better mechanism to dynamically select which implementation use. I think that using ServiceTracker instead DS is not a good option, but I'm open to suggestions :)

Thanks in advance.

Pablo García
  • 237
  • 1
  • 10

2 Answers2

5

This looks to me like a strategy pattern, which can very well be implemented using services. Assuming you have a type of service called Operator (and have an interface with the same name), this would work roughly like this:

  • Create a OperatorProvider service, which contains the necessary functionality, and some additional information (such as, when is this implementation suitable), and create a number of instances of that, one for each of your strategies.
  • Create a selector service, which implements the Operator interface, and channels all calls to the service to the most suitable OperatorProvider. The way in which this service selects the most suitable provider, is probably part of the intelligence.
  • The actual user of the service now only has a dependency on an Operator service, and does not have to worry about the provider selection.

I assume you can put the selection strategy in the selector service, but if it really is an external component, you can use any mechanism you like to handle the communication between the intelligent component and the selector: a service interface, events, etc.

Angelo van der Sijpt
  • 3,611
  • 18
  • 24
  • Hi Andy. I like your idea of an intermediate selector service to select the appropriate instance :) However, the developers of "Operators" and "Algorithms" probably are not familiarized with OSGi, and I think that the Selector could confuse them. Anyway, I found your comment an elegant form to solve my problem. If nobody gives me another solution, I'll mark your answer as "checked" (this is my first question in StackOverflow, I don't know if I've I can check more than an answer or modify my choice). – Pablo García Apr 27 '11 at 14:49
  • There is no need for the operator-implementors to know a lot about OSGi, as longs as they just implement the correct interface. As for accepting an answer: I don't think you can revise your choice, so choose wisely. (Or see the [faq](http://stackoverflow.com/faq) for more guidance.) – Angelo van der Sijpt Apr 27 '11 at 14:53
  • Thanks Angelo (not Andy!). Your idea is cool because Selector also can bind other services that the "Algorithm" uses to extract information :) (I cannot upvote your answer yet, I need more reputation). – Pablo García Apr 27 '11 at 15:23
0

I guess, some sort of dynamic strategy pattern or even dependency injection could fit your needs. Some class uses a strategy (you called it operator) which can change at runtime. I think, you have another service that can tell the which strategy to use (based on runtime parameters).

A rough implementation could look like that:

public Worker {
  private Operator operator;    // your actual operator strategy
  public void setOperator(Operator actualOperator) {
    this.operator = operator;
  }

  public doSomething() {

     while(stopCriterion) {
       Operator operatorForThisIteration = operator;  // pick the injected service
       operatorForThisIteration.doSomething;
     }
  }
}

And another service, the one that can inject dependencies to worker instances, would maintain a list of all worker instances, implement some logic to choose a new service and inject in into all (or some) workers.

Andreas Dolk
  • 113,398
  • 19
  • 180
  • 268
  • Hi Andreas. I am searching loose coupling using the OSGi capabilities. The "intelligence" should be outside the "Worker" (and also optional) but not managing Workers. Nevertheless I note your idea to use it in other problems ;) – Pablo García Apr 27 '11 at 14:55
  • @Pablo - the coupling is pretty loose, `Operator` is an interface and not a service implementation ..!? – Andreas Dolk Apr 27 '11 at 16:00