Chianese-Danielle.doc
Upcoming SlideShare
Loading in...5
×
 

Chianese-Danielle.doc

on

  • 570 views

 

Statistics

Views

Total Views
570
Views on SlideShare
570
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Chianese-Danielle.doc Chianese-Danielle.doc Document Transcript

  • Clarkson University Adding the model component and a credit card extension to IBM's "SunSet Books" workload application utilizing the platform independent J2EE standards and the Model-View-Controller architecture A Thesis by Danielle Chianese Department of Mathematics and Computer Science Submitted in partial fulfillment of the requirements for a Bachelor of Science Degree with University Honors May 2004 Accepted by the Honors Program ______________________________ Advisor Date ______________________________ Honors Reader Date ______________________________ Honors Director Date
  • Adding the model component and a credit card extension to IBM's "SunSet Books" workload application utilizing the platform independent J2EE standards and the Model-View-Controller architecture Written by Danielle Chianese Advised by Douglas J. Macintosh Assistant Professor of Software Engineering Clarkson University
  • Acknowledgements Many thanks go out to Professor Douglas Macintosh, my advisor who continually motivated me to stay on track. I would also like to thank Professor David Craig and Professor Hayley Shen for their patience. Thanks also go out to all the IBMers who helped make this thesis possible: my manager Greg Lacey, and all our technical advisors, Loraine Arnold, Jim Stutzman, Tom Sirc, and Karen Smolar. Abstract Adding the model component and a credit card extension to IBM's "SunSet Books" workload application utilizing the platform independent J2EE
  • standards and the Model-View-Controller architecture by Danielle Chianese A thesis is presented on the design and implementation of the model portion of a workload application for IBM Corporation's zSeries Integrated Testing Department. This application is compliant to the Java 2 Enterprise Edition standards and the Model-View- Controller architecture, and is in the format of an online bookstore. In addition, the design and implementation of a credit card workload application was also attempted. To accomplish this, IBM's WebSphere Application Developer was used. A facade between the controller and model aspect of the application was written as an Enterprise Java session bean. The model itself was written as two Enterprise Java entity beans, both of which accessed IBM's DB2 database, then returned the information via the facade back to the controller. Furthermore, as this is a testing application, three levels of tracing were implemented for debugging purposes. In the end, the entire workload application, called SunSet Books, was completed and has now been incorporated into IBM's zSeries Integrated Testing Department's testing suite. While the design of the credit card application and most of the implementation was completed, time did not permit for the proper testing necessary to finish the application. TABLE OF CONTENTS Chapter 1 - Introduction ............................................................................. 1 1.1 z/Series System Integration Test ..................................................................... 1 1.2 Previous SunSet Books application ................................................................ 2 1.3 Hypothesis ........................................................................................................ 3 Chapter 2 - Background ............................................................................. 4
  • 2.1 J2EE technology overview ............................................................................. 4 2.2 MVC architecture ............................................................................................ 5 2.2.1 The model ........................................................................................ 5 2.2.2 The view ........................................................................................... 5 2.2.3 The controller ................................................................................... 6 2.3 Tiers ................................................................................................................ 7 2.4 Java Database Connectivity ............................................................................ 8 2.5 Java Naming and Directory Interface ............................................................. 9 2.6 JavaServer Pages ........................................................................................... 10 2.7 Servlets .......................................................................................................... 10 2.8 Enterprise Java Beans ................................................................................... 11 2.8.1 Message-driven beans ..................................................................... 11 2.8.2 Session beans ................................................................................. 12 2.8.3 Entity beans .................................................................................... 12 2.9 Data Transfer Objects ................................................................................... 14 Chapter 3 - Project Requirements ........................................................... 15 3.1 Specifications ................................................................................................ 15 3.2 High level design .......................................................................................... 16 Chapter 4 - Implementation Details of Sunset Books Model ................ 19 4.1 The view ........................................................................................................ 19 4.2 The controller ................................................................................................ 20 4.3 The model ..................................................................................................... 21 Chapter 5 - Implementation Details of Credit Card Extension ............ 27 5.1 Overview ....................................................................................................... 27 5.2 Database table setup ...................................................................................... 27 5.3 Program flow ............................................................................................... 28 Chapter 6 - Development Environment .................................................. 32 6.1 WebSphere Studio Application Developer ................................................... 32 Chapter 7 - Tracing ................................................................................... 34 7.1 Tracing .......................................................................................................... 34 Chapter 8 - Discussion and Conclusion ................................................... 36 8.1 IBM's intended use ........................................................................................ 36 8.2 Further Development .................................................................................... 39 Literature Cited ......................................................................................... 40 References .................................................................................................. 41 LIST OF FIGURES Figure 1: Members of BookBrowse class .......................................................................... 3 Figure 2: Example of J2EE architecture (containers) ........................................................ 4 Figure 3: Model View Controller example ........................................................................ 7 Figure 4: Example of J2EE architecture (tiers) .................................................................. 8 Figure 5: Connecting to a Data Source ............................................................................. 9 Figure 6: EJB Types ........................................................................................................ 11 Figure 7: View of the EJB architecture (local and remote) ............................................ 14 Figure 8: Application component model and workflow ................................................. 18 Figure 9: Sunset Books view component ........................................................................ 20 Figure 10: The controller component ............................................................................. 21
  • Figure 11: The model component ................................................................................... 22 Figure 12: General form of SQL statements ................................................................... 25 Figure 13: PETCard database tables ............................................................................... 28 Figure 14: PETCard database access diagram ................................................................ 30 Figure 15: Example of tracing ........................................................................................ 34 Figure 16: Index page of application .............................................................................. 37 Figure 17: Searching for a book ...................................................................................... 37 Figure 18: Search results for “King” .............................................................................. 38 Figure 19: A Detail for “King” .......................................................................................
  • Chapter 1: Introduction 1.1 z/Series System Integration Test IBM’s zSeries operating system server testing division is always looking for new workload applications to test the limits of their software/machine and to make sure they have not "broken" any old code in a new operating system release. Each release goes through four stages of testing: unit test, function test, system test, and system integration test. System Integration Test is the department that puts the product through the last series of tests before shipment. These tests stress various interactive combinations of the common software packages combining IBM's DB2 database, WebSphere Application Server (WAS), and WebSphere Message Queuing (MQ). The department attempts to find problems before users can, and recreates problems that users have found. They write workload applications that are as similar as possible to a real client situation. These workload applications should be flexible in how much they stress each of IBM's software applications. This stress should vary not only in intensity but also in variety. Errors need to be logged along with any known causes. Among their current applications is an online bookstore application called Sunset Books, which can have a user browse for books and place and cancel orders. This simulates a high demand book retailer's website. This application currently strains the limits of the server with a workload by having thousands, or even hundreds of thousands, of “users” using the bookstore’s services at once. It is currently written to test WebSphere, DB2, and WebSphere MQ. However, the structure of the old bookstore is neither scalable nor portable, and is not itself J2EE compliant. This project completely rewrote the bookstore to be J2EE compliant, which
  • now allows for both scalability and portability, and continues along previous lines to constantly improve the quality of IBM's testing product. In addition, a component to add credit card functionality to Sunset Books was also designed and developed. However, there was not enough time for full testing. This credit card application is also be J2EE compliant and is fully modular, with the ability to be reused in other applications. 1.2 Previous SunSet Books application The old bookstore application was written over several summers by a collection of interns. It also had a web interface, but was not J2EE compliant. Instead of being split into a model, view, and controller, it was written in one large PETservlet class that took care of all these of these pieces. This made it difficult to add new features or modify old ones. For example, the old bookstore only did a search on author. It would have been complicated to add a similar search for title (see Figure 1).
  • Figure 1: Members of BookBrowse class 1.3 Hypothesis The new Sunset Books bookstore application will be more scalable and easier to maintain and extend than the previous version. This is because following the J2EE standard provides for separation of components, separation of implementation and interface, and greater modularity. Chapter 2: Background
  • 2.1 J2EE technology overview J2EE stands for the Java 2 Enterprise Edition. It is an industry standard for developing multi-tier enterprise applications (see Figure 2) [8]. Because it is a standard, it ensures the portability of the applications that follow it across many systems and platforms. The standard includes both complete specifications and compliance tests. It calls for object oriented modular components, which allows for easy scalability and maintainability. Applet HTTP Container SSL Apple t Web Container EJB Container EJB JS Servl et J2SE WebSphere JTA JMS JTA JMS Java JNDI Java JNDI Mail Mail JDBC JDBC Application RMI- RMI- Client IIOP IIOP Application HTTP Container Client SSL J2SE J2SE JMS JAAS JAXP JDBC Database J2SE Figure 2: Example of J2EE architecture (containers) [3] 2.2 MVC architecture By applying the Model-View-Controller (MVC) architecture to a J2EE application, you separate core data access functionality from the presentation and control logic that uses this functionality (see Figure 3). Such separation allows multiple views to share the same enterprise data model, which makes supporting multiple clients easier to
  • implement, test, extend on, and maintain. Each of the three components can reside on separate systems. This cross-platform communication means that the components can be located in separate buildings, or even separate countries, and still perform together. This allows for more efficient use of resources. Another benefit of this architecture is that the components can interact among themselves with no need to know the implementation of the other components. In fact, this separation of components allows for the division of developer responsibilities and minimal code duplication, which promotes faster production. 2.2.1 The model The model represents enterprise data and the business logic that governs access to, and updates of, this data. The business logic is represented by Enterprise Java Beans (EJBs). This exposes the application functionality. It encapsulates the application state and responds to state queries. The model is responsible for notifying the view of changes. It responds to requests from the controller to access or modify the data it represents. 2.2.2 The view In its basic form, the view is a web interface that the user sees. It usually takes the form of JavaServer Pages (JSPs). These webpages are a mixture of static html and Java function calls which dynamically provide data based on user requests. The view renders the contents of a model by accessing enterprise data through the model and specifying how that data should be presented. It requests updates from the models and sends user gestures to the controller. It allows the controller to select the view. It is the view's responsibility to maintain consistency in its presentation when the model changes.
  • 2.2.3 The controller The controller is the "middleman" which translates interactions with the view by the user requests understood by the model [15]. There is one controller for each functionality, and it takes the form of a servlet. These servlets use data transfer objects (DTOs) to pass information to and from the view and the model. They map user actions to model updates and select which view to respond to based on the last client action and the results of the corresponding model actions. Model Enterprise Java Beans Change State State Notification Change Query View View Selection Controller Java Server Pages Servlets User Gestures Method Invocations Events Figure 3: Model View Controller example [15]
  • 2.3 Tiers Another way of looking at the architecture is through tiers. Most applications have three tiers, although some have four (see Figure 4). The top tier is the client tier. It exists on the client machine. For a typical large web application similar to the one we are trying to emulate, the client would be a user at home on their personal computer, or perhaps someone in the workplace on a computer there. The client contains mostly applets and small scripts that are run on the user's machine. An optional tier is the web tier, which can include JSPs and servlets. Next is the business tier, which holds the EJBs. Lastly there is the Enterprise Information System tier, where the database is located. The enormous benefit to this tier architecture is that each tier can be worked on by separate people with no loss to efficiency, and they can be built and executed on separate platforms as well. This makes it easier to organize the implementation. The tier architecture allows each tier to be developed in different languages if necessary. For example, in the case of the Bookstore application, the top tier web interface is a JSP written in html, Java, and Javascript. The middle tier is servlets written in Java. The lowest tier consists of EJBs, and they are written in Java and execute SQL queries on the DB2 database. Sample J2EE Application Database Client and other Machines J2EE Server Machine servers Client Tier Web Tier Business Tier EIS Tier JSP Pages, Java Beans Database, Web Entity Servlets (optional) Legacy Browser Beans, Systems Session Web pages, Beans, applets, Message- Java Beans Driven Class Beans (optional)
  • Figure 4: Example of J2EE architecture (tiers) [16] 2.4 Java Database Connectivity Continuing in the spirit of portability, Java Database Connectivity (JDBC) allows a J2EE program to be written only once, but be able to connect to any type of database because it is vendor neutral [11]. This makes it both portable and versatile. To access a database, DML statements need to be executed from the host language. The JDBC standard provides the corresponding features to the Java language. In a web application, you can use it to make dynamic calls to databases from Java applications through the JDBC Application Program Interface (API), which uses standard network connections (see Figure 5). client client Application Application lookup lookup JNDI JNDI DataSourc DataSourc jdbc/nameofDB Naming Naming jdbc/nameofDB JDBC Driver ee Service Service JDBC Driver Database Database Figure 5: Connecting to a Data Source [11] To reduce database connection time, the EJB container maintains database connections in a JCBC connection pool to cache these connections so that they are
  • always available when the application needs them. When an EJB requests such a connection, its container gets one from this pool and assigns it to the bean. 2.5 Java Naming and Directory Interface Java Naming and Directory Interface (JNDI) is another platform-independent API specified in Java technology that provides naming and directory functionality to applications written in the Java programming language. Designed specifically for the Java platform, it uses Java's object model, which means that applications can store and retrieve named Java objects of any type. Naming and directory services play a fundamental in any kind of network by providing network-wide sharing of a variety of information about applications, machines, networks, services, and users. The JNDI provides methods for performing standard directory operations, such as associating attributes with objects and searching for objects using their attributes [12]. 2.6 JavaServer Pages JavaServer Pages (JSPs) are the "view" of the model-view-controller architecture. JSP technology allows for the mixing of static html with dynamic html [2]. In keeping with object oriented tradition, JSP technology separates the user interface from content generation and supports a reusable component-based design. This means web designers can change page layout without altering the dynamic content, and makes it faster and easier than ever to build web-based applications. In keeping with J2EE standards, JSPs are platform independent. The technology uses XML-like tags that encapsulate the logic that generates the content for the page. 2.7 Servlets
  • Like JSPs, servlets provide a component-based, platform-independent method for building web-based applications. A servlet is a Java programming language class used to extend the capabilities of servers that host applications accessed via a request-response programming model. Servlets are commonly used to extend the applications hosted by web servers. There are http-specific servlet classes defined by Java Servlet technology for this purpose. Servlets are good for web pages based on data submitted by a user, for pages where data changes frequently, and pages where the information is from a corporate database or other such source [2]. 2.8 Enterprise Java Beans An Enterprise JavaBean (EJB) is a server-side J2EE component that implements a business task or business entity [6]. There are three kinds, message-driven beans, session beans, and entity beans (see Figure 6). EJB Synchronous Asynchrono Entity Session Message-Driven CMP BMP Stateless Stateful Figure 6: EJB Types [5] 2.8.1 Message-driven beans Message-driven beans (MDBs) are stateless, server-side, transaction-aware components that listen for and process asynchronous messages delivered via the Java
  • Message Service (JMS) [5]. This means that a sender can send his messages, and does not have to wait for the receiver to receive it. This bean is responsible for processing messages, and can be modeled to represent tasks [4]. 2.8.2 Session beans A session bean is non-persistent enterprise bean created by a client and that normally exists only for the duration of a single client-server session. It represents behaviors associated with client sessions, and can be modeled to represent a task or workflow of a system, and to provide coordination of those activities. In our case, it could be a user book search. It is commonly used to implement the façade of EJB modules. This bean performs operations for the client. These objects can be either stateless or stateful. Stateful session beans keep track of the conversational state with a specific client, and therefore cannot be shared among clients. Stateless session beans maintain noconversational state, and are pooled by the container to be reused. If they do maintain state, then the EJB container manages this state if the object must be removed from memory. However, session bean objects must manage their own persistent data. This application will be using a stateless session bean. 2.8.3 Entity beans An entity bean, on the other hand, is modeled to represent business or domain specific concepts. They can be thought of as the “nouns” of the system [4]. Enterprise beans represent persistent data maintained in a database, and encapsulate operations on the data they represent. Both session beans and entity beans are accessed synchronously through a remote or local EJB interface method invocation. It is a synchronous invocation because there is a request, and then a blocking wait for the return. There are
  • two ways to handle entity bean persistence, bean-managed persistence (BMP) and container-managed persistence (CMP). [1]. In this application, container-managed persistence (CMP) is used. CMP has several advantages over BMP. The EJB container manages the relationships between the entity beans, and handles all database storage and retrieval calls. This way, the developer does not need to code the database access calls in the entity beans themselves. Instead, they must specify the settings in the entity bean's deployment descriptor. This allows both for faster development and greater portability across database servers. The containers are responsible for registering the unique lookup name in the JNDI namespace when the server starts up, and then binding the appropriate object type into the JNDI namespace. EJB containers create bean instances, manage pools of these instances, and destroy them as necessary. They also provide the means for a remote client to access components that live within them (see Figure 7). To have container-managed relationships between entity and session beans, the EJBs must reside in the same container and use the local interface capability rather than the remote interface capability. A bean uses a local interface if it wants to provide tight coupling with its clients inside the same Java Virtual Machine (such as another EJB) with Remote Remote View pass-by-reference semantics and expose its methods to other beans that reside within the Client same container. This also avoids the network overhead and performance limitations of a EJB EJB remote invocation, because in remote Home invocation, method arguments and return values are Object passed by value. This means that the complete objects have to be serialized and set over EJB Local the network to the remote party, which reconstructs them as new objects. So, a bean Home Local usually only uses a remote interface when it needs to interact with distributed clients Client EJB Componen EISs EJB t (such as a servlet) and expose its methods across the network tier [4]. Local Object Container Local View EJB Server Java Virtual Machine
  • Figure 7: View of the EJB architecture (local and remote) [4] 2.9 Data Transfer Objects Since we do not expose a remote interface to our entity beans, only the session bean data transfer objects (DTOs) limit inter-layer data sharing to serializable JavaBeans, therefore avoiding remote references. Chapter 3: Project Requirements 3.1 Specifications The goal of this software design and development project was to rewrite a software application to adhere to stricter standards and be scalable, portable, and maintainable. This application is currently used to test IBM proprietary software. The
  • new Sunset Books was written using the WebSphere Application Developer and built conforming to J2EE 1.3 standards and following the MVC architecture. The code needed to be flexible enough so that it does not need to get rewritten. If that had been necessary, the code would have needed to be recompiled. To detect the changes, the application server would need to be reset. This is not the only testing application being run on the zSeries test servers. If all such testing applications were repeatedly being recompiled and the servers constantly being restarted, the testing department could never test their operating system long enough to find defects. The application is run on a WebSphere Application Server (WAS) version 5.0. This transaction engine is perfect for such a use as an online bookstore, because it is high-performance and scalable. It is a J2EE compliant Web services-enabled application server that is capable of handling high volume secure transactions [7]. The front end are Java Server Pages version 1.2. These pass information to several servlets, which then forward requests to Enterprise Java Beans version 2.0. These EJBs use EJB Query Language to query the backend, which is a DB2 database version 7.2. IBM's DB2 7.2 has built-in support for Java based operating environments. It also has integration into WebSphere and its web services, and also supports message queuing technologies. It has cross-platform capabilities. It also has a very useful Control Center for easy database administration [13]. The application also uses WebSphere Message Queuing Service (MQ) to buy books. MQ is used to exchange information across different platforms. This helps enable our portability specification. It offers secure and reliable deliverability of messages, and ensures the data is delivered free from errors and safe from unauthorized access. It makes the best use of resources by dynamically distributing its workload. In this case, the bookstore application puts a buy message to a buy queue and waits to
  • receive confirmation. MQ's role in this is to transport that buy message to Webbuy, a C script which will then process the buy and return the looked-for confirmation via MQ. 3.2 High level design Sunset Books was split into three pieces corresponding to the three parts of the MVC architecture. These pieces are the model, the view, and the controller (see Figure 8). The whole application is a high demand online website for a bookstore. This represents the average client who would use the zSeries server and its z/OS operating system. The benefit of using the MVC architecture for this project means that the developers did not need to know the implementation of the other two components. They merely needed to agree on common interfaces between their respective components and then they could proceed with their own implementation. Later on, if the application needs to be extended or scaled larger, it can easily be done because of the modularity of the components of the project. Three programmers, including myself, were assigned to the project. We took advantage of the MVC architecture and each took one of the three components. Because of the modularity and separation of implementation of the J2EE standard, this was relatively easy to do and increased the speed of development. While all three components will be mentioned, this thesis focuses on the Model component's design and implementation. As seen in the figure below, when this application is run the first event that will occur is an HTTP request issued by the Web client to the server. This is in turn answered by a servlet in the controller component, when then extracts the parameters from the request. The controller passes the request on to the session EJB façade. This bean executes the necessary business logic by accessing the entity beans. It then creates and
  • DTO and populates it with the data returned by the entity beans, and returns it to the controller. The servlet in the controller sets this DTO as a request attribute and forwards it back to the appropriate JSP in the view. This JSP then accesses the DTO to build the user response, and returns the resultant HTML to the client. HTTP RMI/IIO Web Client 1 Control 2 Facade 3 5 4 Entity 7 View 6 DT Model O Web Module EJB Module Web Container EJB Container Application Server Figure 8: Application component model and workflow [4]
  • Chapter 4: Implementation Details of Sunset Books Model 4.1 The view The view (see Figure 9) is a website consisting of JSPs that encompass specific functionalities. The names are self-explanatory. Index.jsp is the home page for the project. From there the user can navigate to Help.jsp to receive hints on how to use the website, Reports.jsp to see a list of annual reports and links to the corresponding applet/html file, Results.jsp to see a list of top ten featured books, and Search.jsp to search for a book. Using Search.jsp, the user can search for a book by title, author, ISBN, category, or any category thereof. This will send them to Results.jsp, which will display the ISBN, author, title, category, and price of all the matching books. The books can be ordered by any of these categories. Once the user chooses a book to see information about, it will send them to Details.jsp. This will display the same information as Results.jsp, along with a second category, publisher, year, and price. From Details.jsp the user can order a book, which will send them to Cart.jsp and add the book to their "shopping cart." They can then return to Search.jsp to search for more books. They can also be able to "checkout." This will return Order.jsp with the order information from the WebBuy processing. With the modularity of J2EE, it would be
  • easy to add more JSPs so a user could login or use a credit card to buy a book without having to change the current structure of the view. Search.jsp Index.jsp Help.jsp Results.jsp Reports.jsp Details Cart.jsp Figure 9: Sunset Books view component 4.2 The controller The controller (see Figure 10) is the "traffic director" who receives requests from the view and forwards them to the model, and takes the returned information from the model and sends it to the view. It performs error checking on both the requests it receives from the view and the data it receives from the model. The view can only call the Action servlet within the controller. This helps keep the application modular, because to add additional functionality only code in the Action servlet would need to be modified. Calling only the Action servlet from the view is also good security, because users cannot see exactly what type of data retrieval is being used, and therefore cannot "hack" the system. This servlet then sends the information requests to the appropriate servlets. The Browse servlet gets the details and results of a book request from the model and passes it
  • to either Details.jsp or Results.jsp. FeaturedBooks servlet returns the top ten books to Results.jsp. The Buy servlet gets its data from the model and returns it to either Cart.jsp or Order.jsp. Order.jsp Cart.jsp Results.jsp Details.jsp Browser Action servlet Buy FeaturedBooks Browse servlet servlet servlet MQ EJBs Figure 10: The controller component 4.3 The model In this case, the model is an enterprise java session bean and two entity beans (see Figure 11). The model takes the forwarded requests from the controller by means of its session bean facade BookBrowseEJB. This is another case of separation of implementation, because the controller does not need to know how the model works, it just needs to know the interfaces allowable by the session bean. The facade provides a simple and unified interface to the complex model that lies behind it. This way, the dependencies between the model classes and its clients are reduced, which means more freedom to adapt to new requirements. Through this bean, either the results or details entity beans will be called, depending up on the request. These entity beans will retrieve the book data from the DB2 database and forward it back through the session bean to the controller. Only the three function calls getDetails(), getResults(), and FeaturedBooks() can be used.
  • Results Local Results BookBrowse Local EJB Home Featured Session Bean Servlet Book Results Browse Bean EJB Book Results and Browse Details Entity DB2 EJBHome Beans Book Browse Browse Servlet EJBBean DetailsLocal DetailsLocal Home Enterprise Information Web Tier EJB Tier System or Database Tier DetailsBean Figure 11: The model component EJBs work by querying a database using EJB QL (EJB Query Language), a query language similar to SQL. EJB QL statements are independent of database implementation because queries can be expressed at the entity attribute level instead of tables and columns, which are the underlying implementation in a relational database. These queries are defined in the deployment descriptor, then the EJB provider generates the SQL statements for the actual database access.
  • Initially, the user will look up a book by ISBN, author, title, category1, or any combination thereof, and choose how he would like the Results ordered (alphabetically by title or author, or price ascending or descending). This request will be sent down through the view and the controller to the session bean, and call getResults(). He will then get his ordered Results back in a data transfer object (DTO) called ResultsDTO. These results will contain a title, author, ISBN, and price. Then, based on these few pieces of information, he can choose to see the additional Details about the book. This will again be sent to the session bean as a request to getDetails(). These Details will contain not only the ISBN, author, title, and price, but also year of publication, both categories, and the publisher, and are returned to the view via DetailsDTO. Based on the Details of a book, the user could choose to purchase it, and the flow of information would then leave the model. It may seem ambiguous why we chose to split the entity returned into two entities, Results and Details. The benefit gained by not sending what could potentially be several thousand category1's, category2's, publishers, and years was big, especially considering that several hundred users would be doing this each second. Finally there was the last function call, FeaturedBooks. The purpose of this was to have an added feature on the website, just as a real online bookstore may have a top bestseller list. We implemented it by passing the function a year and how many results we wanted. We temporarily hardcoded it for the current year and ten Results. One interesting facet of this feature was that since we were searching by year, we needed to be able to access the year field in the database. However, only the Details bean could do that. Therefore, we used the Details entity bean to get the information, then parsed out only the information we needed to put into the ResultsDTO. Now that the data the searched for has been acquired, we need to present it to the viewer. The next stage is formatting the output. If the user searched for author, they
  • probably want it displayed alphabetically by author. Or maybe they searched for title, but want it listed in ascending price order. Regardless, we needed to make a decision about where this was done. A real client application would want to reduce the load on the server as much as possible. Therefore, it did not make sense to send not only the requested data, but the orderby category as well, and then order the data on the server. With thousands of browse requests, this increased need for resources would add up to an unacceptable and unnecessary amount. It therefore made sense to do it on the backend before sending the ordered information back to the view. Ordinary SQL statements that query a database follow a specific format (see Figure 12). Conveniently, there's an ORDERBY clause that would allow us to choose what we wanted the resulting information ordered by, and in which direction it would be ordered (ascending or descending). However, EJB QL follows EJB 2.0 specifications, which did not have an ORDERBY clause. This meant that we could not do the ordering within the database. This was unfortunate for two reasons: it would have been an added stress on DB2, and it probably would have been faster than anything we wrote on our own. Select a1, a2, … an From r1, r2, … rm Where P [order by …] [group by…] [having…] Figure 12: General form of SQL statements Since using ORDERBY was out of the question, we had to decide where to order the information. As I stated before, it reduced the server load to keep the ordering in the
  • backend. So we chose to order it after we retrieved the information from the database, but while it was still in the model component and before it was passed up to the view. I wrote several functions in session bean to order the information based on which category they chose to order the data on. As necessary (as in the case of more than one book with the same author), a secondary ordering by ISBN was imposed. This was made possible by implementing the Comparator class to suit the variable requirements. Only after that was the information passed from the model to the view. There was another reason for keeping the ordering in the model component. Later on, IBM would upgrade to using the EJB 2.1 specifications, which did include an ordering clause. They could then choose whether to continue to order the data in the model component, or change to ordering in the database. Since either way the information passed to the view would be ordered, this kept the interfaces between the view and model the same no matter how the internal logic was conducted. This kept the model modular, which was in keeping with the J2EE standards. Once the data was ordered, we had to decide how to display it to the user. While this is normally completely taken care of by the view, we had to consider a few things ahead of time. You may search for "cat" on Google and get 45 million results, but Google will only display the first ten until you choose to see more. This is for two reasons. The user will probably not want to look at more than the ten displayed results, so this way they do not waste their time. Secondly, the difference in the load on the server for ten results, and for 45 million results, is tremendous. Multiply that by the thousands of users searching for things each second and you will quickly understand why they display ten results at a time. Sunset Books had the same conceptual problem. A realistic application would want to limit their server load, and they would also want to limit their displayed results to a reasonable amount. Therefore, we choose to make the amount displayed variable. We then set the variable to 25.
  • While this seems to be only a view problem, the necessary implementation takes place in the model. Sending the first 25 results is easy, however, if the user wants to see the next page of the results, the model needs to fetch results 26-50, and not resend 1-25. We solved this by keeping track of which section of results to display, and then parse out the correct Results to display to the user. Chapter 5: Implementation Details of Credit Card Extension 5.1 Overview Once the main Bookstore program was finished, I began adding an extension. The ease of doing so was made possible by the fact that we had used J2EE standards. Now it was easy to add this completely modular extension. Not only that, but we have hopes to use this extension with other workload applications, such as IBM's "Travel Agency." This extension allowed for the books to be bought with credit cards. The basic idea is to have the "customer" attempt to purchase a book. His information, such as his name, credit card number, and expiration date, will be send to the credit card database, matched against that to verify his identity, then it will check to make sure this purchase will not put him over his credit limit. If both of these things are ok, the purchase will go
  • through. If not, the purchase will be rolled back and the customer will be notified of the reason why. 5.2 Database table setup Unlike the model component of the bookstore application, this application's database was not already in place, but instead would need to be written from scratch. The final database and its tables are shown below (see Figure 13). Customer Table Merchant Table Billable Customer Last Merchant Address Billable Customer ID Name ID ID PK PK FK Account Table Billable Account Credit Current Available Status Customer ID Limit Balance Credit ID PK FK Credit Card Table Name Card Account Valid Expiration On Status PIN ID ID From Date Card PK FK Transaction Table Card Account Merchant Transaction Return Transaction Timestamp ID ID ID Amount Code ID PK FK FK FK Transaction Authorization Type Code
  • Figure 13: PETCard database tables 5.3 Program flow Do transaction Credit transaction Check merchant identity (future implementation) Verify customer identity, parameters: customer name, transaction amount, card number, expiration date, merchant id Check that name, card number, and date match those in credit card table. Check that credit card status in table is ok If verified, If transaction type is charge, get approval Check account status Check credit rating Check that transaction amount will not cause balance to go over limit If approved (or if transaction type is credit), do transaction Charge balance (this would need to be flushed periodically) Change available credit Create transaction record Create new transaction id and add Add timestamp Add card id Add account id Add merchant id Add transaction type Return successful result Return result via MDB Within the credit card database, each main step of this algorithm touches a different table (see Figure 14). The merchant identity is verified through the merchant table, the customer identity is verified via the credit card table, the billable customer identity is gotten by the customer table, approval is found in the account table and is based on available credit, and the transaction record is recorded in the transaction table.
  • Entity Beans Verify merchant identity Merchant Message Driven Bean Verify customer identity CreditCard Make transaction Session Get billable customer Customer Bean DB2 Request transaction Get approval Account PETCardEJB Return request successful/failed Create transaction record Enterprise Transaction Information System or Database Tier Web Tier EJB Tier Figure 14: PETCard database access diagram To explain the tables in a little more detail, the merchant table is a future implementation that will verify that a merchant is valid and not someone trying to steal credit card numbers. The credit card table is where the customer's information that they sent (name, card number, and expiration date) are compared with the table's data to verify the customer's identity. The customer table billable customer verification can be explained thus- Many married couples, or a parent and child, will share a credit card and both names will be on it. This will check to see which of these names the transaction will be billed to. The account table contains information such as a credit card's limit and balance, and will therefore check and see if the customer has enough available balance to
  • be able to make the purchase. If the user's information passes all these tests, the transaction will go through and will be recorded in the transaction table. Chapter 6: Development Environment
  • 6.1 WebSphere Studio Application Developer WebSphere Studio Application Developer (WASD) was a very useful tool in this project. It is a development environment specifically designed to assist in writing J2EE applications. It was an excellent tool that made it easy to develop Java packages for both the business logic specific to my model component and also for the common code shared by all three components. It made the integration of the three components written by separate programmers easy to do by allowing for version control. It had its own built in test environment, complete with a test server so the application could be run on our own computers before actually being ported to the zSeries test servers. WASD also had an intuitive debugger to work with. What I considered the most important part of this developer was its ability to allow multiple developers to work on a project. It not only allowed for the easy addition of modules such as JAR files to an individual's portion of a project, but allowed for the easy addition of another developer's entire portion of a project as well. The developer had only to add the JAR files to the build path for their project or to the application path of the application server. Not only would it retain directory structure, but would also keep track of the current version of that portion. Below that was its ability to aid the individual developer. In the case of my EJBs, there was an intuitive graphical user interface (GUI) that, with a few clicks of the mouse, would set up the scaffolding for a basic enterprise java bean's code, after which I would fill in the business logic. It easily allowed for choosing the specification level, the type of bean (session or entity), its type of persistence, and adding methods and database queries. One fantastic component of the developer was the local history. This saved a copy of a file each time it is edited and saved. This allowed us to replace a current file with a previous edit or even restore a deleted file.
  • Once the code was written, it had to be compiled. This of course involved the debugger, since any syntax errors or linking problems would prevent the compilation from being successful. Like many visual working environments, it would detect an error, indicate where it was found, and attempt to diagnose the problem by listing possible problems/corrections. In order to debug the logic of the application, the debugger allowed you to control the execution of the program by setting breakpoints, suspending launches, stepping through the code, and examining the contents of variables. Now that the code compiled, it could be tested on the test server that was provided by the application developer. The test server was J2EE compliant. I found this to be the most convenient tool in the application developer. The best part about it was that it imitated the appearance of being deployed on a WebSphere Application Server without actually deploying the code, which is time consuming. Once I had my EJBs written, I would start the test server. This would allow me to test them without requiring me to write a front end to my portion of the application. Within this test server I could make requests from the database and test to see that my queries worked properly even with invalid or unexpected input. Because of this, integration with the other two components of the application was easier knowing that I had already tested my portion to the best of my ability. Chapter 7: Tracing 7.1 Tracing Tracing was an essential part of this project (see Figure 15). Since this was a workload application for a testing department, it meant that our application would be continually breaking the system. Because of this, the testers wanted the ability to see
  • exactly where our program had stopped, what it was doing when it stopped, and what values it was currently holding at the time. Figure 15: Example of tracing Tracing was also greatly helping in our own debugging process. While we were polishing our implementation and interfaces, we would use our tracing object to see what values were being passed and where the application may have stopped working correctly. Combined with the WSAD debugger, it was a powerful tool. To do our tracing, we created a BookStoreTestData object, which extended a basic TestData object. We included a WebAppTraceLogger object we called TRC. This trace object was created by IBM to assist in the development and debugging of their applications. Using it illustrates the modularity of Java and the ease of adding additional packages. The information it collected could be accessed remotely, which allowed the
  • information to be reported directly back to a user instead of being output to a logfile. This trace object had three error levels for its error messages. Level 1 was for critical errors where continuing was suspect. Level 2 was for serious errors, but recovery and/or continuation was expected. Level 3 was for likely errors or exceptions handled during normal operations. Using level 2 would also print out the level 1 error messages, and using level 3 would print out the level 1 and 2 error messages as well. Chapter 8: Discussion and Conclusion 8.1 IBM's intended use IBM will phase out usage of the old bookstore application with the new Sunset Books (see Figures 16, 17, 18, 19). Initially it will be run on the zSeries servers in the integrated testing department. There it will be run extensively to initially find any bugs in our workload application, and then in turn it will be used to find any bugs or deficiencies in the z/OS operating system, and particularly with the interfacing between and the capacities of MQ, DB2, and WebSphere. The original goal of the application was to expose bugs in the z/OS before the product reached the client. Not only does Sunset Books stress the various aspects of the
  • system, but the stress is variable. Maybe one day the department would like to focus on DB2, and in particular with a large number of one type of query, like browsing for a book. The next week, they may focus more on MQ and do a lot more buys of books. If they do happen to find a problem due to a bug, they can have it log one of the three levels of tracing to see where the problem is located and potential reasons why. Once the testing application is working well on the zSeries server, they hope to phase out the old bookstore on the pSeries server as well. This will be a true test to see if the application is platform independent. They will also be distributing the bookstore application across multiple systems to make sure that remote data exchange works well. The end goal is two-fold: to make testing the system easier, and to produce a higher quality product. Figure 16: Index page of application
  • Figure 17: Searching for a book Figure 18: Search results for “King”
  • Figure 19: A Detail for “King” 8.2 Further Development The beauty of using Java and the J2EE standard is that Sunset Books is a scalable application. Modular components can be added without affecting the structure and integrity of the existing application. The requirements for this application will be constantly changing, and it will need to be modified accordingly. For example, when the credit card application is finished, it can be easily added to Sunset Books with very few necessary modifications. In addition, because Java is an object oriented programming language, and through the use of WSAD it is easy to add small new features to the application, such as a different method of searching for books. Another common need to change the Sunset Books will be because of new versions of the applications it tests, along with new versions of the J2EE standards and components. For instance, currently when the session bean receives its book results or details, they are unordered and therefore must be ordered using java in the session bean. With the new EJB 2.1 specifications, we will be able to use the SQL statement "order by"
  • in the EJBQL. This means the ordering will be done in the database, rather than on the server. This will reduce the load on the server, making it able to handle more requests. The sorting will also probably be faster because Java is a rather slow language, as opposed to SQL in a database that is designed to execute such statements. Also, the testing department was thinking of upgrading to DB2 8.0, and the testing application needs to be able to integrate with the new database seamlessly. Literature Cited [1] Armstrong, Eric, et al. The J2EE 1.4 Tutorial. 31 Mar. 2004. Sun Microsystems. <http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html>. [2] A Tutorial on Java Servlets and Java Server Pages (JSP). 1999. <http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial>. [3] Bill Shanon, “Java 2 Platform Enterprise Edition Specifications, v1.4”, Sun Microsystems, California, 2002. [4] Brown, Ian, et al. WebSphere Studio Application Developer Version 5 Programming Guide. 3rd draft. N.p.: International Business Machines Corporation, 2003. [5] Enterprise JavaBean2.0 Specification Changes. Apr. 2001. Sun Microsystems. <http://java.sun.com/developer/technicalArticles/ebeans/ejb20/>. [6] Enterprise JavaBeans Technology. Sun Microsystems. <http://http://java.sun.com/products/ejb/>. "IBM Unveils New J2EE WebSphere." Computer Reseller News 1043 (2003): 98-103. [7] IBM WebSphere Application Server Family. IBM. <http://http://www-306.ibm.com/software/info1/websphere/index.jsp? tab=products/appserv>. [8] Java 2 Platform, Enterprise Edition (J2EE) Overview. Sun Microsystems. <http://java.sun.com/j2ee/overview.html>. [9] JavaServer Pages Technology. Sun Microsystems.
  • <http://http://java.sun.com/products/jsp/>. [10] Java Servlet Technology. Sun Microsystems. <http://http://java.sun.com/products/servlet/>. [11] JDBC Overview. Sun Microsystems. <http://http://java.sun.com/products/jdbc/overview.html>. [12] JNDI Overview. Sun Microsystems. <http://http://java.sun.com/products/jndi/overview.html>. [13] Jones, Jeff. The Big Picture: IBM DB2 Information Management Software and DB2 Universal Database. 26 Feb. 2004. IBM. <http://http://www-106.ibm.com/developerworks/db2/library/techarticle/0301jones/0301j on es.html>. [14] Model-View-Controller Architecture. 2001. Sun Microsystems. <http://www.dpi.ufv.br/downloads/j2ee/j2ee_kit/03_build_and_deploy/design_pattmodel _vie w_controller/index.htmlerns/>. [15] Ramachandran, Vijay. Design Patterns for Building Flexible and Maintainable J2EE Applications. Jan. 2002. Sun Microsystems. <http://java.sun.com/developer/technicalArticles/J2EE/despat/>. [16] Stefanie Bodoff, Dale Green, Kim Haase, Eric Jendrock, Monica Pawlan, Beth Stearns, “The J2EE Tutorial”, Addison-Wesley, Boston, 2002. References Bruce Eckel, “Thinking In Java”, MindView, Inc., 2002. IBM z/OS Integration Test: Parallel Sysplex Test Report Library. IBM. <http://www-1.ibm.com/servers/eserver/zseries/zos/integtst/library.html>. Sliwa, Carol. "Sun Says Java Will Support Key Web Services Standards." Computerworld 37.6 (2003): 12-16. <http://search.epnet.com/direct.asp?an=9148901 &db=mfh>.