Copyright 2000 by Software Engineering Research and L&S Computer Technology, Inc.
Appears in Proceedings Computer Measurement Group Conference, Dec. 2000
Page 3 of 3
external and internal networks and among processes;
the number of interactions required to retrieve the data
and to accomplish the end-to-end business tasks; and
how to integrate legacy applications – whether to
modify the legacy application to provide a new,
customized Application Program Interface (API) or use
an Adapter that calls existing APIs and reformats data
as needed [GAMM95].
The technical architecture choices focus on
the hardware and support software platforms. We
must decide the number and size of processors that
we need, and determine which processors the various
processing steps should execute on (for example, do
we need separate web server(s) and application
server(s), and database server(s) or can some
functions be consolidated). We must also select
among middleware packages, and determine how to
best configure the environment for redundancy and
recovery. There are many other such choices that
need to be evaluated.
Web applications have a myriad of
implementation options that affect the software
architecture, such as:
• Whether the application will execute on the
server and which technology is most appropriate
[e.g., Common Gateway Interface (CGI)
processes, Active Server Pages (ASP), Java (or
other language) servlets, or server API
applications]
• Whether some of the application will execute on
the client and which technology is most
appropriate (e.g., scripts, applets, etc.)
• Whether component libraries should be used
(e.g., Enterprise Java Beans (EJB), ActiveX
Controls, etc.)
• How to access databases (e.g., Remote SQL,
stored procedures, middleware products, etc.)
These choices affect performance as well as
other quality of service attributes, such as availability
or security. In some cases, there are trade-offs to be
made between quality attributes. For example, putting
the application on a different machine than the Web
server may improve availability (failures in the
application will not interfere with the operation of the
Web server) but degrade performance (by increasing
overhead for communication across machines). If
these trade-offs are identified early, an architecture
that addresses these trade-offs can be selected. If not,
it may not be possible to meet some (or all) quality
objectives. This paper focuses on using SPE
techniques to construct and evaluate performance
models of various architectural alternatives early in
development. The goal is to select a combination that
will meet performance objectives.
3.0 SPE Models for Web
Applications
The SPE techniques for Web applications are
similar to those that we have used for distributed
systems [SMIT99b; SMIT98d; SMIT98c]. Web
applications use different implementation technologies
than other distributed systems, but implementation
details do not affect the SPE models during the early
life cycle stages. The following paragraphs give a
high-level overview of the modeling and evaluation
steps; Section 4 illustrates them with a case study.
The first step in the SPE process is to select a
set of performance scenarios that represent the
important web-application interactions. These are
usually the most frequent interactions; they also
include the important functions that must perform well
if the application is to meet its business objectives.
Next, we create an end-to-end performance scenario
that represents (at a high level) the processing steps in
each of the performance scenarios. We use extended
UML sequence diagrams to represent the system
interactions. (An example appears in Figure 4, and the
notation is explained in [SMIT98c]).
After representing the overall flow, we identify
processing steps that have the greatest impact on
performance and add details for them. For example, a
database query, particularly on a remote computer,
usually has a far greater impact on response time and
scalability than firewall processing. We also include
specific details for processing steps that correspond to
the software architecture alternatives we are
evaluating. That is, if we want to compare the
performance of two alternatives, such as client vs.
server processing for form validation, we must
represent the processing steps required for form
validation in the model. Next we convert the sequence
diagrams into a software execution model, add
performance specifications, and solve the software
execution model to determine the end-to-end response
time (without contention delays). The software
execution model often identifies problems with Web
applications, particularly when they need to transfer
large amounts of data over relatively slow
communication lines. After selecting a software
architecture alternative that meets performance
objectives, we use the system execution model to
evaluate technical architecture alternatives and
software scalability and capacity requirements.
The web execution environment is typically
complex. At the architectural level of design, we will
use deliberately simple models of software processing
that are easily constructed and solved to provide
feedback on whether the proposed software is likely to
meet performance goals. Thus our approach is to first
评论0
最新资源