I chose OSGi to develop this framework for several reasons:
The first (and main) reason is the flexibility that provides. In OSGi a service (as all services in Service Oriented Architecture) is formed by an interface and an implementation. To access a service you only need to know the interface, not the implementation. The implementation is automatically bound with the interface. And even you can manage many implementations at the same time!
This implementations can appear or disappear in real time, so at the beginning of your algorithm you could have 10 different crossovers implementations but only one at the end. OSGi gives you the capability of manage the dynamism of services.
To create a service you don’t need to touch code, just create an XML that specifies:
- The interface (a normal Java Interface) to implement
- The class that implement this interface(s).
- And, if you need it, the methods to bind or unbind other service interfaces automatically (and set filters, the cardinality or the optionality). For example “I need at least two different crossovers to start”.
This is called Declarative Service Specification. If you need more information this is a good tutorial.
Finally, OSGi includes Event Admin manager. This service is a publish/subscribe mechanism. In normal OOP you call a method with arguments. With this mechanism you send the argument to “space” and the interested “guys” who need this data could filter and take it to use. For example, send an event when a fitness evaluation is performed and other service(s) could read this information for their purposes. The fitness operator don’t need to know how many other services are listening, neither have a control. This is another quick tutorial to understand the event admin.
But, what about distributed programming? The final advantage of OSGi is the Remote Services Specification, that means the local services are indistinguishable from the distributed ones in other process, machines or networks. The previous ideas presented are compatible with this specification. In my case, I am using Eclipse Communication Framework, but other implementations could be used. With this implementation you stablish how the services communicate (using REST, SOAP, TCP…) but you don’t have to modify the service code!
More information about this ideas, but more focused to the application in EAs, are in a journal revision process, so, I’ll notify when it is published 🙂