Application Integration
Application integration involves several
considerations. Adopting an integration path based on such considerations
usually lead to constraints on subsequent integration considerations. The final
result, particularly for complex systems, contains usually a set of compromises
taken at each step of the design and its revision and refinement.
The means of achieving integration is an important
decision is taken in the initial stages of design. It could be based on one or
more of the following technologies:
·
File
Transfer (see File transfer)
·
Sharing
access to databases
·
Remote
Procedure Calls, RPC (see RPC)
·
Messaging
(see Messaging).
When dealing with legacy applications, a combination
of two or more of these technologies is not rare due to different capabilities
of the components of the integration problem.
Loose Coupling
It is desired that components be independent of each
other to enable the maintenance and update of each without affecting other
components reliant on its output, or are targets of its input.
Data Types and Format
The exchange of data between the different components
is best served by the evolution of a common data format. This is not
practically possible in all cases, and a mixture is usually found particularly
when different integration technologies are used.
Data Formats do change mostly due to upgrades in the
components which probably enables a more efficient data exchange with other
components. More frequently, the exchanged data types are augmented by new
types as business requirements change.
Performance
Components are usually immutable. Changes in them are
not a usual part of the integration effort. Integration, however, would depend
on the speed with which data is provided to consuming components. When this is
not available, it may be necessary to establish events which triggers the
consuming component of the availability of data. This is easier applied to
shared databases. Blocking (see Blocking) RPC may be a necessity, but the
penalty is well understood. Messaging facilitates the issue of event notices dispatched
to a waiting component.
Data or Functionality
Integrated applications may not want to simply share
data, they may wish to share functionality such that each application can
invoke the functionality in the others. Invoking functionality remotely can be
difficult to achieve, and even though it may seem the same as invoking local
functionality, it works quite differently, with significant consequences for
how well the integration works.
Asynchronicity
Computer processing is typically synchronous, such
that a procedure waits while its subprocedure executes. It’s a given that the
subprocedure is available when the procedure wants to invoke it. However, a
procedure may not want to wait for the subprocedure to execute; it may want to
invoke the subprocedure asynchronously, starting the subprocedure but then
letting it execute in the background. This is especially true of integrated
applications, where the remote application may not be running or the network
may be unavailable—the source application may wish to simply make shared data
available or log a request for a subprocedure call, but then go on to other
work confident that the remote application will act sometime later.
