You are on page 1of 53

JAVA PETSTORE: A CASE STUDY

By ROHIT NAMBIAR B.E., Bhartidasan Uni !rsity, India, "##"

A REPORT S$%&itt!d in 'artia( )$()i((&!nt *) th! R!+$ir!&!nts )*r th! d!,r!! MASTER O- SCIENCE D!'art&!nt *) C*&'$tin, and In)*r&ati*n S.i!n.!s C*((!,! *) En,in!!rin, /ANSAS STATE UNIVERSITY Manhattan, /ansas "##0

A''r* !d %y:

Ma1*r Pr*)!ss*r

Dr. 2i((ia& J. Han3(!y

ii

ABSTRACT

The Java PetStore application (an open source application) is Sun Microsystems model example of a web application. The Java PetStore is an implementation of a distributed application accordin to the J!"" blueprints maintained by Sun and its source code can be freely downloaded from the Sun #ebsite. The application consists of a #eb site throu h which it presents an interface to customers where the customers can buy pets online. $ccordin to %Sun Microsystems Java &lueprints'( the Java Pet Store application demonstrates certain models and desi n patterns and documents best practices and architectural ideas for J!"" applications. The application also helps developers and architects understand J!"" technolo ies( and how each of the J!"" platform components fit to ether. &ut the main problem in Sun)s primary J!"" blueprint application lies in the poor documentation that fails to explain in detail how the desi n oals( architectural desi n*patterns are mapped on to a real web application. Morover ivin +ust the source code for the application devoid of any class dia rams and lac, of enou h dia rammatic representation ma,es it extremely difficult for an end user to understand the desi n concepts of the PetStore. The purpose of this case study is to ta,e Sun)s primary J!"" blueprint application( the Sun Java Pet Store (-pen Source)( and study the +ava petstore applications( its architecture( its respective desi ns by the way of dividin it into functional modules( representin them in detail with the help of class dia rams and analy.in how it presents a ood material for a case study. &ased on Sun)s J!"" best/ practice sample application( we learn the recommended desi n patterns for buildin flexible( scalable( cross/platform #eb/based applications. #e have ta,en into account what 0uality oal has been achieved by the application and how the desi n*architecture affected the desi n oals and vice versa. #e also added thou hts about the performance of an e0uivalent( revised( and fully optimi.ed J!"" Petstore #eb application by loo,in into some testin statistics performed on the application.

ii

TAB4E O- CONTENTS
4IST O- -I5URES 6666666666666666... 4IST O- TAB4ES66666666666666666.. AC/NO24ED5EMENT 66666666666666. 7 INTRODUCTION 666666666666666666 " BAC/5ROUND 66666666............................................ !.1 #ebservice $pplications 22222222222222. !.1.1 $rchitecture of J!ee $pplication22222222.. !.! J!ee 3esi n Patterns &lueprints22222222222... 8 PETSTORE ARCHITECTURE AND DESI5N666666. 5.1 6eneral PetStore -verview2222222222222.. 5.! 7e0uirement 8 Specifications 222222222222. 5.5 Model :iew ;ontroller $rchitecture2222222222. 5.4 Structural :iew $rchitecture2222222222222.. 5.4.1 Modular 3esi n and its >mplementations222222 5.4.! "ntity &ean and Session &ean ;lass 3ia rams2222 9 PETSTORE IMP4EMENTATION 666666666666 4.1 Pa e @low 3ia ram22222222222222222.. 4.1.1 Pa e Screenshots2222222222222222 4.! Petstore JSP pa es222222222222222222.. 4.5 Petstore BMC @iles222222222222222222. 0 TESTIN566666666666666666666666.. A.1 Enit Testin 222222222222222222222 A.! Java Profilin 22222222222222222222. A.!.1 A.!.5 ;PE Profilin 22222222222222222. Memory Profilin 222222222222222... iii iv v 1 ! ! ! 4 4 4 9 < 1= 1! 1? !1 !1 !! !A !D !D !D !9 !9 !9 !<

A.5 Coad Testin 222222222222222222222 !9 : EVA4UATIONS AND ENHANCEMENTS 666666666. D.1 Testin 7esults22222222222222222222 !<

D.! "valuation2222222222222222222222 D.5 "nhancements 2222222.2222222222222 ; CONC4USION666666666666666666666. < BIB4IO5RAPHY6666666666666666666.....

54 5D 5D 5<

ii

4IST O- -I5URES
@i ure 1 J!ee $rchitecture 3ia ram 222222222222...222.. @i ure ! Ese ;ase 3ia ram for the ;ustomer 2222.22222222.. @i ure 5 @i ure 4 @i ure A @i ure D @i ure 9 @i ure < @i ure ? Model :iew ;ontroller $rchitecture for Java Petstore..2222.2 Model :iew ;ontroller Se0uence 3ia ram2222222222 Petstore @unctional Modules 222222222222222.. ;lass 3ia ram for Si n-n Module2222222222222. ;lass 3ia ram for Product ;atalo Module222222222... ;lass 3ia ram for Shoppin ;art Module2222222222. ;lass 3ia ram for Mail Module22222222222222. 5 9 ? 1= 11 1! 15 14 1A 1D 1< 1? != !1 !! !! !5 !5 !4 !4 !A !< !? 5= 5= 51 5! 55

@i ure 1= ;lass 3ia ram for ;ustomer Module222222222222 @i ure 11 ;ontrol Module / #eb $pplication @ramewor,2222222.... @i ure 1! "ntity &ean ;lass 3ia ram for Petstore22222222222. @i ure 15 Session &ean ;lass 3ia ram for Petstore2222222222.. @i ure 14 Pa e @low 3ia ram222222222222222222... @i ure 1A Screen shot representin applicationFome pa e2222222.. @i ure 1D Screen shot representin ;ate ory Screen2222222222 @i ure 19 Screen Shot representin Product >tems Screen2222222... @i ure 1< Screen Shot representin ;art Screen22222222222.. @i ure 1? Screen Shot representin Si n-n Screen2222222222. @i ure != Screen shot representin &illin >nformation22222222.. @i ure !1 Screen shot representin -rder ;onfirmation22222222. @i ure !! testMethod() enerated for testin cart.+sp222222222.. @i ure !5 7esult for Enit test2222222222222222222 @i ure !4 6raph showin Feap Memory Esa e22222222222.. @i ure !A 6raph showin the number of -b+ects 8 $rray created2222. @i ure !D 7esults for Memory Profilin 22222222222222.. @i ure !9 7esults for ;PE Profilin 2222222222222222 @i ure !< 7esults for Coad Testin 2222222222222222 iii

4IST O- TAB4ES

Table 1 $ctions and the 3escription for the customer22222222. Table ! Petstore Modules and their @unctionality2222222222 Table 5 "ntity &eans for the $pplication222222222222. Table 4 Session &eans for the $pplication22222222222.. Table A Petstore JSP Pa es2222222222222222222 Table D Petstore BMC @iles222222222222222222.

D 11 1? != !A !D

iv

AC/NO24ED5EMENTS
> sincerely than, my ma+or professor( 3r. #illiam J. Fan,ley for his continuous support and uidance throu hout the development of this pro+ect. Fis patience and critical review has helped me in evaluatin and finishin my wor,. > would also li,e to than, 3r 3aniel $ndresen and 3r Scott $. 3eloach for servin in my committee. Cast but not the least > would li,e to than, my Parents( Sister for their constant support and patience and all my friends who always help me out whenever > am in need.

7.

INTRODUCTION

The Sun Java &lueprints lay down a set of desi n oals and architectural desi n patterns for buildin reliable( scalable cross/platform applications. The Java PetStore is one such sample application developed by Sun &lueprint team to teach developers of best practices used to develop J!ee applications. $lthou h Sun claims that the &lueprints help a real developer to build a lar e and complex J!ee #eb applications it does not prove its claim by ivin any analysis of the internal desi n patterns( class dia rams or eneral application framewor,s. The Main -b+ective for ta,in up this case study was to o throu h various desi n patterns that the Sun Java &lueprints recommend as the best architectural and desi n patterns for buildin a flexible( scalable( cross/platform web application. The next step involved studyin how those desi n patterns or oals are mapped on to live web applications li,e the +ava petstore application. @or better understandin of the best architectural practices and the desi n patterns of the blueprint uidelines we loo,ed into the architecture of the +ava petstore and discuss the consistent Petstore desi n conformin $rchitecture conformin to the J!ee 3esi n Patterns. 3escribin the PetStore to the Model :iew ;ontroller architecture and structurally

decomposin the application to modules with class dia rams helps a developer to better understand how to build similar applications with reuse. #e also ave an overview as to how the petstore application benefits from such architectural desi n. #e could not have discussed so much detail about the petstore application without buildin and runnin the application. #e further ran some performance tests to ive a eneral idea of how the petstore application could be further enhanced in the future. The contributions in the remainin sections are as followsG Section ! ives bac, round information re ardin the #ebService applications( eneral J!ee application architecture and the blueprints for J!ee desi n patterns. Section 5 ives the PetStore architecture and desi n. #e went throu h the eneral PetStore -verview( the re0uirement and specifications for the application followed by the Model :iew ;ontroller $rchitecture conformin to PetStore. #e further studied the PetStore desi n by dividin the structural architecture into functional modules and drawin class

dia rams correspondin to each module. The modular desi n and its implementations in PetStore application is discussed followed by describin some of the entity bean and session bean used in the application. Section 4 shows the PetStore >mplementations includin the Screen Shots with some JSP and BMC files used in the application. Section A 3escribes the various Performance tests li,e Enit Testin ( Memory Profilin and Coad testin run on the PetStore application. Section D describes the -verall evaluations and the "nhancements possible on the case study conducted. Section 9 describes some of the conclusion for this case study

"

BAC/5ROUND

".7 2!%s!r i.! A''(i.ati*n #ebservices can be defined as self/contained( self/describin modular applications

that can be published( located( and invo,ed across the #eb. #eb services are also termed as buildin bloc,s for creatin open distributed systems. #eb Services perform functions( which can be anythin from simple re0uests to complicated business processes. -nce a #eb service is deployed( other applications (and other #eb services) can discover and invo,e the deployed service. &ac, round J!"" is an evolution of existin application server technolo y used to build usable web services systems that exhibit the features li,e r!(ia%i(ity, s!.$rity, transa.ti*ns, s.a(a%i(ity. There are a lot of features that oes in buildin web services( such as BMC interoperability( load/balancin ( and transactions. Fence we ma,e a thorou h case study studyin the J!"" web services usin the classic example of the +ava pet store. ".7.7 Ar.hit!.t$r! *) J"!! A''(i.ati*n server/side deployments in the Java

The J!"" architecture is used for buildin pro rammin

lan ua e and for build traditional web sites( software components( or !

pac,a ed applications. J!"" application is hosted within a container( which provides 0ualities of service necessary for enterprise applications( such as transactions( security( and persistence services. The %$sin!ss (ay!r performs business processin and data lo ic. >n lar e/scale J!"" applications( business lo ic is built usin "nterprise Java&eans ("J&) components. This layer performs business processin and data lo ic. >t connects to databases usin Java 3atabase ;onnectivity (J3&;) or SHC*J( or existin systems usin the Java web ;onnector $rchitecture (J;$). >t can also connect to business partners usin (the J$B $P>s). &usiness partners can connect with J!"" applications throu h web services technolo ies (S-$P( E33>( #S3C( ebBMC). $ servlet( which is a re0uest*response oriented Java ob+ect( can accept web service re0uests from business partners. The servlet uses the J$B $P>s to perform web services operations. Shared context services will be standardi.ed in the future throu h shared context standards that will be included with J!"". The basic J!"" web service is shown below @i ure.

services technolo ies (S-$P( E33>( #S3C( ebBMC) throu h the Java $P>s for BMC

-i,$r! 7 J"!! Ar.hit!.t$r! Dia,ra& !.!

J"!! D!si,n 5*a(s: There are a common set of desi n oals described by the +!ee blueprints. Some of those J!"" desi n oals areG Str$.t$ra( d!.*&'*siti*n = 3ecomposin an application into different modules( or classes( ma,es it easier for developer to understand the application. This also helps for maintenance and modifiability.

S!'aratin, Data 'r!s!ntati*n, r!'r!s!ntati*n and B$isn!ss (*,i. / >n applications( the areas of the code that deal with the user interface are more li,ely to have more fre0uent chan es( while the underlyin business lo ic mi ht have less or no chan es.

E>t!nsi%i(ity: The application should be easy to modify and update with a renewed set of features S!.$rity: There should be absolute safety of transactions( in a web application. Mini&i?! n!t@*r3 tra))i.: The amount of data in a web application that needs to be transmitted should be minimi.ed. D!si,n r!$sa%i(ity: Felps in reduced development costs and improvements in 0uality over a lon period

8. P!tSt*r! Ar.hit!.t$r! and D!si,n: 8.7 P!tst*r! O !r i!@ : The Java PetStore is a typical e/commerce applicationG an online pet store that sells customers products( types of pet from do s to reptiles. The Java Pet Store consists of "nterprise Java &eans ("J&) architecture( Java Server Pa es (JSP) technolo y( ta libraries( and servlets that build the application. $ customer shops( places orders( mana es her user account. The application has a #eb site throu h which it presents an interface to customers. The users view of how he interacts with the petstore application can be seen by the shoppin interface described above( that allows shoppers to buy items online. The interaction can be summari.ed as followsG $ customer connects to the application( by pointin the browser to the E7C for the application)s home pa e. The customer can browse throu h the catalo or search for products. $t any point durin the whole interaction( the customer can si n into the application by providin an account identifier and a password. #hen the customer si ns in( the application can recall information about the customer such as a preferred shippin address and billin information( buyin preferences( and so on. ;ustomers who don)t have an account can create one at any time by providin an account identifier( customer name( password and some other personal details. The customer browses throu h the catalo to see a list of all the products in that cate ory. @or example( the customer can select the cate ory 3o s to view all do s that the pet store sells. The customer then selects a particular product in the list resultin in the detailed information li,e ima e of the product alon with pricin information of the product. #hen the customer decides to purchase a particular item he clic,s a button to add the item to the shoppin cart. $s the customer browses throu h the catalo ( the application remembers all the items placed in

the cart and the customer can recall the shoppin cart at any time durin the interaction to review or revise the contents of the cart. $ chec,out button is presented alon with the shoppin cart so that a customer can choose to order the items in the shoppin cart at any time. This brin s up a si nin*si nup screen. #hen the customer as,s to chec, out( the application presents a summary of all items that would be ordered alon with their costs and then he confirms the order. #hen the customer confirms the order( the application be ins to ather shippin and billin information for the order. @irst it presents a form( where the customer can enter shippin information. >f the customer is si ned into the application at this time( the form comes up filled in with the customer)s preferred shippin address else he is as,ed to enter billin information( includin credit card details and a billin address. @inally the customer confirms the order and the application accepts the order for delivery. $ receipt includin a uni0ue order number and other order details is presented to the customer. The application validates credit card and other information( updates its inventory database( and optionally sends a confirmation messa e via email.

ACTOR ;ustomer

ACTION &rowse catalo

DESCRIPTION "ach cate ory has several products associated to it

;ustomer

&rowse 3etail

"ach product variant has detailed view that displays the product description( a product ima e( price( and the 0uantity in stoc,.

;ustomer ;ustomer

&rowse >tem &rowse Products

"ach >tem is viewed. >f we now select a product the application will

display all variants of the product. ;ustomer Epdate ;art This allows the user to manipulate the shoppin cart (add( remove( and update line items). ;ustomer Epdate Personal >nfo This allows user to update his personal information ;ustomer ;ustomer Epdate $ccount Submit -rder The chec,out pa e displays the shoppin cart. The billin displayed. ;ustomer Purchase -rder The final step wherein the order is committed to the database. Ta%(! 7 A.ti*ns and th! D!s.ri'ti*n )*r th! .$st*&!r and the shippin addresses are

<

-i,$r! " Us! Cas! %!t@!!n th! C$st*&!r and th! 2!% Sit!

8." R!+$ir!&!nt A S'!.i)i.ati*ns: >n the +ava petstore other than the customer( there are other potential users which include the administrators responsible for maintainin inventory and performin other mana erial tas,s( and associated businesses such as suppliers. "ach class of users has access to specific cate ories of functionality( and interaction with it usin specific user interface. Fence to understand the petstore architecture we first describe some basic specification re0uired by each class of user. ;ustomerG $ ;ustomer will need some lin,s on the pa e so as to et 0uic, access to all tas,s. >t also re0uires a catalo and a search mechanism to et an or ani.ed view of items and providin a way to locate items. @or the products all the detail showin their price availability( picture should be available. $ shoppin cart to add and remove items and a chec,out bill showin the total order cost and billin information. $dministratorG $n administrator re0uires all the features of a customer plus some modifyin options for the product and the inventory status. Fe would re0uire an update option so that a chan ed inventory is committed to the database. &usinessG The business user re0uirement and specifications are mostly related to security. Fence user authentication is important so that a user is identified to access a protected area. Some ,ind of user information( such as a credit card number( must be transmitted confidentially to the application and some ,ind of user administrations must be present for rowin number of users. -nce the petstore application re0uirements are satisfied we application and thus discuss the architectural details. 8.8 M*d!( Vi!@ C*ntr*((!r Ar.hit!.t$r!: o on to desi nin the

The PetStore application is based on the Model :iew ;ontroller $rchitecture. This ,ind of $rchitecture separates data presentation( data representation( and application behavior. The architecture consists of three componentsG the model( the view and the controller. The model encapsulates the core data and business functionality of the application. The view encapsulates the tas, of displayin the information to the user i.e. data presentation. "ach view has an associated controller( which encapsulates the interaction of the user with the system( and abstracts the system behavior by sendin service re0uests to the model for some operation on the data. &y separatin business and control lo ic from data presentation( the architecture provides the flexibility to handle such application complexity. The architecture provides flexibility( reusability( testability( extensibility( and clear desi n roles for application components >n the +ava petstore the model( view and controller represent( divisions for the entire petstore application. The model consists of a roup of classesG ;art"J&$ction( >nventory"J&( ;ustomer"J&( etc. ModelMana er.+ava provides the access to these classes. The view is provided by a browser( stand/alone applications that provide this functionality and interfaces to spreadsheet pro rams. The controller consists of MainServlet.+ava( which sends re0uests to other controller ob+ects such as Shoppin ;lient;ontroller.+ava( $dmin;lient;ontroller.+ava( and their related support classes.

1=

-i,$r! 8 M*d!( Vi!@ C*ntr*((!r Ar.hit!.t$r! )*r Ja a P!tst*r!

11

-i,$r! 9 S!+$!n.! Dia,ra& )*r M*d!( i!@ C*ntr*((!r

8.9 Str$.t$ra( Vi!@ Ar.hit!.t$r!: The petstore applications can be divided into smaller modules with each module supportin a particular action in the petstore. The division is based on the shoppin interaction scenarios( with various behavior captured durin the interaction or ani.ed as modules as scenarios correspond to the functionality provided by the application itself. The modular structure can be subdivided dependin upon the functionality of each sub modules. The modular view of the pet store application is reflected in the subpac,a es of PetStore application)s top/level pac,a e com.sun.j2ee.blueprints.petstore

MODU4ES

-UNCTIONA4ITY 1!

Si n-n ;ontrol Product ;atalo ;ustomer Mail Shoppin ;art

>t helps a user to si n on before accessin certain screens( and mana es the si n on process Sends re0uest to the business lo ic( controls screen flow( also coordinates component interactions. Eser can search for products and also shows the descriptions of the selected items This module helps in representin customer information li,e address( credit card info and contact info. Esed for sendin confirmation messa es to the user. >t trac,s the items a user has selected for purchase. Ta%(! " P!tst*r! M*d$(!s and th!ir -$n.ti*na(ity

-i,$r! 0 P!tst*r! -$n.ti*na( M*d$(! $ccordin to the input from the Eser interface( the ;ontrol module will either invo,e information usin the Product ;atalo Module or store information in the Si n-n(

15

;ustomer module. >n terms of the Model :iew architecture( the view element is the user component( the ;ontrol component and the interfaces manifest the operations of the controller and the databases where the information is stored provide the notion of Model. 8.9.7 M*d$(! D!si,ns and M*d$(! I&'(!&!ntati*n:

#e will discuss the various classes involved in each module of the Petstore $pplication and this will later be shown usin the class dia rams and their interactions. Si,nOn M*d$(!: The Si n-n module is controlled by the Si n-n@ilter component com.sun.+!ee.blueprints.si non.web. The user si non process is coordinated by the web application framewor, component Si n-n@ilter( which detects re0uests for protected pa es( si ns on users( and forwards re0uests to appropriate E7Cs.

Figure 6

Class Diagram for SignOn Module

14

&ased on the re0uest E7C( the 7e0uestProcessor creates and executes an FTMC action ;reateEserFTMC$ction that performs business lo ic. ;reateEserFTMC$ction returns an "vent ;reateEser"vent( which the 7e0uestProcessor passes to the "J&;ontrollerCocal"J& by way of the interface #eb;ontroller( implemented by class 3efault#eb;ontroller. $n "vent represents a command to be executed by the "J& controller which is a stateful session bean "J&;ontrollerCocal"J& extended by class Shoppin ;ontroller"J&. The "J& controller builds and evaluates an "J&$ction subclass ;reateEser"J&$ction that creates the Eser entity. Pr*d$.t Cata(*, M*d$(!:

Figure 7 Class Diagram for Product Catalog Module

1A

-ne accesses the catalo to retrieve information about catalo entries li,e cate ories( products( and items. The ;atalo Cocal interface is implemented by the ;atalo "J& stateless session bean( which is created by ;atalo CocalFome. The ;atalo Cocal methods return instances of ;ate ory( Product( and >tem( either individually or rouped by pa e. The ;atalo "J& ets its data from a ;atalo 3$- and ;atalo 3$- retrieves the data from a relational database usin J3&;. Sh*''in,Cart M*d$(!: -ne can use Shoppin ;artCocalFome to create a

Shoppin ;artCocal bean. Shoppin ;artCocal"J& contains methods that perform all of the operations and is the enterprise bean for the interface. The >mplementation of the Shoppin ;art Module consists of a stateless session bean which maintains a collection of ;art>tem ob+ects. The Session bean methods are used to add( remove( et( and update items( as well as to empty the cart.

Figure 8

Class Diagram for Shopping Cart Module

1D

Mai( M*d$(!: The Petstore and the order processin center communicate throu h the help of Java Messa in service. $lso Purchase orders are represented as BMC messa es. The purchase order is created usin #eb actions( "J& events and "J& actions. #hen a user first sends a purchase order the Si n-n module ensures he is already si ned in. The #eb $pplication @ramewor, then creates an -rderFTMC$ction and assembles it into an -rder"vent which is sent to the "J& Tier. The -rder"J&$ction builds and transmits a purchase order. The $ction class then creates a new purchase order. The Eni0ue6enerator"J& creates a uni0ue ordered>3 for the purchase order( sets the shippin ( bilin address and the credit card information. The -rder"J&$ction iterates over the collection of items in the shoppin cart( addin the items to the purchase order. >t then sends the purchase order to the order processin control. $syncSender "J& is a stateless session bean which handles loo,in up the messa in service and sendin the purchase order BMC document. Purchase-rderM3& is a messa e/driven bean which receives the purchase order messa e

Figure 9

Class Diagram for Mail Module 19

C$st*&!r M*d$(!: The customer module is implemented as a collection of entity beans. The reason for choosin the entity beans over the +ava classes comes from the fact that the entity beans combine the benefits of enterprise beans with better performance to that of +ava classes. $lso very little code was necessary to create the entity beans( because the "J& container mana es the persistence of attributes and relationships >t also helps in simplifyin the desi n. #e now represent the dia ram representin the entity bean which trac,s the customer data li,e his account information( credit card information etc. The customer module is separate from the user si non module.

Figure 10

Class Diagram for Customer Module

C*ntr*( M*d$(!: The ;ontrol Module consists of the #eb $pplication @ramewor, and the files and the classes that extend the framewor,. The main function of ;ontrol Module is to coordinate the actions of the other modules. The user or a client only interacts with

1<

the control module. >n accordance with the J!ee &lueprints( the petstore application uses of a #eb $pplication @ramewor,. The main functions of the #eb $pplication @ramewor, are G @ilter client re0uest and provide services li,e security( lo response encodin in etc. The pet store

uses two such servlet filtersG "ncodin @ilter( which ensures that re0uest and matchI and Si n-n@ilter( which enforces security and performs user si non. The @ront ;ontroller servlet( MainServlet.+ava processes all re0uests comin into for the website. >t handles re0uest dispatch( screen flow( and view eneration.. Map each re0uest to Ftml $ctions which implements the re0uested service. $n FTMC action is a developer/defined class implementin interface com.sun.+!ee.blueprints.waf.controller.web.action.FTMC$ction( that performs #eb/tier business operations. "ach time the 7e0uestProcessor receives a re0uest( it uses the E7C to loo, up the correspondin FTMC action class in the re0uest map( creates an instance of that class( and executes the action by invo,in the actions perform method. The FTMC action is implemented usin the interface FTMC$ction havin the followin methods / public void doStart(FttpServlet7e0uest re0) which initiali.es the action( public "vent void perform(FttpServlet7e0uest re0) throws FTMC$ction"xception which performs the actions business function and public void do"nd(FttpServlet7e0uest re0( "vent7esponse evr) which is called only if perform does not throw an exception $fter "xecutin the Ftml $ction if an "J& event is returned which re0uests operations in the "J& tier. To access the "J& tier( petstore defines two classesG an "vent( implementin interface com.sun.+!ee.blueprints.waf.event."vent and an "J&$ction interface com.sun.+!ee.blueprints.waf.controller.e+b.action. "J&$ction $fter executin the business lo ic #eb $pplication @ramewor, selects the Jext view to display based on the current view. $ developer can pro rammatically determine the next screen to display usin a #eb $pplication @ramewor, screen flow handler com.sun.+!ee.blueprints.waf.controller.web.flow.@lowFandler.com.

1?

The #eb $pplication @ramewor, #$@ specifies the screen flow map and the re0uest map in a sin le file( mappin s.xml. $ url/mappin perform in response to a particular re0uest E7C. 6enerates the selected view and ives it to the client. element in the mappin s.xml file defines both the next screen to display and the action to

-i,$r! 77 C*ntr*( M*d$(! = 2!% A''(i.ati*n -ra&!@*r3

!=

8.9." Entity B!an And S!ssi*n B!an C(ass Dia,ra&s Entity B!ans:

-i,$r! 7" C(ass Dia,ra& )*r Entity B!ans

Entity B!an ;ustomer"J& $ccount"J&

-$n.ti*na(ity Trac,s customer id( account( and profile Trac,s account status( credit card( and contact info

;ontact>nfo"J& Trac,s family and user name( email( and address ;redit;ard"J& $ddress"J& Eser"J& Trac,s card number( card type( and expiration date Trac,s lines of street address( state( .ip code( and country Trac,s a user name and password

!1

;ounter"J&

Esed only by Eni0ue>d6enerator"J& to mana e series of uni0ue numbers Ta%(! 8 Entity B!an )*r th! A''(i.ati*n

S!ssi*n B!ans:

-i,$r! 78 C(ass Dia,ra& )*r S!ssi*n %!ans

S!ssi*n B!an $ssyncSender"J&

-$n.ti*na(ity ;onverts shoppin cart contents and customer data into an BMC messa e representin an order( and sends the messa e to the -rder Processin ;enter

;atalo "J& Shoppin ;art"J& Shoppin ;ontroller"J&

Provides an interface to the catalo Maintains the contents of users virtual shoppin cart Provides access to the Shoppin ;lient @aKade

!!

Shoppin ;lient@acade"J& Provides unified access to customer( shoppin cart( and user id Si n-n"J& Eni0ueid6enerator"J& ;reates and authenticates system use ;reates lobally uni0ue ob+ect identifiers

Ta%(! 9 S!ssi*n B!ans )*r th! A''(i.ati*n 9 P!tst*r! I&'(!&!ntati*n: The Petstore application was implemented on the Sun J!ee 1.4 $pplication Server with pointbase 4.A database server as the default database for the application. The pointbase database server includes a prepopulated database containin the tables and data re0uired by the petstore applications. @or recompile( reassemble and redeploy the petstore we ma,e use of build.xml that uses the Java based $nt build facility. The build.xml file can define various tar ets that are used to compile and assemble the application for e. . it compiles all +ava source code( assembles the ear and war files and deploys the full application. 9.7 Pa,! -(*@ Dia,ra&:

!5

-i,$r! 79 Pa,! -(*@ Dia,ra& 9.7.7 Pa,! S.r!!nsh*tsG

!4

-i,$r! 70 S.r!!n sh*t r!'r!s!ntin, H*&! )*r '!tst*r!

-i,$r! 7: S.r!!n sh*t r!'r!s!ntin, Cat!,*ry S.r!!n )*r '!tst*r!

!A

-i,$r! 7; S.r!!n Sh*t r!'r!s!ntin, Pr*d$.t It!&s )*r '!tst*r!

-i,$r! 7< S.r!!n sh*t r!'r!s!ntin, Cart S.r!!n )*r '!tst*r!

!D

-i,$r! 7B S.r!!n sh*t r!'r!s!ntin, Si,nOn )*r '!tst*r!

-i,$r! "# S.r!!n sh*t r!'r!s!ntin, Bi((in, In)*r&ati*n )*r '!tst*r!

!9

-i,$r! "7 S.r!!n sh*t r!'r!s!ntin, Ord!r C*n)ir&ati*n )*r '!tst*r!

9." P!tst*r! JSP Pa,!s: The JSP pa es basically provide a user interface for the application. #e define a few JSP pa es used for the petstore.

index.+sp banner.+sp footer.+sp cart.+sp product.+sp item.+sp search.+sp Si non.+sp

The main pa e for the petstore Shows the banner on the top of the pa e. Shows the footer on the bottom pa e. Shows the shoppin cart 6ives the product for a cate ory 3isplays the items in the cate ory Shows a search form 3isplays the user si nin

!<

Si noff.+sp

3isplays the user si nout Ta%(! 0 JSP Pa,!s

9.8 P!tst*r! CM4 -i(!s:

application.xml mappin s.xml screendefination.xml web.xml

deployment descriptor for the petstore application helps in mappin the petstore screen flow defines the screen for "n lish deployment descriptor for the petstore #eb Tier components

si non/con@i ure.xml Populate/ET@<.xml PopulateSHC.xml

confi ures the si non filter helps in populatin the database cloudscape 8 oracle s0l command to create sample database. Ta%(! : CM4 -i(!s

0. T!stin,: 0.7 Unit T!stin,: Enit testin involves execution of the unit test cases to evaluate implemented subpro ram units( and trac,in and resolvin unit/level errors. This is accomplished as subpro ram units are developed( and before they are inte rated into lar er components and pro rams units. "ach module is tested alone in an attempt to discover any errors in its code. >n the +ava petstore each of the +ava or the +sp pa es are unit tested usin $ppPerfect testin tool. 3urin Enit Testin .+ava files( the JEnit framewor, is used and for .+sp files( the FttpEnit framewor, is used. #e tested the cart.+sp file for the +ava petstore. The tool !?

allows you to specify details of the Test ;lasses and also lets you select the various Test;ase options. To enerate test cases we manually navi ate to the pa e in a browser. The tool is able the necessary Fttp re0uest and response ob+ects needed to unit test the pa e. >f error code is detected in any of the responses it is displayed as a failed test case in the 7esults tab. >f there are any failed assertions in the test( it will be displayed a ainst the testMethod of the failed testclass. 0." Ja a Pr*)i(in,: Java Profilin provides a full view of the petstore application and its environment and helps in better understandin count and ;PE usa e. 0.".7 CPU Pr*)i(in,: the application)s profile. Testin the petstore with the profiler shows us various profilin metrics such as heap memory usa e( ob+ect instance

;PE Profilin helps to understand the brea,down of how time is used by the ;PE when an action is processed. -ther results usin the tool include details on all classes and their methods( includin the number of invocations( ;PE time consumed( details on how the application)s processin brea,s down for ;PE usa e( identifyin classes and methods that ta,e the bul, of the processin time. 0."." M!&*ry Pr*)i(in,:

The Feap Memory Profilin helps in detailed information about the profiled J:M)s heap memory. The results for this type of profilin involves ;hart displayin the current and maximum memory si.e( a chart of count of live ob+ects over time in the application( charts are displayed showin details on each call to the 6arba e collector and Possible memory lea,s in the application.

0.8 4*ad T!stin,:

5=

Coad testin can identify failures involvin scalability re0uirements as well as involvin how the performance of a system varies under normal conditions of utili.ation e ( as the load increases and becomes heavy.

E a($ati*ns And Enhan.!&!nts:

:.7 T!stin, R!s$(ts: Unit T!stin,: #e tested the cart.+sp file for the +ava petstore. To enerate test cases we manually navi ate to the pa e in a browser. The tool is able the necessary Fttp re0uest and response ob+ects needed to unit test the pa e. >f error code is detected in any of the responses it is displayed as a failed test case in the 7esults tab. >f there are any failed assertions in the test( it will be displayed a ainst the testMethod of the failed testclass. #e filter out the methods to be tested based on their access specifiers. @or example( Private methods are called from other methods of the same classI hence we choose to not test them initially.

51

-i,$r! "" t!stM!th*dDE ,!n!rat!d )*r t!stin, .art.1s' This results obtained can be summari.ed by analy.in the @i ure below. Server Pa es shows the number and percenta e of server pa es whose Test ;ases failed and is shown in the @i ure as a hori.ontal bar raph.The table in shows the followin columnsG

@ile Jame: This is the name of the JSP file i.e. cart.+sp. Test ;lasses: The number of Test ;lasses created for cart.+sp i.e. 1 Test ;ases: The number of Test ;ases enerated for the cart.+sp i.e. 1

5!

-i,$r! "8 R!s$(ts )*r Unit T!st M!&*ry Pr*)i(in,G The Memory chart below shows how much of the total memory is allocated on the heap. @i ure is plotted with the time stamp on the B/axis and memory used by the petstore application (in Lilobytes) on the M/axis. The total si.e of the heap is also plotted a ainst the M/axis to provide an indication of the amount of memory bein consumed. The @i ure !! below indicates that the memory usa e of the petstore application is within safe levels as the memory usa e within the total memory constraints.

55

-i,$r! "9 5ra'h )*r H!a' M!&*ry Usa,!

-i,$r! "0 5ra'h sh*@in, th! n$&%!r *) O%1!.ts A Array .r!at!d The @i ure !5 ives an idea of the number of ob+ects and arrays bein created by the petstore application at any iven point in time. The @i ure !5 is plotted with the time 54

stamp a ainst the number of ob+ects created by the application. >f the charts are risin steadily and there is no decline( it may indicate that the ob+ects and arrays created are not ettin arba e collected and there may be a memory lea,. #e were also able to detect some of the most heavily used ob+ects and the amount of memory that they are consumin . #e chose one of the such pac,a es com.sun.+!ee.blueprints.si non.web and were able to pull out information li,e the ;lasses present within them( number of Cive -b+ects( Si.e of the -b+ects( total number of -b+ects and total si.e of -b+ects in bytes( created for the petstore application.

-i,$r! ": R!s$(ts )*r M!&*ry Pr*)i(in,

&y chec,in the code of methods that have heavy allocations of ob+ects we can find ways to reduce or reuse the ob+ects that are bein created and thereby improve the speed and efficiency of the application. The first level of this tree shows the percenta e of total ob+ects allocated in the petstore application i.e. 1==N. The next level shows the total number of ob+ects that were allocated by that thread i.e 4 ob+ects. $t the next level we

5A

have nodes representin different pac,a es. This information is used to identify the proportion of memory utili.ed by each method in the runnin threads.

CPU Pr*)i(in,: The @i ure below shows us the number of times a method was invo,ed and the time it too, to execute the method as well as the time it too, to execute overall( includin execution of any procedures( or method calls.

-i,$r! "; R!s$(ts )*r CPU Pr*)i(in, 0.8 4*ad T!stin,:

5D

The @i ure below ives the details of the total hits of the total number of users i.e. 4A=. $ pie chart is used to depict the distribution of the number of hits that were executed as part of the selected pro+ect. Eser ;ount ;hart is used to depict the Eser ;ount at different points of time while runnin the test and is plotted with the Time on the B/axis and the Eser ;ount on the M/axis. 7esponse Time chart show the response time in milliseconds plotted a ainst time . Three values are plotted in the chart( that is Minimum is showed usin a reen line( whereas the Maximum is depicted by a red line and the avera e is plotted with a yellow line. Fit ;ount at 3ifferent TimesG $ bar chart is used to show the number of hits at various times while runnin the test. The chart is plotted with Time on the B/$xis and Fit ;ount on the M/$xis. Throu hput raph shows Time on the B/$xis and bytes received (in Lilobytes) on the M/$xis. This chart shows the bytes received at different times durin while the test was runnin .

-i,$r! "< R!s$(ts )*r th! 4*ad T!st :." O !ra(( E a($ati*n:

59

-n the positive side of thin s there are number of thin s to be learnt and evaluated from this case studyG The foremost would be to understand the Model :iew ;ontroller $rchitecture and how the use of such architecture would help us in buildin reliable scalable +!ee $pplications. The separation of 3ata presentation( representation and &uisness lo ic helps because in applications( the areas of the code that deal with the user interface (or data presentation) are more li,ely to have more fre0uent chan es( while the underlyin buisness lo ic mi ht have less or no chan es. Morover accordin to the divide in the architecture we can separate of the tas,s accordin to the s,ill set. The decomposition should result in a set of ob+ects that can be assi ned to various subteams based on their particular s,ills. This division of labor allows wor, on each ob+ect to proceed in parallel. @or e. . a person ood in raphic desi n will be better desi nin the view part of the architecture while an application developer is better off developin application. The Structural decomposition of the application accordin to their functionalities and decomposin an application into different modules( or classes( ma,es it easier for a developer to understand the application. This also helps for maintenance and modifiability of the application. $lso the modules are decoupled so that each module can be developed independent of the other. Modularity of an application has many advanta es includin ease of testin ( easier maintainability and chan eability( and also aids in reuse of code. $s J!ee is desi ned for multitier application with a client tier( #eb tier( "J& tier and the ">S tier. The #eb tier accesses the enterprise information system resources directly( or oes throu h an "J& tier. The decision depends on the functionality( complexity( and scalability re0uirements of the application. Since such re0uirements can chan e as the application evolves( one oal for the desi n is to ma,e it amenable to mi ration to an "J&/centric approach. "ase mi ration from #eb/centric to "J&/centric. This provides scalability( reliability( persistence( asynchronous communication( and declarative transaction and security control. the buisness lo ic of the

5<

Coo,in at the drawbac,s or the ne ative aspect of doin this case study isG The Petstore application is rather very complex application. 6oin throu h the code and ma,in sense of how the Petstore confirms to the Model :iew $rchitecture was really tou h and cumbersome. Moreover the Model :iew $rchitecture is a conceptual way of loo,in at the Petstore. >t claims of ivin reusability( testability and extensibility but not of the claims are well supported by their implementation methadoli ies. The Model :iew ;ontroller architecture moreover which they claim is the foundational architecture to build J!ee applications is somewhat outdated with M:; for strut based system bein introduced. >t is claimed that structural decomposition of the application helps in decouplin the modules and thus it can be developed individually. &ut the Petstore is a complex application and some of the modules are not mapped to ether even thou h they conform as the subpac,a e to the top pac,a e com.+!ee.blueprints.Petstore. The learnin curve itself for this type of a case study is 0uite hi h. Enderstandin the code and mappin them to the M:; architecture and further decomposin those to functional modules are difficult. The lac, of any performance oriented comparisons with applications developed on diffrent technolo ies ma,es the assumption difficult that the desi n patterns ive the best reliable( sacalable cross platform application The number of lines of code i.e. approximately 14!== lines of code ma,es the application real complex. The Petstore with same functionality has been implemented

:.8 Enhan.!&!nt :

5?

$lthou h the Java Petstore is the best architectural and desi n implementation for a J!ee $pplication its performance has been much in contention. $lthou h Sun Microsysytem claims that the Petstore $pplication is not built for showin any performance measures the fact remains that the best claimed architecture and the desi n indirectly points to some ,ind of results to show that Petstore performance is better than the applications developed in other technolo ies. -ne such enhancement to this case study would be to study the $rchitecture of .Jet Petshop which is a petstore implementation with same functionality as that of +ava petstore but implemented in Microsoft.Jet. >n the recent past there have been many papers with some claimin that .Jet implementation ives better performance than the Java Petstore. -ther claims includin made by -racle is that the newer version of +ava Petstore outperforms the performance of the .Jet version. Enderstandin and comparin the architecture and desi n of +ava Petstore and then runnin some performance tests to evaluate the performance statistic will help in better understandin which technolo y (.J"T or J!ee) is more customed to build reliable( scalable and robust #eb applications.

C*n.($si*ns:

This case study studied the recommended desi n oals for J!"" applications and covered the various architectural and desi n implementation for the Petstore application. The eneral implementation of the sample application i.e. Java PetStore was studied comparin it to the different desi n oals or patterns recommended in the Java &lueprints. The poor documentation( lac, of class dia rams and absence of a application framewor, led us to explain these in detail pertainin to the PetStore application. >n this case study we ma,e use of some concepts from the &lueprints 6uidelines and explain how the various architectural pattern li,e the M:; architecture help in buildin J!ee application. The ;lass 3ia rams were drawn accordin ;ontroller architecture correspondin to the relationship between different classes in a module. The conceptual representation of the Model :iew to the PetStore separates presentation( data representation and business lo ic( so that the module which are more li,ely to chan e are separated from the module which chan e less or do not chan e. Structural decomposition

4=

of the application to functional modules conform to the desi n oals and thus ma,e a complex application li,e PetStore with approximately 14!== lines of code more readable( maintainable and easier for a developer. The use of a #eb $pplication @ramewor, used in the control module helps in reuse and even security to the application and helps an end user who has to build a lar e complex system. The Java PetStore was not built to analy.e the performance rather it is a benchmar, to build web applications which conform to the best desi n and codin practices. $ccordin to the analysis of the Java Pet Store usin some of the testin methods performed in this case study there was a eneral perception that the performance of the application was ood in terms of its functionality( memory usa e and the load accommodated on the website. Moreover to et a real performance statistic would re0uire comparin the Java PetStore application build on different technolo ies. $ better way of analy.in the performance of the Petstore application would have certainly helped. There are some drawbac,s for this case study li,e the use of an old Model :iew ;ontroller architecture without the strut framewor,( the complexity of the code which has a hi h learnin curve and ma,es it difficult for structural decomposition of modules. @inally the claims by the Sun Microsystems that the 3esi n patterns and oals help a developer build scalable( reliable and cross platform application cannot be confirmed fully due to the lac, of actual implementation of such a web application durin the process of this case study but the discussion and advanta es of such an implementation is clear by discussin the various architectural and desi n issues covered in this case study.

< Bi%(*,ra'hy:

41

O1P Sun Microsystems( www.+ava.sun.com( 1??A/!==A O!P Java &lueprints Team( httpG**+ava.sun.com*reference*blueprints( $pril !==A O5P Java Petstore Source code( httpG**+ava.sun.com*+!ee**1.4*download.htmlQsamples( June !==A O4P 3. $lur( J. ;rupi 8 3. Mal,s(' Core J2EE Patterns( 1??D OAP ModelR:iewR;ontroller( httpG**+ava.sun.com*blueprints*patterns*+!eeSpatterns*modelSviewScontroller*( !==A ODP ;ore +!ee Patterns( httpG**+ava.sun.com*blueprints*core+!eepatterns*index.html( !==! O9P 3esi nin "nterprise $pplications with the J!"" Platform( httpG**+ava.sun.com*blueprints* uidelines*desi nin SenterpriseSapplicationsS!e* ( !==A O<P Java Pet Store Sample $pplication >mplements ;ore J!"" Patterns httpG**+ava.sun.com*blueprints*patterns*catalo .html( !==A O?P J2EE vs. Microsoft.NET -A comparison of building XML-based web services ttp!""www.t eserverside.com"articles"article.tss#l$J2EE-vs%&TNET' 2(() O1=P &rass( ;lements and La.man( $ddison #esley( %Software $rchitecture in Practice'( 1??< O11P $ppPerfect 3evSuite A.= Testin Tool( httpG**www.appperfect.com*products*devsuite*index.html( !==!/!==A O1!P $ppPerfect 3evSuite A.= Tutorial( httpG**www.appperfect.com*support*devsuitetutorial.html( !==!/!==A O15P openM3B*"xample.Petstore $P> 1.5( htt':FF@@@.*'!n&d>.*r,Fd*.$&!ntsF'!tst*r!F7.8F1a aFind!>.ht&(( !==5

4!

Los dueos y gerentes de negocios necesitan tener informacin financiera actualizada para tomar las decisiones correspondientes sobre sus futuras operaciones. La informacin financiera de un negocio se encuentra registrada en las cuentas del mayor. Sin embargo, las transacciones que ocurren durante el perodo fiscal alteran los saldos de estas cuentas. Los cambios deben reportarse peridicamente en los estados financieros. En el complejo mundo de los negocios, hoy en da caracterizado por el proceso de globalizacin en las empresas, la informacin financiera cumple un rol muy importante al producir datosindispensables para la administracin y el desarrollo del sistema econmico. La contabilidad es una disciplina del conocimiento humano que permite preparar informacin decar cter general sobre la entidad econmica. Esta informacin es mostrada por los estados financieros. La e!presin "estados financieros" comprende# $alance general, estado de ganancias y p%rdidas, estado de cambios en el patrimonio neto, estado de flujos de efecti&o 'E(E), notas, otros estados y material e!plicati&o, que se identifica como parte de los estados financieros. Las caractersticas fundamentales que debe tener la informacin financiera son utilidad y confiabilidad. La utilidad, como caracterstica de la informacin financiera, es la cualidad de adecuar %sta al propsito de los usuarios, entre los que se encuentran los accionistas, los in&ersionistas, los trabajadores, los pro&eedores, los acreedores, el gobierno y, en general, la sociedad. La confiabilidad de los estados financieros refleja la &eracidad de lo que sucede en la empresa.

I. ESTADOS FINANCIEROS Estados financieros que presenta a pesos constantes los recursos generados o utilidades en la operacin, los principales cambios ocurridos en laestructura financiera de la entidad y su reflejo final en el efecti&o e in&ersiones temporales a tra&%s de un periodo determinado. La e!presin "pesos constantes", representa pesos del poder adquisiti&o a la fecha del balance general '*ltimo ejercicio reportado trat ndose de estados financieros comparati&os). +lgunos estados financieros 1.1 ESTADO FINANCIERO PROYECTADO Estado financiero a una fecha o periodo futuro, basado en c lculos estimati&os de transacciones que a*n no se han realizado, es un estado estimado queacompaa frecuentemente a un presupuesto, un estado proforma.

45

44