One of the projects that I am currently working on is a Dual-API SDK. This “Framework” has two APIs (or “sides”) - Client API and the SPI (Service Provider Interface) API.
The Client API provides the ability for the Client to deal with various kinds of Artifacts (Requirements, Tasks, CRs, etc.) without paying attention to which “Repository” they came from. Meanwhile, the SPI API provides the ability to ”implement” and “register” the “Providers” (corresponding to various “Repositories” that implement a subset of the SPIs).
Once these SPIs are “registered”, it becomes possible for the “Framework” to provide the “CRUD” operations for the appropriate Artifacts from the “Repositories” that support the given Artifact type(s).
The following requirements decided the backbone-technology to be used for this “Framework” product:
- Ability to dynamically register and un-register SPIs (corresponding to various “Repositories”).
- Ability to support multiple versions of the same SPIs co-existing in the same runtime environment.
- Support modularity of SPI implementations and loose coupling between various modules.
- A low cost (or possibly free) server with a license that allowed us to bundle it with our “Framework” product.
- A Java-based technology.
The most suitable technology for this turned out to be OSGi. This was a suprisingly easy choice. The only other option that came close was Mule 2.0.
