Database Reference
In-Depth Information
10.1.2.1 N-Tier Architecture Advantage
The N-tier architecture has many advantages over the more traditional client/server architecture:
1.
Agile software
: The N-tier architecture is useful in creating more flexible and easily modifi-
able software; by treating software components as stand-alone data providers, middleware
service providers, business service providers, and service consumers, the N-tier architecture
creates software infrastructure of reusable parts.
2.
Maintainable software
: The N-tier architecture is useful in creating more maintainable and
easily upgradable software; because software components are stand-alone reusable parts of
business logic, they are used from the same place without need for multiplication or replica-
tion and are, therefore, easier to change and upgrade rendering the application as a whole
more easily maintainable.
3.
Reliable software
: The N-tier architecture is useful in creating more testable, more easily
debuggable, and thus more reliable software; flexible and maintainable software does not
automatically imply reliable software, but because software components are stand-alone
packets of business logic, bugs can be localized more easily and their functionality can be
calibrated more accurately rendering the application as a whole more reliable.
4.
Reduced complexity
: The N-tier architecture is useful in creating more streamlined, simpli-
fied, and standardized software, because the software component's paradigm eliminates the
need for custom interconnections between disparate constituents of a composite application
(which includes existing and legacy systems) that increases in complexity rapidly with the
increase in the number of disparate constituents. For instance, for a composite application
constituted of
n
applications and
m
data sources, the problem of corresponding
n
×
m
inter-
connections is barely manageable even for small values of
n
and
m
. However, in the N-tier
architecture, this problem is resolved to a great extent by interfacing all components to (say)
a single standardized data bus: this reduces the problem of
m
×
n
interconnections to that of
only
n
+
m
interconnections! All components can connect with each other via connections
to this singular data bus without the need for multiple customized single-purpose intercon-
nects between each pair of components.
The interfacing approach of point-to-point interfaces between two applications
would be prohibitively expensive for EAIs that may involve tens and hundreds of
such interfaces. EAIs also adopt the alternate approach of instituting an information
broker whereby all systems communicate with the information broker by uploading
data into the same while simultaneously translating it into a single format and protocols
native to this central broker. Because information is routed through the information broker,
rather than going directly among different systems, this simplifies the problem considerably
and it becomes easy to connect disparate systems via their respective adapters for this broker
that use the singular format and protocols of this central broker. Any future systems have
only to devise one
adapter
to integrate with the central broker to start communicating trans-
parently with all other systems. The exchange of data between the various systems intercon-
nected by EAI is governed by the business rules determined by the user; and the message
broker routes the messages according to these rules. However, the data in the messages is
translated en route into whatever format is required by the concerned application.
