Professional Documents
Culture Documents
..
..
..
..
SUN MICROSYSTEMS ..
.. W H I T E PA P E R
..
..
.
Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
The Sun Approach for Dot-Comming . . . . . . . . . . . . . . . . . . . . . . . . .4
The Need for a Better Architectural Model . . . . . . . . . . . . . . . . . . . .4
The Limitations of Traditional Architecture . . . . . . . . . . . . . . . . . . .5
Services-Driven Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
The New Focus on “Network Services” . . . . . . . . . . . . . . . . . . . . . .6
Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
The Services-Driven Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
The 3–Dimensional Architectural Framework . . . . . . . . . . . . . . . . . .10
Systemic Qualities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
Tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
Logical Application Tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
Physical Deployment Tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Platform Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
3-Dimensional Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
The SunTone Architecture Methodology . . . . . . . . . . . . . . . . . . . .21
SM
The explosion of the web has fundamentally changed the mission and critical suc-
cess factors facing most corporate IT shops. The “users” are now real, live customers,
and there are tens of thousands or even millions of them. More than ever before, sys-
tem problems can result directly in lost revenue and lost customers. When a system
crashes and the phone rings, it’s not an angry branch manager on the phone—it’s CNN.
Corporate IT organizations are being faced with developing applications that are
more scalable, reliable, and secure than ever before, more quickly than ever before, and
with far greater Quality of Service (QoS) than ever before. IT organizations are
confronting huge challenges in retraining staff in Web-based technologies and
implementing the process changes necessary for rapid, successive, bug-free releases to
the web. Perhaps more than any other single factor, application architecture can make
or break a dot-com system. Get the architecture wrong, and a system can ultimately
prove impossible to scale, secure, or rapidly change.
Most of the biggest names on the Internet run on Sun, and many of their systems
have been built with the help of Sun Professional Services. Over the past several years,
Sun Professional Services has amassed a tremendous amount of expertise in building
dot-com applications. We have recently synthesized this learning into a standard process,
SM
the SunTone Architecture Methodology (SunTone AM).
This paper details the key concepts in a 3-dimensional approach to creating dot-com
system architecture. It gives an overview of:
• How QoS requirements should be used to drive the architecture definition process.
• How these principles are synthesized into the SunTone Architecture Methodology,
which is iterative and incremental, architecture-centric, use-case-focused, systemic-
qualities-driven, and pattern-based.
architectures.
• ISV Partners—ISV products used to implement a solution set which are built with
Java™2 Platform, Enterprise Edition (J2EE-technology) compliant products, or prod-
ucts with a well-defined roadmap for migrating to J2EE.
This paper discusses the 3-Dimensional Architectural Model that is at the core of the
SunTone Architecture Methodology, and gives an overview of the methodology.
Today’s Web users need access to multiple enterprise services at any time, from
anywhere, using anything—from laptops to PDAs to cell phones and pagers. The sheer
number of clients, the diversity and heterogeneity of these clients, and the service
level expectation of these clients are all expanding exponentially, quickly making the
enterprise fortress model obsolete.
Customer
Order Entry Billing Service Shipping
(Mainframe) (HP server) Inventory (Sun server)
(Sun server) Management
(Oracle)
Mergers and acquisitions compound the problem, because even enterprise-wide tech-
nology strategies become silos within the combined organization, creating “silos of silos.”
Internet
Intranet
For example, a company might separately Web-enable its order entry system and its
inventory system. Although this allows customers to check on product availability and
order products, it does not enable customers to check availability as part of the order
entry process, let alone suggest alternative products as substitutes for those that are
currently out of stock.
The systems architecture needs to support what might best be described as an enter-
prise utility model. Like electricity through a power outlet or water through a faucet,
services need to be provided around the clock from standard access points to any
network device. These services need to bridge the silos to allow for an integrated,
customer-centric presentation of your business.
SERVICES-DRIVEN ARCHITECTURE
THE NEW FOCUS ON “NETWORK SERVICES”
The dot-com age is all about service delivery—anytime/anywhere access to any
needed service with predictable availability, reliability, performance, and security. The
SunTone Architecture Methodology focuses on how to identify, design, and deploy
network services to deliver this quality of service, within the severe time constraints
imposed by the dot-com space.
The goal of the SunTone AM is to define and deliver network services that provide
the desired functionality with a high level of predictability, so that these services can
be counted on by end users or by other network services.
• They are based on well-defined, public interfaces. This enables them to use and be
used by other services and to deliver their functionality across multiple types of
networks and client devices.
• They can be shared and re-used by multiple network services, end users, and net-
work service developers.
• They are coarse-grained, and relatively few in number, providing a coherent and
complete range of functionality through a minimum, manageable set of APIs.
• They provide predictable QoS. These services are built on flexible and scalable
infrastructures which offer specific strategies for QoS enabling the service to
support diverse requestors.
• They can be combined and re-combined to create new services. For example, in an
online book purchase, the merchant may combine a payment authorization service,
a credit card fraud screen service, a delivery address verification service, a directory
service, and an order-entry service. To the end user, it appears as a single network
service--a sales transaction.
• They are easily controllable and manageable across the network, enabling them to
be used in the routine course of business: they can be brokered, billed, administered,
monitored, advertised, or syndicated.
Service Characteristics
• Coarse Grained
• Few in Number
Service • Location Independent
Interface • Predictable QoS
• Can be combined, brokered,
metered, outsourced
DESIGN PRINCIPLES
Although as noted earlier, legacy system architectures are fundamentally unsuited
to the supporting web-based applications, no company has the time or luxury to
re-architect beginning with a clean slate. In practice, an architecture must address the
requirements of integrating existing systems, bridging the legacy environment and all
of its heterogeneous resources to a more flexible dot-com-ready infrastructure.
To meet these challenges, the architecture will need to adhere to several overarching
principles. The dot-com architecture must be:
• Services-based, not just code-based: The unit of re-use should emphasize reusable
generic service functionality, be readily available, deployed as components across the
enterprise and capable of being managed and controlled to achieve the needed
quality-of-service (QoS) levels.
• Assembled, not built: Using services as building blocks, systems should be formed
by assembling existing services, not by starting from scratch. Some of the parts may
even be provided by resources from outside of the corporate boundaries. Assembly
should be rapid and efficient, not a costly process of custom integration.
Intranet
The services-driven approach establishes a standard across the enterprise that allows
for easy discovery and integration of business services. Creating this architecture
involves standardizing interface technology so that once deployed, services are
available for use by other services without complex message reformatting or protocol
conversions. This standardization allows legacy silos to be easily accessed, integrated
and aggregated, resulting in an enterprise-wide services tier.
• Layers: The hardware and software stack that hosts services within a given tier;
physical, network, and software platforms and standard API sets that support the
components which provide a service. Layers, like tiers, represent a well-ordered
relationship across interface-mediated boundaries. While tiers represent processing
chains across components, layers represent container/component relationships in
implementation and deployment of services.
This Architectural Framework can be graphically depicted as a cube such as the one
shown in Figure 5.
Tiers—Application Partitioning
c e s t i o n ss ation t
e s our tegra usine esent Clien
R In B Pr
System Level
Strategic Level
Application
Service Level
User Level
Virtual Platform
Upper Platform es
i
Lower Platform au lit
icQ
tem
Hardware Platform Sys
Layers—Hardware/Software Stack
Figure 5—The Sun 3-D Architectural Framework
The key principle embodied in the cube is the recognition of the orthogonal
relationship that exists among tiers, layers, and systemic qualities. Each tier of
application functionality is hosted by a layered hardware/software stack. Systemic
qualities must be pervasive throughout the architecture; each must be addressed for
every layer, and for every tier.
In many cases, such as availability, the phrase Quality of Service is synonymous with
the term “systemic qualities”, or what we might endearingly call the “ilities” (reliability,
availability, securability, reliability, etc.). However, some of the capabilities referred to,
such as flexibility, have not traditionally been included in discussions of QoS. We use
the term “systemic qualities” to apply to all of these system characteristics.
For the Internet, the focus of Quality of Service is different than the host-based and
client-server models of the past. For these new e-commerce systems the focus is on
real-time continuous processing for mission critical applications, not on a mainframe
model with programmed downtime and a batch-processing model. These new systems
are distributed heterogeneous environments that require a different perspective on
QoS. In some ways the challenge is more complex, on the other hand, if these archi-
tectures are properly designed from the beginning, this can contribute to, and not
challenge, QoS achievement.
• Availability—essentially the percentage of time that the system is available for use.
Total availability is also impacted by factors beyond the architecture such as latency
within a user’s ISP or the general Internet.
These Systemic Qualities are required at each tier of a dot-com architecture and are
not the responsibility of any given layer—instead the layers must complement and
cooperate in providing each quality within a given tier. Some qualities, such as secu-
rity or manageability, need to be pervasive—present at all layers in all tiers.
For this reason, the Sun 3-D Architectural Model represents these Systemic Qualities
as a separate dimension, orthogonal to the tiers and layers which represent the logi-
cal/distributed partitioning and the platform layering. Viewing Systemic Qualities
(and the related QoS levels which need to be supported) in this way is one of the key
insights of the SunTone Architecture Methodology, and allows architectural
alternatives to be quantitatively and qualitatively evaluated for their ability to provide
these capabilities.
User-level qualities are those, such as usability and accessibility, that directly affect
the user interface and end-user functionality, are felt at run-time, and are controlled
in the design phase.
Service-level qualities are those, such as performance and availability, that directly
affect business functions of end-users, are felt at run time, and are controlled by
system management.
Strategic-level qualities are those, such as scalability and flexibility, that affect
the enterprise itself, are manifest over time, and are controlled primarily through
architecture. Of course, failures in scalability will result in failures in performance and
availability, which will be felt directly by the end user.
Naturally, which category a particular quality falls in is relative to the business goals
and design of the systems. While security might be a system-level quality for most
applications, it may be a service-level quality for a company that is selling security
oriented services. The key to the use of these categories is not what category the
quality is in generally, but how each quality is experienced by what constituency and
how it is designed or controlled.
The Internet provides the infrastructure necessary for any number of vastly different
access devices to gain access to enterprise resources. The implementation of resources
does not remain static but changes in response to advances in technology as well as
partnering and outsourcing relationships. By separating processing into discreet
presentation, business, and integration tiers, an enterprise can take advantage of new
delivery channels regardless of the associated access technology, and can remain
independent of back-end resource implementations. This approach allows user inter-
faces, business processing and rules, and back-end resource implementations to evolve
separately as business requirements and technologies change.
Partitioning the services layer into separate tiers allows business logic to remain
independent of access channels and resource implementations, thereby allowing the
enterprise to couple business service processing with any number of different access
methods and back-end resource technologies.
For these reasons, Sun recommends a five-tier model that includes the following tiers:
• Clients: Any client device or system that manages display and local interaction
processing. Enterprises may not have control over the technologies available on the
client platform, an important consideration in tier structuring. For this reason state
at the client tier should be transient and disposable.
• Business services: These services execute business logic and manage transactions.
Examples range from low-level services such as authentication and mail transport
to true line-of-business services such as order entry, customer profile, payment, and
inventory management.
In order to achieve certain system qualities, typically expressed as QoS levels, pro-
cessing in complex systems is commonly partitioned across network segments, CPU
clusters, and storage complexes. This partitioning segregates the system’s deployment
architecture into tiers within which common strategies are implemented for QoS
qualities such as security, scalability, load distribution, high availability, etc.
Since QoS levels are typically qualities associated with services, there is often, but
not always, a correspondence between logical tiers and physical tiers. Thus it is
common to see physical tiering associated with the logical Presentation, Business, and
Integration tiers.
PLATFORM LAYERING
Implementing the various tiers of an application requires a combination of traditional
and specialized hardware, software, and networking technologies. Rapid development
and enhancement of a service-driven network requires creating a flexible underlying
platform environment that can be readily adapted to changing business conditions and
evolving technologies. Today the application itself is built upon an underlying platform
that can be divided into three primary layers:
• The upper platform layer consists of products such as Web servers, application
servers, and various types of middleware.
• The lower platform layer is comprised of the operating system environment and
associated low-level systems services.
• The hardware platform layer includes computing hardware such as servers, storage
hardware such as storage arrays, and networking hardware such as switches and
routers, and associated peripherals.
New classes of systems software have rapidly evolved over the last several years to
support these complex requirements. Web servers, application servers, and message-
oriented middleware products provide most of these processing requirements, allowing
developers to focus more on the business aspects of Web-based application development.
Many of these products can combine to provide a complete service-hosting environment
that is completely independent of the underlying hardware and operating system
environment. Today it is these products, not the underlying hardware and OS, that pre-
sent the “platform” visible to and needed for application development and deployment.
Many upper platform products are available today on a wide variety of lower plat-
form products. Applications written to run on these products can be deployed on a
hardware platform and remain isolated from future hardware or operating system
changes. Although an application might maintain independence from the underlying
lower platform, it can often become dependent instead on the upper platform soft-
ware. Since the upper platform software product space today is changing rapidly, appli-
cations need to maintain upper platform independence.
This requirement gives rise to the notion of a “virtual platform layer,” which provides
an application with standard APIs and specifications for the upper platform. By writing
applications so that they depend only on the virtual platform APIs, developers can
make applications portable across upper platform products.
To put it simply, if you choose your APIs wisely at the virtual platform layer, the
payoff is platform independence across the lower layers.
The promise and delivery of such virtual platforms is an old story: it is the story of
standards-based computing. FORTRAN, the C library, the X Windows System, and POSIX
are all examples of successful virtual platform APIs. Historically, these virtual
3-DIMENSIONAL EXAMPLE
Consider an extremely simplistic example in which a retail catalog firm wants to be
able to take orders over the Internet, initially via HTML forms from desktop browsers,
and from other device types in the future. A legacy order entry system is currently
used by their call center operators to enter customer orders received over the tele-
phone, and this system will be used as the back-end for a new web-based, customer
self-service system. A packaged solution is being considered as a replacement for the
legacy system. It has been determined that the best way to communicate with the
legacy system is via message queues.
Order Legacy
Order Form Order System Order
Form Handler Service Interface System
N
N
IO
E
IO
S
C
S
T
T
R
T
TA
E
N
U
IN
E
R
N
O
LI
G
E
S
U
C
E
S
E
T
n
B
E
R
IN
R
io
P
at
liz
l le
ra
Pa
Virtual HTML JSP EJB JMS APPO
g
in
ue
Q
g
rin
Upper Any Browser iES iAS MQ Series CICS te
us
Cl
b in
Ro
u nd g
Ro a lin
Lower Any OS Solaris Solaris Solaris MVS l Sc
ta
on
o riz
H gy
te
ra
St
Hardware Any HW E450 E5500 E250 ES9000 g
a lin
Sc
Client Tier—An order entry form that accepts order information from a customer
and returns whether or not the order is accepted. This is “served” from the presentation
tier as HTML—there is no persistent code deployed to the client device.
resentation Tier—An order form handler that forwards to an order processing ser-
vice the order entry data received from the form. Device-specific order form handlers
will be developed to deal with formatting and dialog interaction differences among
various access devices.
Business Tier—An order service that provides such processing as calculating the
tax and shipping costs associated with the order, and forwards the resulting informa-
tion on to the legacy order processing system.
Lower latform—It is decided that iES, iAS, and MQSeries will be run on the Solaris™
Operating Environment. The Legacy Order Processing system runs on MVS. The client-
side of the application is independent of operating system.
The SunTone AM builds on the ideas comprising the Unified Process. Like the Unified
Process, the SunTone AM is use-case-focused, architecture-centric, as well as iterative
and incremental. The SunTone AM significantly extends the Unified Process through
the incorporation of two additional fundamental concepts: it is systemic-qualities-driven,
and patterns-based. The SunTone AM refines the Unified Process notion of architectural
views to better reflect the extremely complex platform environments required for
dot-com applications.
USE CASE-FOCUSED
Use cases are functional scenarios that describe the complete flow of an operation
from the perspective of an actor. Actors are entities that are external to the system,
typically users or other systems. Examples of use cases are scenarios such as
“Customer browses on-line catalog”, or “Sales Representative enters order”.
ARCHITECTURE-CENTRIC
In an architecture-centric approach, architecture is defined and validated before the
development teams begin the bulk of implementing the system design. This is
generally accomplished by building a prototype that exercises all of the unproven,
architecturally significant aspects of a system prior to the start of detailed design and
large-scale development. The architectural prototype focuses on such things as bench-
marking the performance of a volume of representative transactions, testing the
compatibility of various technologies, or certifying the smooth operation of a failure
recovery mechanism.
Application
Integration
The SunTone AM considers systemic qualities like those discussed above (e.g. security,
manageability, scalability, availability) to be architectural considerations on a par with,
and orthogonal to, the application-level partitioning and platform layering which are
traditional concerns. In fact, these considerations are the primary focus of the architec-
tural process. This focus distinguishes architecture from design, which is concerned
primarily with the specific functionality to be provided by individual components.
For this reason, the SunTone AM also places a critical emphasis on identifying, ranking,
and quantifying these systemic qualities as requirements. Not all systems need all these
qualities, and some systems need more of one than another does. An advertising-sup-
ported portal may have low need for authentication-based security, but high need for
scalability; a high-net-worth private financial services system may have the reverse.
Different architectural choices will be appropriate for each context, and thus each
needs to be architected with an understanding of the business value of the specific
qualities.
PATTERNS-BASED
“ atterns” as used in the SunTone AM means “a solution to a problem in a
context”—patterns are a distillation of experience in solving problems. It is a rare
context and problem that has not been observed and addressed at some level in the
past. Patterns are a formalized way of generalizing and documenting these solutions
to recurring problems.
What is architecture?
The terms “system architecture” and “system design” are often used interchangeably,
but in fact deal with two very different system engineering processes. System archi-
tecture focuses primarily on the overall structure of a system, identifying major com-
ponents and their relationships. The systems architect seeks to define:
• how the major components should be organized with respect to one another
Thus, the architect focuses on issues such as which components belong together or
apart; which ones should be visible to one another; which should be replicated; how
they should be distributed; how they should talk to one another; where they should be
stored; and so on.
The vast majority of what drives decisions with respect to overall system organization,
decomposition, and mechanization are the system’s target service level requirements.
Considerations such as how fast the system must be, or how frequently a component
will change are the primary factors in making decisions about architecture. The detailed
functional requirements only play a minor role in the architecture analysis process. (See
table next page).
What happens when a button is pushed? How often the button is pushed, how many
users are simultaneously pushing the button,
where the users physically are (e.g. inside the
intranet, out on the Internet, etc.) when they
push the button.
How the system should respond to an event. The timing constraints, if any, between events.
Which bits of information should be supplied What kinds of constraints should be placed
in response to an event. on which kind of data, based on which user
characteristics.
What are the business rules? How complex are the rules? How often are
they changed? Can they be changed by
programmers or by users themselves? Will
they be implemented by a single individual,
or by separate teams? Do they change
together or independently?
What is the database schema? How complex is the schema, are there any
pre-existing constraints around it? (E.g. pre-
defined DB.)
What are the fields of the messages? What are the external systems that could be
or must be interacted with, and what are
their characteristics?
Layers
Unconstrained Tiered Tiered and Layered
Architectural Patterns
REQUEST
DISPATCHER TRANSACTION
REQUEST MIRRORED
HANDLERS RESOURCES
Many design patterns are applicable within each of several layers of the implementation
stack. Replication, for example, can be applied at the application layer, via 2-phase
commit logic, in the upper platform, via native database replication, or at the hardware
layer, via RAID.
Similarly, many design patterns are applicable within or across multiple tiers. Load
distribution, for example, can be applied in the Presentation Tier, via dispatching
requests to one of several web servers, in the Business Tier, by dispatching a request to
one of several application servers, and in the resources Tier, by dispatching to one of
several database segments.
• Internet Cloud
— Cisco Global Director
• Switching Fabric
— Alteon
• Application Server
— iPlanet server
• Messaging
— Tuxedo Messaging
• Database Resiliency
— Oracle SQLNet redirection
• Server Infrastructure
— SunCluster
Once an architectural style has been selected, it is useful to make initial assump-
tions about how the layers and tiers should be provisioned with system components
and services. These assumptions are typically based on experience-based implementa-
tion preferences for things like technologies and programming models, and a high-
level consideration of the Systemic Quality requirements. For example, an
organization that has standardized on the J2EE technology platform model would
likely make an initial assumption that J2EE would be included within the Virtual
Platform. Similarly, if the project developers have experience with a specific EJB tech-
nology-based server implementation, it would make sense to initially assume the pres-
ence of that EJB Server in the Upper Platform.
R
E INCEPTION ELABORATION
Q
U OUTLINE ESABLISH REFINE BASE
I CONTEXT PLATFORM ARCHITECTURE PLAN
R
COMPLEXITY ANALYSIS
E CONTEXT PROBLEM CAPABILITY
M ANALYSIS ANALYSIS ANALYSIS
ANALYZE
N
T
S
ARCHITECTURAL TARGET STRATEGY GRANULARITY
APPLY
STYLE PLATFORM SELECTION SELECTION
no yes RESTRUCTURE
Architectural Views
Thus, a high-level architecture statement provides the big-picture view of the key
objectives and components of the architecture. It includes a functional decomposition
of the primary business entities as well as the supporting mechanisms required to
provide the specified functionality while achieving the desired system qualities.
For this reason, the layers frequently provide a useful framework for views that
address the needs of different groups of stakeholders among those responsible for
creating, deploying, managing, and evolving the system. The SunTone AM categorizes
its views by layers. Layers reflect the primary distinguishing factor among skill sets
within and across the development team. Additionally, layers reflect different oppor-
tunities to incorporate components and COTS from multiple sources. Within each
layer, views can describe different aspects of the architecture such as:
• Evolutionary considerations
Within views, various types of models are used to effectively communicate structure
and purpose. This includes the use of the Unified Modeling Language (UML) and
extensions, as well as summarizations that help to ensure that systemic qualities are
being focused on at all levels. For example, a matrix format can highlight the approach
to systemic qualities across different layers. In this format, the rows represent the sys-
tem layers, and the columns represent the systemic qualities relevant to this system.
Each cell describes a feature, strategy, product, practice, or some combination thereof
employed at that layer to support the specified systemic quality:
Redundant
system SNMP on H/W tuned CPU/ Any
Server components components memory/IO Enterprise
Hardware Sun E5500 lockdown Add Servers N+1 Servers Remote Admin configuration Server
SNMP,
Remote
Solaris, Redundant Admin Solaris
iPDS, Firewalls Network Resource Any Solaris
Lower Platform Firewall SSL Connections Manager Instance Tuning Platform
Multiple
LDAP iPAS soft- instances, N+1
based cluster thread/ instances iPAS mgnt. session affinity
Upper Platform iPAS 60 uid/pw failover sessions pools console load balancing Solaris, NT
J2EE
EJBs and Security Solaris Any J2EE
Vitrual Platform CMP Model JDMK Production JVM platform
identified
failover
Application Order Service uid/pw state JDMK good code
The system is also driven from a Domain Object Model (DOM), which is not a view
per se, but a starting point for system development. The domain object model is a log-
ical object model of the problem domain, identifying the business entities and their
relationships. Along with general business rules, it captures constraints and invariants
of the underlying problem domain. The model should refer only to the business enti-
ties and activities, not to solution-domain mechanisms. Somewhat of an art, an effec-
tive domain model can significantly and favorably impact schedules and design
decisions by minimizing design efforts going down the wrong paths.
Defining this model may begin early in inception by defining essential entities.
Further definition will continue through elaboration. A well-specified domain object
model enhances the functional specification, and provides an ongoing source of docu-
mentation for later project participants.
The architectural core of the SunTone AM consists of iteratively defining each of the
various architectural views. The process begins with identifying the various tiers that
will make up the application, and then defining each view by considering the required
System Qualities, and applying component patterns accordingly. At each step in the
process, the architect determines whether an as yet un-addressed System Quality will
be addressed directly within the current view, or whether to defer the implementation
of that quality to a lower layer in the stack.
SEGMENT PRODUCT
N
IO
E
IO
S
C
S
T
T
R
T
TA
E
N
U
IN
E
R
N
O
LI
G
E
S
U
C
E
S
E
T
B
E
R
IN
R
P
S
N
TER
T G
PA N
IN
HTML
HTML JSP EJB JMS APPC I O
IT
RT
PA O
N
• TI
I BU
R L
ST O
An
Any
AP CHE
APACHE IAS MQ SERIES CICS
CIC DI TR
Br wser
Browser • N
CO
ESS G
C N
AC CI
• N
LA
Any OS
Any SOLARIS SOLARIS SOLARIS MVS
MV BA
A D
LO
•
R
VE
I LO
FA
Anyy HW
An E450 E5500 E250 ES9000 •
As illustrated in Figure 13, the patterns are applied across tiers and layers, and their
selections are driven by the Systemic Qualities.
This approach unites the Sun 3-D Framework as an architectural style; an iterative,
pattern-driven architectural process; and view-based architectural expression into a
single whole. By bringing together Sun’s long experience in dot-com architecture, the
proven and respected Unified Process, and the best current practices in pattern-based
systems, the SunTone AM provides an invaluable guide for the working system
architect in the dot-com age.
These factors combine to demand a new architectural approach, which identifies the
qualities a system or infrastructure needs to deliver value to the business which is
building it, and uses these qualities as its driving principles. When done properly, the
result is an architecture that delivers value beyond its simple functions, now and into
the future.
The 3-Dimensional Framework, SunTone AM, and Patterns provide a clear, compelling
approach that fills this need. It does not make dot-com architecture into a simple cook-
book, but it does provide a frame of reference in which a talented, experienced architect
can make the right decisions quickly and with confidence. The result:
• Systems with the scalability, reliability, and security demanded in the dot-com age:
Whether it’s “Anyone, Anywhere, Anytime, on Anything” or “Everyone, Everywhere, All
the time, on Everything”, dot-com architectures need to drive from the qualities they
will have to deliver. By framing the systemic qualities of the system as strategic
requirements and relating them properly to the logical and implementation
dimensions, the 3-Dimensional Framework allows an architecture to be described
and analyzed at design time for its delivery of these capabilities.
• Flexible systems and real reuse: A system delivered in a browser today may need to be
delivered to a hand-held device, an automobile, or a programmatic agent in the near
future. By enforcing the separation of concerns implicit in the tiered approach, and by
analyzing the functionality in terms of business services, the 3-Dimensional
Framework allows presentation, business, and resource implementations to evolve
independently. By designing and deploying functionality as network-available services
with extremely high QoS, the framework encourages real reuse of these services with-
out the cost of code ownership and deployment for each project.
• Systems with a long lifespan and the ability to evolve: The promise of standards-based
computing, embodied in the 3-D framework’s virtual platform layer, helps ensure that
architects and developers can spend more time addressing business issues rather
than technical issues. It allows for platform independence, allowing your enterprise to
take advantage of advances in computing hardware, network technologies, and
software without expensive reengineering of core dot-com applications.
DOT-COM-READY WORKSHOP
Sun’s Dot-Com-Ready Workshop is a good first step for defining your dot-com busi-
ness strategy and evaluating the technical requirements of building a 3–dimensional
Architecture. The workshop is customizable for your specific needs and will show you
how Sun consulting services, architectural approaches, competency center offerings,
and specific products and services can help you build your 3–Dimensional Architecture.
dot-com solutions. The project team examines your IT infrastructure as a set of logical
and physical components, then builds a customized, demonstrable proof-of-concept of
the technology supporting your business needs.
• Develop a master architectural plan that outlines the entire architecture, the rela-
tion of the architecture to the strategic requirements, and the identification of the
COTS components and any necessary custom application development
• Support Services: Sun’s support services offer the proactive systems support, the
expert knowledge transfer, and the seamless service integration you need to help
meet your mission-critical uptime objectives. Our systems support programs focus
on proactive failure prevention, rapid recovery, and technical services planning for a
global corporation’s enterprise network environments.
• Professional Services: Sun Professional Services can help you create or restructure
your IT infrastructure to leverage the Internet for optimal performance and service
quality. Sun consultants provide a full spectrum of IT planning and integration con-
sulting services, systems and network management services, Internet/intranet plan-
ning and integration services, and dot-com consulting services.
SALES OFFICES
ARGENTINA 54-11-4317-5600 • AUSTRALIA: • CANBERRA 02 6 217 5500 • MELBOURNE 03 9679 6200 • NORTH SYDNEY 02 9466 9400 • BELGIUM 32-2-704 80 00 • BRAZIL 5511-5187-2100 • CANADA 905-477-6745 • CHINA (86) 10-6803-5588
FRANCE 33-(0)1-30-67-50-00 • GERMANY 49-89-46008-0 • HONG KONG (852) 2202-6688 • INDIA (9180) 2298989 • ITALY 39-039-6055-1 • JAPAN 81-3-5717-5027 • KOREA 82-2-2193-5114 • LATIN AMERICA 650-688-9040 • MALAYSIA (603) 2116 1888
MEXICO 525-258-6100 • NETHERLANDS 31-33-4501234 • NEW ZEALAND: • AUCKLAND 0011649 976 6800 • WELLINGTON 0011644 462 0780 • SINGAPORE (65) 4381888 • SPAIN 34-91-596-9900 • SWEDEN 46-8-631 10 00 • SWITZERLAND 41-1-908-90-00
TAIWAN 886-2-8732-9933 • THAILAND (662) 3446888 UNITED KINGDOM 44-1252-372272 • UNITED STATES: • ATLANTA 770-360-6400 • BOSTON 781-270-7200 • CHICAGO 630-285-8700 • EL SEGUNDO 310-607-2442 • IRVINE 949-833-1640 • NEW YORK 212-558-9200
SANTA CLARA 408-276-9488 • SOMERSET 732-469-1000 • WASHINGTON D.C. 703-204-4100 • WORLDWIDE HEADQUARTERS 1-650-336-7786 OR 1-888-980-7263 • EUROPEAN HEADQUARTERS 44-1276-451440 • ASIA-PACIFIC 650-786-0239
© 2001 Sun Microsystems, Inc. All rights reserved. Sun, Sun Microsystems, the Sun logo, Java, Enterprise JavaBean, JavaServer Pages, Solaris, SunReady, Java 2 Platform, Enterprise Edition, iPlanet, Sun Cluster, SunTone
Architecture Methodology, and iForce are trademarks, registered trademarks, servicemarks or registered servicemarks of Sun Microsystems, Inc. in the United States and other countries. Products bearing SPARC
trademarks are base upon architecture developed by sun Microsystems, UNIX is a registered trademarks or registered in the United States and other countries, exclusively licensed through X/Open Company Ltd.
Printed in USA 5/01 FE1590-0