Service Loose Coupling
Loose coupling can be thought of as the resilient relationship that exists among two or more systems or companies that have some sort of relationship based on exchange. Each transactional end should make its requirements explicit somehow and make very few, if any, assumptions about the other end. While the notion of loose coupling originated in computer systems, Karl Weick later brought it in to organizational studies.
Loose Coupling in Computing Loosely coupled computers systems are regarded as being useful in the event that either the destination or the source computing systems are subject to changes on a frequent basis.
Loose coupling can be thought of as a design goal that has to be sought out by companies who are in the process of implementing an Enterprise Messaging System.
There are numerous dimensions to the idea of loose coupling. Integration, for instance, between two applications may be coupled loosely in time through the usage of Message oriented middleware – meaning the availability of such a system does not have any affect on the other. On the other hand, integration might be coupled loosely in format through the utilization of middleware as a means of performing data transformation – i.e. differences in data models are not able to prevent integration. When it comes to Service Oriented Architecture or Web Services, loose coupling can mean simply that the implementation is concealed from the caller.
Loose coupling may be applied to friction free linking that is enabled by open architectures. Services that are loosely coupled, even if they might be employing incompatible system technologies, might be able to be joined together on demand as a means of creating composite services, or readily disassembled in to functional components. Through normative or inceptive means, participants are able to establish a shared semantic framework in order to ensure that messages retain a consistent meaning across the spectrum of participating services.
Loose coupling is thus descriptive as an approach in which integration interfaces are developed with very few assumptions among sending and receiving parties. This reduces the risk that any changes that take place in one particular application will make a change in a relating application necessary.
Loose coupling can also be thought of as a computer system wherein two or more physical processors share storage disks in a real time atmosphere. The system has to be designed in order to enable code to be shared. It must be reentrant and the records to be shared have to be protected via record locking.
The extent of the loose coupling can be measured through a notation of the quantity of changes within the data elements that might occur in the sending or receiving systems, and then determining whether the computers would still be able to communicate in a correct manner. Such changes might include items like
- New data elements that are added to messages
- Data elements that are omitted
- The order of data elements being altered
- The structure or name of a data element being altered
Loose coupling can be enhanced in a major way by transmitting messages through the use of a flexible file format like XML as a means of enabling subscribers to publish clear definitions of how they use this info subsequently. A subscriber, for instance, might wish to publish a collection of statements that was used to extract data from a publisher’s messages through sharing relevant Xpath expressions utilized for the transformation of data. Such a step would then allow a responsible publisher of data to see whether their subscriber’s extraction methods would work when a change is made to a published format.
By reducing the data passed in to a service to the key data, the loose coupling of services is then enhanced. A service, for instance, that transmits a letter is most reusable when only the customer identifier is passed and the customer address is obtained from within the service. This effectively decouples services because then they do not need to be called in a specific order.
Loose Coupling and On Demand Businesses
Loose Coupling and “On Demand” Businesses tend to change their structures quite often. This trend has been enforced by the ongoing focus on globalization and service orientation. Today’s business world is undergoing preparation for independent autonomous service providers as well as service consumers.
Many parts of the business process have begun to be outsourced to external partners. Business units and departments are then transferred to service providers. Such service providers do not merely focus on the internal workings of the business, but external markets for which they may offer their services.
Indeed, everything in today’s business environment seems to be moving towards an “on demand” business structure, wherein service providers are compelled to react to events from within the environment.
In order to do well in a competitive market, a high level of autonomy must be maintained. This should include the freedom to select the right supporting IT systems. There is an increasing degree of separation that creates a vital need for loose coupling to take place among application components. This enables the supported business processes to bend with the continuously changing nature of the business structure.
As a means of attaining such agility, the supporting applications have to be agnostic to organizational changes such as the reshuffling of roles and responsibilities, in sourcing and outsourcing, the division of the departments or the entire company, fusions and all sorts of other reorganizations.
Business processes should not be limited buy supporting Information Technology systems. The business processes should smoothly follow all business changes. If, for example, part of the process is outsourced to an external partner, then part of the supporting Information Technology system winds up getting cut off. The system’s remaining parts should start then communicating with the outside partner. The system should not be allowed to collapse. It is also undesirable for an adaptation to a new situation to cost a lot of time and money. This should be prevented at all costs.
Can Service Oriented Architecture live up to the hype?
Loosely coupled application parts should be able to readily put the scissors right in to the structure of the business without disrupting supporting Information Technology systems. At the same time, the synchronous command and control nature of Service Oriented Architecture is one method of tightly coupling application components that do not allow for such a wide degree of flexibility.
Service Oriented Architecture can be loosely coupled in the technical domain, where common web services technology is utilized, but it is not really in the functional domain where Service Oriented Architecture may be associate with calling foreign services and thus eliminating the redundancies of data.
The availability of stored data and services might be made to disappear after an act of outsourcing, which might lead to costly consequences and major risks. All this has to do with the creation of dependencies via Service Oriented Architecture. So in a way, Service Oriented Architecture’s promise of delivering loose coupling, which tends to be asynchronous, can at the functional level be regarded as hype.
Information Technology Flexibility vs. Organizational Flexibility.
Of course the utilization of Service Oriented Architecture does have its benefits. The restructuring of an application in following the business process of redesign can be very beneficial. The Information Technology department can also benefit from this. It will lead, in the end, to lower Information Technology costs for the business side, as well as delivery at a faster rate.
Right now, Service Oriented Architecture’s position in the market is that of a mainly command and control type architecture at the highest granularity levels of functional decomposition. In order to attain both loose coupling and autonomy within the context of the previously mentioned organizational evolutions, event driven architecture can be regarded as a more apt style of architecture at the current level of granularity.
Event Driven Architecture provides flexibility directly to the business itself. With Event Driven Architecture, a business is able to reorganize without affection the construction of an application. Event Driven Architecture assures that a change can be made to the structure of a business without altering the applications.
Granularity
Why, then, is Service Oriented Architecture promoted at such a level of granularity? In charge is the causality of four aspects. First off, Service Oriented Architecture tends to be considered in terms of web services. Secondly, web services technology on the performance level is currently inappropriate at the lower levels of granularity. Third, web services come from request and reply patterns; thus, they tend to be associated with command and control solutions. Finally, event driven models are not well known – people only look for solutions in more commonly known domains.
It is an unfortunate fact that the command and control pattern is inappropriate at this level. Service Oriented Architecture can be a good idea in the middle layers of functional composition when it is based on synchronous web services. In those situations, the command and control type of interaction will typically be required, and may in fact be in good balance with the performance of web services.
