.

NET Questionnaire
Gregory Leake
Microsoft Corporation

James Duff
Vertigo Software, Inc.

May 2003

Applies to:

Microsoft® .NET Framework 1.0 and 1.1

Microsoft® Windows 2000 and Windows Server™ 2003
Microsoft® Internet Information Services
Microsoft® SQL Server™ 2000
Oracle® 9i Database

Summary: Version 3.x of the .NET Pet Shop addresses the valuable feedback given by reviewers of
the .NET Pet Shop 2.0 and was created to ensure that the application is aligned with the architecture
guideline documents being produced by the Microsoft. (20 printed pages)

Download the Pet Shop 3.0 Installer.msi code sample.

Contents

Abstract
What is the Java Pet Store?
Microsoft .NET Pet Shop
Business Requirements
Application Data Model
.NET Pet Shop 2.0 Architecture
.NET Pet Shop 3.0 Architecture
Conclusions
Appendix A: Changes between Versions 2 and 3

Abstract
The purpose of the original .NET Pet Shop study was to take Sun's primary J2EE blueprint
application, the Sun Java Pet Store, and implement the same application functionality with Microsoft
.NET. Based on the .NET implementation of Sun's J2EE best-practice sample application, customers
can directly compare Microsoft's .NET technology to J2EE-based application servers across a variety
of fronts while learning about the similarities and differences in the recommended design patterns
for building Web-based applications. The .NET Pet Shop application is now in its third revision and is
designed to show the .NET best practices for building enterprise n-tier applications which may need
to support a variety of database platforms and deployment models. The .NET Pet Shop 3.0 has been
re-architected based on community feedback on the .Net Pet Shop 2.0 to comply with Microsoft's
Prescriptive Architecture Guidance as published on MSDN. The third revision is also fully compliant
with the Middleware Company Application Server Benchmark Specification, and will serve as
Microsoft's entry in the upcoming Middleware Application Server Benchmark this spring: a second
round of testing by the Middleware Company to compare the scalability of .NET and the J2EE
platforms for building and hosting enterprise Web applications.

What is the Java Pet Store?

The Java Pet Store is a reference implementation of a distributed application according to the J2EE
blueprints maintained by Sun. The sample application was originally created to help developers and
architects understand how to use and leverage J2EE technologies, and how each of the J2EE
platform components fit together. The Java Pet Store demo includes documentation, full source code
for the Enterprise Java Beans (EJB) architecture, Java Server Pages (JSP) technology, tag libraries,

1
 . NET Questionnaire
and servlets that build the application. In addition, the Java Pet Store blueprint application
demonstrates certain models and design patterns through specific examples.

The full Java Pet Store contains three sample applications:

• Java Pet Store: The main J2EE Blueprints application.

• Java Pet Store Administrator: The administrator module for the Java Pet Store.
• Blueprints Mailer: A mini-application that presents some of the J2EE Blueprints design
guidelines in a smaller package.

The original version of the Java Pet Store was designed to work with the following databases:
Oracle, Sybase, and Cloudscape. IBM has created a DB2 port of the application. The application is
publicly available at the Java 2 Platform Enterprise Edition Blueprints. The premise of the main
application, the Java Pet Store, is an e-commerce application where you can buy pets online. When
you start the application you can browse and search for various types of pet from dogs to reptiles.

A typical session using the Java Pet Store would be:

Homepage—This is the main page that loads when the user first starts the application.

Category View—There are five top-level categories: Fish, Dogs, Reptiles, Cats, and Birds. Each
category has several products associated to it. If we select Fish as the category, we might see
"Angelfish" etc.

Products—If you now select a product the application will display all variants of the product.
Typically the product variant is either male or female.

Product Details—Each product variant (represented as items) will have a detailed view that
displays the product description, a product image, price, and the quantity in stock.

Shopping Cart—This allows the user to manipulate the shopping cart (add, remove, and update
line items).

Checkout—The checkout page displays the shopping cart in a read-only view.

Login Redirect—When the user selects "Continue" on the checkout page, they are redirected to
login page if they have not signed in yet.

Verify Sign In—After being authenticated onto the site, the user is then redirected to the credit
card and billing address form.

Confirm Order—The billing and the shipping addresses are displayed.

Commit Order—This is the final step in the order-processing pipeline. The order is now committed
to the database at this point.

2
 . NET Questionnaire

Figure 1. Java Pet Store

Microsoft .NET Pet Shop

The goal of the .NET Pet Shop was to focus solely on the Java Pet Store (the administration and
mailer component were not implemented in .NET). In addition to reproducing the functionality of the
Java Pet Store application, two additional objectives were added:

• Compare and contrast the code and code size of a real world, best-practice application
between .NET and J2EE.
• Provide data on how many users a typical, well-designed application can support when
implemented in .NET and in J2EE.

Figure 2. .NET Pet Shop

The overall logical architecture of the .NET Pet Shop is given in Figure 3. The main focus of the
design was to use ASP.NET Web Forms for the presentation tier which communicate to C# business
components in a logical middle tier. In turn the business components access a back end database
through ADO.NET and a SQL Server helper class known as the Data Access Application Block (DAAB)

3
 . NET Questionnaire
for more information on the DAAB and to download the full DAAB source code. Data Access is fully
abstracted into a Data Access Layer (DAL), separate from the business logic layer (BLL). New with
the .NET Pet Shop 3.0, we have introduced a DAL layer for both Oracle 9i and SQL Server 2000
databases. Class loading of the appropriate DAL layer occurs dynamically at runtime based on an
application configuration setting in Web.Config. Note that .NET Pet Shop 3.0 uses two backend
databases, and the order process involves a distributed transaction across these two databases.
Using simple Web.Config application settings, users can deploy the .Net Pet Shop to work with single
or multiple backend databases, and can freely mix SQL Server and Oracle backend databases with
the distributed transaction handled by .NET Serviced Components using COM+ Enterprise Services.

Figure 3. .NET Pet Shop high-level logical architecture

Figure 4 shows how the Microsoft .NET Pet Shop might be physically deployed. In this case inbound
network traffic is split between the two application servers using Network Load Balancing, NLB, or
perhaps hardware load balancing. Once a network request has reached one of the machines in the
cluster, then all the work for that request will be performed on that particular machine. The business
logic and data access components will be installed as assemblies on both servers, which in essence
will be identical clones of one another. If the load-balancing software is configured to use "sticky
Ips," then each server can have its own session-state store, because a second request will be
guaranteed to return to the server where the first request was fulfilled. For a more fault-tolerant
solution, the two application servers can share a common session-state store such as SQL Server or
a dedicated session server (Not shown on diagram). The type and location of the session-state store
is determined by the values in the 'sessionState' child node of the 'system.web' element in the
'web.config' file for each Web site.

4
 . NET Questionnaire
Figure 4. .NET Pet Shop physical deployment diagram

Business Requirements
As part of the architecture documentation for Pet Shop 3 we have laid out what we considered to be
the business requirements for the .NET Pet Shop, so that developers and customers could
understand some of the trade-offs we made when we made some of our design decisions for the
application.

What are the functional requirements of the Pet Shop application?

• The application should enable customers to browse the company catalog by category and
through key word searches.
• The application should provide customers with a mechanism to purchase multiple items
through a shopping cart model.
• The application should provide a simple security model so that a customer is required to
sign in before they are allowed to purchase the contents of the cart.
• The application is intended to support a high-volume enterprise-class e-commerce solution;
hence the application should demonstrate the following:
• High performance, measured in terms of supported users, and the user response
time.
• The ability to scale up by adding more processors
• The ability to scale out by adding more machines to form a cluster
• With large Enterprise System it is likely that the application will be required to access
multiple data repositories, hence the application should support distributed transactions.
• The application should allow for a flexible deployment strategy. By default the application is
designed to be deployed to two physical machines, one application server and one database
server but should be extensible to work in other deployment models. The application should
support multiple database vendors. In this case we have chosen Microsoft SQL Server, and
Oracle.
• The application should be easy to maintain, which will be measured by the lines of code in
the application.

Application Data Model

Database

The database schema used in the .NET Pet Shop is ported directly from the Java Pet Store. The Java
Pet Store supports several database vendor formats and so we took the schema for the Sybase
application and created it in a Microsoft SQL Server 2000 instance. This required no changes to the
Sybase version of the schema. With the creation of an Oracle version of the .NET Pet Shop, we took
the original Oracle implementation of the Java Pet Store database.

The database has the following overall structure of tables; see Table 1:

Table 1. Database table in Pet Shop

Table Purpose
Name
Account Represents basic customer information
BannerData Stores the ad banner information
Category The catalog categories (Fish, Dogs, Cats, etc)
Inventory Product inventory status

5
 . NET Questionnaire
Item Individual product details
LineItem Order details
Orders The orders placed by the customer. An order
contains one or more line items
OrderStatus Order status
Product Catalog products, each product may have one
or more variants (Items). A typical variant
might be male or female.
Profile Customer user profile
Signon Login table for customers
Supplier Information concerning fulfillment suppliers

With version 2 of the .NET Pet Shop, the application was modified to create a scenario where a
distributed transaction would be required to complete the order process. For the distributed
transaction scenario, the Orders, OrderStatus, and LineItem tables have been split off into a
separate database instance that could be installed on a separate machine. We have kept this
distributed design pattern in the third version of the .NET Pet Shop.

Figure 5. .NET Pet Shop orders database schema

6
 . NET Questionnaire

Figure 6. .NET Pet Shop accounts and products database schema

What Changes Could Be Made to the Pet Shop Table Design?

There are some changes that could be made to the schema used in the application; however, we
have not made these changes in order to keep in line with the schema provided by the Java Pet
Store reference implementation. These changes are listed in table 2:

Table 2. Possible improvements to the Pet Shop schema

Change Reason
Not store You may want to use different client
HTML in application types, hence by storing only an
tables image file name, rather than an image tag, in
the database you can be more flexible with
the client type you can deploy
Use a one- Helps make the application more secure,
way because if any part of the system is

7
 . NET Questionnaire
encryption compromised it will still be difficult to read the
algorithm password. Would require the facility to reset
for customer the password to a new value.
passwords
Encrypt Prevent access to the credit card information
credit card should the system to compromised. Additional
information changes would be to make the table only
accessible with write permissions via a stored
procedure; hence a hacker would need to
access the database via an alternative set of
credentials to read the data.

.NET Pet Shop 2.0 Architecture

Figure 7. .NET Pet Shop 2 Application Architecture

.NET Pet Shop 2.0 was designed to be deployed in a physical two-tier deployment and took
advantage of this fact in the implementation of certain parts of the application. The application
consisted of a Web tier built with ASP.NET Web Forms which used "code-behind" to separate the
application HTML from the user interface code. The middle tier contained business components to
control the application logic which talked to a SQL Server database through a customized version of
the Microsoft Database Access Application Block (DAAB). To support distributed transactions, some
of the middle tier business components were implemented using Enterprise Services. With Microsoft
.NET this is the recommended way to support distributed transactions. However, not all classes
extended the ServicedComponent class, as there is a performance overhead of implementing all
classes as Enterprise Serviced Components. When publishing the .NET Pet Shop 2.0, which was used
in the first Middleware Application Server benchmark, we received much feedback on optimizations
that should be made to the architecture to make it more relevant to large-scale enterprises. The
major areas of feedback included:

• Creating a completely abstracted data tier with no imports of data-specific classes in the
middle tier.
• Implementing a data access layer for Oracle that works transparently with the same
business and UI layers as the SQL Server version.
• Completely abstracting Web session state from the business logic and data layers such that
the backend components of the application can be physically distributed onto separate computers

8
 . NET Questionnaire
from the Web server, or reused from other types of clients such as Windows-based clients vs.
Web–based clients.
• Fully partitioning application modules into separate namespaces and physical assemblies.
• Additional feedback across a variety of fronts.

.NET Pet Shop 3.0 Architecture

Figure 8. .NET Pet Shop 3.0 application architecture

Application Areas

Table 3. Application areas in the Pet Shop solution

Area Purpose .NET Implementation

User Capture data input ASP.NET Web Forms,
Interface from the user and user controls, and
Component display data returned server controls. These
s by the backend constructs allow for
system. They also clean separation
handle simple between designer HTML
navigation. Refer to and UI code such as
User Interface event handlers for
Components. buttons
User Controls user These are implemented
Interface navigation and as C# classes. The
Processing process flows with session state
backend business management is handled
objects. Also handles by ASP.NET.
management of user
session data. Refers
to User Process
Components.
Business Components that These are implemented

9
 . NET Questionnaire
Component implement the as C# classes
s business logic for an
application
Business Thin data classes for These are implemented
Entities passing data as C# classes with each
between tiers of the field exposed as a
application. Refer to property. Each class is
business entity marked as "serializable"
components. to enable inter-process
transfer.
Data Access Handle the These handle the
Layer interaction with back interaction with
Component end data stores, backend data stores,
s including databases, including databases,
messaging systems, messaging systems,
etc. etc. Implemented as
four C# projects:

• A set of interface
classes for each data
access method we
want to expose.
• An implementation
of the interfaces for
SQL Server.
• An implementation
of the interfaces for
Oracle 9i.
• A set of factory
classes to load the
correct
implementation,
either SQL Server or
Oracle.

Microsoft Visual Studio .NET Solution

Figure 9 shows the Microsoft Visual Studio .NET solution layout for the .NET Pet Shop application.
Each element or tier of the application was given its own project to make the solution manage and
clearly define where new classes used in the application should be placed or old ones can be found.

10
 . NET Questionnaire

Figure 9. Visual Studio .NET application solution

The purpose of each project is listed in Table 4:

Table 4. Visual Studio projects in the Pet Shop solution

Project Purpose
BLL Home for business logic components
ConfigTool Administration application used to encrypt
connection strings and create event log
source
DALFactory Classes used to determine which database
access assembly to load
IDAL Set of interfaces which need to be
implemented by each DAL implementation
Model Thin data classes or business entities

11
 . NET Questionnaire
OracleDAL Oracle specific implementation of the Pet
Shop DAL which uses the IDAL interfaces
Post-Build Project to run post compile actions such as
adding assemblies to the GAC or COM+
Pre-Build Project to remove assemblies from the GAC
or unregister assemblies from COM+
SQLServerDAL Microsoft SQL Server specific
implementation of the Pet Shop DAL which
uses the IDAL interfaces
Utility Set of helper classes including a wrapper for
the DPAPI
Web Web pages and controls
Solution Miscellaneous items used to build the
Items application such as Pet Shop.snk key file
used to sign application assemblies

Database Portability

One of the key requirements for this version of the Microsoft .NET Pet Shop was to provide an
implementation of the application that supported both Oracle and SQL Server databases. When
designing the database access mechanism for the application, we had a choice as to which database
providers we should use; we could either use the generic OLE-DB managed provider or the
database-specific, performance-optimized .NET managed providers, such as the SQL Server and
Oracle managed providers provided with the .NET Framework 1.1. One of the key requirements for
the application was to create a high-performance solution, so we chose to build the application using
the database-native .NET managed providers. For an analysis of the difference in performance
between the managed providers and the generic OLE-DB providers, readers should refer to Using
.NET Framework Data Provider for Oracle to Improve .NET Application Performance, which shows
that the vendor-specific providers can perform two to three times better than the equivalent OLE-DB
provider. The tradeoff that we made when choosing to go with a database-specific access class was
that we would need to write a separate data access layer for each database platform we wanted to
support and hence the application would contain more code. While the two data access layers share
much common code, each is clearly targeted for use with a specific database (Oracle or SQL Server
2000).

In order to simplify the use of the database access classe,s we elected to use the Factory Design
Pattern as outlined by the GoF, with reflection being used to dynamically load the correct data
access objects at runtime. The factory is implemented as follows: a C# interface is created with a
method declared for each method that must be exposed by the database access classes. For each
database that we want to support, we create a concrete class that implements the database specific
code to perform each of the operations in the interface or "contract." To support the runtime
determination of which concrete class to load, we create a third class which is the factory itself and
reads a value from configuration file to determine which assembly to load using reflection. With the
reflection namespace in .NET, you can load a specific assembly and create an instance of an object
using that assembly. To make the application more secure and provide improved support for
versioning, we can add "evidence" about the assembly file to load in the application configuration
file, in this case, web.config. This means that the .NET Framework will only load the assembly that
we have signed during compilation and has the correct version number. Figure 10 shows how the
business logic, factory, and databases access classes interact with each other. The key advantage of
the solution built is that the database access class can be compiled after the business logic classes
as long as the data access class implements the IDAL interfaces. This means that should we want to
create a DB2 version of the application, we do not need to change the business logic tier (or UI tier).
The steps to create a DB2 compatible version are:

12
 . NET Questionnaire
1. Create the database access classes for DB2 which implement the IDAL interfaces.
2. Compile the DB2 access classes into an assembly.
3. Test and deploy the new data assembly to a running server.
4. Change the configuration file to point to the new database access classes.

No changes or recompiles need to be performed on the business logic components.

Figure 10. DAL factory implementation in .NET Pet Shop

Stored procedures

Normally we would recommend to customers that they use stored procedures to access tables in the
database. There are several reasons for this:

• Stored procedures provide a clean mechanism to encapsulate queries.

• Changing a query can be done without changing the data access code.
• A DBA can easily see what SQL statements are being executed.
• Stored procedures are typically more secure, and it is easier to control database access.
• By using stored procedures you can avoid round trips to the client by issuing more than one
request in the stored procedure.
• Stored procedures usually offer the best performance compared to middle-tier-generated
SQL.
• Stored procedures offer an excellent way to encapsulate XML queries and XML input
parameters.

The disadvantage of stored procedures is they tend to be proprietary and are not portable across
platforms.

However, to make the best use of the financial investment that you have made in your database
software and hardware, developers will tend to optimize the SQL used in their applications for their
specific database engine regardless of whether the SQL is in a stored procedure or generated in the
middle tier. A good example of this is generating unique numbers or identity numbers, as all
databases support their own particular mechanisms for doing this, and so the SQL used to generate
the unique number tends to be specific to the database being used. There are always alternatives,
but they do not perform as fast as the proprietary solutions.

With the .NET Pet Shop we took the conscious decision not to use stored procedures in the
application as this might be seen to be an unfair advantage for the .NET solution in the Middleware
Benchmark. In reality the difference in performance is small because the application is relatively
simple and most of the SQL statement execution plans are cached in the database. However, for

13
 . NET Questionnaire
purposes of the Middleware Benchmark specification, which disallows the use of stored procedures
even to wrap simple SQL statements, the .NET Pet Shop 3.0 uses no stored procedures.

Caching

One of most effective ways to improve the performance of a database-driven applications is to

eliminate accessing the database for every request. ASP.NET offers a variety of caching mechanisms
that boost performance in most applications. The two main ways to use caching in ASP.NET are
output caching and data caching.

.NET Caching Options

Page-level output caching takes the response from an ASP.NET Web page and stores the full page in
a cache. The page cache is designed to work between the Web tier and the middle tier and caches
the results/data of middle-tier methods, or the results of database calls in the case of two-tier apps.
The first .NET Pet Shop distribution was offered in a page-level output-cached version and a
noncached version. Version 3 only supports data caching but can easily be modified to support
output caching. With Windows Server 2003 and IIS 6.0, certain output cached pages (those with
VaryByParm="none" and the directive to Cache 'Anywhere') can also be kernel-level cached, with
even faster access from Internet clients. Regardless, any output-cached page (kernel or nonkernel
cached) is served extremely quickly by the Windows application server with much less resource
(CPU) consumption, since no processing is actually occurring to recreate the page.

ASP.NET Output Caching

The original .NET Pet Shop application, version 1.5, also used a variation on page-level output
caching, partial page caching or fragment caching to cache different regions of page. For instance,
the header information that appears on the top of every page is cached. However, the header
information is dependent on the user signing in (so two different versions of the page have to be
cached). ASP.NET easily allows this by using the VaryByCustom attribute on the 'OutputCache'
directive. Using VaryByCustom requires overriding the GetVaryByCustomString method to get a
custom cache for the header.

ASP.NET Data and Object Caching

The object cache (Cache API) allows you to store the results of a method call or database query in
the internal caching engine with the .NET Framework. Since you have gone further through more of
the application pipeline, the data cache may not offer the same performance boost that output
caching yields, since HTML pages still must be dynamically constructed on each request. However, it
does offer a good compromise between fully dynamic pages and reducing the load on the database
by storing nonvolatile data in the middle tier. For example, you may want to display the same piece
of data differently in two Web pages, or use the cached objects or data differently in various pages
of the same application.

ASP.NET Cache Monitoring

There are several ways to monitor what is happening in the ASP.NET caching system. The foremost
method is to use Perfmon but you can also use a SQL Server trace to check when database access is
occurring or not occurring as the case may be. To monitor the cache in Perfmon, select the Output
Cache Entries and Cache API Entries counters under the ASP.NET Application performance object
and add them to the Perform graph. It is also possible to monitor the turnover rate and the hit rate
within Perfmon to detect whether the item is being used in the cache.

Table 5. Summary of caching options in .NET

Type of Benefits Limitations

Caching
Output Offers best Entire page output is
Caching performance cached

14
 . NET Questionnaire
Fragment Simple to Limited to time
Caching implement. Entire invalidation
page output is
(Cache user cached
controls)
Cache API Different user Cached controls can
controls on a page be shared across
can have different pages. Need to cache
cache timeouts each user control
individually

Pet Shop Middleware Benchmark Caching Rules

The Middleware Company has defined strict rules for the benchmark application as to what can be
cached and how it can be cached. Basically, page-level output caching is disallowed, but middle-tier
data caching is allowed in certain places in the application. The following data was allowed to be
cached; it does not need to be refreshed from the database on each request: category information,
product information, item information (excluding inventory data), and some account information. In
terms of inventory data, the current quantity in stock should reflect an up-to-date value whenever
an item is added to the cart or a user navigates to the 'ItemDetails' page. For the account
information the username and password has to be validated on every single login attempt, and the
address used for billing information should always be refreshed from the database to ensure that it
is up to date during a checkout process. The implication of this is that the results for most products
searches and browse operations can be cached in the middle tier using a data/object cache set to
expire on a given interval.

The second rule for the benchmark is that page level output caching should not be allowed; the web
server should always be required to recreate the rendered HTML for a page. The reason for this is to
test the ability of the application servers to generate dynamic pages, not how fast the server could
pull HTML from a cache.

Pet Shop 3.0 Caching Implementation

For this version of the application, we used data caching in the code behind of the ASPX pages to
cache the results of middle tier (business logic tier) requests. The following sample code shows how
one would access the ASP.NET cache API to retrieve information from the cache. The example is
based on the category query, category.aspx.cs, in the Pet Shop application. In the Pet Shop a user
can select one of the five predefined categories of pet and view a list of animals in that category.
The first thing the code does is to check to see if the data has already been cached by using the
category id as a key to look up an element in the data cache. If this element does not exist, either
because the data has not yet been cached, or the current cache has expired, it will return null. If the
element exists, the data from the cache is pulled and cast to the appropriate type. If the data is not
in the cache, the middle tier is invoked to query for the data. The results from the middle tier query
are then added to the cache with an expiry time of 12 hours from now. Alternatively, we could
expire the cached based on a fixed time of day, a dependency on another cache item, or by
supplying a callback function which could be used to clear the cache.

Copy Code
// Get the category from the query string string categoryKey =
WebComponents.CleanString.InputText(Request["categoryId"],50); // Check to see
if the contents are in the Data Cache if(Cache[categoryKey] != null){ // If the
data is already cached, then used the cached copy products.DataSource =
(IList)Cache[categoryKey]; }else{ // If the data is not cached, // then create a
new products object and request the data Product product = new Product(); IList
productsByCategory = product.GetProductsByCategory(categoryKey); // Store the
results of the call in the Cache // and set the time out to 12 hours
Cache.Add(categoryKey, productsByCategory, null, DateTime.Now.AddHours(12),
Cache.NoSlidingExpiration , CacheItemPriority.High, null);

15
 . NET Questionnaire
products.DataSource = productsByCategory; } // Bind the data to the control
products.DataBind();

Conclusions
The architecture of the .NET Pet Shop has been enhanced to provide a more flexible solution in
terms of deployment options and the application is more readily customizable and adaptable to the
changes in business models. Despite all these changes, the performance of the Pet Shop has
remained roughly the same as the 2.0 implementation, and shows that the Microsoft .NET
framework offers a viable alternative to J2EE for Enterprise solutions. Using the .NET Pet Shop and
J2EE Pet Store, architects and developers can compare .NET and J2EE side by side using functionally
identical reference applications that illustrate best coding practices for each platform. The upcoming
Middleware Benchmark will test the new .NET Pet Shop 3.0 implementation to compare its
performance to two new J2EE implementations—one based on CMP 2.0 and one based on a pure
JSP/Servlet architecture with no EJBs. The testing will be conducted by the Middleware Company
and published on the ServerSide with a variety of J2EE application servers. A panel of J2EE experts
has been established and is overseeing this benchmark to ensure fairness across tested products
and adherence to specification/best practice for all implementations. In addition, the major J2EE
application server vendors have been invited, along with Microsoft, to participate by commenting on
the specification, providing implementations to be tested, and being on site for tuning/optimizations
and the testing process. Microsoft has opted to fully participate in this second round of testing.

Appendix A: Changes Between Versions 2 and 3

Item Description Reason
1 Created a database Allows clean separation of
access layer (DAL). business logic from database
access code, hence we can
change database vendor
without changing the business
logic code.
2 Created a common The model project only contains
project for all thin thin classes for holding data
data classes and would be used in each tier
(models). of the application as a container
to transport data in. All the
model classes support
serialization through the
[Serializable] tag to add
improved support for clustering
and any future changes we
want to make to physical
deployment.
3 Removed references Good design practice as it
to System.Web in allows middle-tier components
Components project. to be used with different types
of UI.
4 Changed some of The header and banner controls

16
 . NET Questionnaire
the custom server contain a lot of HTML/UI
controls to Web user content hence they are easier
controls; however to maintain if they are
the Pager control implemented as web user
was left as a custom controls. The Pager control
server control. deals with the manipulation of
the query string and using data
in viewstate, and so it is better
suited being a custom server
control.
5 Created an To support an Oracle database
implementation of we created a specific Oracle
the DAL for Oracle. DAL that would take advantage
of an Oracle specific driver
6 The DAL layer now To hide which database we are
implements a using on the back end, we use
factory [GoF] to load a Factory method to return an
the appropriate interface to the DAL layer we
vendor specific DAL. want to use.
7 All public fields in This allows the field storage
the model class mechanism to be hidden and
were converted to provides a good place to add
properties. break points in code if you want
to see what functions modify
certain data.
8 Created a database Allowed clean separation of
access layer (DAL). business logic from database
access code, hence we can
change database vendor
without changing the business
logic code.
9 Changed all static Response to review feedback
methods to instance
methods.
10 Fixed the version Allows for specifying evidence
number in when loading an assembly in
assemblyinfo.cs to a the DALFactory objects.
specific version to
match deployment.
11 Added pre- and This enables for running gacutil

17
 . NET Questionnaire
post-build steps to and regsvcs utilities on certain
the Visual Studio assemblies once the project has
.NET solutions. been compiled.
12 Renamed order More intuitive for other
business developers to understand what
components based the components do.
on the function they
perform rather than
their implementation
mechanism.
13 Created a The application event log
configuration tool to source needs to be created by a
aid application member of the administrators
setup. group. The easiest way to
ensure that this was done was
to provide a simple tool to do
this that could be run post
deployment.
14 Modified code to Response to user request to be
allow different DALs able to use a mixed-database
to be used for the deployment model.
accounts and
products database
and the orders
database.
15 Page output caching Request of for demonstration of
is added to the how the VaryByCustom function
pages; however this can be overridden to enable
will be removed for pages such as the header and
benchmarks. banner controls to be cached
within pages such as
default.aspx.
16 Added process flow Response to review feedback as
control classes to it provides a single location to
Web application. control navigation and state
management for a Web domain
such as accounts or shopping
carts.

18