SOA Talk

Aug 3 2011   4:55PM GMT

Decoupled Service Contracts enable more modular services

Jack Vaughan Jack Vaughan Profile: Jack Vaughan

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 James Denman

There have been some heated debates over on the forums at 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

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
From the Vault: Using atomicity to gain SOA granularity -Apr. 2009

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: