Are OSGi and Jigsaw at odds? The teacup tempest opens a view on a larger issue – that of component coupling. The Java controversy of late pits full OSGi modularity versus Jigsaw’s “simpler” approach. But, what is key perhaps is where the proper level of modularity lies for any given set of components.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
By James Denman
There have been some heated debates over on the forums at TheServerSide.com lately about whether full blown OSGi modularity is strictly necessary, or if Jigsaw’s “simpler” approach is good enough. Based on those discussions, the biggest issue in the debate may be where the proper level of modularity lies. The OSGi side maintains that each package should be its own independent module without dependencies on other packages, while the Jigsaw side puts forward the possibility that modules can be defined at a higher level then packages and that packages can be spread across modules.
Either way, the connections between the modules must maintain modularity or the benefits of having a modular architecture will largely be lost. The great thing about building with highly interchangeable parts is that you can pull one part out and replace it with another similar – but somehow better – part without disrupting the rest of the system. But if the parts are all soldered together, you can’t pull one without breaking another.
Bringing this analogy back to SOA, if you’re service components are bound by strictly coupled service contracts, you’re not getting as much value as you could be getting from your potentially reusable services. According to the Art of Software Reuse blog, the trick to maintaining modular services is to employ decoupled service contracts. Specifically, they advocate the Decoupled Contract Pattern from SOApatterns.org.
In a blog by Vijay Narayanan, we learn that the Decoupled Contract Pattern abandons the contract specifications of a WSDL document in favor of a more technology agnostic approach. By creating a contract without references or dependencies to any proprietary technologies, the Decoupled Contract Pattern enables a more modular binding of services.
More on decoupled design issues
Search for more on loose coupling on SearchSOA.com
From the SearchSOA.com Vault: Using atomicity to gain SOA granularity -Apr. 2009