If systems are decoupled in time, it is difficult to also provide transactional integrity ; additional coordination protocols are required. Data replication across different systems provides loose coupling in availability , but creates issues in maintaining consistency data synchronization. Loose coupling in broader distributed system design is achieved by the use of transactions, queues provided by message-oriented middleware , and interoperability standards.
Four types of autonomy, which promote loose coupling, are: reference autonomy , time autonomy , format autonomy , and platform autonomy. Loose coupling is an architectural principle and design goal in service-oriented architectures ; eleven forms of loose coupling and their tight coupling counterparts are listed in: .
Enterprise Service Bus ESB middleware was invented to achieve loose coupling in multiple dimensions;  however, overengineered and mispositioned ESBs can also have the contrary effect and create undesired tight coupling and a central architectural hotspot. Event-driven architecture also aims at promoting loose coupling. Loose coupling between program components can be enhanced by using standard data types in parameters.
Passing customized data types or objects requires both components to have knowledge of the custom data definition. Loose coupling of services can be enhanced by reducing the information passed into a service to the key data.
For example, a service that sends a letter is most reusable when just the customer identifier is passed and the customer address is obtained within the service. This decouples services because services do not need to be called in a specific order e. GetCustomerAddress, SendLetter. Loose coupling of application integration in business process automation contexts can be increased by following a presentation layer integration model in which automation applications interact with underlying automated applications through the presentation layer or graphical user interface.
Coupling refers to the degree of direct knowledge that one component has of another. Loose coupling in computing is interpreted as encapsulation vs. An example of tight coupling occurs when a dependent class contains a pointer directly to a concrete class which provides the required behavior.
The dependency cannot be substituted, or its "signature" changed, without requiring a change to the dependent class. Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes. Any class that implements the interface can thus satisfy the dependency of a dependent class without having to change the class.
This allows for extensibility in software design; a new class implementing an interface can be written to replace a current dependency in some or all situations, without requiring a change to the dependent class; the new and old classes can be interchanged freely. Strong coupling does not allow this.
Advantages and disadvantages
This is a UML diagram illustrating an example of loose coupling between a dependent class and a set of concrete classes, which provide the required behavior:. For comparison, this diagram illustrates the alternative design with strong coupling between the dependent class and a provider:. Computer programming languages having notions of either functions as the core module see Functional programming or functions as objects provide excellent examples of loosely coupled programming.
Functional languages have patterns of Continuations , Closure , or generators. See Clojure and Lisp as examples of function programming languages. Object-oriented languages like Smalltalk and Ruby have code blocks, whereas Eiffel has agents. More than a new architectural approach, such architectures require a different perspective on the role of IT in the organization. The role of the service-oriented architect, therefore, is critical to the success of companies looking to achieve the substantial returns business agility can provide. Today's enterprise architect must understand the practice of Service-Oriented Architectures.
The potential rewards for this effort are enormous -- finally, distributed computing technology promises to be flexible and nimble enough to respond to business needs and provide the business agility companies have craved for so long, but which has always been just out of reach. Service-Oriented Architectures are an approach to distributed computing that thinks of software resources as services available on a network.
- Common Edible Mushrooms.
- Understanding SOA with Web Services!
- Loosely Coupled: The Missing Pieces of Web Services by Doug Kaye!
- Water Science & Technology in China: A Roadmap to 2050;
However, these older examples of service-orientation suffered from a few difficult problems. First, they were tightly coupled, which meant that both ends of each distributed computing link had to agree on the details of the API. A code change to a COM object, for example, required corresponding changes to the code accessing that object. Secondly, such Service-Oriented Architectures were proprietary. What is new about today's Service-Oriented Architectures built with Web services is that they are standards-based and loosely coupled.
The reliance upon universally accepted standards like XML and SOAP provides broad interoperability among different vendors' solutions, and loose coupling separates the participants in distributed computing interactions so that modifying the interface of one participant in the exchange does not break the other.
The combination of these two core principles means that companies can implement Web services without having any knowledge of the consumers of those services, and vice versa. The Service-Oriented Architectures we will discuss are the standards-based, loosely coupled kind, which we will refer to as SOAs. The power and flexibility that SOAs can potentially offer the enterprise is substantial. If an organization abstracts its IT infrastructure so that it presents its functionality in the form of coarse-grained services that offer clear business value, then consumers of those services whether they are at the same company or one of that company's business partners can access those services independent of the underlying technology issues that support them.
Furthermore, if service consumers can discover and bind to available services while they are active, then the IT infrastructure behind those services can offer extraordinary flexibility to the businesses that invoke them. Achieving these levels of power and flexibility, however, is a difficult task that requires a new approach to architecture. Enterprise architects must become ''service-oriented architects'' who understand the practice of SOA, as well as SOAs themselves.
This distinction -- between the practice of architecture and the architectures that result -- is subtle, but critical. This article discusses the practice; that is, what service-oriented architects must do to build SOAs. The principles of SOA SOA is a type of enterprise architecture and, as such, it begins with the needs of the enterprise. However, the difference between SOA and other approaches to enterprise architecture is in the business agility that SOA offers.
Web Services Strategies
Business agility is the ability of a company to respond quickly and efficiently to change, and to leverage change for competitive advantage. For the architect, building an architecture that provides business agility means creating an IT infrastructure that meets as-yet-unknown business requirements -- a situation that throws traditional IT planning and design out the window. To meet the needs of the agile enterprise, the practice of SOA has the following core principles:. In essence, services act as a layer of abstraction between the business and the technology.
The service-oriented architect must understand the dynamic relationships between the needs of the business and the available services on the one hand, as well as the technical underpinnings that offer the layer of abstraction required by the services.
Instead of dealing with concrete requirements from business, SOA considers the next level of abstraction: The ability to respond to changing requirements is the new ''meta-requirement. To visualize how a SOA is supposed to work, it is better to think of a living organism rather than the traditional ''building a house'' metaphor that gave software architecture its name. IT environments are in a constant state of change, so the work of a service-oriented architect is never done.
Loosely Coupled : The Missing Pieces of Web Services by Doug Kaye (2003, Paperback)
For the architect used to building houses, tending to a living organism requires a new way of thinking. Fortunately, however, the foundations of SOA rely upon familiar architectural principles. The foundations of SOA There are two increasingly popular movements in IT -- one architectural, the other methodological -- and each has something to offer the service-oriented architect. MDA begins with a platform-independent model that represents the functional requirements and use cases of the users of the system.
From this platform-independent model, architects can derive whatever platform-dependent models they need to specify the design of the system under construction. These platform-dependent models are so detailed that they can be used to automatically generate the implementation code itself. The core strength of MDA is that the designs for systems are fully specified; thus, there is little leeway for misinterpretation when the systems are built, and the models can be used to generate working code.
But MDA has some limitations. First, MDA assumes that the business requirements are fully specified before the model is built, which is not the case in the typical dynamic business environment.
Loosely Coupled: The Missing Pieces of Web Services
Second, MDA does not offer a feedback loop; if developers need to diverge from the models, there is no set way to keep the models up to date. AMs like XP provide a process for building software systems in environments where requirements are unknown or in flux. XP requires that a user representative work closely with the development team, helping to write tests that guide the daily work of the developers. All members of the team pitch in on the design, which is kept as minimal and informal as possible.
The goal of AMs is to build just what the user wants, avoiding extraneous work on artifacts like formal models. AM's core strength lies in its agility -- the ability to deal with changing requirements. AM's main weakness is its limited scalability. For example, XP works well for small teams and projects of moderate size, but as the project scope grows, it becomes more difficult for team members to have a solid grasp of all aspects of the project without a concrete, comprehensive plan to work from. MDA centers on formal models, while AM eschews them.
However, at the risk of being iconoclastic, we will take certain elements from each of these approaches and put them together into a coherent architectural practice.