3.1 Architecture Fundamentals
To prepare for the upcoming discussion of
service-orientation and technology architecture, letÕs begin by establishing
some fundamental terminology. The next set of sections provide definitions that
borrow content from SOAGlossary.com to establish the following basic
architecture-related IT terms:
• Technology
Architecture
•
Technology Infrastructure
• Software
Program
We are by no means attempting to formally define these terms
for the IT industry. These definitions are simply part of the common vocabulary
used by the books in the Prentice Hall Service-Oriented Computing Series
from Thomas Erl to ensure consistency and clarity across all titles.
Figure 3.1 – An overview of how
the enterprise elements represented by these terms relate to each other.
An Analogy for Architecture and Infrastructure
ItÕs well known how the IT community borrowed the term
ÒarchitectureÓ from its traditional association with the design and
construction of buildings and structures. Its origin also helps us establish an
analogy that is useful for distinguishing a technology architecture from a
technology infrastructure.
A building has a physical design expressed in an
architecture blueprint or specification. However, the building exists within a
surrounding environment. This environment may or may not provide a lot of
support for the building to fulfill its purpose. For example, an office or
residential building located within a city is supported by the streets, power
plants, utility pole cables, sewer systems, and other resources provided by the
city environment. This supporting environment can be considered infrastructure.
In order for a building to take advantage of these
infrastructure extensions, its physical design needs to integrate them as part
of its official architecture. Therefore, an architecture specification for a
building will encompass the parts of its surrounding infrastructure that are
relevant to the building. As a result, there is no firm boundary between what constitutes
the building architecture and the environmental infrastructure. This same overlap
exists in the IT world, as explained in the following definitions.
Technology Architecture
A technology architecture expresses fundamental and
foundational aspects of physical design for some piece of technology. Whereas
computer hardware products will have their own individual technology
architectures, within a typical IT enterprise, we are most concerned with the
architecture of software programs.
For a program we purchase we may want to understand its
internal design to ensure that it is compatible with the environment already
established within our enterprise. For programs we build, it becomes our
responsibility to define the physical design ourselves.
When designing a new software program, we need to take into
consideration the environment in which it will need to be deployed and in which
it will need to carry out its purpose. In most established enterprises,
implementation environments already exist in the form of servers, operating
systems, and runtime and middleware platforms. As explained in the next
section, all of these parts are considered technology infrastructure. And, as
with buildings and cities, the software programÕs architecture is comprised of
new parts interwoven with the relevant parts of the infrastructure that already exist as extensions of the
surrounding implementation environment.
The scope of technology architecture can vary depending on
what it is we are designing. Some well-known types include:
• Component
Architecture – In a distributed computing environment this
represents the physical structure of an individual software program that exists
as a component.
• Application
Architecture – A technology architecture with a physical boundary
limited to the deployment environment of a particular application or system. In
a distributed computing environment, an application architecture can encompass
multiple component architectures.
• Integration
Architecture – The technology architecture of two or more connected
applications or systems including whatever technologies, resources, or extensions
were added to enable their integration. Many integration architectures include
middleware platforms and associated adapter or bridging extensions.
• Enterprise
Architecture – Unlike component, application, and integration
architectures which are often documented in design specifications prior
to the creation of programs, enterprise architectures frequently result as a
documentation of what already exists within an enterprise environment. An
enterprise architecture specification can encompass (or may just reference) all
previously listed forms of architecture and may also act as a formal
documentation of the enterprise infrastructure as well.
Figure 3.2 – Common
traditional levels of documented technology architecture.
In a service-oriented environment the scope of technology
architecture can also vary and distinct forms of service-oriented architectures
exist that roughly correspond to the previously listed traditional types. These
are explained separately in the upcoming Types of Service-Oriented
Technology Architecture section.
Note: As just mentioned, you can define an
architecture for a piece of hardware or a software program, which is why you
will sometimes see the term ÒarchitectureÓ further qualified as hardware architecture
or software architecture. Since our focus in SOA projects is primarily on
software design, why then do we continue using the broader Òtechnology
architectureÓ term? As we will explore throughout this chapter and the design
patterns in this book, architecture in the world of service-oriented computing
relies on a combination of software and hardware resources, both of which find
their way into typical architecture specifications.
Technology Infrastructure
Within a typical IT enterprise, technology infrastructure
represents the environment in which software programs are deployed. As with the
term Òarchitecture,Ó infrastructure can be qualified with ÒsoftwareÓ or
ÒhardwareÓ to identify certain parts of this environment.
Common forms of hardware infrastructure include:
• servers
and workstations
• routers,
firewalls, and networking equipment
• back-up
power supplies, cables, and other computer equipment
Types of software that can be considered part of an
enterpriseÕs technology infrastructure include:
• operating
systems and system APIs
• runtime
environments and system agents
• transaction
management programs and message queues
• middleware
and adapters
• user
account management and security technologies
What generally distinguishes a technology that is part of
infrastructure from one that is exclusive to a particular component or
application architecture is that it is made available to multiple applications
or systems and therefore exists as a resource of the enterprise (and is
therefore also separately owned and governed). An example of a common software
program that can be classified as part of infrastructure or specific to an
application architecture is a database.
Figure 3.3 – A
software program implemented within an enterprise finds itself dependent on
various resources in the surrounding infrastructure.
As previously mentioned, relevant pieces of technology
infrastructure find their way into almost all forms of architecture
documentation because they become part of the architecture itself. An
enterprise architecture specification often documents some or all of an
enterpriseÕs infrastructure in a reference format that is made available to
authors of other architecture design documents.
The infrastructure of an enterprise will frequently
determine the processing potential of technology architectures that reside
within it and are built upon it. This potential threshold is then further
leveraged or constrained by the design of the architecture itself.
Consequently, a software program is required to exist and execute within the
boundaries and thresholds established by both its underlying infrastructure and
architecture.
Figure 3.4 – Technology infrastructures and
architectures collectively establish boundaries that determine the processing
thresholds of software programs. In this example, the maximum instances of a
program that can be concurrently invoked is less than what the infrastructure
can support because of limitations introduced by the architecture and the
software programÕs own design.
Software Program
A software program is simply an existing system,
application, or solution. It may represent a purchased product or a
custom-designed program. In relation to technology architecture, a software
program can be considered an implementation of the design documented in an
architecture specification, as well as the logic that resides and executes
within the supporting environment also specified by the technology
architecture.
Part of a software programÕs design can be documented within
an application architecture specification. Usually this part is back-end
centric with an emphasis on the programÕs overall structure (including
components it may be comprised of), technologies, and resource requirements. A
typical application architecture specification is therefore frequently
supplemented with additional types of design documents, such as functional
specifications that illustrate the flow and style of the program user
interfaces and detailed design documents that establish programming routines
and algorithms.
Depending on the conventions, methodologies, or preferences
of the IT department, this additional design information may or may not be
considered part of the programÕs official technology architecture.
Figure 3.5 – The physical design of a software program
is partially defined by its application architecture along with relevant parts
of the surrounding infrastructure. Other documents, such as a functional
specification, establish additional design characteristics, such as the
programÕs user-interfaces.
Relationship to Design Framework
Chapter 3 of SOA: Principles of Service Design establishes a design framework that includes the following terms:
• Design Characteristic
• Design Principle
• Design Pattern
• Design Standard
If you havenÕt already, it is recommended that you read up
on these terms in preparation for subsequent chapters in this book. Their
individual definitions are also published at SOAGlossary.com.
Figure 3.6 illustrates how closely this design framework can
tie into the architecture-related vocabulary we just covered. In the end,
principles, patterns, and architecture all revolve around and influence design.
Figure 3.6 – How the elements of a design framework
can relate to architecture-related elements.
