The OSGi alliance vision for the future of modular application development – which they see as the future of application development in general – includes a component-based application development community strong enough to support a thriving component market. Much like consumers now download apps that make their mobile phones perform the latest greatest tricks, application developers may one day be able to download modular components that can plug into existing enterprise applications.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
At JavaOne 2011, Peter Kriens gave two informative talks about OSGi and also led the Birds of a Feather group for OSGi as well. Kriens sessions explained why, despite the difficulties it presents, implementing modularity with OSGi is valuable for today's application developers. He also explained how to get there from here, and cleared up some misconceptions about OSGi and modular applications.
One assumption that outsiders might make is that the "Services" in Open Services Gateway initiative stand for the sort of Web services in a service-oriented architecture (SOA). Turns out, as Kreins pointed out, OSGi services are actually local services which are much less verbose and therefore much faster. Still, much of the service-oriented mindset applies to OSGi modularity.
In both cases, the services are the agent of modularity (SOA folks read "loose coupling") between systems. The difference is that Web services generally allow communication between systems distributed over some distance via the Internet, whereas in OSGi local services connect subsystems (modules) that interact to form complicated applications.
These local services are extremely important in the OSGi model of modularity. These services, when done properly, are what allows truly loose coupling between modules. According to Kriens, it's very important to ensure that each module is blind to the internal operations of all the other modules. That way, they cannot have any dependencies on anything but express outputs. It also means that it doesn't matter how those outputs are arrived at. It makes the modules interchangeable parts, and a little bit more.
If you already have a module that outputs data x, y and z, and you're building a module that needs input data x, y and z, it can be very tempting to glom your new module right onto the existing module. Kriens insists that this is not the best way to go about it. All your new module really needs are x, y and z, so that's where you're dependencies should be.
If, down the line, another developer needs to replace the existing module, all they have to do is make sure the replacement module still provides x, y and z. They could even split the module into two parts as long as between the two of them, they both still provide x, y and z. This gives future developers much more flexibility as they work with enterprise systems.
Which is why Kriens suggests moving to OSGi via services first. Building truly modular modules is really hard – especially if the rest of your subsystems aren't modular yet. The OSGi framework can feel like it's all or nothing. But you can set up the services in a modular way whether the modules are actually modular or not. With well defined services in place, it becomes much easier to move to OSGi in an iterative fashion where you create pockets of modularity.
Having modularity in pockets won't immediately grant you all the benefits of a fully modular system, but if implemented properly, they will garner some benefit. These benefits can be used to prove the value of modularity and encourage other developers to join in with building up existing modularity and creating new components that have real modularity.