DECOUPLING

Digg This!

Page 1 of 2   next page »

There are a number of reasons why we continuously change our enterprise applications, but sometimes it's hard to explain to the requester why another change would be so costly and time-consuming to implement. IT leaders who want to be fully prepared for inevitable changes in the corporate software infrastructure should do their best to avoid system coupling on both business and technological levels.

A modern enterprise information system (EIS) consists of hordes of applications bound together to support business activities in the enterprise. The degree of application coupling identifies the difficulty of making changes to them. Although coupling has been always used to describe the connections between application's components, it can be also used to describe relations between applications within the entire EIS.

Applications shouldn't be thought of as a system created forever. The technology is always improved, new data is collected, organizations are restructured, merges occur, and new laws and regulations are passed, all of which affect the EIS. High coupling is a trait that complicates systems maintenance and makes it more expensive to manage. Highly coupled solutions are more difficult to modify since changes made in one place cause changes to be made somewhere else. Although coupling is essential to the connected applications that should have common assumptions about their interaction processes, we should typically work towards decreasing these levels of coupling.

The last technological response to the coupling and integration problems, is Service-Oriented Architecture (SOA).

There are two major aspects of coupling - technological and functional. They are addressed in different ways by different people.

• Technological coupling is the result of assumptions about transport protocols, data encoding schemes, authentication mechanisms, and so on. This aspect is the responsibility of system architects.
• Functional coupling comes from assumptions about the process of interaction and exchanged data. This aspect should be addressed by analysts and domain experts.

Technological Coupling
Technological coupling is caused by assumptions about technical aspects. The more the application knows about how interaction process is organized, the higher coupling is.

To become integrated, applications should speak the same language. This can be achieved by writing applications to use a single communication technology or by adapting them to each other using bridges, proxies, and other similar approaches. Within these methods, individual technological assumptions of particular solutions are replaced with a single standard set of assumptions. These assumptions are usually more high-level. For example, instead of specifying that input files should start with left brocket characters, we specify that it is XML text that conforms to an XML schema. These assumptions are usually supported by third-party libraries and tools, so we do not have to implement them explicitly in our applications. Thus Web service interaction assumptions are implemented by a respective runtime (in Microsoft .NET and Java EE, such a runtime is a part of corresponding platforms).

Today, the most popular solutions are based on Service-Oriented Architecture (SOA) and Enterprise Service Bus (ESB). There are many SOA/ESB products available on the market that helps integrate applications with each other with minimal changes and replaces development efforts with configuring efforts. Often the integration of two particular applications could not be foreseen at the time of conception, like in case of a merger or an acquisition. SOA and ESB offer ideology and tools that help integrate existing applications and facilitate future integrations. The primary theme of products that offer solutions to problems of high technical coupling is independence from technical peculiarities of the applications.

SOA/ESB products help overcome the following issues:

• Differences in transport protocols and message exchange patterns: For example, one client may require synchronous invocation over HTTP, while another might require asynchronous calls over a reliable asynchronous transport accessed through JMS API. Today's popular solution is to use messaging products such as WebSphere MQ or Microsoft Message Queuing, and to use bridges to adapt applications that use other transports. WS-BPEL implementations (that provide orchestrating for Web services) are also used for translating message exchange patterns.
• Differences in data models: For example, an EIS may use an internal format for purchase orders. If a decision to support a public standard like UBL is made, then an adapter service to translate incoming and outgoing messages between these two formats is required. SOA products provide extension points where such adapters can be added to supply auxiliary libraries and languages that will support format transformations.
• Legacy service integration: SOA solutions allow interaction of different legacy applications based on various integration technologies. It might be supported by bridges between the technologies. For example, if a SOA application with SOA technical assumptions needs to interact with a CORBA application with respective assumptions, then a bridge translating SOAP messages to CORBA and vice versa can be used. Such integration is often almost transparent and changes in the legacy application sometimes can be avoided.
• Changes of a service location: If an application accesses a service provided by another application, it should be ready for changes of the service location. This is usually achieved in one of the following two ways:
  - The application attempts to find the required service using a service directory mechanism such as UDDI. So if the service is relocated, the application can find it again in the new location.
  - The application uses a messaging product like WebSphere Message Broker. Here developers shift the responsibility for locating services to the messaging product which routes messages to correct destinations. Administrators have to update the product configuration if location of the service changes.
  
• Multiple authentication domains: Sometimes different partitions of an EIS use different authentication mechanisms. In such cases, authentication information needs to be translated from one security domain to another. For example, WS-Trust and WS-SecureConversation implementations can be utilized.

These products reduce the amount of technical assumptions that have to be shared by applications, thus reducing technical coupling between them.

Although modern approaches are useful, we should not consider tools magic wands. They do not make developers free from knowing technologies and thinking about how to use them effectively. It is very easy to misuse the tools and to introduce security and performance problems, as described later in this article.

Another important point is that we cannot assume a migration to SOA being the last migration. SOA/ESB is based on experience gained from previous integration technologies like CORBA, and it will be superseded by technologies based on experience gained from SOA/ESB. This issue should be considered when the cost of migration to SOA is estimated. Early signs of coming transition are complexity and overabundance of standards.

When problems of technical coupling are solved, this is not the end of the story, but rather, just the first step in making problems related to functional coupling more obvious.

Functional Coupling
Functional coupling is the concept that can be applied to real business processes and paper-based bureaucracy. For example, if a member of an organization has to sign ten forms in different departments to access a document, then the workflow is tightly coupled with a number of other business processes in this organization.

In computer systems, high functional coupling may happen when highly coupled workflows are implemented because of pitfalls in functional requirements. In some cases computer-based implementation of business processes does not reflect actual processes (this might happen due to many reasons and in particular from restructuring an organization's workflow). In all cases, functional coupling is caused by what an application does rather than how. Therefore, such problems are solved by changing functional assumptions about business processes and implementing these changes.

Functional coupling problems are often less obvious than the technical ones. They should be detected and addressed by analysts and domain experts who need to decide what requirements need modification.

An important aspect of activities that reduce functional coupling is reaching functional cohesion, meaning that application functionality should contribute to a single well defined task. UNIX commands and text utilities are classic examples of correlation between programs and specific actions.

Often application scope is extended on an ad hoc basis and the initial task gets lost in changes. It is like a library maintenance application that transforms into Internet bookshops by adding a few use cases here and there. Low cohesion of applications in an EIS leads to a number of problems. The most obvious are:

• Code is difficult to understand which raises expenses for each change.
• Applications are more highly linked and they are more likely to break if another one changes. Moreover, if these applications are maintained by different development teams, then making changes requires additional team coordination expenses.
• System failures happen more often, and the applications are difficult to test when business processes are spread among different applications and servers. This leads to increased development and testing efforts and increased bugs found after deployment.
• In systems with low cohesion, services are more often located on different servers. As a result the network load is raised, and more expensive hardware is typically required to achieve acceptable performance.

Sometimes functional coupling problems and a lack of functional cohesion can be noticeable to software architects. A possible indicator is absence of communication cohesion (i.e., when several different applications are responsible for operating the same business data). This makes an EIS more difficult to maintain and forces developers to deal with problems that could have been avoided if a more adequate domain analysis were done.

Requirements affect applications, but the reverse may also be true. An EIS that adequately implements business processes of an organization provides extremely valuable feedback about the organization's structure and workflow. Thus, if an application belonging to an EIS demonstrates poor cohesion, it may be a sign that underlying business processes could be improved to increase the degree of cohesion. Organizations should not neglect using this as a way of collecting helpful information.

Problems of high functional coupling cannot be reduced purely by technological means since the most difficult part is requirement gathering. The most that we can expect from tools is help in performing a re-factoring of an application and related workflows. Modern IDEs, such as JetBrains IDEA or Eclipse, provide great facilities for program source code re-factoring. We could also expect that in the future we will have tools to make changes on the level of Web services and business processes. For example, when the definition of a Web service is modified, an adapter Web service that provides older versions of the service could be automatically generated. This adapter can be helpful while migration to the new version of the service is in progress allowing updates within the EIS applications one-by-one. But in all cases, decisions about what refactoring procedures should be performed are taken on by humans.

Common Coupling Traps
Along the road to SOA, developers can easily increase coupling, while thinking they're decreasing it. Many coupling traps arise when developers make their systems conform to some additional requirements and principles by compromising its conformance to the original functional requirements. This often happens because IT departments are under increasing pressure to minimize the cost of changes, and developers believe that these additional principles will simplify modifications in the future.

However cost saving techniques that are successfully applied inside an application do not necessary work within the context of an EIS. This was discovered a long time ago (http://citeseer.ist.psu.edu/waldo94note.html), but many people continue learning it from their own experience. One of the important techniques that fail is maximally generic, flexible, and fine-grained interfaces (the latter technique is sometimes over-applied even in the context of a single application).

Let's look at the most common practices that may increase cost of changes. Although the design patterns described below are acceptable approaches, in some cases, we recommend considering them as a warning sign.

Exposing the Application "As-Is"
There are a number of tools that simplify and automate design of Web services by generating a WSDL document from existing code. However, relying on existing internal interfaces can lead to the following problems:

• Analysis that was done during initial application development could be already obsolete at the time of WSDL development.
• Technical assumptions of existing internal components could be invalid when their functionality is exposed as a Web service. For example, an invoker could be specified as a user name parameter to method invocation. This solution could work nicely for local EJBs that are called from servlets, because it is assumed that servlets check user credentials. However if it is exposed as a Web service, it could create a huge security hole. Another similar example is when servlets are responsible for data validation and in these cases some business methods could rely on the servlets to validate data and skip checking it.
• Tools do not discriminate between functional and technical aspects of existing interfaces. They typically leak technical aspects of systems to ESB and often ignore existing standards for passing around such technical information. For example, client credentials could be provided in a custom manner instead of using WS-Security headers.
• Legacy services usually reflect technical approaches popular at the time of their design. If such services are translated by tools, they could be extremely inefficient.

The recommendation here is to design WSDL according to business requirements, ignoring technical aspects of previously implemented solutions. Technical aspects are better expressed independently of business functions. Development of a WSDL document should not be considered a problem, but an opportunity to specify or double-check the functionality being exposed.

Page 1 of 2   next page »