Download The Java Pet Store is an Sun Micro System`s example web

Introduction:
The Java Pet Store is Sun Micro System’s example web application in the J2EE
blueprint series that was designed to document the best practices, design patterns, and
architectural ideas for J2EE applications. This same application, called the .NET Pet
Store has been implemented using C# and .NET.
The purpose of this case study is to test the claims made by Microsoft that the
.NET version is far superior in all measures of performance metrics requiring just onethird the lines of code (LOC’s) and provides 28 times faster average response times,
requires one-sixth the CPU utilization, and scales much better as the number of users
increases. There is an additional claim that the architecture of the .NET version is also
superior.
This case study will also study in-depth the .NET application, the architecture,
classes and other components that make up the .NET application.
Overview of .NET:
.NET developed by Microsoft, is a part of their web services strategy to provide
massive interconnectivity between people, systems, information and also devices through
the use of software.
.NET includes a host features deployed across the Microsoft platform such as
servers that are used to host Web services, which are built by development tools and in
turn applications that make use of these and a worldwide network of organizations to
provide information and assistance to customers.
.NET applications have the ability to be quickly and securely built and the use of
.NET technology provides the means for deployment and management of these
applications with web services.
Java Pet Store:
The original intent in developing the .NET Pet Store application was to use Sun’s
primary J2EE blueprint application, the Sun Java Pet Store, and implement the same
application functionality with Microsoft .NET . This will allow customers to compare the
two technologies in several performance issues and recommended design patterns.
The original Java Pet Store application was built to provide a working model of
various J2EE components integrated together and also to demonstrate how different J2EE
technologies could be used. The Java Pet Store Demo consists of full source code for the
Enterprise Java Beans (EJB) architecture, Java Server Pages (JSP) technology, tag
libraries, 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 Java Pet Store is an example e-commerce application where customers can buy
pets in various categories online. This also includes the ability to search and browse for
products ranging from dogs to reptiles. A website is used as an interface to present the
application to customers.
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.
Microsoft .NET Pet Store:
The .NET Pet Store focuses solely on the Java Pet Store component and does not
implement either the administration or the mailer component. In addition, to retaining the
functionality of the Java Pet Store, further 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.
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.
The application makes use of ASP.NET web forms for the presentation tier which
communicates 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). Data Access is fully
abstracted into a Data Access Layer (DAL), separate from the business logic layer (BLL).
The following diagram 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 loadbalancing software is configured to use "sticky ip’s," 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.
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.