8.2 Distributed Communication


Distributed communication allows software running on different processors to interact and exchange information either directly or indirectly via a communication mechanism. Key attributes of distributed-communication technologies include support for direct or indirect, connectionless or connection-oriented, and asynchronous or synchronous communications. Several commonly used distributed communication technologies are presented in Table 8-1.

In models that provide synchronous communication, such as RPC (Figure 8-1), the calling application is blocked until a response is received from the remote application. Synchronous forms of communication typically work well in a local area network (LAN) environment, in which connectivity, network speed, and bandwidth are readily available. Synchronous forms of communication should be used with caution over slower networks or the Internet. Problems may arise from unexpected blocking time because of slow network performance, connectivity, or bandwidth availability.

Figure 8-1. Remote procedure calls

graphics/08fig01.gif

In asynchronous communications, application processes are not blocked. Therefore, a message may be sent to a remote program, but the response from the remote application could be received at a later, possibly indeterminate time. This allows developers to build applications that interleave communications as well as perform additional processing.

As mentioned earlier, some communication technologies communicate directly with remote applications, whereas others communicate indirectly. Direct-communication technologies require a direct link to be established ”and possibly maintained ”between the two applications that participate in the information exchange. The receiving application must be available ”running and reachable via the network under normal conditions ”at the time of the request. Therefore, most direct-communication technologies are connection oriented. Once a connection is established between the two applications, the receiver binds to an instance of the requester, creating a connection context. In essence, the requester and the receiver share a state for the duration of the connection and can determine the exact context of both requests and responses.

Table 8-1. Distributed Communication Technologies

Distributed Communication Technologies

Key Attributes

Direct Communications

Indirect Communications

Connection-Oriented Communications

Connectionless Communications

Synchronous Communications

Asynchronous Communications

Remote procedure call (RPC) (point to point)

graphics/tick.gif   graphics/tick.gif   graphics/tick.gif  

Message passing (point to point)

graphics/tick.gif   graphics/tick.gif graphics/tick.gif graphics/tick.gif graphics/tick.gif

Message queuing

  graphics/tick.gif   graphics/tick.gif   graphics/tick.gif

Publish/subscribe (one to many)

  graphics/tick.gif   graphics/tick.gif   graphics/tick.gif

By contrast, indirect-communication technologies, such as the message-queueing technology shown in Figure 8-2, do not require the receiving application to be available at the time of the request. The communication provider will usually queue messages for an application until it becomes available. Therefore, most indirect-communication technologies are connectionless. However, if the model does not queue messages through the use of an independent queue manager, as shown in the message-passing model in Figure 8-3, messages sent while the remote application is unavailable will result in a delivery failure or will be lost. Although the message-passing model itself is connectionless and asynchronous from the application's point of view, the process of sending a message is often implemented in a synchronous and connection-oriented manner. This means that the sender is blocked until either the message is delivered to the remote application's receive queue or the MESSAGE SEND operation times out and then fails because of an unreachable application.

Figure 8-2. Message queues

graphics/08fig02.gif

Figure 8-3. Message passing

graphics/08fig03.gif

Messages to a remote application are one-way and inherently asynchronous and stateless. Because this form of communication is stateless, all state information must be passed inside the message for the requester to determine the context of a particular response or request.

The publish/subscribe communication technology shown in Figure 8-4 is similar to the message-queuing model but is a one-to-many model. In this model, applications publish information on a network and subscribe to receive information of interest. Both the publisher, or producer, and the subscriber, or consumer, applications do not need to know about the existence, location, or state of the information producers or consumers. Systems that use this model can be dynamically reconfigured with new publishers' or subscribers' programs without interruption.

Figure 8-4. Publish/subscribe communications technology

graphics/08fig04.gif

Many middleware products are available to help developers implement these communication technologies. These products often provide features beyond the simple communication, such as object orientation, security, quality of service, and data marshaling. Table 8-2 presents some distributed communication middleware products, along with the communication technologies they implement.

The choice of a communication technology depends on the requirements of an application. This choice will strongly influence the system architecture, or design, and the manner in which an application performs transaction processing. Again, RPC or message-passing communication technologies are best suited for situations in which the distributed applications are expected to be available and reachable under normal operating conditions and when an application requires a response from a remote application before continuing execution. Message queuing or publish/subscribe communication technologies are best suited to situations in which the remote application may not always be available and immediate responses are not required.

Table 8-2. Distributed Communication Middleware Products

Product Name

Vendor

Communication Technology

VisiBroker (CORBA)

Inprise

RPC (via IIOP)

BEA WebLogic (EJB Server)

BEA Systems

RPC (via RMI over IIOP)

MQSeries

IBM

Message queuing

Java Message Service (JMS)

Sun Microsystems

Message passing, message queuing, and publish/subscribe

MessageQ

BEA Systems

Message queuing

In general, distributed database applications typically use RPC or message queues for communication. The choice of a distributed communication technology has a large impact on transaction processing. Systems designed to use synchronous communication for distributed communications typically use a transaction-processing model called distributed transactions for database operations, whereas systems that use message queues for distributed communication use a model called queued transactions. In the sections that follow, we discuss the fundamentals of transactions and the differences between distributed transactions and queued transactions.



Modernizing Legacy Systems
Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices
ISBN: 0321118847
EAN: 2147483647
Year: 2003
Pages: 142

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