There always has been been promises to solve tech problems since ever; although, sometimes a solution creates another problem, first we had monolithic applications where all code has to be written by the same team; from I/O access to Presentation; then we had libraries to concentrate common pieces of code for a particular task, but these libraries created to be reuse had interdependencies with other libraries of code, then to solve these interdependencies we create versioned libraries and ship them in a single file, but as we had versioning we start to have problems with libraries having dependencies for a particular version and any new version might break the code; thus our code is still tightly coupled; even though, we have tried all tricks in the book (and some that aren’t in the book) to decouple our modules.

One common approach is to use patterns such factories to decouple the modules and leave the factory to decide (based on configuration) which “module” to deliver, and yet still once the object has been delivered it cannot be retaken or change into some new version; despite all these efforts, one fundamental problem remains: “how to decouple our modules and make them resilient to change in other modules”. Since 1999 there has been efforts from a group to define a standard for a framework capable of this decoupling, it first started as a solution for device communication where its applicability is obvious (i.e. in a Smart House where appliances come a goes any time) where the modules should be self aware of each other and auto-configurable.
Nowadays this framework is making its way into the enterprise application world to allow a SOA environment to exists in a single JVM or distributed JVMs, making modules reusable, secure, distributed, resilient, environment aware, self configurable, versioned and more; it varies from WS SOA in not requiring a transport layer removing this overhead and making services resilient. This framework its defined by OSGi Alliance and they provide the detailed specs for the framework but several implementations can be found both in commercial and open source versions, some examples are:

http://www.knopflerfish.org/
http://www.eclipse.org/equinox/
http://felix.apache.org/

A promise of a SOA environment without the overhead of the transport layer and a build in ability to react to failures and code changes is a great improvement it definitely adds a great number of advantages for (at last) modular development. We definitely should keep an eye in the releases of implementations of RFCs from this group.

Tips & Examples, Comentarios java, architectura, soa