Loosely Coupled Systems

The term loosely coupled system is bound to come up in almost any discussion of JMS-based distributed systems. Loosely coupled systems are typically composed of a group of processes that communicate with each other indirectly. This indirect communication makes it unnecessary for each of these processes to know details about each other: how many there are, where they are located or if they are currently available or not. Indirect communication can be realised by connecting all of the system processes to a Message-Oriented Middleware (MOM) provider rather than connecting them directly to each other.

Since JMS is the standard Java interface to MOM providers, JMS is the most common technology of choice for loosely coupled systems that are implemented in Java. One could argue that systems implemented using Java Spaces are also loosely coupled, but these two technologies are very similar in any case.

Traditional client/server systems can be considered tightly coupled. The bulk of distributed systems in operation today fall into this category, so before getting into the details of loosely coupled systems, let's have a look at how they differ from tightly coupled systems.

Tightly coupled systems are characterized by connection-oriented communication. Typically, a client opens a connection to a server and then uses this connection to exchange data with that server. The establishment of a connection requires that the server is alive and reachable at the moment that the client tries to contact it. Thus if clients are expected to be able to connect to the server at arbitrary times, then there is a strong high availability requirement on the server.

Connections also require that the client explicitly knows the network address at which the server can be reached. In simple cases where there is a single centralized server and its clients connect only to that server, this does not present a major problem — although there can be a lot of reconfiguration required if the address of the server changes, for example. In more distributed environments, where there are a multitude of servers and each performs a specialized function, keeping track of the address associated with each service, and ensuring that every server is available when each client needs, it becomes more difficult.

Loosely coupled systems use messaging as the means of communication between the system components. Such systems typically are:

  • Asynchronous

    The code that processes an incoming message is executed when the message arrives. It is not necessary to poll for the availability of a new message, or to block a thread waiting for the arrival of the next message.

  • Temporally Distributed

    This means that the components of the system that communicate with each other do not all need to be available at the same time. It is not an exception if the intended recipient of a message is not available when the message is sent; processing will continue when the recipient becomes available.

  • Indirectly Addressed

    It is not necessary for an entity in the system to know the network addresses of the entities with which it exchanges messages. It is not even necessary to know their identities or even how many they are. Message producers address messages to named topics, and consumers of messages independently specify from which topics they want to receive messages.

  • Peer-to-Peer

    Although the components of a loosely coupled system may request services from each other, the roles of client and server are blurred, or often nonexistent. There are message producers and message consumers, and many components will have both roles at the same time. Since the various system components have equal status, they are referred to as peers.

Important 

JMS provides the functionality required to realize systems that possess these traits.

Traditional IT Systems

In order to clearly see the importance that JMS and loosely coupled systems will play in the architectures of J2EE systems, we need to take a look at how distributed systems are evolving. In the past, computer systems have been completely contained within single organizations. Here an organization will often correspond to a single company, but the determining characteristic is that an organization has central control over its IT systems: hardware, software, networking, policies, etc.

In large companies, this could correspond to individual departments rather than the company as a whole. With traditional IT systems, any interaction between the computer systems of two different organizations was actually achieved through the interaction of human representatives from each organization, each with access to the system of their own organization.

For example, the inventory control system of a department store indicates that it is time to reorder a particular item. This results in store employee calling up the distributor of that item and placing an order. The person taking the order then enters it into the order processing system of the distributor.

With the Internet emerging as the common IT platform for commerce, there is a huge movement underway to interconnect businesses directly without requiring human intervention for every transaction. This is giving rise to large-scale distributed systems that span across multiple organizations. "Multiple organizations" does not just mean a handful; an automated business-to-business marketplace may have thousands of participants.

Consider the problems presented by implementing such systems with tightly coupled architectures. Imagine that your company's IT systems have strong dependencies on other systems of other companies over which you have no control. Can you execute distributed transactions that include foreign databases? What guarantees do you have about uptime and responsiveness of the other systems? What about security? Who do you contact to resolve these issues?

The technical aspects of these problems can be solved with enough effort, but the problems are not just technical. The non-technical problems include negotiation, consensus, trust, and standardization among many organizations. Within one company, decisions can be dictated; among many companies, consensus is required, and there is no guarantee that this can always be achieved in a reasonable amount of time. If the technical solutions are extremely complex, staffing problems result. Projects of this magnitude require a large staff of programmers to implement. It is not reasonable to expect to be able to find armies of Java/networking/server gurus, so a simple programming model is required.

Inserting JMS

Inserting JMS as a buffer between the organizations that participate in a large-scale distributed system alleviates many of these problems. Each individual system must have tightly coupled interaction only with the JMS provider. The organization that maintains the JMS server is the central contact for connectivity issues. Security is simplified. The optional JMS support for JTA distributed transactions becomes very important here, as it allows each distributed transaction to be contained within a single organization.

Also important is the fact that JMS presents a simple programming model that facilitates asynchronous communication and concurrent, event-driven processing without requiring programmers to master the subtleties of developing multi-threaded code.

For all of these advantages, JMS introduces its own set of issues and dependencies. JMS relies on a central message server, which some organization must maintain. The interaction between JMS clients and the message server is tightly coupled. This paradox is discussed further below.

The reliability, availability and performance of the server is crucial, otherwise the loose coupling of the other system components is not possible. In many cases, this will mandate that the server is implemented as a cluster that provides load balancing and guarantees high availability, but presents the outward appearance of single JMS-compliant message server (see Chapter 8 for an in depth discussion of this).

Although this discussion has centered around the scenario of large systems that span multiple companies, the usefulness of JMS is not limited to this. Systems that span multiple departments in large companies may represent a similar scenario if the departments have a large degree of autonomy (or simply have difficulty cooperating). In some cases the inter-organizational aspects are not an issue, but a system can still benefit from asynchronous communication.

JMS — Peer-to-Peer or Client/Server?

As you have learned, the JMS API depends heavily on the concepts of connections, clients, and servers. These are the standard concepts of tightly coupled, client/server systems. At this point you might think all of the pontification above about the glory of loosely coupled systems is a bunch of nonsense. But wait, there is an explanation.

There are two different views of a JMS-based, loosely coupled distributed system:

  • The infrastructure view, in which the messages server is central hub of all communication

  • The application view, in which the message server does not appear at all

Thus the messaging model is implemented on top of a connection-oriented client/server model. Does this defeat the purpose of messaging? No. Consider these advantages when compared to implementing the distributed system entirely via tightly coupled means:

  • The whole system has only one well known server address

  • Only one element of the system (the message server) has a crucial high availability requirement

  • The most critical part of system is a completely standard, off the shelf product

click to expand

Essentially, the use of a message server as the central hub of an otherwise very decentralized JMS-based system reduces the complexity of the communication infrastructure to that of a simple client/server system with a single server. We will see later that with some limitations of the functionality specified by JMS, multicast networking can be employed to eliminate the central server and bring the connectionless messaging paradigm right down to the network level.



Professional JMS
Professional JMS
ISBN: 1861004931
EAN: 2147483647
Year: 2000
Pages: 154

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net