Java Reference
In-Depth Information
Communications
buffer
Communications
Buffer
First name
Middle initial
Last name
Street address 1
Street address 2
City
State
Zip
Credit card no.
Expiration date
Service
requester
Service
provider
Figure 7.6 When we use a fixed communication area to connect two systems, we tightly couple
the requester and provider. Changes to the interface—for example, an added country or a nine-
digit ZIP code—can render the interface obsolete.
For example, consider the communications buffer in figure 7.6. If we were to
switch from five-digit to nine-digit
ZIP
codes, then both the service requester
and the service provider would have to change their interfaces at the same
time. Added or deleted fields can also lead to problems. If changes occur with-
out the notification of one side or the other, we'll have a bug. Using a fixed
parameter set through communication-area mapping algorithms or some form
of
RPC
(including
CORBA
) can improve the situation somewhat. In this case,
the software can enforce our rigid interface. We'll catch some of the error con-
ditions, but we'll still have to deal with the difficulties of coordinating inter-
face changes.
When this changing interface is between two organizations or even compa-
nies, the consequences can be dramatic. The problems are compounded as
new clients are added to the interface. Here are some possible ways we can
deal with the change, all with significant disadvantages:
Synchronizing schedules
We can try to synchronize schedules. That means that the service provider
must wait until all the clients of the interface can change. This is one of the
many reasons that software development for large organizations is so tedious
and takes so long. Managing interfaces like this can occupy entire departments
for years.
