Welcome!

Microservices Expo Authors: Liz McMillan, Pat Romanski, Elizabeth White, Mehdi Daoudi, Yeshim Deniz

Related Topics: Microservices Expo

Microservices Expo: Article

Understanding Coupling in the Context of an SOA

Comparative Architecture

Since the beginning of computing we've been dealing with the notion of coupling, or the degree to which one component is dependent on another component in both the domain of an application or an architecture. Lately, the movement has been towards loose coupling for some very good reasons, but I'm not sure that many architects out there building SOAs understand the motives behind this.

Breaking this concept down to its essence, we can state that tightly coupled systems/architectures are dependent on each other, thus changes to any component may prompt changes to many other components. Loosely coupled systems/architectures, in contrast, leverage independent components, and so can operate independently. However, it's not as simple as all that.

Keep in mind that how loosely or tightly coupled your architecture is is a matter of requirements, and not as much about what's popular. Indeed, architects need to understand the value of SOAs and loose coupling, and make the right calls to insure that the architecture matches the business objectives. So it's helpful to walk through this notion of coupling as you approach your SOA.

Hang Loose!
With the advent of Web Services and SOA we've been seeking to create architectures and systems that are more loosely coupled. Loosely coupled systems provide many advantages including support for late or dynamically binding to other components while running, and can mediate the difference in the component's structure, security model, protocols and semantics, thereby abstracting volatility.

This contrasts to compile-time or run-time binding that requires that you bind the components at compile-time or run-time (synchronous calls) respectively, and also requires that changes be designed into all components at the same time due to their dependencies. As you might imagine, this kind of coupling makes testing and component changes much more difficult.

The advantages of loosely coupled architectures, as found in many SOAs, are apparent to many of us who have built architectures and systems in the past, at least from a technical perspective. However, they have business value as well.

First and foremost, a loosely coupled architecture allows you to replace components, or change components, without having to make reflective changes to other components in the architecture/systems. This means businesses can change their business systems as needed, with much more agility than if the architecture/systems was more tightly coupled.

Second, developers can pick and choose the right enabling technology for the job without concerning themselves with technical dependencies, such as security models. Thus, you can build new components using J2EE, which will work and play well with other components written in Cobol or perhaps C++. Same thing goes for persistence layers, middleware and protocols. You can mix and match to meet your needs, even leverage services that may exist outside of your organization without regard for how that service was created, how it communicates, or where it's running.

Finally, with this degree of independence components are protected from each other and can better recover from component failure. If the SOA is designed correctly, the failure of a single component shouldn't take down other components in the system. Thus, loose coupling creates architectures that are more resilient. Moreover, this also lends itself better to creating a failover subsystem and moving from one instance of a component to another without affecting the other components in the SOA.

It should be noted, however, that not all tight coupling is bad. Indeed, in some cases it makes sense to more tightly couple components, such as when dependencies are critical to the design. An example would be two services that can't work apart, and must function as one, and so are better tightly coupled. You have to look at your requirements, and then determine the degree of coupling needed in your architecture, and it may not always be loose coupling.

Testing for Loosely Coupled Architecture
So, now that we know the basic differences between a tightly and loosely coupled architecture, as well as the advantages, perhaps it's a good idea to break down loose coupling in to a few basic patterns: location independence, communication independence, security independence and instance independence.

  • Location independence refers to the notion that it doesn't matter where a service exists. The other components that need to leverage the service can discovery it in a directory, and leverage it through the late-binding process. This comes in handy when you're leveraging services that are consistently changing physical and logical locations, especially services outside your organization that you may not own. Your risk calculation service may exist in L.A. on Monday and in New York on Friday, and it should make no difference to you.

    Dynamic discovery is key here, meaning that calling components can locate service information as needed, and without having to bind tightly to the service. Typically, these services are private, shared or public services as they exist in the directory.

  • Communications independence means that all components can talk to each other no matter how they communicate at the interface or protocol levels. Thus, we leverage enabling standards, such as Web Services, to mediate the protocol and interface difference.

  • Security independence refers to the concept of mediating the difference between security models in and between components. This is a bit difficult to pull off, but necessary to any SOA. To enable this pattern, you'll have to leverage a federated security system that's able to create trust between components, no matter what security model is local to the components. This has been the primary force behind a number of federated security standards that have emerged in support of the loosely coupled model and Web Services.

  • Instance independence means that the architecture should support component-to-component communications, using both a synchronous and asynchronous model, and not require that the other component be in any particular state before getting the request, or message. If done right, all the services should be able to service any requesting component, asynchronously, as well as retain and manage state no matter what the sequencing is.

    The need for loosely coupled architecture in your SOA is really not the question. If you have a SOA, you should have a loosely coupled architecture if done correctly. However, analysis and planning are also part of the mix. Understanding your requirements and how each component of your architecture should leverage the other components of your architecture. With a bit of up-front work, you'll find your coupling loose and your SOA successful.

  • More Stories By David Linthicum

    Dave Linthicum is Sr. VP at Cloud Technology Partners, and an internationally known cloud computing and SOA expert. He is a sought-after consultant, speaker, and blogger. In his career, Dave has formed or enhanced many of the ideas behind modern distributed computing including EAI, B2B Application Integration, and SOA, approaches and technologies in wide use today. In addition, he is the Editor-in-Chief of SYS-CON's Virtualization Journal.

    For the last 10 years, he has focused on the technology and strategies around cloud computing, including working with several cloud computing startups. His industry experience includes tenure as CTO and CEO of several successful software and cloud computing companies, and upper-level management positions in Fortune 500 companies. In addition, he was an associate professor of computer science for eight years, and continues to lecture at major technical colleges and universities, including University of Virginia and Arizona State University. He keynotes at many leading technology conferences, and has several well-read columns and blogs. Linthicum has authored 10 books, including the ground-breaking "Enterprise Application Integration" and "B2B Application Integration." You can reach him at [email protected] Or follow him on Twitter. Or view his profile on LinkedIn.

    Comments (2) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    Peggi D 04/15/05 12:46:54 PM EDT

    Great article that nails the issue of coupling and its impact on the successful use of the SOA approach

    Peggi D 04/15/05 12:46:54 PM EDT

    Great article that nails the issue of coupling and its impact on the successful use of the SOA approach

    Microservices Articles
    CloudEXPO New York 2018, colocated with DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one location.
    DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City. Digital Transformation (DX) is a major focus with the introduction of DXWorldEXPO within the program. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term.
    Two apparently distinct movements are in the process of disrupting the world of enterprise application development: DevOps and Low-Code. DevOps is a cultural and organizational shift that empowers enterprise software teams to deliver better software quicker – in particular, hand-coded software. Low-Code platforms, in contrast, provide a technology platform and visual tooling that empower enterprise software teams to deliver better software quicker -- with little or no hand-coding required. ...
    "We do one of the best file systems in the world. We learned how to deal with Big Data many years ago and we implemented this knowledge into our software," explained Jakub Ratajczak, Business Development Manager at MooseFS, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
    All zSystem customers have a significant new business opportunity to extend their reach to new customers and markets with new applications and services, and to improve the experience of existing customers. This can be achieved by exposing existing z assets (which have been developed over time) as APIs for accessing Systems of Record, while leveraging mobile and cloud capabilities with new Systems of Engagement applications. In this session, we will explore business drivers with new Node.js apps ...
    Using new techniques of information modeling, indexing, and processing, new cloud-based systems can support cloud-based workloads previously not possible for high-throughput insurance, banking, and case-based applications. In his session at 18th Cloud Expo, John Newton, CTO, Founder and Chairman of Alfresco, described how to scale cloud-based content management repositories to store, manage, and retrieve billions of documents and related information with fast and linear scalability. He addres...
    While some developers care passionately about how data centers and clouds are architected, for most, it is only the end result that matters. To the majority of companies, technology exists to solve a business problem, and only delivers value when it is solving that problem. 2017 brings the mainstream adoption of containers for production workloads. In his session at 21st Cloud Expo, Ben McCormack, VP of Operations at Evernote, discussed how data centers of the future will be managed, how the p...
    Digital Transformation is well underway with many applications already on the cloud utilizing agile and devops methodologies. Unfortunately, application security has been an afterthought and data breaches have become a daily occurrence. Security is not one individual or one's team responsibility. Raphael Reich will introduce you to DevSecOps concepts and outline how to seamlessly interweave security principles across your software development lifecycle and application lifecycle management. With ...
    Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple cloud provider environments. Yet, despite this portability promise, developers may include configuration and application definitions that constrain or even eliminate application portability. In this session we'll describe best practices for "configuration as code" in a Kubernetes environment. We will demonstrate how a properly constructed containerized app can be deployed to both Amazon and Azure ...
    The now mainstream platform changes stemming from the first Internet boom brought many changes but didn’t really change the basic relationship between servers and the applications running on them. In fact, that was sort of the point. In his session at 18th Cloud Expo, Gordon Haff, senior cloud strategy marketing and evangelism manager at Red Hat, will discuss how today’s workloads require a new model and a new platform for development and execution. The platform must handle a wide range of rec...