J2EE Internet Store An Example of Building an Enterprise Web Application

Transcription

1 Javier Ramos Rodríguez J2EE Internet Store An Example of Building an Enterprise Web Application Bachelor s Thesis Information Technology May 2005

2 2 DESCRIPTION Date of the bachelor's thesis May 17, 2005 Author(s) Javier Ramos Rodríguez Degree programme and option Information Technology Name of the bachelor's thesis J2EE Internet Store: An example of building an enterprise web application. Abstract It is obvious that software development has change considerably in the past years. The machines have considerably increased their speed and telecommunications have grown exponentially in the last 15 years. Also, customer s requirements have increase in the past years and more complex and reliable software is required. The software development has to adapt to the new infrastructures; many tools and software patterns have appear to help developers to build software that adapts to both, technology and customers requirements. Probably the development of enterprise applications is the most complex task in software engineering. It requires the domain of various technologies, such as databases, transactions handling, distributed applications and Client/Server applications among others. Developers have to face several problems due to the size of the enterprise applications. With this diploma work I attempt to show and explain how to build enterprise applications using the J2EE platform. The idea is to talk about the platform and its technologies, explaning also some design concepts like design patterns. I tried to explain all the concepts the simplest way using a practical approach following a usual example: An Internet Store. First, I introduce the J2EE platform and all its technologies trying to summarize all the concepts the best way. Also, I talk about the design patterns used in the development of enterprise applications. In the second part, I explain the application trying to show all the concepts that were introduce before. Subject headings, (keywords) J2EE, Java, OOP, Struts, EJB, JDBC, XML, Design Patterns, Hibernate, Spring, Open Source, UML Pages Language URN 336 English Remarks, notes on appendices Mikkeli Polytechnic Tutor Supervisor: Reijo Vuohelainen Employer of the bachelor's thesis

3 3 List of figures Chapter 2: FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE Chapter 3: FIGURE FIGURE

4 4 Chapter 4: FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE

5 5 Chapter 5: FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE

6 FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE

7 7 Abbreviations API: Application Programming Interface ASP: Active Server Pages BMP: Bean Managed Persistence CGI: Common Gateway Interface script CMP: Container Managed Persistence COM: Component Object Model CORBA: Common Object Request Broker Architecture DAO: Data Access Object DB: Data Base LAMP: Linux+Apache+MySQL+PHP/Perl/Phyton DBMS: DataBase Management System DCE: Distributed Computing Environment DCOM: Distributed COM DNS: Domain Name System DTD: Document Type Definition EJB: Enterprise Java Bean EL: Expression Language EMF: Eclipse Modeling Framework FTP: File Transfer Protocol HTML: HyperText Markup Language IDL: Interface Description Language ISBN: International Standard Book Number J2EE: Java 2 Enterprise Edition J2ME: Java 2 Micro Edition J2SE: Java 2 Standard Edition JCA: Java Connector Architecture JCP: Java Community Process JDBC: Java DataBase Connectivity JDK: Java Development Kit JNDI: Java Naming and Directory Interface

8 8 JMS: Java Message Service JMX: Java Management Extensions JRE: Java Runtime Environment JSF: Java Server Faces JSP: JavaServer Page JSTL: JSP Standard Tag Library JTS: Java Transaction Service JVM: Java Virtual Machine LDAP: Lightweight Directory Access Protocol MVC: Model-View-Controller pattern NIS: Network Information Service ODBC: Open DataBase Connectivity OLE: Object Linking and Embedding OMG: Object Management Group OODB: Object Oriented DataBase OOP: Object Oriented Programming ORB: Object Request Broker ORPC: Object Remote Procedure Call PHP: Hypertext Preprocessor POJO: Plain Old Java Object RMI: Remote Method Invocation RPC: Remote Procedure Call SB: Session Bean SFSB: State Full Session Bean SGML: Standard Generalized Markup Language SLSB: State Less Session Bean SMTP: Simple Mail Transfer Protocol SOAP: Simple Object Access Protocol SQL: Structured Query Language SSI: Server-Side Include SSL: Secure Sockets Layer TCP: Transmission Control Protocol

9 9 UDP: User Datagram Protocol UI: User Interface UML: Unified Modeling Language UMTS: Universal Mobile Telecommunications System URL: Uniform Resource Locator VB: Visual Basic VO: Value Object WML: Wireless Markup Language WSDL: Web Services Description Language XML: EXtensible Markup Language

10 10 TABLE OF CONTENS Description... 2 List of figures... 3 Abbreviations... 7 PREFACE INTRODUCTION OPEN SOFTWARE SOLUTIONS ENTERPRISE ARCHITECTURE AND THE PRESENT PANORAMA LAMP CORBA NET J2EE JAVA 2 ENTERPRISE EDITION OVERVIEW J2EE DEFINITION MULTITIER ARCHITECTURE tier approach Multitier approach MAIN ARCHITECTURAL PATTERNS USED IN ENTERPRISE APPLICATIONS J2EE MODEL J2EE TECHNOLOGIES JDBC Types of JDBC technology drivers Establishing a connection Concurrence problems with the database XML DTDs SERVLETS JSP PAGES JSP Pages Overview JSP Use Language Syntax Directives Script Elements Comments Actions JavaBeans JSP example JSP Architecture...75

11 JSP vs. ASP Examples JSP Expression Language (EL) JAVA STANDARD TAG LIBRARY (JSTL) JAKARTA STRUTS MVC in web applications Servlet Front Controller pattern Model View Controller architecture using Struts Struts Example DISTRIBUTED APPLICATIONS Distributed Applications on Internet Intranet Applets Distributed Computation Environment (DCE) Distributed Component Object Model (DCOM) Common Object Request Broker Architecture (CORBA) Java Remote Method Invocation (RMI) Java RMI as a technology for development enterprise applications JAVA NAMING AND DIRECTORY INTERFACE (JNDI) JNDI Architecture ENTERPRISE JAVABEANS (EJB) EJB Architecture Distributed components Implicit or Declarative Middleware Physical situation transparency Local interfaces TYPES OF COMPONENTS Session Beans (SB) Entity Beans Message-Driven Beans J2EE EJB Structure EJB Operation J2EE vs..net Similarities between J2EE and.net Advantages of.net over J2EE Advantages of J2EE over.net The Future...144

12 12 3. NEW APPROACHES USING JAVA 2 PLATFORM MVC FRAMEWORKS JavaServer Faces (JSF) Spring Struts vs. JSF vs. Spring HIBERNATE Hibernate Structure Hibernate Overview Hibernate Features Hibernate Example DESIGN PATTERNS USUAL OOP DESIGN PATTERNS ENTERPRISE APPLICATIONS DESIGN PATTERNS Session Facade Business Delegate Service Locator Value Object Value Object (EJB) Data Access Object Page-by-Page Iterator Fast-Lane Reader CASE STUDY: J2EE INTERNET STORE MAIN DESCRIPTION Functional Requirements of the System Non-Functional Requirements of the System ARCHITECTURE Software Used USE CASE VIEW General Diagram User Registration Diagram User Authentication Product Visualization Product Searches Shopping Cart Administration

13 LOGICAL VIEW GLOBAL ARCHITECTURE Item Facade User Facade Util Facade Shopping Facade PACKAGE DESCRIPTIONS Package fi.mamk.jramos.j2ee.j2eestore.model.category.dao Package fi.mamk.jramos.j2ee.j2eestore.model.category.vo Package fi.mamk.jramos.j2ee.j2eestore.model.country.dao Package fi.mamk.jramos.j2ee.j2eestore.model.country.vo Package fi.mamk.jramos.j2ee.j2eestore.model.idegenerator.ejb Package fi.mamk.jramos.j2ee.j2eestore.model.item.dao Package fi.mamk.jramos.j2ee.j2eestore.model.item.vo Package fi.mamk.jramos.j2ee.j2eestore.model.itemfacade.delegate Package fi.mamk.jramos.j2ee.j2eestore.model.itemfacade.ejb Package fi.mamk.jramos.j2ee.j2eestore.model.order.ejb Package fi.mamk.jramos.j2ee.j2eestore.model.order.vo Package fi.mamk.jramos.j2ee.j2eestore.model.shoppingcart.ejb Package fi.mamk.jramos.j2ee.j2eestore.model.shoppingcart.vo Package fi.mamk.jramos.j2ee.j2eestore.model.shoppingfacade.delegate Package fi.mamk.jramos.j2ee.j2eestore.model.shoppingfacade.ejb Package fi.mamk.jramos.j2ee.j2eestore.model.shoppingfacade.ejb.actions Package fi.mamk.jramos.j2ee.j2eestore.model.specificitem.dao Package fi.mamk.jramos.j2ee.j2eestore.model.specificitem.vo Package fi.mamk.jramos.j2ee.j2eestore.model.transport.dao Package fi.mamk.jramos.j2ee.j2eestore.model.transport.vo Package fi.mamk.jramos.j2ee.j2eestore.model.userfacade.delegate Package fi.mamk.jramos.j2ee.j2eestore.model.userfacade.ejb Package fi.mamk.jramos.j2ee.j2eestore.model.userfacade.ejb.actions Package fi.mamk.jramos.j2ee.j2eestore.model.userfacade.exceptions Package fi.mamk.jramos.j2ee.j2eestore.model.userfacade.util Package fi.mamk.jramos.j2ee.j2eestore.model.userfacade.vo Package fi.mamk.jramos.j2ee.j2eestore.model.userprofile.ejb Package fi.mamk.jramos.j2ee.j2eestore.model.userprofile.vo Package fi.mamk.jramos.j2ee.j2eestore.model.util Package fi.mamk.jramos.j2ee.j2eestore.model.utilfacade.delegate Package fi.mamk.jramos.j2ee.j2eestore.model.utilfacade.ejb Package fi.mamk.jramos.j2ee.j2eestore.http.controller.actions Package fi.mamk.jramos.j2ee.j2eestore.http.controller.frontcontroller Package fi.mamk.jramos.j2ee.j2eestore.http.controller.session Package fi.mamk.jramos.j2ee.j2eestore.view.actionforms Package fi.mamk.jramos.j2ee.j2eestore.view.applicationobjects Package fi.mamk.jramos.j2ee.j2eestore.view.messages PROJECT INFORMATION

14 14 6. CONCLUSION REFERENCES INTERNET REFERENCES BOOKS REFERENCES

15 15 PREFACE The goal of this diploma work is to show the reader how to develop enterprise applications using the J2EE platform. Enterprise applications may be one of the most difficult fields in the Software engineering field. In this diploma work I try to explain all the architecture and its technologies in the simplest possible way. However, this diploma is focus on software engineering s who are willing to learn this new platform. So, I assume the reader has some basic knowledge about this world. Next, I describe the requirements to follow this diploma work, which are the usual for a J2EE course: Java Language Knowledge: The reader must know the basic Java concepts like what is a JVM, a Java thread, a static variable, a Java interface, garbage collector Object Oriented Programming (OOP): The reader must understand the basic ideas of the OOP, like what is an object, a class, hierarchy, an abstract class Database Knowledge: The reader must have enough knowledge to understand what is a transaction, an SQL query, a primary key Software Design Knowledge: The reader must know the basic idea of software design like the UML language or the design patterns.

16 16 Diploma work organization This diploma work is organizing in two parts: 1. On the first part I introduce the knowledge to be able to understand and follow the final web application. We begin with an introduction to the enterprise applications; talking about the origins of these types of applications and the present panorama, we also discuss about the open source solutions. Finally we introduce the most famous enterprise technologies. Then, we have the J2EE overview. First, we give a short introduction and we also explain some basic concepts to understand the architecture. After that, we explain the J2EE architecture and all its technologies which are necessary to understand the main application. After that, we introduce other new approaches based on the Java technology. Then, we discuss about the big topic on enterprise application: J2EE vs..net.

17 17 Finally, we go into the scary world of the design patterns. This is probably the most difficult part to understand but the knowledge of these patterns is necessary to build scalable applications. We, begin with a short review of the usual OOP patterns, on this section I don t try to teach the patterns is just a short review to be use as a reference for someone who already study then, if the reader doesn t have any knowledge about these main pattern he may have some difficulties following this diploma work. I recommend further reading about design patterns. After this review, we introduce the J2EE Core Patterns, which are the main patterns used in the J2EE platform, most of them related with the EJB technology. We take a close look to these patterns because they are use on the main application. 2. On the second part we describe the application. We will use case diagrams to describe the functionality and class diagram to show the structure of the application. 3. Finally, we have the conclusions.

18 18 1. INTRODUCTION Software development has change considerably in the past years. The machines have considerably increased their speed, and telecommunications have grown exponentially in the last 15 years. Also, customer s requirements have increase in the past years and more complex and reliable software is required. The software development has to adapt to the new infrastructures; many tools and software patterns have appear to help developers to build software that adapts to both, technology and customers requirements. Probably the development of enterprise applications is the most complex task in software engineering. It requires the domain of various technologies, such as databases, transactions handling, distributed applications and Client/Server applications among others. Developers have to face several problems due to the size of the enterprise applications. They should have knowledge of the following: Software engineering: They must have the ability to analyze the customer requirement and be able to create a good representation of the application using languages like the UML. Also, they must know the general requirements in enterprise application development. Enterprise applications technology: Developers must know a wide range of different tools and technologies used in the development of enterprise applications. Design Patterns: They should know all the basics design pattern to help building more reliable applications. Also, the experience of the developers is crucial.

19 OPEN SOFTWARE SOLUTIONS The design of enterprise applications has always been one of the most fruitful fields for proprietary software. The companies have always been reticent to the installation of free software to manage their precious treasure which is their information. One of the causes of this situation is mainly the ignorance of the market, as much on the part of the companies suppliers of services like on the part of the companies who contract these services. Many consultancies use proprietary solutions simply because they do not know others, even when the margins of benefits that can obtain are smaller. On the other hand it is very common that the clients know only the solutions of the most important companies and follow the way that these companies mark. The consequence of all this is normally the acquisition of as expensive products as unnecessary, simultaneously that are generated high costs of formation, consultancy and sub hiring. Luckily, the panorama nowadays is changing. At the present time the number of enterprise solutions in form of free software is growing at a rate that seems unstoppable. No longer are only the classic Web servers or data bases the protagonists, but a great number of products like applications servers, mail solutions, Web services systems, etc., are arising considerably. It s difficult to ignore the existence of such solutions, and the people in charge in the decision making are considering, more often, the world of free software like a valid solution.

20 20 This causes that at the present time is feasible to create an enterprise architecture with all the requirements of scalability, reliability, easy to maintain, flexibility, security that these systems need; and using only and exclusively free software.

21 ENTERPRISE ARCHITECTURE AND THE PRESENT PANORAMA A possible abstract definition of enterprise architecture would be: "the study of complex enterprise systems from the point of view of its structure". An enterprise architect has to be able to study a concrete problem and choose a series of components to model the most suitable architecture for the problem. These components can be application servers, Web containers, mail servers, etc. The architect, also, has to be able to settle down how these components work, the tools to use and the existing relations between the components. The most complicated work and with the greater responsibility for an enterprise architect is the election of the enterprise platform on which the architecture of a company will be laid the foundations. An erroneous election can have catastrophic results for the company and also for the person in charge of this election. An enterprise development platform has to offer a series of directed services to the architects and developers to facilitate the development of enterprise applications, and at the same time it must provide the greater possible amount of functionalities to the users. Usually an enterprise development platform has the following requirements: Scalability: The application has to offer as much horizontal scalability as vertical scalability so that if the load of the system increases we can be able to add servers or to extend the existing ones without making modifications. Easy to maintain: It has to allow adding or modifying the existing components without modifying the system behavior. Reliability Database Access

22 22 Availability: We need to have support for fault tolerant architectures, redundant systems, etc., we need to assure that our system will be always available. Easy to expand: The system has to support the addition of new components and capacities to the system without affecting the rest of the components. Manageability: Our systems easily have to be manageable and easy to configure. Security: We require good security systems at authentication, authorization, and transport level. Performance: Our application needs to offer automatically clustering support, load balance, object pools, connection pools, caches, and in general, mechanisms that allow to increase the performance in a transparent way for the user. Multitier Architecture Support: In an enterprise application, it has to be a separation between the user graphical interface and the business model. The user interface (UI) can be standalone (window mode) or Web based. The business model encapsulates the application logic. The model has to be reusable for the different user interfaces. To achieve this, a multitier architecture has to be implemented. The importance of an enterprise platform is that all these components are offered to us automatically so that the developers are much more productive. The difference between using an enterprise development platform and not using it is that in the second case our developers will lose long time making systems at low level, not being able to center in the development of applications and therefore diminishing considerably the productivity.

23 23 To develop an enterprise architecture using unique and exclusively products based on free software is really complicated. Probably, when proposing the use of any product based on free software in our company we will be with the typical questions: "Who is going to give technical support?", "What telephone should I call if some error takes place? Luckily it seems that something is changing in the enterprise panorama. Many architects and engineers are beginning to see a new requirement indispensable for any enterprise development platform: The availability of free solutions. A platform that has free solutions contributes very important benefits extra to the architects since they obtain a great number of solutions at low cost that can evaluate, and in addition they usually have an ample community of developers to be able to solve problems that may appear. Returning to the subject of the proprietary solutions, many of these, often do not have of some (or several) of these characteristics, reason why we have to be very careful when we acquire these products (often very expensive) and to make sure that what really offers to us is worth what we are paying. In case outside little, the proprietary solutions, often can represent problems for the companies since these will be bound to third organizations on which they will depend for the evolution of his structures of information. It is for that why at the present time most important platforms are those than have the support of great amount of companies, organizations or associations and that have standardization groups which they assure the same ones the future. At the present time the more important enterprise development platforms are three: LAMP CORBA.NET J2EE

24 LAMP Lamp is an open source web platform used to develop web applications. Basically, is a set of various tools, concretely: Linux + Apache + MySQL + Perl/PHP/Python. It uses Linux as operating systems, Apache as a web server, MySQL as Database server and Perl/PHP/Python as programming languages. All of the software it s open source. The main characteristics of this approach are: Uses Script programming languages Provides database access Supports XML The main advantage of this approach is that doesn t require a lot of knowledge on Web technologies and developers can easily build web applications. The problem is that this approach doesn t satisfy the requirements to build enterprise applications such scalability, reliability, multitier support or security. Mostly, because PHP is a script language and not a powerful Object Oriented (OO) language like Java. Although PHP supports the concept of Object, is not a OO Language. So, the software quality is very low and is only suitable for home users.

25 CORBA Without a doubt, the model followed by any enterprise platform. The advantages that CORBA offers are very important: Support of multiple operating systems. Support of multiple languages. Great amount of services: mail, events, transactions, persistence, etc. Controlled by a serious organism, OMG. The advantages are very important, even so, CORBA drags problems that suppose a serious trouble: Complexity: CORBA is a very complex development platform, although abstraction layers exist to facilitate the development of applications, the true is that to develop a simple "Hello World program it is not a trivial work. Bureaucracy: The evolution of the CORBA specifications is subject to too many passages of bureaucracy, which causes an enormous delay in the development of new features in the platform. Few free solutions: As a result of his complexity and from the slowness of his evolution causes that few free solutions exist. OpenORB is an example and some others exist but the amount is not elevated.

26 NET The enterprise development platform of Microsoft offers to the developers some interesting advantages: Support of multiple systems languages: Although it doesn t support all its characteristics, the true is that with.net is possible to develop applications using simultaneously several programming languages. Ideal for Microsoft environment: If in our company we have great amount of software and dependent hardware of Microsoft, probably the best option is to continue developing is this platform, since its integration with products of the company is perfect. Visual Studio.NET: The platform.net has this great tool that in addition to its power offers a homogenous environment for development. A great department of marketing:.net will be a platform that will widely be used at enterprise level thanks to Microsoft marketing department who has tremendous effectiveness. It doesn t require so much experienced developers: Under the development platform of Microsoft.NET is possible to use languages like VB that make the creation of enterprise applications very simple. This way it is possible to have an equipment of developers little experienced but been able to create applications easily.

27 27 Even so, if the list of advantages is quite great, the list of disadvantages does not have anything to envy: It does not support multiple operating systems: The world of NET tour around the operating system Windows and although is being tried to transfer important parts of the platform, like the CLR or C #, to other operating systems, the true is that these parts comprise very small of the totality of the platform of Microsoft. An only owner: The platform NET is dominated only by Microsoft. This supposes a serious problem since it the only company that can add and remove characteristics from the platform. Also, this causes that the competition is null and the evolution of the platform is not stimulated. It is an immature technology: Its immaturity causes that probably it must spend some time until is really productive. Few free solutions: There is not an exact correspondence between the parts of the platform.net and free solutions. We cannot created a complete architecture only using products based on free software.

28 J2EE J2EE is a platform created by SUN in the year 1997 and is one of the best development perspectives for companies that want to base its architecture on products based on free software. J2EE offers us among other the following advantages: Support of multiple operative systems: Because the platform is based on the language Java, is possible to develop architectures based in J2EE using any operating system where you can execute a virtual machine Java. Control organism: The platform J2EE is controlled for the JCP, an organism formed for more than 500 companies. The most important companies of computer world are among the companies, this guarantees the evolution of the platform. Competitiveness: Many companies believe solutions based in J2EE and that they offer characteristic as performance, price, etc. This way the client has a great amount of options to choose. Maturity: Created in the year 1997 as answer to the technology MTS of Microsoft, J2EE already have many years of life and a great amount of important projects. Free solutions: In the platform J2EE it is possible to create unique based complete architectures and exclusively in products that are free software.

29 29 Even this way, the J2EE platform also has disadvantages, some important ones: It depends on an only language: The platform J2EE depends exclusively on Java language. You can only use this language to develop applications, this can suppose a big problem if our team doesn't have the enough knowledge or has other preferences. Complexity: Although it is not such a complex platform as CORBA, a VB.NET doesn't exist in Java. The creation of applications under J2EE usually requires more experienced developers that the necessary ones to develop under.net or LAMP. Heterogeneity: A great heterogeneity exists in the development solutions. It doesn't exist in J2EE a simile to Visual Studio.NET. The great quantity of available tools causes confusion inside the developers and it can create dependences inside the companies.

30 30 2. JAVA 2 ENTERPRISE EDITION OVERVIEW 2.1. J2EE DEFINITION J2EE is a group of Java APIs specifications for the development of enterprise applications. The main characteristics are: Most of the abstractions of the APIs corresponds to interfaces and abstract classes Exists multiple implementations from different companies, even some Open Source A application built with J2EE doesn't depend on one particular implementation Sun defines the J2EE platform like: The Java 2 Platform, Enterprise Edition (J2EE) defines the standard for developing multitier enterprise applications. The J2EE platform simplifies enterprise applications by basing them on standardized, modular components, by providing a complete set of services to those components, and by handling many details of application behavior automatically, without complex programming. The J2EE platform takes advantage of many features of the Java 2 Platform, Standard Edition (J2SE), such as "Write Once, Run Anywhere" portability, JDBC API for database access, CORBA technology for interaction with existing enterprise resources, and a security model that protects data even in internet applications. Building on this base, the Java 2 Platform, Enterprise Edition adds full support for Enterprise JavaBeans components, Java Servlets API, JavaServer Pages and XML technology. The J2EE standard includes complete specifications and compliance tests to ensure portability of applications across the wide range of existing enterprise systems capable of supporting the J2EE platform. In addition, the J2EE specification now ensures Web services interoperability through support for the WS-I Basic Profile The most important issue from the Sun definition is that the J2EE is a standard for development enterprise applications, is important to realize that the J2EE fully supports multitier architectures, essential in enterprise applications. Also is important to realize that the J2EE is based on the Java 2 Standard Edition (J2SE) but adds a wide range of enterprise systems such Enterprise Java Beans (EJB).

31 31 The most important features of the J2EE are: Open Source, it s just a specification. Is a Standard supported by several companies. Is platform independent. Used to build portable, reliable and scalable applications. Supports multitier architectures. Sun offers three different versions of the Java 2 platform: J2ME (Java 2 Platform, Micro Edition) For devices (e.g.: PDAs) J2SE (Java 2 Platform, Standard Edition) For applications and applets J2EE (Java 2 Platform, Enterprise Edition) Based on J2SE As time passed by, more APIs are been moving to the J2SE.

32 MULTITIER ARCHITECTURE In order to understand how to build enterprise applications we have to take a closer look to the multitier architecture. Usually in an enterprise application we have three components: 1. User Interface (UI) code: This is the presentation layer, it s the code written to show the information to the user. In case of a Web based interface the code is written to generate dynamically web pages, in case of Java JSP pages are used. 2. Business logic: This is the model layer. This is the code that contents all the application logic. It processes the information fetched from the UI or the database code. 3. Database code: This is the data layer. This code is in charge to communicate with the database in order to get the information and create the objects use by the other layers. We will talk later about the layer architectural pattern, now we focus on the physical structure of an n-tier application. There are two basic architectures in which the database and programmer code are arranged: client/server (or 2-tier) multi-tier (or 3-tier or n-tier)

33 tier approach The Client/Server architecture looks like this: Figure 1 In this approach the clients have all the code and they access to a database server which is in another computer. This architecture has an important problem, if the model layer or the database changes we have to recompile and reinstall the application in all computers, this is a big problem in enterprise application were the number of clients is very high.

34 Multitier approach The 3-tier architecture look life this: Figure 2 With this approach we insert a server in the middle who has the business logic and the database logic. Using this architecture a change in the model or the database only affects the main server. We can use an n-tier approach by using more middle servers, like in the 4-tier where we separate the business logic and the database logic in to two different servers having a distributed environment.

35 35 A more complex example could be: Figure 3 This is an example using the Java 2 Enterprise Edition platform. Here we have different clients that use different UI, some are standalone clients and other are web based clients, then we have the middle tier that takes care of the clients request and finally the database. We will explain later on the J2EE and its different technologies.

36 MAIN ARCHITECTURAL PATTERNS USED IN ENTERPRISE APPLICATIONS There are two main architectural patterns used in the development of enterprise applications: 1. Layers Pattern: This design pattern is essential in order to build scalable and reusable application. This pattern is related to the multitier architecture. The main idea is to logically divide the application in modules or layers, each of them having different function. PRESENTATION LOGIC DATABASE The presentation layer is the part of the application where all the code written for the UI resides. This layer represents the client tier in the 3-tier architecture, if the client is standalone this layer will represent all the classes used to create the interface. If the client is Web based this layer

37 37 represent the pages or classes use to create the web pages that the user sees in the Web browser. In the case of the J2EE, the JSP pages are commonly used to generate dynamic Web pages, and are the main component in the presentation layer. The logic layer represent the business model and is in charge of implement the main functions of the system. It fetch the information from the presentation layer and process the information, if its necessary it will ask the data layer to get some information. Here we will have the main classes of our application. This layer corresponds to the business tier in the 3-layer architecture; the middle server will have the code corresponding to this layer. The data layer will have the code necessary to connect to the database and create the objects used in the second layer. It represents the database layer in the 3-tier architecture. The main issue here is how the layers communicate with each other. The idea is that one layer only communicate with the lower layer sending request, no bidirectional communication takes place. The upper layer sends a request to the lower layer and gets a response, but the upper layer doesn t know how this operation was done, it only knows the public interface. So, the communication takes place only from the upper layers to the lower layers, is not allowed to send a request from one lower layer to an upper layer. This approach provides a high level of abstraction and encapsulation allowing the developers to build scalable and reusable applications because we can change the data layer and the logic layer won t be affected as long as the public interfaces are kept the same. This approach allows us to build reusable software been able to change different modules without affecting the others. For example, we can change the database and the logic layer will not be affected. The business logic layer has all the functionality of the systems and also treats the data independently of its internal representation. This pattern is related to the Facade design pattern that we will discuss later on.

38 38 2. Model-View-Controller (MVC): MVC was originated in the Smalltalk-80 system to promote a layered approach when developing graphical user interfaces. It emerged in the late 1970s and early This pattern tell us how the three layers communicate with each other: The model handles application and business logic. The view handles presentation logic showing the data to the user. The controller accepts and interprets keyboard and mouse input. Figure 4 The main idea here is to separate the model (meaning nongui) code from its presentation. Later on, we will study Struts, the MVC implementation in the J2EE platform.

39 J2EE MODEL In this section we will analyze the general J2EE model and later on we will go through its different components. Figure 5 As we can see in the graphic, Sun uses also the layer pattern to describe the J2EE platform. Sun separates the presentation in two parts: the part on the server which generates the web pages and the client part.

40 40 Now let s take a general look to each layer: 1. Client-Side Presentation: In the client-side we have the user interface that can be: Desktop Client: A standalone client written using Java code. Web based client: In this case the client use a browser to interact with the model. It can be a Java Applet which is a Java application that is downloaded in the client and executed in there. With this approach most of the system functionality is on the client side. Nowadays the tendency is to have clients with barely any functionality and servers with all the system functions, mostly for security and performance reasons. So, nowadays is usually that the client use a browser that receives HTML pages generated dynamically in the server. Other: Other kinds of clients. 2. Server-Side Presentation: In this side we have the main server; this layer is in charge to provide de information to the client. So, here we use a Web server that is in charge of serving Web pages to the client. In the case of a Web based system, the server will use JSP pages or Servlets to generate the view by generating HTML pages dynamically. Later on, we will get more in deep with these two technologies. Communication between Client and Server can take place using various methods: HTTP Protocol: The most common way to communicate in a Client/Server web based environment. The server receives a request, processes it and then generates a Web page that is send using the HTTP protocol (TCP Port 80).

41 41 XML: This is a standard way to communicate using text files. Using XML we have a portable way to send information between Server and Client. XML files are easy to manage because they keep the information with a well defined structure and because are text files, all kinds of clients can read the files. Java Remote Method Invocation (RMI): RMI is a technology used to invoke remote objects in a distributed system. Is a high-level solution better than using sockets directly. RMI is only supported by Java but it can be used over IIOP (CORBA). 3. Server-Side Business Logic: On this layer we have the EJB Container who is in charge of manage the EJB. An EJB (Enterprise JavaBean) it is a safe, transactional and maybe persistent object used to implement de business logic. They can be local or remote. We will talk more in detail later on about the EJB because they are the main component in the business logic on the J2EE platform. 4. Enterprise Information System: This is usually a database with the company information.

42 J2EE TECHNOLOGIES JDBC JDBC technology is an API (included in both J2SE and J2EE releases) that provides cross-dbms connectivity to a wide range of SQL databases and access to other tabular data sources, such as spreadsheets or flat files. Right now, JDBC current version is 2.0. It s a technology used at the lower layer to access to the database. The JDBC API makes possible three things: 1. Establish a connection with a database or access any tabular data source. 2. Send SQL statements. 3. Process the results. The design is based in two well know APIs: ODBC (Open DataBase Connectivity). X/OPEN SQL CLI (Call Level Interface). The programmer always works with the java.sql and javax.sql packets. To be able to connect to the DB and to send queries, it is necessary to have an appropriate driver for it: A driver is usually a.jar file that contains the implementation of all the interfaces of the JDBC API. Our code never depends on the driver, since always works against the packages java.sql and javax.sql.

43 43 The package diagram looks like it follows: Figure 6

44 Types of JDBC technology drivers JDBC technology drivers fit into one of four categories: 1. A JDBC-ODBC bridge provides JDBC API access via one or more ODBC drivers. Note that some ODBC native code and in many cases native database client code must be loaded on each client machine that uses this type of driver. Hence, this kind of driver is generally most appropriate when automatic installation and downloading of a Java technology application is not important. 2. A native-api partly Java technology-enabled driver converts JDBC calls into calls on the client API for Oracle, Sybase, Informix, DB2, or other DBMS. Note that, like the bridge driver, this style of driver requires that some binary code be loaded on each client machine. 3. A net-protocol fully Java technology-enabled driver translates JDBC API calls into a DBMS-independent net protocol which is then translated to a DBMS protocol by a server. This net server middleware is able to connect all of its Java technology-based clients to many different databases. The specific protocol used depends on the vendor. In general, this is the most flexible JDBC API alternative. It is likely that all vendors of this solution will provide products suitable for Intranet use. In order for these products to also support Internet access they must handle the additional requirements for security, access through firewalls, etc., that the Web imposes. Several vendors are adding JDBC technology-based drivers to their existing database middleware products. 4. A native-protocol fully Java technology-enabled driver converts JDBC technology calls into the network protocol used by DBMSs directly. This allows a direct call from the client machine to the DBMS server and is a practical solution for Intranet access. Since many of these protocols are proprietary the database vendors themselves will be the primary source for this style of driver. Several database vendors have these in progress.

45 Establishing a connection Before a database can be accessed, a connection must be opened between our program (client) and the database (server). This involves two steps: 1. Load the vendor specific driver To ensure portability and code reuse, the API was designed to be as independent of the version or the vendor of a database as possible. Since different DBMS's have different behavior, we need to tell the driver manager which DBMS we wish to use, so that it can invoke the correct driver. An Oracle driver is loaded using the following code snippet: Class.forName("oracle.jdbc.driver.OracleDriver") 2. Make the connection Once the driver is loaded and ready for a connection to be made, you may create an instance of a Connection object using: Connection con = DriverManager.getConnection( "jdbc:oracle:thin:@dbaprod1:1521:shr1_prd", username, passwd); The first string is the URL for the database including the protocol (JDBC), the vendor (Oracle), the driver (thin), the server (dbaprod1), the port number (1521), and a server instance (SHR1_PRD). The username and password are your username and password.

46 46 JDBC is a low level technology that is used for other high level technologies like EJB. For enterprise applications is not recommendable to use direct SQL queries to the database because it creates a dependency between the database and the application Concurrence problems with the database The transactions guarantee that there won t be any problem if two or more transactions modify common data at the same time. However, depending on the blocking strategy we can have three kinds of problems: 1. Dirty reads: A transaction reads data updated by another transaction, but still not committed. 2. Non-repeatable reads: A transaction rereads data that has changed magically from the first reading because of another transaction that has change the value. 3. Phantom reads: A transaction sends again a query and obtains magically more lines the second time because another transaction has updated the table. The java.sql.connection package provides the method settransactionisolation that allows to specify the level of wanted isolation: TRANSACTION_NONE: Transactions not supported. TRANSACTION_READ_UNCOMMITED: Dirty Reads, non-repeatable reads and phantom reads may occur. TRANSACTION_READ_COMMITED: Non-repeatable reads and phantom reads may occur. TRANSACTION_REPEATABLE_READ: Phantom reads may occur. TRANSACTION_SERIALIZABLE: It eliminates all concurrence problems.

47 47 The bigger isolation level, the DB does more blocks and there is less concurrence. Not all the drivers/dbs have to support all the isolation levels. Usually supports TRANSACTION_READ_COMMITED and TRANSACTION_SERIALIZABLE. The default isolation level usually is TRANSACTION_READ_COMMITED. So depending, on the operation we have to modify the isolation level.

48 XML EXtensible Markup Language (XML) is an open standard for describing data from the W3C. XML was introduced in 1998 and is used for defining data elements on a Web page and business-to-business documents. XML uses a similar tag structure as HTML; however, whereas HTML defines how elements are displayed, XML defines what those elements contain. While HTML uses predefined tags, XML allows tags to be defined by the developer of the page. Thus, virtually any data items, such as "product," "sales rep" and "amount due," can be identified, allowing Web pages to function like database records. By providing a common method for identifying data, XML supports businessto-business transactions and has become "the" format for electronic data interchange and Web services. The human-readable XML tags provide a simple data format, but the intelligent defining of these tags and common adherence to their usage determines their value. Countless vocabularies have been developed for vertical applications; so many in fact that a universal language was developed to provide a standard for interoperability between them. An XML document is self defining if an XML schema is included in it. Schemas, such as W3C XML Schema, are written in XML and identify the tags and their relationships to each other in the document. Unlike HTML, which uses a rather loose coding style and which is tolerant of coding errors, XML pages have to be "well formed," which means they must comply with rigid rules. These rules allow building efficient parsers. Is important to remember that is a different between upper and lower case.

49 49 XML and HTML Tags Following are examples of XML and HTML tags. Note that the XML statements define data content, whereas the HTML lines deal with fonts and display (boldface). XML defines "what it is," and HTML defines "how it looks." XML <firstname>maria</firstname> <lastname>roberts</lastname> <datebirth> </datebirth> HTML <font size="3">maria Roberts</font> <b>october 29, 1952</b> In theory HTML is a subset of XML specialized in presentation of documents for the Web, while XML is a subset of SGML (Standard Generalized Markup Language) specialized in the administration of information for the Web. XML it contains HTML although not in their entirety. HTML is simply a language, while XML is a metalanguage, this is, a language to define languages. Figure 7

50 50 Objectives The main objectives are: XML should be directly usable on Internet. XML should support a wide variety of applications. XML should be compatible with SGML. It should be easy writing programs that process XML documents. The number of optional characteristic in XML should be absolutely minimum, ideally zero. The XML documents should be readable for human and reasonably clear. The design of XML should be prepared quickly. The design of XML should be formal and concise. The documents XML should be create easily. The conciseness in the marks has minimum importance. XML Documents All documents should have a root element. Between the beginning tag and the end there can be other elements or text. Contrary to HTML, is not possible to mix the order of the nested tags. The first element that opens up should be the last one that closes. The following example would not be well formed: < tag-1 > < tag-2 > < /tag-1 > < /tag-2 > An element can have attributes: The value of the attribute has to go quoted (better with ) For a given element, an attribute can only have a value

51 51 Here is an XML document example: <?xml version="1.0" encoding="utf-8"?> <collection> <description> Some recipes used for the XML tutorial. </description> <recipe> <title>beef Parmesan with Garlic Angel Hair Pasta</title> <ingredient name="beef cube steak" amount="1.5" unit="pound"/>... <preparation> <step> Preheat oven to 350 degrees F (175 degrees C). </step>... </preparation> <comment> Make the meat ahead of time, and refrigerate over night, the acid in the tomato sauce will tenderize the meat even more. If you do this, save the mozzarella till the last minute. </comment> <nutrition calories="1167" fat="23" carbohydrates="45" protein="32"/> </recipe>... </collection>

52 DTDs A DTD (Type Definition Dates) it allows to specify elements of an XML application: How they are nested If they are empty or not The attributes (and their type) of each element A document is valid if it follows the rules of its DTD. All the parsers require that the documents are well formed, but not all require that they are valid. A more complex parser also verifies that the one document follows its associate DTD.

53 SERVLETS A servlet is a software application written in Java that is executed in the server. The Java Servlet API allows a software developer to add dynamic content to a web server using the Java platform. The generated content is commonly HTML, but may be other data such as XML. Servlets are the Java counterpart to dynamic web content technologies such as CGI or ASP. It has the ability to maintain state after many server transactions. This is done using HTTP Cookies, session variables or URL rewriting. The servlet process is carried out on the server and only the results are send to the client (usually in HTML format). When a browser sends a request to the server, it executes the servlet that processes the request and it generates the appropriate answer that is returned to the client. Servlets Features The servlets has a series of advantages in front of other technologies: Execution capacity: The servlets are able to be executed in the same space in the server, this offers certain advantages compare to other technologies like CGI that loads several times in memory to process several user s requirements. The servlets only need to be loaded once when they are invoked. Compiled: Because they are compiled inside Java, we have binary code as a result (bytecode) that allows the servlets to be executed much more quickly. Also offers advantages like the detection of errors. This makes Servlets more stable, easy to develop and to debug.

54 54 Security: The servlets presents a high degree of security against errors because they are written in Java and executed in a virtual machine (JVM). The Java virtual machine is in charge of checking that all the operations are carried out properly, not allowing invalid operations. Platform Independent: This Java advantage, and because Servlets are written in Java they are also platform independent. Durable: The servlets remains in memory until they are remove in an explicit way. This way, the servlets only needs to be invoked once to serve multiple client requests. Dynamically Executed: The servlets can be loaded dynamically through the net. This assures that the Servlet will not consume the server resources; they are only loaded when they are needed. Although the server can also be a servlet in certain cases. Multithread: Java was designed to be a multithread language. The servlets supports this characteristic, which allows the users to be treated in different threads inside one process. This method requires fewer resources and is executed more quickly than when creating new processes for each request. Protocol Independent: This allows Servlets to support HTTP and also the possibility to use FTP, SMTP or POP3 commands, besides Telnet sessions and other protocols. The API offers a robust support for the usual HTTP functions without sacrificing the capacity to support other protocols.

55 55 Safe: The security of the servlets is based mainly on three facts: Because they are implemented in Java, the invalid accesses to memory are avoided; also, type errors are not possible. The servlets uses a Server's security manager reinforcing the security politics. The servlet has access to all the information contained in the client's request. These data used with security protocols like SSL, allows the verification of each client's identity. Written in Java: This feature gives Servlets many advantages like support for the programming guided to objects, strong types confirmation, multithread support, platform independence, etc. Capacity: In a servlet you can use without more difficulty anyone of the elements defined in the API of Java (JDBC, CORBA, JMS, JTS, JNDI, EJB...) and, in general, any class Java made by others. Portability: The servlets are written in Java using a well defined API. A servlet you can execute practically without any change in the container that implements the API. Integration: The Servlets is very integrated with the server. The Servlets can use of the server to obtain absolute path, to carry out loggings, confirmation of permits... Expandable and Flexible: The API of the Servlets is designed so that starting from the basic classes; new classes can be created that carry out functions more or less specific. Free: Practically all the current web servers support servlets

56 56 As we estate before, a servlet is a Java class that can receive requests (usually HTTP) and generate an output (usually HTML, WML or XML). The servlets that conform a web application are executed in a web container. Each servlet can associate to one or more URLs. The Servlet API defines the expected interactions of a web container and a servlet. A web container is essentially the component of a web server that interacts with the servlets. The web container is responsible for mapping a URL to a particular servlet and ensuring that the URL requester has the correct access rights. A servlet is an object that receives requests and generates a response based on the request. The API defines HTTP subclasses of the generic servlet requests and responses as well as an HTTP session object that tracks multiple requests and responses between the web server and a client. Servlets may be packaged as a Web application. The main packages are javax.servlet and javax.servlet.http.

57 57 The class diagram look like this: Figure 8 Figure 9

58 58 The programmer in order to create a Servlet only needs to write a class which extends from HttpServlet and implement the method doget or dopost. A simple example could be: import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class HelloWorld extends HttpServlet { public void doget(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { response.setcontenttype("text/html"); PrintWriter out = response.getwriter(); out.println(""); out.println("<head>my first servlet</head></title>"); out.println(""); } } This Servlet, when is called, it generates a dynamic Web page with the message My first servlet. In a Java virtual machine (JVM), there s only one instance of each Servlet that is programmed, and in consequence it can receive only concurrent requests. doget, dopost, etc. should be thread-safe. A servlet can be implemented like: javax.servlet.singlethreadmodel (marker interface) In this case, the container can create multiple instances.

59 59 The servlets allows interactions in both directions between client and server, among the possibilities that servlets provide we have: Dynamic construction and return of a HTML file based on the client request. Process user's inputs through a HTML form, returning an appropriate answer. It gives user's certification and other security mechanisms. Access to resources such server databases to return useful information to the client. Allow the server to communicate with client's applets using a common protocol maintaining connection open during the whole conversation. It adds elements automatically like headed or feet, to all the pages returned by the server.

60 60 Before the JSP pages appear, the main use of the Servlets was to generate the view of an application web: 1. Receive petition HTTP associated to a URL 2. Read parameters 3. Invoke operation on the business model 4. Generate HTML Nowadays, the JSP pages are use to generate the view (HTML) because as we ll see later on Servlets have many limitations. JSP pages provide better mechanisms to generate dynamically Web content. But still, the Servlets are really important and are usually used as application controllers. So, the main approach right now in the J2EE platform is to use the MVC pattern as it follows: View: JSP Pages. Model: EJB Controller: Servlets. As we will see later on, the Jakarta Struts MVC Java implementation provides a generic servlet that constitutes the main of the controller.

61 JSP PAGES The main problem with Servlets is that the text generate for the view is mix with Java code and this has some disadvantages: It is not possible to use tools for generation of HTML, WML, etc. directly. The text generation needs to be written by a person with knowledge of Java, which is economically very expensive. Changes in the aspect of the graphic interface require recompilation, creation of a new.war file and re-start the server. In an application web, especially in Internet, changes in the graphic interface are very common. We want to be in a situation were there is a complete job separation: People that work on the graphic aspect like graphics designers or similar with knowledge of graphic design and tools for generation of HTML and WML. People that implement the controller and the model like computer engineering with design and implementation knowledge. Also it should be possible to use the tools directly to design Web pages. Another requirement is that the graphic interfaces updates should not cause the re-start of the server. JSP pages were created to overcome this Servlets limitation on the generation of the view. Servlets are still use as application controllers but JSP pages have substituted them in the view generation. Even, JSP can use Java code (scriptlets), a tag approach can be used using technologies like standard tags (JSTL), providing a total separation between the model and the presentation.

62 JSP Pages Overview JavaServer Pages (JSP) it is a group of technologies that allow the dynamic generation of web pages using a mark-up language like HTML or XML, to generate the content of the web pages. It can also mix the mark-up language with Java code using scriptlets. Been part of the Java technology, with JSP we can develop platform independent applications. An important feature is that it allows separating the user interface from the generation of the dynamic content, providing quicker and more efficient development processes. JSP features The characteristics offered by JSP like alternative to the generation of dynamic content for the Web are summarized below: Performance improvements: Use of thin processes (Java threads) for handling request. The servlet container can be executed as part of the web server. Support of reusable components: By means of the creation, use and modification of JavaBeans in the server, these can be used in JSP pages, servlets, applets or Java applications. A JavaBean is a reusable component (Java class) that encapsulates data in simple and safe way. Separation between presentation code and implementation code: The changes in the HTML code relative to how the data are shown, they don't interfere in the programming logic and vice versa.

63 63 Labour Division: The Web pages designers can be centred in the HTML code and the programmers in the logic of the program. The developments can be made independently. The frequent modifications of a page are carried out this way more efficiently. Important back of the solid Java technology. At the moment, there are different technologies that compete with JavaServer Pages. But JSP have a series of advantages regarding to these technologies: Active Server Pages (ASP): ASP is a similar technology created by Microsoft. JSP has several advantages. First, the dynamic part is written in Java, not in Visual Basic Script, or another specific language of Microsoft, for that reason is much more powerful and easier to use. Second, it is portable to other operative systems and Web servers. We will discuss these issues more in detail later on. Servlets: JSP doesn't provide us anything that we were not able to do with a servlet. But it is much more convenient to write (and to modify) normal HTML than to have to make a trillion sentences println to generate HTML. Also, separating the content format can put different people on different tasks: The experts in Web pages design can develop HTML pages, leaving space so that the servlets programmers insert the dynamic content. Server-Side Includes (SSI): SSI is a broadly supported technology that includes externally defined pieces inside a static Web page. JSP is better because it allows us to use servlets instead of a separate program to generate the dynamic parts. Also, SSI, it is really designed for simple tasks; not for real programs that use data forms, make connections to databases, etc.

64 64 JavaScript. JavaScript can generate dynamically HTML on the client side. This is a useful capacity, but it only manages situations where the dynamic information is based on the client's environment. With the exception of the cookies, HTTP and sending forms are not available with JavaScript. And, because it is executed in the client, JavaScript cannot access to the resources in the server side, as databases, catalogs, etc JSP Use To be able to use this technology it is necessary a web server that support HTML pages, and code that implements a JSP container where we can execute the JSP labels. Most of web servers are written in traditional programming languages, compiled in native code because of efficiency reasons. For these servers it is necessary to add supplementary code that implements the JSP container. Server API s have been provided to extend servers functionality. The Apache server has modules. In the old versions it was necessary recompile the server code to support a new module, nowadays they are loaded dynamically being based on configuration files. Once the JSP container has been installed and configured, the.jsp files are treated the same as the.html files, locating them in any place of the directory hierarchy. Although the JSP specification doesn't presuppose anything on the implementation of this technology, most of the available implementations are based on Servlets, this mean Java language. It s important to realize that the JSP specification doesn t require that JSP are implemented using Servlets (Java language). There are several JSP containers in the market, Tomcat is a well know free JSP container widely use on the market and is part of the Jakarta project.

65 65 The first component of the implementations based on servlets, is a special servlet denominated page compiler. This servlet with their associated Java classes, it is known as JSP container. The container is configured to call to the page compiler for all the.jsp pages requests. His mission is to compiling each.jsp page in a servlet whose purpose is generating the dynamic content specified by the original.jsp document. To compile a page, the page compiler scans the document searching for JSP labels, generating the corresponding Java code for each of them. The static HTML labels are converted to Java strings. The labels that make reference to JavaBeans are translated in the corresponding objects and methods calls. Once the code of the servlet has been created (its service() method has been coded), the page compiler calls to the Java compiler to compile the source code and add the file of the resulting bytecodes to the appropriate directory on the JSP container. Once the servlet corresponding to the.jsp page has been generated, the page compiler invokes the new servlet to generate the answer for the client. While the code of the page.jsp doesn't lose temper, all the references to the page will execute the same servlet. This supposes a certain delay in the first reference to the page, although mechanisms exist in JSP for precompile the.jsp page before the first petition has taken place.

66 66 The main packages are javax.servlet.jsp y javax.servlet.jsp.tagext. Figure 10

67 Language Syntax The source code of a JSP page includes: 1) Directives: Group of labels that contain instructions for the JSP container with information about the page in which they are. They don't produce any visible output, but they affect to the global properties of the.jsp page that have influence in the generation of the corresponding servlet. 2) Script Elements: They are used to encapsulate Java code that will be inserted in the corresponding servlet of the.jsp page. 3) Comments: They are used to add comments to the.jsp page. JSP supports multiple styles of comments, including those that comments in the HTML page generated as answer to the client's request. 4) Actions: They support different behaviours. They can transfer the control among pages, applets and interact with JavaBeans on the server side. JSP labels can be personalized to extend the functionalities of the language.

68 Directives 1) Page: Information for the page. Multiple directives can be include in a.jsp page. It s not possible to repeat the use of an attribute in the same directive neither in others of the same page except for import. The attributes that are not recognized will generate an error during the execution (the name of the attributes is sensitive to uppercase and minuscule). page attribute1= value1 attribute2=... %> 2) Include: It allows to include the content of another.html or.jsp page. It can be used to include the common head and foot of pages. include file= localurl % > 3) Taglib: This directive is used to notify to the JSP container that the page will use one or more libraries of personalized labels. A labels library is a collection of personalized labels that can be used to extend the basic functionality of JSP. taglib uri= taglibraryuri prefix= tagprefix % >

69 Script Elements 1) Declarations: They are used to define variables and specific methods for a.jsp page. The variables and the declared methods are accessible for any other script element of the page, although they are coded before the own declaration. The syntax is: <%! declaration (fi)% > 2) Expressions: They are bound to the contents generation. They can be used to print values of variables or results of the execution of some method. All result of an expression is converted to a String before being added to the page. The expressions doesn t finish with ;. <% = (hours < 12)? AM : PM % > 3) Scriptlets: They can contain any type of Java sentences, being able to leave open one or more blocks of sentences that will be closed in labels of later scritplets. Sentences like if-else, while and do/while can be included. <% scriptlet% >

70 Comments 1) Content comments: This type of comments will be included in the output of the.jsp page, and therefore they will be visible in the source code that arrives to the client. It is the standard type of comment for HTML and XML. You can include dynamic content in the comment (JSP expressions), and the value of the expression will appear like part of the comment in the client. <!--comment--> 2) Comments: They are independent of the content type of the page and the script language used; these comments can only be seen examining the original.jsp page. <%--comment--% > 3) Script language comments: They can be introduced inside the scriptlets or the JSP expressions, using the native comments of the syntax of the script language. These comments won't be visible for the client, but they will appear in the servlet of the corresponding.jsp page. <% / * comment * /% >

71 Actions 1) Forward: It is used to transfer the control of a.jsp page to another localization. Any code generated until the moment is discarded, and the request process begins in a new page. The client browser continues showing the URL of the initial.jsp page. The value of the parameter page, it can be a static document, a CGI, a servlet or another JSP page. To add flexibility to this parameter, you can build their value like concatenation of values of different variables. It can be useful to pass pairs (parameter/value) to the destination of the label, for this we use < jsp:param... / >. < jsp:forward page= localurl / > 2) Include: It provides a simple form of including content generated by another local document in the output of the current page. In opposition with the label forward, include transfers the control temporarily. The value of the attribute flush, determines if the buffer of the current page should be emptied before including the generated content by the included program. As in the previous case, you can complete this label with the use of < jsp:param > to provide additional information to the called program. < jsp:include page= localurl flush= true / > 3) Plug-in: The purpose of this label is to generate specific HTML code for the client's browser when applets are invoked that use the Sun Plug-in. 4) Beans: It provides three different actions to use with JavaBeans on the server side: < jsp:usebean >, < jsp:setproperty > and < jsp:getproperty >.

72 JavaBeans Javabeans are reusable components, usually Java classes, whose attributes represent the information of a data type (the attributes of a concrete entity of the database) and it has methods setattribute and getattribute to assign or to obtain the data of the attributes since they will be private in order to hide data, so they won t be modified. The characteristics of a Bean are the following: 1. They need to have a constructor without parameters (by default). 2. The attributes should be private. 3. The access methods to the attributes should begin with set or get. 4. They should be serializable, since they are objects that will send among.jsp pages or from a Servlet to a.jsp page. The JavaBeans and the.jsp pages are related since JSP has labels for the creation and access to the beans. The JavaBeans can be in four different environments: Page: o Bean only visible in this page (it is destroyed at the end of each execution). o Bean hooked as attribute in javax.servlet.jsp.pagecontext. Request: o Bean hooked as attribute in javax.servlet.servletrequest. Session: o Bean hooked as attribute in javax.servlet.http.httpsession.

73 73 Application: o Visible to the whole application web. o Bean hooked as attribute in javax.servlet.servletcontext. javax.servlet.jsp.pagecontext, javax.servlet.servletrequest, javax.servlet.http.httpsession and javax.servlet.servletcontext are environment variables that the JSP Container controls. Note that the javax packet is the implementation of the JSP specification and is provided by the JSP container, for example, Tomcat.

74 JSP example This is the Hello world JSP example: <html> <head> <title>jsp page </title> </head> <body> page language="java" %> <% out.println("hello World"); %> </body> </html> As we can see in the example, with JSP we can mix HTML code with Java code. Although, like we state before, this is not a good approach and is only valid for small applications. The first line is a directive telling the container that the language use in the scriptlet is Java and the second line is Java code that prints the hello world message.

75 JSP Architecture Before Struts and EJB appear the model used was: Servlets (or JSP pages) as controllers. JSP pages for the view JavaBeans for data access. DB CAPA 2 Controller CAPA 3 Data Model CLIENT BROWSER REQ RES H T T P SERVLET CAPA 1 View create JavaBean JSP DB The usual steps were: 1. Client sends a request via HTTP protocol. 2. The request is taken by the controller, usually a servlet. 3. The controller will take care of the request and will create a JavaBean with the info for the response taken from the database. 4. The controller will call the JSP page that will generate the HTML page with the JavaBean information. 5. The HTML page is send back to the client with the response.

76 76 A usual architecture was: CLIENT BROWSER HTTP APACHE SERVER HTML PAGES VIEW JAVASCRIPT TOMCAT JSP PAGES USE SERVLETS (LOGIC) CREATE JavaBeans DATA JDBC DB The web server (like Apache) was in charge of serve the HTML pages to the client. Tomcat (JSP container) was in charge to create the servlets corresponding to the JSP pages in charge of the view. The Servlets had the application logic and were in charge of creating the JavaBeans that were use for the JSP pages to show the information to the client. As we can see, with this approach the layers pattern was implemented not letting the JSP pages (View) create the JavaBeans, the Servlets (Model) were in charge to do that using the information stored in the database. The Servlets will access using the JDBC technology.

77 77 So, the programmer was in charge to manually implement the MVC pattern. There were two main problems with this approach: 1. The elimination of Java code from the view code was really hard to achieve and at the end there was always some Java code in the.jsp pages, usually to show an array of JavaBeans or other operations that required some logic in the view. 2. In big applications like enterprise application they were many troubles to implement persistence with the JavaBeans and also the Servlets were too much overloaded causing many troubles for the programmer and ended with a low quality product. Struts were created to solve the first problem giving a good implementation of the MVC pattern having Servlets as controllers and JSP pages for the view; giving also labels to avoid Java code on the view. Also, the Java Standard Tag Library (JSTL) and the JSP 2.0 were created for the same reason. Enterprise Java Beans appear to solve the second problem and take care of the model on enterprise applications. We will discuss these technologies later on. So this approach is only good for small application and the Struts-EJB approach should be use for bigger and more scalable applications.

78 JSP vs. ASP Few years ago it was easy to choose a server-side language as CGI used to be only the only scripting language available. But in due course of time, the developers found out that CGI scripts were inefficient and it was very difficult to write server extensions as we saw before. At that time, Microsoft came up with Active Server Pages (ASP), which allows developers to use simple scripting to access the server and its extensions. But ASP had some disadvantages. It limits you to work on Microsoft platforms, and the simplest of mistakes in the script can cause the server to crash or hang, effectively bringing down your website. In response to ASP, Sun Microsystems gave the world Java Server Pages (JSP) technology, which is entirely based on Java programming language. Internally, JSP pages are dynamically converted into Servlets, which are simply Java classes. This means JSP enjoys all the capabilities that Java programming supports. JSP is a great deal more efficient than many other scripting languages, such as CGI and ASP. Tags can be defined in tag libraries and then used within any JSP page. This makes for a better separation of page content from its code, which leads to less scattered code and hence, the site is easier to maintain. Global changes need to be made only to the tags defined in these tag libraries, making time-consuming, page-by-page fixes things of the past. JSP and ASP can be use, more or less, to develop the same type of web applications. However, they have many differences. Platform and server independence JSP follows the philosophy of the JAVA architecture of write once and execute where you want." The installation of ASP is limited for architectures based on Microsoft technology.

79 79 This way, with JSP you can execute you web application in any operating system or in most popular web servers, as for example Apache, Netscape or Microsoft IIS. While ASP only has native support for IIS and Personal Web Server that are the two web servers for Microsoft systems, the first one with technology NT and the second for Windows 98 systems and similar. Open Source The JSP API benefits of the extended JAVA community, on the other hand the ASP technology is specific of Microsoft that develops its processes internally. Tags While both, JSP as ASP use tags and scripts to create dynamic web pages, the JSP technology allows developers to create new tags. The developers can create this way, new tags and not to depend so much on the scripts and avoid mixing view code with logic code allowing the separation between presentation and model layers. Reusability The JSP components are reusable in different platforms (UNIX, Windows). The advantage of Java The JSP technology uses Java as Script language while ASP uses VBScript or Jscript. Java is a language more powerful and scalable than Script languages. The JSP pages are compiled in Servlets that can use all the Java libraries available. Java makes the work of the easiest developer and helps to protect the system against the errors while the ASP applications has more than enough with the NT systems cause they are more susceptible of errors.

80 80 Maintenance The applications that JSP uses have an easier maintenance that those that ASP uses. The Script languages are well for small applications, but they don't fit well for big applications. Java is a structured language and big applications are easier to develop and maintain. The JSP technology makes bigger emphasis in the components that in the Scripts, this makes JSP easier to revise the content without it affects the logic or to revise the logic without changing the content. Conclusion The advantages on using the Java JSP technology instead of Microsoft (ASP) are diverse and interesting. However, ASP has also some advantages: Support to various programming languages. JSP is based only on Java technology. Easy to learn. There are other technologies available in the market but are not suitable for developing enterprise applications: CGI: This technology now is obsolete. It was the first technology used to generate HTML pages dynamically. But it has many disadvantages; the main one is that it creates a new process on each request needing too much server resources. PHP: This technology is widely use on internet and is part of the LAMP platform. As we state before this technology is not suitable for enterprise applications because, among other problems, it s based only on script language.

81 Examples We can see now the differences on the code of both technologies. ASP (using JScript): LANGUAGE = JScript %> <TITLE>Simple Scripting Tricks</TITLE> Anyone can count like this:<br> <% for (i = 1; i < 6; i++) { Response.Write(i + "<BR>"); } i = ; %> It would take a long time, however, to count to <%= i %>. JSP: <%@ page language="java" %> <TITLE>Simple Scripting Tricks</TITLE> Anyone can count like this:<br> <% for (int i = 1; i < 6; i++) { out.println(i + "<BR>"); } i = ; %> It would take a long time, however, to count to <%= i %>.

82 JSP 2.0 JSP 2.0 is an upgrade to JSP 1.2 with several new and interesting features that make the life of web application developers and designers easier. The objective of JSP 2.0 is to make JSP easier to use than ever, and more importantly to be used without having to learn the Java programming language itself, thank to the new expression language no more Java code is needed in the JSP. JSP were incorporate in the J2EE 1.4. The JSP 2.0 specification has the next features: The Expression Language first introduced by the JSTL 1.0 (Java Standard Tag Library) specification is now incorporated in the JSP specification, making it available for use with all standard and custom components, as well as in template text. The EL has been extended with a function call mechanism that JSTL 1.1 takes advantage of to make a set of commonly needed functions readily available. JSP error pages now have access to more information about the error, through new variables that are better aligned with the error-handling mechanism defined by the servlet specification. The requirements for how containers report JSP syntax errors have been made stricter to make it easier to find out what's wrong. All J2EE 1.4 specifications, including JSP 2.0 and Servlet 2.4, use XML schema for declaration of the deployment descriptor rules. One benefit of this is that you can now list the declarations in the web.xml file in any order. JSP 2.0 also adds a number of new configuration options to the deployment descriptor, to allow for global configuration instead of per-page configuration. Writing JSP pages as XML documents is now much easier, thanks to more flexible rules and new standard action elements.

83 83 Custom tag libraries can now be developed as a set of tag files (text files with JSP elements), and tag handlers implemented as Java classes can use a new, simplified tag handler API. At the same time, a number of new features, such as support for a dynamic attribute list and executable fragment attributes, have been added. Compatibility with JSP 1.x : A JSP 2.0 container has to be able to execute applications with JSP 1.x syntax. Is possible to migrate a JSP 1.x application to JSP 2.0 syntax page to page Expression Language (EL) In JSP 1.x if you want to set a value to an attribute of a tag, is necessary to use an expression <% =... %>. Example: < jsp:usebean goes = " shoppingcart " scope = " session " class = " org.acme.shoppingcart " / > < xxx:if test =" <% = shoppingcart.getnumberofproducts () > 0% >" >... < /xxx:if > JSP 2.0 provide with the EL facilitate their construction. Example: < xxx:if test =" ${sessionscope.shoppingcart.numberofproducts > 0}" >... < /xxx:if > The expressions have to be surrounded for ${}. Any value that doesn't begin with ${, it is considered a literal. Here are some examples of access to attributes of Java objects:

84 84 ${user.firstname} = user.getfirstname() ${user.address.city} = user.getaddress().getcity() ${user.preferencesmap["shipping"]} = user.getpreferencesmap().get("shipping") ${user.preferenceslist[0]} = user.getpreferenceslist().get(0) This example show how to access to a JavaBean using the JSP 2.0 EL. The object is user, and instead of have to write scriptlets using Java code like on the right we can use the Expression Language provided by JSP 2.0.

85 JAVA STANDARD TAG LIBRARY (JSTL) JSTL got born with the intention of compile in one standard the most used Tag libraries that were circulating on the net. Basically they were for: Iterate over collections. Print values of JavaBeans properties in a safe way. Internationalization of messages, numbers, dates, etc. URLs generation applying URL rewriting. Access to XML documents. Etc The JSTL specification was development under the auspice of the JCP (Java Community Process). The JCP is a process supervised by SUN but open to companies, and particular individuals that guides the development and approval of the standards for the Java language. At the present time the JCP has 700 participants. The JSTL 1.0 specification was finished the 11 th of July Some days later the first implementation created by members of the Taglibs project of the Apache foundation appeared. The last JSTL version nowadays is it is 1.1, implemented by the Taglibs project. JSTL is optional in J2EE 1.4.

86 86 JSTL provides: Five libraries of JSP labels: o Common functions for iteration over data, conditional operations, and import of other pages (Core Tags). o Internationalization and text format (I18n Tags). o String manipulation functions. o XML process (XML Tags). o Access to databases (the use if this tag is only recommended for small applications or prototypes). An expression language to index objects and their properties without necessity of Java code. Tag Library Validators (TLVs) JSTL requires a JSP 2.0 container.

87 JAKARTA STRUTS Struts is a tool for the development of applications Web under the MVC patron using the J2EE platform. Struts is developed like part of the Jakarta project of the Apache Software Foundation. The original author was Craig R. McClanahan. Struts allows to reduce the development time, been free software and its compatibility with all the platforms where J2EE is available, it transforms it into a highly available tool. It is a framework that implements the MVC architecture pattern in Java. It works on any application server that implements the APIs servlets and JSP A framework is the extension of a language by means of one or more classes hierarchies that implement a functionality and (optionally) they can be extended. The framework can involve TagLibraries. As we mention before, the MVC architecture pattern (Model-View-Controller) is a pattern that defines the independent organization of the Model (Objects of Business), the View (interface with the user or another system) and the Controller (controller of the workflow of the application).

88 88 The MVC pattern architecture look like it follows: Figure 11

89 MVC in web applications The browser generates a request that is handled by the Controller (a specialized Servlet). The Servlet is in charge of analyzing the request, follow the configuration that has been programmed in the XML and call the corresponding Action (A java class that is used to access to the model) passing the corresponding parameters. The Action will instance or use the business objects (EJB) and they will do the task. Depending on the result of Action, the Controller will redirect to one or more JSP pages, which will be able to access the objects of the Model in order to carry out its task. STRUTS 1. Request CONTROLLER (Servlet) 2. Action WEB BROWSER 4. Redirect 3. Results MODEL (EJBs) 6. Result VIEW (JSP/TagLibs) 5. Uses So, Struts is basically the implementation of the View and Controller from the MVC pattern. It also implements the gateway between the controller and the model using the classes Action.

90 90 So, as we mentioned before, Struts is a framework that gives support to implement the View and Controllers layer of a Web application; it also provides: A Servlet Front Controller and related classes. Template system. Parameters validation. JSP Tag Library. The Servlet Front Controller pattern is the key of Struts implementation providing the basic structure of the MVC pattern. It is important to remember that Struts also provides a Tag library that can be used instead of the JSTL to generate the view; but it is also possible to use both at the same time. Struts Tag library provides the following type of Tags: Bean: Print the value of the JavaBeans properties in a safe way. Support for internationalization of messages. Logic: Flow control. HTML: Basic HTML generation: o Form inputs. o URL rewriting.

91 91 Tiles: Implementation of the Composite View pattern. o Template systems for JSP pages. It replaces Template. o Template systems was used with Struts 1.0 It is recommendable not to use the Bean and Logic Tags because JSTL provides the same type and it is a standard. In the other hand, Tiles is a powerful tool and it can be use along with JSTL. So, to generate the view we can use Struts+JSTL Tags.

92 Servlet Front Controller pattern The Servlet Front Controller pattern that Struts implements is show bellow: Figure 12

93 93 Let s take a look to each class of the Struts MVC implementation: ActionServlet. o It s the Servlet Front Controller. o In web.xml file is specified that all the URLs that imply process (GET or POST) are redirect to this servlet. E.g.: URLs that finishes in.do ActionForm Classes. o If the programmer wants it, can access to the request parameters through a JavaBean that extends from ActionForm. Specially useful in forms. Action Classes (method execute). o It access to the request parameters, directly or via the corresponding ActionForm. It carries out the operation invoking a method from the model. Usually the Session Facade of the model. The Session Facade is a design pattern that will discuss later on. o It leaves the result returned by the method in the request or in the session. o It returns an ActionForward object that represents the URL that is necessary to visualize next (sendredirect or forward).

94 Model View Controller architecture using Struts Model: o Independent classes from the view and the controller. Controller: o Group of Action classes. o Interact with the model and select the next view (leaving the data in one of the four possible environments, usually request or session) View: o Group of ActionForm classes. o Group of JSP pages. o They don t contain Java code. o They only visualize data. o They use JSP actions to recover the values to show and to format.

95 Struts Example On this section we will show an example using Struts to help to understand this framework and to see how easy is to create a MVC pattern architecture. This example helps to understand the most tedious part which are the configuration files. First, after install the JSP container, for example Tomcat, we download from the Struts implementation. Then, inside the WebApp directory we create the web.xml file with the main configuration. Figure 13

96 96 A standard configuration could be: <?xml version="1.0" encoding="iso "?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" " <web-app> <!-- Establish the default list of welcome files --> <welcome-file-list> <welcome-file>index.jsp</welcome-file> <welcome-file>index.html</welcome-file> <welcome-file>index.htm</welcome-file> </welcome-file-list> </web-app> After this, we need to modify the server.xml file to include the WebApp: Figure 14 <Context path="/example" docbase="example" debug="0" reloadable="true" crosscontext="true"> <Logger classname="org.apache.catalina.logger.filelogger" prefix="localhost_example_log." suffix=".txt" timestamp="true"/> </Context>

97 97 We create a basic HTML page as main page (index.html) and we have our Web Application. Now we can begin to add the components of Struts. We decompress the file and we should copy struts.jar file inside Tomcat library. Figure 15 We should also create a file struts-config.xml and to modify the file web.xml to add the struts tag-libs: <taglib> <taglib-uri>/web-inf/struts-bean.tld</taglib-uri> <taglib-location>/web-inf/struts-bean.tld</taglib-location> </taglib> <taglib> <taglib-uri>/web-inf/struts-html.tld</taglib-uri> <taglib-location>/web-inf/struts-html.tld</taglib-location> </taglib> <taglib> <taglib-uri>/web-inf/struts-logic.tld</taglib-uri> <taglib-location>/web-inf/struts-logic.tld</taglib-location> </taglib>

98 98 <taglib> <taglib-uri>/web-inf/struts-template.tld</taglib-uri> <taglib-location>/web-inf/struts-template.tld</taglib-location> </taglib> And to configure the Front Controller Servlet (ActionServlet): <!-- Standard Action Servlet Configuration (with debugging) --> <servlet> <servlet-name>action</servlet-name> <servlet-class>org.apache.struts.action.actionservlet</servlet-class> <init-param> <param-name>application</param-name> <param-value>applicationresources</param-value> </init-param> <init-param> <param-name>config</param-name> <param-value>/web-inf/struts-config.xml</param-value> </init-param> <init-param> <param-name>debug</param-name> <param-value>2</param-value> </init-param> <init-param> <param-name>detail</param-name> <param-value>2</param-value> </init-param> <init-param> <param-name>validate</param-name> <param-value>true</param-value> </init-param> <load-on-startup>2</load-on-startup> </servlet> <!-- Standard Action Servlet Mapping --> <servlet-mapping> <servlet-name>action</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping>

99 99 Now we can start writing our actions. We can create the following class with the first action: import java.io.*; import java.util.*; import javax.servlet.*; import javax.servlet.http.*; import org.apache.struts.action.*; import org.apache.struts.util.*; public final class accionbasica extends Action { public ActionForward perform(actionmapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException } { } request.setattribute("user","example"); // Forward control to the specified success URI return (mapping.findforward("home")); Then we tell the system how to map the request to this action using the struts-config.xml file: <action-mappings> <action path="/exaction" type=" Exaction "> <forward name="home" path="/homestruts.jsp"/> </action> Finally, we create the JSP page the way we want. To execute we have to start Tomcat and then go to next URL:

100 DISTRIBUTED APPLICATIONS A distributed application is an application whose procedure is distributed by multiple computers on a net. The distributed applications are at the same time capable to serve multiple users and, depending on their design, to make a more appropriate use of the resources. The organization of a distributed system is shown in the following figure: USER INTERFACE LEVEL INFORMATION PROCESS LEVEL DATA STORAGE LEVEL The natural progress of the software development consists on creating applications that are distributed on the net. The future distributed applications will be made up of many objects that will be distributed in several computers. There are several approaches and standards at the moment that give support to the development of distributed applications, establishing the communication outline and distribution of the different components in the net. Many enterprise applications works on a distributed system having different modules working on different machines; understanding distributed applications are crucial to develop enterprise applications. Next, the different solutions for the design and implementation of distributed applications are detailed.

101 Distributed Applications on Internet The popularity of Internet has made grow the distributed applications that are executed on a structure. These first generation applications admit communication based on specific application protocols like HTTP, FTP Intranet Applets In an intranet environment, the corporate information systems admit services that adapt to the organizational necessities of the company. These intranet services can be implemented by Client/Server services, as a company Internal Web. The Java applet paradigm offers the possibility to execute the client interface layer and part of the information process layer Distributed Computation Environment (DCE) The Distributed Computation Environment (DCE) constitutes another focus for the construction of distributed applications. It was developed by the Open Software Foundation that now is call you Open Group ( DCE integrates a series of services and fundamental technologies to build distributed applications. The distributed systems are organized in cells that are groups of resources, services and user process that admit common functions and they share a group common DCE services. The DCE provides intermediate support, since it is not an autonomous product, is a services package that is integrated in an operating system.

102 102 The services and technologies that DCE uses in a cell are the following: Directory Services (CDS and GDS): They store the names of the resources that are available inside the distributed environment. Distributed Files Service (DFS): It provides a file system that operates in all the computers in a cell. Distributed Time Service (DTS): It is used to synchronize the hour in all the computers in a cell. Remote Procedure Call (RPC): They replace the TCP sockets like basic mechanism for the communication. DCE Threads: They are thin processes that simplify the design of Client/Server applications. Figure 16

103 Distributed Component Object Model (DCOM) The Pattern of Distributed Component Object Model (DCOM) it is the Microsoft solution for the development of distributed systems. The DCOM is based on COM that constitutes the nucleus of Microsoft object oriented development strategy. COM is the result of the Microsoft Object Linking and Embedding (OLE) technology that allowed to admit compound documents, documents that could manage multiple applications. The COM objects are instances of classes and they are organized in interfaces (simple collections of methods). The COM objects can only be accessed thru his methods, and each object it is implemented inside a server. A server can be a.dll file, an independent process or an operative service. COM avoids the details of the implementation and it presents an unique and uniform interface for all the objects, independently how each one is implemented. The interface language definition that is used to define the interfaces and methods of COM comes from DCE. DCOM is in essence the COM distributed on multiple computers. The communication among machines is carried out through RPC of objects, or ORPC, The ORPC is based on the Microsoft RPC that is in essence, the RPC of the DCE. The ORPC can be configured to use a series of transport protocols, but it works better with UDP.

104 104 Although DCOM is a Microsoft product, it constitutes an open standard that has been transported to other operative systems like UNIX. Microsoft tries that the DCOM becomes a solution of crossed platform for the development of distributed applications, although at the moment has not been very successful. The Java development kit of Microsoft includes a JVM and an API that provides an interface to the COM and DCOM. Here is an example of the DCOM architecture: Figure 17

105 Common Object Request Broker Architecture (CORBA) The Common Object Request Broker Architecture (CORBA) offers another approach to the construction of distributed systems. CORBA, like the DCOM but contrary to the DCE, it is object oriented. It allows the objects of a computer invoke the methods of objects of other computers. CORBA, contrary to DCOM, is an open solution and it is not linked to any operating system. CORBA uses the objects that are accessible through the Object Request Broker (ORB). The client interface to the ORB is an adapting fragment that is written in Interface Definition Language (IDL). The adapting fragment it is seen as a local proxy of the remote object, providing a mechanism of independent language programming to describe the methods of an object. Figure 18

106 106 CORBA instead of depending on clients and monolithic servers (like browsers and Web servers), the applications can be distributed on several hosts. The advantages that CORBA has are the following: It provides a true OO focus for the development of distributed applications. It is independent of the language. You can use CORBA to connect objects develop in any programming language. It is recognized as an international standard and is admitted by almost all the main companies. Figure 19

107 Java Remote Method Invocation (RMI) The distributed object model that Java uses allows objects executed in a JVM, invoke methods of objects that are executed in another JVM. The object that makes the invocation is denominated client object or local object, while the object whose method is invoked is denominated server object or remote object. A client object never makes direct reference to a remote object; it uses a remote interface that the remote object implements (adapter fragment). This allows compiling the client objects using the remote interface, eliminating the necessity that the files with the classes of the server are present locally during the compilation process. Besides from the remote interfaces, the model uses classes belonging to the adapting fragment and to the skeleton. The client interface invokes the methods of the fragment local adapter object. The local adapting fragment communicates these methods invocations to the remote skeleton, while this last one invokes to the methods of the server object. Figure 20

108 108 The transport layer uses TCP sockets by default to communicate with the skeleton of the server, although other protocols can be used like SSL and UDP. To access to a server object, this should register by remote registration. The remote registration is a process that is executed in the server and it is created executing the program rmiregistry (JDK tool). To be able to carry out this operation it should be active the Java RMI System of Activation Demon in the remote system (tool rmid of the JDK). So when an client object passes an argument as part of the method remote invocation, the argument type will be serializable (all the Java primitive types are serializable, and also all the classes and interfaces that implement the Serializable interface of the package java.io). A class is serializable when it can be converted to a series of bytes, so it can be transmitted, for example, over a network. When a local object is passed like argument to a remote method invocation, the local object will be copied from the local JVM to the remote JVM. The variables will only be copied if they are not static or transitory (declared without the static or transient modifier). The characteristics that should complete a distributed application that is implemented using RMI are the following: The class of the remote object should implement an interface that extends Remote interface. This interface should define the methods that the object will allow to be invoked. These methods should throw the RemoteException. The class of the remote object should extend the class RemoteServer. This is usually made extending the subclass UnicastRemoteObject of RemoteServer The adapting fragment and skeleton classes of the remote object should to be created by using the compiler rmic. The adapting fragment should be distributed to the client's host.

109 109 The class, interface and the skeleton of the remote object, should be in the CLASSPATH variable of the remote host. The daemon of remote activation and the remote register should be activated. An instance of the remote objects should be created, and it should be registered in the remote registration. The methods bind() and rebind() of the class Naming are use to register an object with their associate name. The remote object should install a security administrator to allow the load of the RMI classes. Figure 21

110 110 Now let s take a look of an example of a distributed client/server calculator using RMI: 1. First, we create the interface that extends from the Remote interface with the public methods that we want to make public available. import java.rmi.*; public interface ServOper extends Remote { int sum(int x, int y) throws RemoteException; int minus(int x, int y) throws RemoteException; int multiply(int x, int y) throws RemoteException; int divide(int x, int y) throws RemoteException; } 2. Then, we create the class which implement the interface. This class extends from UnicastRemoteObject import java.rmi.*; import java.rmi.server.*; import java.rmi.registry.*; public class ServOperImpl extends UnicastRemoteObject implements ServOper { static String hostname="localhost"; public ServOperImpl() throws RemoteException { super(); } public int sum(int x, int y) throws RemoteException { return x + y; } public int minus(int x, int y) throws RemoteException { return x - y; } public int multiply(int x, int y) throws RemoteException { return x * y;

111 111 } public int divide(int x, int y) throws RemoteException { return x / y; } } public static void main(string args[]) { System.setSecurityManager(new RMISecurityManager()); try { LocateRegistry.createRegistry(1099); // Default RMI port ServOperImpl serv = new ServOperImpl(); Naming.rebind("//" + hostname + "/ServOp", serv); System.out.println("Correct!!"); } catch (Exception ex) { System.out.println(ex); } } 3. Finally, we write the client class. import java.rmi.*; public class ClientOper { static String hostname="localhost"; public static void main(string args[]) { try { ServOper serv = (ServOper) Naming.lookup("//" + hostname + "/ServOpe"); System.out.println("Executing > result: " + serv.sum(3, 5)); System.out.println("Executing 3-5 -> result: " + serv.minus(3, 5)); System.out.println("Executing 3 * 5 -> result: " + serv.multiply(3, 5)); System.out.println("Executing 3 / 5 -> result: " + serv.divide(3, 5)); } } catch (Exception ex) { } } System.out.println(ex);

112 Java RMI as a technology for development enterprise applications We will discuss now the positive and negative aspects of using Java RMI to develop enterprise applications. Positive aspects: It allows separating the view and the controller physically from the model in a simple way. o Advantages of the 3 layers architectures. It can work over IIOP o A client CORBA can access to a Java RMI object. Negative aspects: Scalability o We would like to have a solution that allows to reply the model layer in several machines, transparently to the developer. Security o We would like to have a solution that allows to specify what roles can invoke certain methods of an remote object. Transactions o We would like to have a solution that hides the transactions API. o We would like to have a solution that allows distributed transactions.

113 113 Persistence o We would like to have a solution that automates the persistence of the objects in the persistent domain. It would not be necessary to program DAOs[1] (Data Access Object). It decreases the development time. It maximizes the portability (the software doesn't depend on the database type). To help developers to overcome these difficulties the Enterprise JavaBeans were introduce. [1] DAO (Access Object Dates): Is a design pattern used to access to the Objects Valued (VO) with the intention of uncouple the business logic from the data logic.

114 JAVA NAMING AND DIRECTORY INTERFACE (JNDI) JNDI is a Java technology used in distributed environment base on Java applications. Naming and directory services play a vital role in intranets and the Internet by providing network-wide sharing of a variety of information about users, machines, networks, services, and applications. Figure 22 A naming service maintains a set of bindings. Bindings relate names to objects. All objects in a naming system are named in the same way. Clients use the naming service to locate objects by name. There are a number of existing naming services, we will describe the most useful ones: 1. COS (Common Object Services) Naming: The naming service for CORBA applications; allows applications to store and access references to CORBA objects. 2. DNS (Domain Name System): The Internet's naming service; maps peoplefriendly names (such as into computer-friendly IP (Internet Protocol) addresses in dotted-quad notation ( ). Interestingly, DNS is a distributed naming service, meaning that the service and its underlying database is spread across many hosts on the Internet.

115 LDAP (Lightweight Directory Access Protocol): Developed by the University of Michigan; as its name implies, it is a lightweight version of DAP (Directory Access Protocol), which in turn is part of X.500, a standard for network directory services. Currently, over 40 companies endorse LDAP. 4. NIS (Network Information System) and NIS+: Network naming services developed by Sun Microsystems. Both allow users to access files and applications on any host with a single ID and password. JNDI is a Java API that provides naming and directory functionality to applications written in the Java programming language. It is designed especially for the Java platform using Java's object model. Using JNDI, applications based on Java technology can store and retrieve named Java objects of any type. In addition, JNDI provides methods for performing standard directory operations, such as associating attributes with objects and searching for objects using their attributes. Also, JNDI defined independent of any specific naming or directory service implementation. It enables applications to access different, possibly multiple, naming and directory services using a common API. Different naming and directory service providers can be plugged in seamlessly behind this common API. This enables Java technology-based applications to take advantage of information in a variety of existing naming and directory services, such as LDAP, NDS, DNS, and NIS(YP), as well as enabling the applications to coexist with legacy software and systems.

116 JNDI Architecture The JNDI architecture consists of an API and a service provider interface (SPI). Java applications use the JNDI API to access a variety of naming and directory services. The SPI enables a variety of naming and directory services to be plugged in transparently, allowing the Java application using the JNDI API to access their services. Figure 23 JNDI is divided into five packages: javax.naming: contains classes and interfaces for accessing naming services. javax.naming.directory: extends the javax.naming package to provide functionality for accessing directory services in addition to naming services. This package allows applications to retrieve attributes associated with objects stored in the directory and to search for objects using specified attributes.

117 117 javax.naming.event: contains classes and interfaces for supporting event notification in naming and directory services. javax.naming.ldap: contains classes and interfaces for using features that are specific to the LDAP v3 that are not already covered by the more generic javax.naming.directory package javax.naming.spi: provides the means by which developers of different naming/directory service providers can develop and hook up their implementations so that the corresponding services are accessible from applications that use the JNDI. We will use the javax.naming package to localize our data sources in a distributed environment.

118 ENTERPRISE JAVABEANS (EJB) Enterprise Java Beans is an architecture that defines the way of building distributed components on the server side. This technology guarantees that the programmed components are scalable, effective and safe in spite of the simplicity of its development, but without a doubt, they have a great amount of concepts that we need to clarify before continuing. These are the main characteristics of the EJB: The EJB is distributed component, this means that we can speak of components that are executed in different servers, possibly using different databases (it is a decision of the analyst-developer). The EJB is executed inside an application server; these servers should follow the standard fixed by SUN Microsystem INC. They are in charge of negotiating resources like net, the connection pools, or the administration of the security. The developer builds the EJB and the application servers negotiate them. The EJB helps the modulate programming; the idea of the programming based on components is the dream of many and the EJB make it possible in a simple way. You can program your component or you can buy it from others, but it will always exist a division and independence among the different components in a system. Inside a system it becomes possible to add or to remove a component without the rest notices the difference.

119 119 The specification that the EJB defines is public and in several companies work on it. Anyone can download from Internet the standard and program their own application server. If that server implements the public interfaces correctly, and it completes the specification it will be able to execute an EJB correctly. There are several implementations right now on the market, many of them open source like JBoss. Some of them are more efficiently than others depending in how they implement the standard. EJB is Java. To program reusable components a clear separation it is needed between interfaces and their implementation, and Java supports it. Java is stable, safe and multi-thread, rarely it gets block and has one of the richest APIs. Java is platform independent, this allows that our components to be reutilize in different projects independently of the platform that they will be executed. EJB solves daily life problems, they can communicate between each other and solve the business logic, they can access to any database that has implemented a JDBC driver, or to access to other systems through an SOAP interface or a web service.

120 EJB Architecture Distributed components The EJB is a software component that is executed in the server part of an application and they can be executed in a distributed multi-layer environment. Although we could define component as piece of accessible software through a public interface, in the case of the EJB, the software and this interface (in fact two) should follow the standard and mandatory implement certain methods that this specification defines, this way the EJB containers can negotiate the life cycle in an uniform way being independent of the container that carries out the task. The EJB are components that can be physically far from the client, for it, it s said that their public interface is remote, Remote Interface. The EJB specification makes use of RMI/IIOP to offer this characteristic. In RMI/IIOP all remote object has an accessible interface for the clients, the client can make use of this interface through the stub that is a proxy sent to the client. When the client invokes the stub, this communicates with the skeleton that is the proxy located in the server side. Once the skeleton received the message he is in charge of communicating it to the distributed object, which will solve the operation (business logic) and he will return the answer to the client through the first skeleton and the stub later. As much the stub as the skeleton are transparent for the client and they always has the sensation of being invoking to the distributed object directly. The problem is that in this type of operations the load is quite heavy: requires to open sockets, transfer objects through the net and transform these objects in binary data according to the protocol (in this case IIOP).

121 Implicit or Declarative Middleware The key of the modern distributed components is that its middleware is implicit, this means, that the code of our software doesn't call directly to the software integrated in the server, but rather it defines in the describer of each component, how we want the context where the code it s executed. For example, an EJB doesn't have the necessity to call in an explicit way, in the code, the transactions API to begin a transaction (atomic operation on the database) but rather we can define in a different file, how we want the EJB to behave. For that, apart from this file where is defined the EJB behaviour, another file is needed tot capture the call to the distributed components and configure the way in that these components will work. In the case of EJB is the EJB Object. The EJB Object is generated by the own container and it is in charge of interact with the container to offer its services. Among other services, it offers the administration of distributed transactions, security, administration of the life cycle, persistence, etc. The advantages are simpler components; the code is centred in solving the logic and not in the way of solving it. You can also change the behaviour of the EJB without modifying their code, only modifying the file that specifies how they should work which is the describer.

122 Physical situation transparency The specification says that it can vary the place where the EJB is, but in some way it is needed to know how we can access to them, this it is the Home Object work. The Home Object is in charge of create and to destroy the EJB Object. It is an object generated by the container, of type Factory that implements the second of the public interfaces of an EJB, the Home Interface. This way the container knows which the EJB type is, which parameters should pass the EJB Object to create a new component or what type of searches the user has defined to obtain the reference to several components. It is important to point out that it exists only one EJBHome implementing their corresponding Home Interface for each type of EJB in each container. This makes possible to search the reference in some cases Local interfaces In the EJB specification 1.1 this concept didn't exist but many application servers began to implement improvements for calls inside one Java Virtual Machine (JVM), this way the necessity of translating the data to RMI to make a non remote call was eliminated. People in charge of the specification realized about this necessity and they created the local interfaces in the version 2.0; that only allow receiving clients' calls of the same JVM. These calls are much quicker and the parameters are also passed by reference and not by value, which decreases the memory consume.

123 TYPES OF COMPONENTS At the moment the standard EJB defines three types of EJB: Session Beans (SB) The session EJB is in charge of solving the business logic of the application. We can say that each method contained in a SB solves a use case (function) of the application, for example: User Control, Prices Agent or Processes Control. In the EJB specification we can find two types of Sessions Beans, State Less (SLSB) and State Full (SFSB). State Less Session Beans The SLSB is component without state, this means, they don't keep any relationship between different calls from a client. Even more, between two calls to the same type of SLSB is possible that the container addresses the client to different instances of the component. Another fact of how they behave this type of components it is their relationship with the number of users. For N users there are M instances being M < N in most of the cases. The maximum value and minimum of M is configurable in most of the servers. With these two values is defined the size of the object pool. The objects pool has been used from the beginning of Java. This is, define a space in memory for several objects, in such a way that instead of having to instance an object every time, we can reuse the existent instances in the pool. This causes memory consumption but offers faster speed. It also makes the garbage collector work less, with this, the improvement of results is quite remarkable. That is the objective of the EJB pools that use the containers, reuse the EJB instances in memory.

124 124 The container guarantees that to an EJB instance only one thread can access, with that we will never have a concurrence problem inside an EJB, the container solves it for us. State Full Session Beans The SFSB is the opposite of the SLSB, they maintain the state, this means, they have a conversation one to one with each client that invokes them. To maintain this conversation it is necessary to make use of the Handle object. The Handle object is a serializable reference to an EJB object. Keeping this reference you can access later on to the EJB with which the client had established a relationship. With the SFSB each client has associate an object EJB during a conversation. In case this reference gets lost, it can recover thanks to the Handle object. For that reason is the client who has to take care of preserving the instance of these objects if he wants call to their SFSB again. For many people, this type of EJB is consider as true heavy scheme and its use is dissuaded in most of the cases. Others maintain their utility for the possibility of maintaining a session distributed among several servers. In any of the cases hibernation should be avoided. The hibernation is the serialization process to disk of those less recently used instances (although it is possible to specify another hibernation policies depending on the application server) when the number of instances required by the clients is bigger than those that can support the SFSB pool. This process can take place, because the server runs out of memory or because it has reached the limit of maximum instances configured on the describer. The opposite process is called activation, and takes place when a client calls to a method of his associate SFSB and this is hibernated.

125 Entity Beans The entity EJB is directly related with the application data, are objects that maintain in memory the data that the application manages like News, Forums, Users. The Entity Beans usually map the relational database tables, although it is also possible that they maintain the data persistence in files, for example a XML, or in LDAP. In any of the cases the objective of an Entity Bean is to search the data in memory from a persistent source and to maintain a total synchronization between the state of the data in memory and the source of the data. For this reason it is said that the Entity Bean are the EJB that survive to the system falls, in the case of a system failure, the data in memory is kept in a persistent device, with this, when the server is restarted they recovered without any problem. This type of EJB totally abstracts the persistence layer of the system and it works like a tool for translation from a relational database to an object, for example, you could change the a column name of a chart in a table and the rest of layers would not realize, since to that column will only be accessed through a get/set method of the Entity Bean. Maybe the critics to this type of components come for the slowness in the search functions (call finders). These methods return a remote collection of interfaces that follow a series of conditions, similar to the SQL instructions. Although it is true that it is slower than a simple SQL query, but usually is not much bigger if the queries make a correct use of the transactions and the number of calls is minimized through the net. If there is a use case that has to return a big object collection the Fast-Lane Reader pattern can be implemented to speed up the process, this patterns says that in these cases where we have a big collection of objects a DAO should be used instead of an entity EJB. We will discuss pattern more in detail later on. As it has been explained before, the EJB stays inside a pool in memory. In the case of the Entity Beans this means that we have several rows of the database in memory, and we can get very quick accesses to those rows, therefore is interesting to maintain those registrations that we believe are we going to use again in memory.

126 126 Inside the Entity Beans there are two forms of managing persistence: one lets the programmer to manually take care of the persistence, in the other the container takes care of everything. Bean Managed Persistence The BMP is the Entity Bean that support persistence thanks to the programmer's explicit instructions; this has to introduce the necessary instructions in the methods defined by the interface EntityBean: ejbload, ejbremove, ejbcreate, etc. Every time this type of Entity Beans is used less, but there are still some operations that can only be carried out thanks to the programmer abilities. In any of the cases, they continue being indispensable when the persistence is not gotten through a relational database. Container Managed Persistence The CMP supports the persistence in a declarative or implicit way thanks to the container; this means that, it is not necessary to implement the methods of the EntityBean interface, it is only necessary to define in a correct way the describer so that the container has this way the necessary information to negotiate the persistence against a relational database. Although in the principles of the EJB, Entity Bean type was not very used, since the programmers didn't trust much of the containers, nowadays are most used ones and they are even recommended because of efficiency issues with regard to the BMP. To create a CMP is really simple and the amount of functions that it carries out is really impressive, many programmers, the first time that see how easy is to create an Entity Bean they get really surprise.

127 Message-Driven Beans They are very similar to the session beans but they receive messages without responding to the client, in other words, they are asynchronous. Purchase authorization or card checkout are examples of this new EJB introduce in the 2.0 specification. Their only method, onmessage, receives the message type and with him carries out a series of operations and the user won't obtain direct answer. When this type of operations will be carried out at an uncertain time and it is not necessary the immediate answer to the client, is when we use this kind of EJB.

128 J2EE EJB Structure The general EJB structure, as we mention before, looks like it follows: Figure 24 As we can see on the diagram the Enterprise JavaBeans are in charge of implement de business logic (Session Beans) and also the data layer (Entity Beans).

129 129 This is a more concrete example of J2EE architecture: Figure 25 Here we have Apache as Web Server and Tomcat as a JSP container as part of the view layer. Apache is in charge of serving HTML pages and Tomcat is the JSP in charge of compiling the JSP pages into Servlets. Jboss is the EJB container and it manages the different EJB that are part of the model and also are the ones who access to the database.

130 EJB Operation Now we will take a look on how the EJB work. We will use a small example to see how to develop using EJB. First, let s review the EJB parts. Enterprise JavaBeans Parts: EJB class that implements the business methods and life cycle methods; uses other helper classes and libraries to implement. Client-view API: consists of EJB home interface and remote interface. o Home interface: controls life cycle: create, remove, and find methods. There should be one Home interface for each local or remote interface. o Remote interface: to invoke the EJB object methods (if the EJB is declared as remote). o Local Interface: Idem for local EJB. Deployment Descriptor: XML document for bean assembler and deployer on the container. o A declaration about EJB environment needed for customizing the bean to the operating environment. Container Runtime services include: transactions, security,distribution,load balancing, multithreading, persistence, failure recovery, resource pooling, state management, clustering

131 131 Naming Convention: EJB class is a descriptive name of the business entity or process with the word Bean appended. Ex: AccountBean. Home interface is same as business entity name with the word Home appended. Ex: AccountHome. Remote interface is just the name of the entity. Ex: Account. The name of the entire EJB (reference in deployment descriptor) is same as the entity name with EJB appended. Ex: AccountEJB. Enterprise JavaBean componets: Next, we show the classes used in the example with their usual methods. <<Home Interface>> AccountHome create() find() remove() <<Remote Interface>> Account debit() credit() getbalance() <<Enterrpise Bean class> AccountBean ejbcreate() ejbfind() ejbremove() debit() credit() getbalance() Deployment Descriptor name = AccountEJB class = AccountBean home = AccountHome remote = Account type = Entity transaction = required..

132 132 General Diagram: Figure 26 The EJB Object is the EJB interface; it can be local or remote. It specifies simple operations to manipulate the state of the bean or to recover it. It doesn't represent business logic, but the persistent state. In our case, the interface is remote (Account). It extends from the EJBObject interface. EJB Home is another additional EJB interface that usually has the searching operations. In our case it s AccountHome. It extends from the EJBHome interface. Finally we have the Bean, in our example AccountEJB; which implements the EJB. Is important to realize that: An CMP Entity Bean doesn't need to implement the search methods In a BMP Entity Bean a DAO is used to implement the search methods Additional services are provided by the EJB container.

133 133 Class diagram of the Remote and Home Interface: Figure 27 As we can see, the EJB nucleus is RMI. We can see how EJB is just a specification that uses interfaces that the programmer has to follow, so we just have to extend from EJBObject and write our EJB interface (Account) and extend EJBHome and write our EJBHome interface (AccountHome).

134 134 This is the class diagram for the Bean: Figure 28 In the case of Entity EJB, the programmer just has to implement the EntityBean interface, in our case the class is AccountEJB.

135 135 Implementation AccountHome Interface: import java.rmi.remoteexception; import javax.ejb.createexception; import javax.ejb.finderexception; import java.util.collection; public interface AccountHome extends javax.ejb.ejbhome { //create methods Account create (String lastname, String firstname) throws RemoteException, CreateException, BadNameException; Account create (String lastname) throws RemoteException, CreateException; // find methods Account findbyprimarykey (AccountKey primarykey) throws RemoteException, FinderException; Collection findinactive(date sincewhen) throws RemoteException, FinderException, BadDateException; EJBHome Interface: import java.rmi.remoteexception; public interface EJBHome extends java.rmi.remote { void remove(handle handle) throws RemoteException, RemoveException; void remove(object primarykey) throws RemoteException, RemoveException; EJBMetaData getejbmetadata( ) throws RemoteException; HomeHandle gethomehandle() throws RemoteException; }

136 136 Account Interface: import java.rmi.remoteexception; public interface Account extends javax.ejb.ejbobject { BigDecimal getbalance() throws RemoteException; void credit(bigdecimal amount) throws RemoteException; Void debit(bigdecimal amount) throws RemoteException, InSufficientFundsException; } EJBObject Interface: import java.rmi.remoteexception; public interface EJBObject extends java.rmi.remote { public EJBHome getejbhome() throws RemoteException; public Object getprimarykey() throws RemoteException; public void remove() throws RemoteException, RemoveException; Public Handle gethandle() throws RemoteException; Boolean isidentical (EJBObject obj2) throws RemoteException; }

137 137 AccountBean class: public class AccountBean implements javax.ejb.entitybean { // life cycle methods from home interface public AccountKey ejbcreate (String latname, String firstname) throws { } public AccountKey ejbcreate(string lastname) throws { } public AccountKey ejbfindbyprimarykey(accountkey primarykey) { } Public Collection ejbfindinactive( Data sinecwhen).. { } // business methods from remote interface public BigDecimal getbalance() {.} public void credit(bigdecimal amt) { } public void debit(bigdecimal amt) throws InsufficientFundException {.} // container callbacks from EntityBean container public ejbremove( ) throws RemoveException{ } public void setentitycontext(entitycontext ec) { } public unsetentitycontext(entitycontext ec) { } public void ejbactivate() { } public void ejbload() {.} public void ejbstore() {.} }

138 138 As we can see in the example; EJB provides a simple way to build persistent and distributed objects. It may be difficult to understand the architecture and hot it works but once learned we can build distributed enterprise applications very easily. EJB is the key of the J2EE platform. It competes with other technologies like CORBA or COM+. Nowadays, CORBA is not suitable to develop Web applications and is only used on intranets; this is due to its complexity and because is still very difficult to make total portable applications and developers find many problems with the portability issue with CORBA. About COM+, the Microsoft solution, we go back again to the old dilemma: Sun or Microsoft? We will discuss in detail this issue on the next section.

139 J2EE vs..net We have been talking a lot so far about these two rival platforms, now let s summarize everything Similarities between J2EE and.net The goal of J2EE and the.net platform is to facilitate and simplify the development of enterprise or corporate applications. The JSP (Java Server Pages) are very similar to ASP (Active Server Pages) or to its descendant ASP.Net, and the EJB (Enterprise JavaBeans) are very similar to the COM/COM+ of Microsoft. The J2EE applications servers and.net provide a model of component access to data and of business logic, separated by an intermediate presentation layer implemented by ASP.Net (:Net) or Servlets (J2EE). Visual Basic.Net and C # are objects oriented languages created for the Microsoft platform, and in their design the existence of Internet has a lot of importance. From the perspective of the developers, J2EE and.net provide the tools to create Web services. As it has been exposed J2EE and.net are multiplatform. Since.Net is using a compilation in two steps, it would allow it theoretically in the future to provide execution environments for different platforms in a similar way to Java and their JREs and SDKs.

140 Advantages of.net over J2EE a) A very important advantage of the environment.net in front of J2EE is the possibility to use different programming languages, whereas J2EE only works with one: Java. However, some theoretical could think that the best thing would be that there was only one programming language (to be possible standardized), this idea is as utopian as to think that Esperanto will finish substituting the other human languages. The reality is that this high diversity of languages is obligatory for the same variety of the necessities of the programmers. Today more code lines are written in Cobol than in C++ or Java. A modern language and object oriented like Java can be completely ineffective -and even inadequate - when approaching problems that involve massive and complex mathematical calculations, while those same calculations can be approached much more appropriately with such a primitive language as Fortran 77. On the other hand,.net facilitates programmers of third languages to pass to this platform reducing the time of learning and training. b) The development tools included by Microsoft in their Visual Studio.Net are much more simple, intuitive and simple of managing than the equivalent development tools in J2EE given by other companies (among them, Sun). Any intermediate/advanced programmer will manage quickly with the programming of user's interface in Visual Studio.Net, the same as it happened to previous versions of Visual Studio. c) C # is an interesting language, easy to learn for the programmers from Java (in fact, Microsoft offers a conversor from Java to C #) that could be a very convenient language for certain programming tasks in different platforms in the case of being standardized. It is not written in any part that the languages cannot evolve (in fact, the programming languages and the human languages do it) and, in that sense, C # is an another evolutionary branch of the tree of the object oriented languages.

141 141 d) Microsoft has impulse with great energy the Web services and it has stood out its importance among the whole developers community. The platform.net has been designed considering the Web services (but not J2EE) being these services characteristic of the platform and offers a new version of ASP, ASP.Net, that can really be considered a programming environment instead of an environment based on scripts. In terms of the own Microsoft,.Net was built for the integration through the XML Web services using protocols and file formats like SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language), and UDDI (Universal Description, Discovery, and Integration). If we compare,.net has advantage with regard to J2EE relating to Web services and these services are characteristic of the platform, although J2EE already responded with the launching of the Java Web Services Developer Pack. Anyway, the easiness, speed and simplicity that allow us to build Web services with the Assistant of services Web of Visual Studio.Net are very superior to the tools to build Web services within the environment of J2EE. But like always, J2EE changes more quickly than.net platform and new Java platforms like Eclipse are emerging and integrating many Web services.

142 Advantages of J2EE over.net a) The implementations of J2EE can be acquired to different companies, whereas.net can only be bought to Microsoft. The fact that there are different organizations implementing J2EE offers big variety for the final users and it allows the existence of a certain competition among them to obtain better products that it doesn't exist in the case of Microsoft and his.net platform. b) Due to the evolutionary process of the Microsoft products, and in many cases, because of reasons of compatibility the security against computer virus of the products of Microsoft is smaller than those based on Java, because from a beginning Java was based on a strict security model. c) Like it has already been written, the Java applications can run in a wide range of operative systems (from enterprise systems as Windows 2000, OS/390, Solaris, HP-UX, IRIX or other Unix versions to systems guided more to personal computers as Mac OS, Windows 9x or Linux, and in operative systems for mobile devices) and of architectures hardware. So far,.net only runs on Microsoft operative systems (although this situation could change in the future), being J2EE the only development environment that offers a real independence of the platform. d) The Java technology is an open technology (in the sense that the code of the complete platform can be obtained, revised and studied by anyone that is interested) and it is largely based in standard of normalization organizations. This facilitates that the developers can know and understand completely how Java works and take advantage of it for their applications and, on the other hand, when being based in enterprise standard, it simplifies the integration with products of multiple companies.

143 143 In contrast, only the source code of the new C# language of the.net platform has been open to the general public (although Microsoft allows companies that have common interest with them, the access to the source code of certain parts of.net). a) Although Java was created originally by a company: Sun MicroSystems, the true is that J2EE are now the product of the collaboration of more than 400 companies and organizations of all type (public, non-profit private, profit private, and of normalization in national and international environments). The.Net platform is -and it will be - the product of a single company that although it has implemented some standards in.net and tried to get that certain technologies become official standards, have the same consent that.net (mainly keeping in mind that most of its code is not public). b) The Java technology already enjoys a certain maturity (many years in the market). J2EE and it has proven their effectiveness in many environments and different enterprise situations, while.net has seen the light officially in 2004.

144 The Future Java is a language thought to last among the programmer community. Although Microsoft insists that within the.net strategy Java is one language more, the true is that it has extended so much among the programmer, educational and investigator community, that its future is even promising, in spite of the strong competition of Microsoft. Possibly many C++ programmers will finally program in C #, for the own nature of the applications that they develop, but many of them also finished programming in Java when developing applications guided to the Net. Until the moment, the J2EE platform is the only platform that runs in multiple operating systems and multiple hardware and whose users can select the implementation that suits more to them. This platform runs at the moment not only in domestic computers or servers or work stations, but also in multitude of devices like mobile telephones, electronic calendars, industrial electronic components, etc. Their installation in the market of the mobile telephones GMS and UMTS can assure a prosperous future, since it is more than probable that will finally become a common media to access to Internet. Java has already made reality the dream of write the code once, execute it anywhere.". Like it was pointed out before, it is perfectly possible that Microsoft provides in the future.net execution environments for different platforms in a similar way to Sun (like for Windows 64 bits Itanium or for a Windows CE on a Pocket PC), but has not still made it for non-windows platforms, and it would be strange that they make it for its own strategy till today. Even this way, it would arrive with a considerable delay with regard to J2EE. On the other hand, we should not forget that in the last announcements of Microsoft technologies transfers to other platforms (component DCOM, for example) they didn't end up being materialized.

145 145 The Microsoft policies, for internal (intents of incorporating new technologies and/or tendencies to their products) and legal reasons, have changed so much that, in some cases, they have abandoned developers and programmers that had adopted their solutions to their luck (a very curious case were the Active Documents; a solution that allowed the programmers of Visual Basic to create web applications without using script programming. This solution, although it looked promising, followed identical road that the dinosaurs). Also because of Microsoft commercial reasons, the substitution of products and technologies for other has been so quick and repetitive that many developers of small and medium companies have given up to follow that evolution, and they have kept technologies from Microsoft that no longer gives support (RDO, DAO, for example) or they have moved to Java. The Microsoft statement to program is more and more easy with.net are not enough for the companies that have invested multitude of technical, economic and personal resources in products and/or Microsoft technologies already obsolete, and also incompatible with the new products. Against this, J2EE offer some comparative perspectives much more stable (big multinationals have made the decision of not beginning to use.net and to continue or to begin with J2EE). On the other hand, the Microsoft penetration in the market of the big corporate systems and in the enterprise applications of high level it is not excessively high. In the elaboration of J2EE multitude of companies have participated, many of them specialized in giving service software/hardware to big companies and corporate systems and that, therefore, they know that sector very well. This plurality, also makes more probable than J2EE it finishes becoming a de facto standard", when having been developed with the participation of many companies that, inevitably, they will have looked toward its own products when elaborating it. J2EE maybe doesn t end up becoming a standard type ISO or IEEE, but after all the protocol TCP/IP is also a de facto standard."

146 146 As we mention before, inside the Visual Studio.Net the Visual Basic.Net language is a true object oriented language. But it also has its problems: although many professional programmers considered VB to be like a smaller language, it was (and it is) the most used language of the planet due overalls to its simplicity. With VB.Net, they are necessary some solid knowledge of programming OO to appreciate in depth the advantages of the same one and to create programs that take advantage of all their possibilities. A programmer that possesses all these knowledge will probably decide to work in C# or Java that have a more standard syntax. Who knows, maybe to suppress the simplicity of Visual Basic to make it more modern can make it loose its charm. C # is a language that can become a stupendous tool for developers that want to elaborate code of high efficiency, without having that deal with in C++, but it is still soon to be able to affirm anything sure about the future. Even this way, it is a language of high quality and it will surely be ideal to program inside.net for their symbiosis with the platform. The web services should still travel a long road among standard, services providers and consumers, but until the moment Microsoft and specifically.net takes a certain advantage on J2EE. Even this way, it continues planning the question of the independence of the platform. If.Net doesn't finish being really multiplatform, possibly J2EE will prevail in the development of Web services for big companies and for web services clients that require not to depend on a specific platform, and.net will prevail in the development of Web services for small and medium companies that use Windows. Even this way, the future, as so many other things, it is uncertain and sure that right now there is somebody that is -still designing inside their head - a new programming language that will go an step further..

147 NEW APPROACHES USING JAVA 2 PLATFORM The Java platform is a technology that is on continuous changing. There are hundreds of companies and organizations working on this technology. Each year new technologies appear that offer new possibilities to the programmers. Besides the J2EE platform technologies there are right now in the market new technologies that are gaining more and more relevance. One platform that is gaining more relevance is the Eclipse platform. Eclipse is a kind of universal tool platform - an open extensible IDE for anything and nothing in particular. Eclipse is an open source project and is part of the Eclipse Foundation, a non-profit corporation formed to advance the creation, evolution, promotion, and support of the Eclipse Platform and to cultivate both an open source community and an ecosystem of complementary products, capabilities, and services. Eclipse started has an ambitious IBM project after some years running as proprietary software IBM decided to release it as an open source platform. Nowadays, there are many companies and organizations working on this project. The Eclipse Platform is designed for building integrated development environments (IDEs) that can be used to create applications as diverse as web sites, embedded JavaTM programs, C++ programs, and Enterprise JavaBeansTM. It has a great Java support.

148 148 Although the Eclipse Platform has a lot of built-in functionality, most of that functionality is very generic. It takes additional tools to extend the Platform to work with new content types, to do new things with existing content types, and to focus the generic functionality on something specific. The Eclipse Platform is built on a mechanism for discovering, integrating, and running modules called plug-ins. A tool provider writes a tool as a separate plug-in that operates on files in the workspace and surfaces its tool-specific UI in the workbench. When the Platform is launched, the user is presented with an integrated development environment (IDE) composed of the set of available plug-ins. The plug-ins are the key of the Eclipse platform, the success of this platform comes from the fact that his IDE is really generic and has a modular approach, so, for been open source anyone can add new modules (plug-ins) and personalize the IDE. This is the main advantage over other approaches like NetBeans (Sun IDE). Eclipse can be configured to give support to new technologies very quickly because of his architecture. Right now, there are plug-ins for various technologies like XDoclet, Spring, Hibernate, Lomboz, Jboss There are right now many approaches using Eclipse with other technologies as a plugin. Nowadays, on the internet forums you can hear developer talk about famous kits for develop scalable enterprise web applications in a really easy way. Like the Struts+EJB kit or the Spring+Hibernate kit. There are so many choices that the developers go crazy each time they start a new project. That s the big advantage of the open source software. First, we will talk about two different approaches for the implementation of the MVC controller and we will compare them with our choice: Struts. Then, we will introduce a powerful alternative to the EJB: Hibernate.

149 MVC Frameworks JavaServer Faces (JSF) JavaServer Faces has been standardized recently (JSF) ( JSF a framework to implement the view layer of a web application, it includes: A set of APIs for representing UI components and managing their state, handling events and input validation, defining page navigation, and supporting internationalization and accessibility. A Java Server Pages (JSP) custom tag library for expressing a JavaServer Faces interface within a JSP page. The primary goal is to make the development of web applications easy and to separate the view from the model. JSF is focus fundamentally for built IDEs that allow developing of web applications graphically, which can be integrated in existent web frameworks. In the future, Struts will be integrated with JSF, and in particular, they will be able to use the JSF tags instead of the HTML tags of Struts (in a similar way to how the JSTL tags has replaced the tags of the Bean and Logic libraries of Struts).

150 Spring Spring is another MVC framework who got born with the idea of simplify the development of web applications. Basically, it tries to solve the main EJB+Struts problems. Unlike other frameworks and APIs, spring does not impose itself wholly on to the design of a project. Spring is modular and has been divided logically into independent packages, which can function independently. The architects of an application have the flexibility to implement just a few spring packages and leave out most of the packages in spring. The "Spring Framework" would not feel bad with this attitude and on the contrary encourages users to introduce Spring into existing applications in a phased manner. So no matter what kind of framework you are using now Spring will co-exist with it without causing you nightmares and further more Spring will allow you to choose specific packages in Spring. Spring can be used along with Struts or JSF because of its layered architecture. So, the application code doesn t depend on Spring APIs. Spring tries very hard to be as simple as possible and it can function as a container it its own right. This can remove the need for a complex, and sometimes expensive, J2EE container. Everything is defined in terms of beans and properties. This, reduce dependencies and specialization so that framework constrains the developer a little as possible. The Spring Framework provides a mechanism for designing systems, aiding you in the modularisation of components and hence in making components more readily testable. The crux of the framework is that you design your business service and data access objects as Java beans, and then provide a dependency mapping between them. This leads to very well structured systems with a pluggable feel.

151 151 Spring Framework is suited to a wide variety of architectures, and can be utilised in discrete parts of a system, as well as across the whole system. Let's give an example where we want to use Spring for the business and data access tiers of a system Struts vs. JSF vs. Spring Struts o Advantages: Is the Standard. Many web applications have been implemented using this framework that is running since Many information and examples. HTML tag library is one of the best. Robust. o Disadvantages: It s difficult to use. ActionForms make the work too complicate. It doesn t have unit test, making it really hard to test. Too many checked exceptions that are not needed in some cases. This is because Java is a robust language. JSF o Advantages: J2EE Standard. Fast and easy to develop with. Rich Navigation framework. o Disadvantages: Immature technology. No single source for implementation.

152 152 Spring o Advantages: Lifecyle for overriding binding, validation, etc. Integrates with many view options seamlessly: JSP/JSTL, Tiles, Velocity, FreeMarker, Excel, XSL, PDF. Inversion of Control makes it easy to test. Easy to use. Layered Architecture, easy to integrate. o Disadvantages: Too immature. It was introduced in 2004 and there is not too many people using it. Requires writing lots of code in JSPs. Almost too flexible. No common parent Controller As we can see, nowadays, the most powerful MVC framework is Spring. Mainly for its easy to use and his flexibility to integrate with other tools like hibernate.

153 Hibernate For most of the applications, to store and to recover information implies some interaction form with a relational database. This has represented a fundamental problem for the developers because the data design and the object model share structures very different inside their respective environments. The relational databases are structured in tables and the objects are usually in a tree form. This difference has made developers of several objects persistence technologies to try to build a bridge among the relational world and the object oriented world. There are basically three ways to access to the database: 1. Using JDBC to send SQL queries directly to the database: This approach is very inefficient because is cause a completely dependence with the database and the result is a non scalable software. 2. Using DAOs: With this approach we have classes that the programmer creates to take care of the persistence. The DAOs are used in the BMP Beans. 3. Automatic managed persistence: Here we have a tool that manages the persistence for the programmer. In the case of the CMP Beans the EJB container takes care of this task. Hibernate is another option for manage the persistence. Hibernate is an alternative to the Entity Beans to handle the persistence of objects. It is a powerful open source tool with the goal to facilitate the object persistence on relational databases.

154 154 It allows you to design persistent objects that will be able to include polymorphism, relationships, collections, and a great number of data types. In a very quick and optimized way we will be able to generate DB in anyone of the supported environments: Oracle, DB2, MySql, etc The key of Hibernate is that makes the persistence transparent to the developer, mapping automatically the business model objects to the relational database and providing a high level object-oriented query language allowing developers to get rid of the SQL queries. This is a great feature because it provides a total separation between the database and the application; this separation is not achieved with EJB that are somehow dependent of the database. Even do, the SQL language is a standard there are some differences between different DBMS. Hibernate supports a wide range of relational database and automatically maps his high level query language to the corresponding database language using standard XML files. One of the unique characteristics of Hibernate it is that it doesn't require that the developers implement interfaces or extend classes to be able to persist the classes. Instead of that, Hibernate uses Java reflection and the increase of classes in execution time using a very powerful Java code generation library called CGLIB. CGLIB is used to extend Java classes and to implement Java interfaces in execution time.

155 Hibernate Structure Figure 29 Client's request will be send from the browser to a Java servlet that communicates with user's service and this, with the DAOs based on Hibernate.

156 Hibernate Overview High level architecture of Hibernate can be described as shown in following illustration: Figure 30 Hibernate makes use of persistent objects commonly called as POJO (POJO = "Plain Old Java Object".) along with XML mapping documents for persisting objects to the database layer. The term POJO refers to a normal Java objects that does not serve any other special role or implement any special interfaces of any of the Java frameworks (EJB, JDBC, DAO, JDO, etc...). Rather than utilize byte code processing or code generation, Hibernate uses runtime reflection to determine the persistent properties of a class. The objects to be persisted are defined in a mapping document, which serves to describe the persistent fields and associations, as well as any subclasses or proxies of the persistent object. The mapping documents are compiled at application start-up time and provide the framework with necessary information for a class. Additionally, they are used in support operations, such as generating the database schema or creating stub Java source files.

157 Hibernate Features Transparent persistence without byte code processing Transparent persistence JavaBeans style properties are persisted No build-time source or byte code generation / processing Support for extensive subset of Java collections API Collection instance management Extensible type system Constraint transparency Automatic Dirty Checking Detached object support Object-oriented query language Powerful object-oriented query language Full support for polymorphic queries New Criteria queries Native SQL queries Object / Relational mappings Three different O/R mapping strategies Multiple-objects to single-row mapping Polymorphic associations Bidirectional associations Association filtering Collections of basic types Indexed collections Composite Collection Elements Lifecycle objects

158 158 Automatic primary key generation Multiple synthetic key generation strategies Support for application assigned identifiers Support for composite keys Object/Relational mapping definition XML mapping documents Human-readable format XDoclet support (an open source code generation engine) HDLCA (Hibernate Dual-Layer Cache Architecture) Thread safeness Non-blocking data access Session level cache Optional second-level cache Optional query cache Works well with others High performance Lazy initialization Outer join fetching Batch fetching Support for optimistic locking with versioning/timestamping Highly scalable architecture High performance No "special" database tables SQL generated at system initialization time Internal connection pooling and PreparedStatement caching

159 159 J2EE integration JMX support Integration with J2EE architecture (optional) New JCA support

160 Hibernate Example Now let s see how easy is to build application using Hibernate. We will se how to create a table, create a persistent object, the object-table mapping and the access to the object. These are the steps: 1. Preparing Database Let s consider a simple database schema with a singe table as APPLABSUSER that we create with this SQL code: CREATE TABLE `applabsuser` ( `USER_ID` int(11) NOT NULL default '0', `USER_NAME` varchar(255) NOT NULL default '', `USER_PASSWORD` varchar(255) NOT NULL default '', `USER_FIRST_NAME` varchar(255) default NULL, `USER_LAST_NAME` varchar(255) default NULL, `USER_ ` varchar(255) default NULL, `USER_CREATION_DATE` date default NULL, `USER_MODIFICATION_DATE` date default NULL, PRIMARY KEY (`USER_ID`), UNIQUE KEY `USER_NAME` (`USER_NAME`) ) ; 2. Create Persistent Java Objects Hibernate works best with the Plain Old Java Objects programming model for persistent classes. Hibernate is not restricted in its usage of property types, all Java JDK types and primitives (like String, char and Date) can be mapped, including classes from the Java collections framework. You can map them as values, collections of values, or associations to other entities. The id is a special property that represents the database identifier (primary key) of that class, Hibernate can use identifiers only internally, but we would lose some of the flexibility in our application architecture.

161 161 No special interface has to be implemented for persistent classes nor do you have to subclass from a special root persistent class. Hibernate also doesn't require any build time processing, such as byte-code manipulation, it relies solely on Java reflection and runtime class enhancement (through CGLIB). So, without any dependency of the POJO class on Hibernate, we can map it to a database table. Following code sample represents a java object structure which represents the AppLabsUser table. Generally these domain objects contain only getters and setters methods. One can use Hibernate extension toolset to create such domain objects. AppLabsUser.java package org.applabs.quickstart; import java.io.serializable; import java.util.date; import org.apache.commons.lang.builder.tostringbuilder; public class AppLabsUser implements Serializable { public void setname(string name) { /** identifier field */ private Long id; /** persistent field */ private String username; /** persistent field */ private String userpassword; /** persistent field */ private String userfirstname; /** persistent field */ private String userlastname; /** persistent field */ private String user ;

162 162 /** persistent field */ private Date usercreationdate; /** persistent field */ private Date usermodificationdate; /** full constructor */ public Applabsuser(String username, String userpassword, String userfirstname, String userlastname, String user , Date usercreationdate, Date usermodificationdate) { this.username = username; this.userpassword = userpassword; this.userfirstname = userfirstname; this.userlastname = userlastname; this.user = user ; this.usercreationdate = usercreationdate; this.usermodificationdate = usermodificationdate; } /** default constructor */ public Applabsuser() { } public Long getid() { return this.id; } public void setid(long id) { this.id = id; } public String getusername() { return this.username; } public void setusername(string username) { this.username = username; } public String getuserpassword() { return this.userpassword; } public void setuserpassword(string userpassword) { this.userpassword = userpassword; } public String getuserfirstname() { return this.userfirstname; }

163 163 public void setuserfirstname(string userfirstname) { this.userfirstname = userfirstname; } public String getuserlastname() { return this.userlastname; } public void setuserlastname(string userlastname) { this.userlastname = userlastname; } public String getuser () { return this.user ; } public void setuser (string user ) { this.user = user ; } public Date getusercreationdate() { return this.usercreationdate; } public void setusercreationdate(date usercreationdate) { this.usercreationdate = usercreationdate; } public Date getusermodificationdate() { return this.usermodificationdate; } public void setusermodificationdate(date usermodificationdate) { this.usermodificationdate = usermodificationdate; } public String tostring() { return new ToStringBuilder(this).append("id", getid()).tostring(); } }// End of class

164 Mapping POJO with persistence layer using hibernate mapping document Each persistent class needs to be mapped with its configuration file. Following code represents Hibernate mapping file for AppLabsUser class. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 2.0//EN" " <hibernate-mapping> <class name="org.applabs.hibernate.quickstart.applabsuser" table="applabsuser"> <id column="user_id" name="id" type="java.lang.long"> <generator class="sequence"/> </id> <property column="user_name" length="255" name="username" notnull="true" type="java.lang.string"/> <property column="user_password" length="255" name="userpassword" not-null="true" type="java.lang.string"/> <property column="user_first_name" length="255" name="userfirstname" type="java.lang.string"/> <property column="user_last_name" length="255" name="userlastname" type="java.lang.string"/> <property column="user_ " length="255" name="user " type="java.lang.string"/> <property column="user_creation_date" length="10" name="usercreationdate" type="java.util.date"/> <property column="user_modification_date" length="10" name="usermodificationdate" type="java.util.date"/> </class> </hibernate-mapping>

165 165 We can also generate Hibernate mapping documents using Hibernate extension toolset. Hibernate mapping documents are straight forward. The <class> element maps a table with corresponding class. The <id> element represents the primary key column, and its associated attribute in the domain object. The <property> elements represent all other attributes available in the domain object 4. Hibernate Configuration File Hibernate configuration file information needed to connect to persistent layer and the linked mapping documents. You can either specify the data source name or JDBC details that are required for hibernate to make JDBC connection to the database. The element <mapping-resource> refers to the mapping document that contains mapping for domain object and hibernate mapping document. <!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN" " <hibernate-configuration> <session-factory> <property name="show_sql">true</property> <property name="hibernate.dialect">org.hibernate.dialect.mysqlmyisamdialect</prop erty> <property name="hibernate.connection.driver_class">org.gjt.mm.mysql.driver</property > <property name="hibernate.connection.url">jdbc:mysql://localhost:3306/applabs</prope rty> <property name="hibernate.connection.username">root</property> <property name="hibernate.connection.password">r00tp@$wd</property> <mapping resource="org/applabs/hibernate/quickstart/applabsuser.hbm.xml"/> </session-factory> </hibernate-configuration>

166 Hibernate Sample Code (Inserting new record) Here is how you can use Hibernate in your programs. Typical Hibernate programs begin with configuration that is required for Hibernate. Hibernate can be configured in two ways. Programmatically and Configuration file based. In Configuration file based mode, hibernate looks for configuration file hibernate.cfg.xml in the classpath. Based on the resource mapping provided hibernate creates mapping of tables and domain objects. In the programmatic configuration method, the details such as JDBC connection details and resource mapping details etc are supplied in the program using Configuration API. Following example shows programmatic configuration of hibernate. Configuration config = new Configuration().addResource("org/applabs/hibernate/quickstart/Applabsuser.hbm.xml") Configuration config = new Configuration().addClass(org.hibernate.quickstart.Applabsuser.class).setProperty("hibernate.dialect", "org.hibernate.dialect. MySQLMyISAMDialect").setProperty("hibernate.connection.driver_class", " org.gjt.mm.mysql.driver")... SessionFactory sessions = config.buildsessionfactory(); In configuration file based approach, hibernate.cfg.xml is placed in the classpath, Following Hibernate code can be used in this method. SessionFactory sessionfactory = new Configuration().configure().buildSessionFactory(); Session session = sessionfactory.opensession(); AppLabsUser user = new AppLabsUser(); Transaction tx = session.begintransaction(); user.setusercreationdate(new Date()); user.setuser ("user@allapplabs.com"); user.setuserfirstname("userfirstname"); user.setuserlastname("userlastname"); user.setusername("username-1"); user.setuserpassword("userpassword"); session.saveorupdate(user); tx.commit(); session.close();

167 Hibernate Sample Code (Quering the database) SessionFactory sessionfactory = new Configuration().configure().buildSessionFactory(); Session session = sessionfactory.opensession(); ArrayList arraylist = null; String SQL_STRING = "FROM AppLabsUser as users"; Query query = session.createquery(sql_string); ArrayList list = (ArrayList)query.list(); for(int i=0; i<list.size();i++){ System.out.println(list.get(i)); } session.close(); As we can see from the example, Hibernate manages the persistence in an efficient, transparent and easy way. Right now, I believe that is the best mapping tool and should be used instead of EJB to manage the data layer, at least until the EJB 3.0 specification gets finally completed.

168 DESIGN PATTERNS On this section we will describe the design patterns that are usually used to build enterprise applications. These patterns help developers to solve usual problems that programmers have to face when programming this kind of applications. First, we will take a general look to the OO Programming patterns to review the main aspects of these patterns. Then, we will focus on the enterprise applications patterns (J2EE Core Patterns). The knowledge of these patterns is crucial to develop scalable and robust applications. This section is more focus to analyst and designers who need to create model for the enterprise applications. For a software engineering, knowing the design patterns is fundamental.

169 USUAL OOP DESIGN PATTERNS Design patterns can be classified in the next categories: 1. Creational Patterns: Creational design patterns abstract the instantiation process. They help make a system independent of how its objects are created, composed, and represented. A class creational pattern uses inheritance to vary the class that's instantiated, whereas an object creational pattern will delegate instantiation to another object. Here are some examples: Abstract Factory: Provide an interface for creating families of related or dependent objects without specifying their concrete classes. Here is the structure: Figure 31 Is recommended to use Abstract Factory pattern when: A system should be independent of how its products are created, composed, and represented. A system should be configured with one of multiple families of products. A family of related product objects is designed to be used together, and you need to enforce this constraint.

170 170 You want to provide a class library of products, and you want to reveal just their interfaces, not their implementations. Example: Figure 32 WidgetFactory class declares an interface for creating each basic kind of widget. There's also an abstract class for each kind of widget, and concrete subclasses implement widgets for specific look-and-feel standards. WidgetFactory's interface has an operation that returns a new widget object for each abstract widget class. Clients call these operations to obtain widget instances, but clients aren't aware of the concrete classes they're using-

171 171 Builder: Is used to separate the construction of a complex object from its representation so that the same construction process can create different representations. Figure 33 We should use the Builder pattern when: The algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled. The construction process must allow different representations for the object that's constructed. Example: Figure 34

172 172 Factory Method: Defines an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. Figure 35 Use the Factory Method pattern when: A class can't anticipate the class of objects it must create. A class wants its subclasses to specify the objects it creates. Classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.

173 173 Prototype: The intent is to specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype. Figure 36 Is better to use the Prototype pattern when a system should be independent of how its products are created, composed, and represented; and when the classes to instantiate are specified at run-time, for example, by dynamic loading; or to avoid building a class hierarchy of factories that parallels the class hierarchy of products; or when instances of a class can have one of only a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state.

174 174 Singleton: It ensures that a class only has one instance, and provides a global point of access to it. Figure 37 Use the Singleton pattern when: There must be exactly one instance of a class, and it must be accessible to clients from a well-known access point. When the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code.

175 Structural Patterns: Structural patterns are concerned with how classes and objects are composed to form larger structures. Structural class patterns use inheritance to compose interfaces or implementations. Structural object patterns describe ways to compose objects to realize new functionality. The added flexibility of object composition comes from the ability to change the composition at run-time, which is impossible with static class composition. Adapter: The idea is to convert the interface of a class into another interface that the clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. A class adapter uses multiple inheritance to adapt one interface to another: Figure 38

176 176 An object adapter relies on object composition: Figure 39 We can use the Adapter pattern when: You want to use an existing class, and its interface does not match the one you need. You want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces. (object adapter only) you need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class. Example: Figure 40

177 177 Bridge: The intent is to decouple an abstraction from its implementation so that the two can vary independently. Figure 41 Use the Bridge pattern when: You want to avoid a permanent binding between an abstraction and its implementation. This might be the case, for example, when the implementation must be selected or switched at runtime. Both the abstractions and their implementations should be extensible by subclassing. In this case, the Bridge pattern lets you combine the different abstractions and implementations and extend them independently. Changes in the implementation of an abstraction should have no impact on clients; that is, their code should not have to be recompiled. (C++) you want to hide the implementation of an abstraction completely from clients. In C++ the representation of a class is visible in the class interface. You have a proliferation of classes as shown earlier in the first Motivation diagram. Such a class hierarchy indicates the need for splitting an object into two parts.

178 178 You want to share an implementation among multiple objects (perhaps using reference counting), and this fact should be hidden from the client. Example: Figure 42

179 179 Composite: The goal of this pattern is to compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. It is used when you want to represent part-whole hierarchies of objects. Or when you want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly. Structure: Figure 43

180 180 Example: Figure 44 Code that uses these classes must treat primitive and container objects differently; even if most of the time the user treats them identically. Having to distinguish these objects makes the application more complex. The Composite pattern describes how to use recursive composition so that clients don't have to make this distinction.

181 181 Decorator: It used to attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. Figure 45 Use Decorador in the next cases: To add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects. For responsibilities that can be withdrawn. When extension by subclassing is impractical. Sometimes a large number of independent extensions are possible and would produce an explosion of subclasses to support every combination. Or a class definition may be hidden or otherwise unavailable for subclassing.

182 182 Facade: It provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. Structuring a system into subsystems helps reduce complexity. A common design goal is to minimize the communication and dependencies between subsystems. One way to achieve this goal is to introduce a facade object that provides a single, simplified interface to the more general facilities of a subsystem. Figure 46 Structure: Figure 47

183 183 Use the Facade pattern when: You want to provide a simple interface to a complex subsystem. Subsystems often get more complex as they evolve. Most patterns, when applied, result in more and smaller classes. This makes the subsystem more reusable and easier to customize, but it also becomes harder to use for clients that don't need to customize it. A facade can provide a simple default view of the subsystem that is good enough for most clients. Only clients needing more customizability will need to look beyond the facade. There are many dependencies between clients and the implementation classes of an abstraction. Introduce a facade to decouple the subsystem from clients and other subsystems, thereby promoting subsystem independence and portability. You want to layer your subsystems. Use a facade to define an entry point to each subsystem level. If subsystems are dependent, then you can simplify the dependencies between them by making them communicate with each other solely through their facades.

184 184 Example: Figure 48 The Compiler class acts as a facade: It offers clients a single, simple interface to the compiler subsystem. It glues together the classes that implement compiler functionality without hiding them completely.

185 185 Flyweight: Use sharing to support large numbers of fine-grained objects efficiently. Some applications could benefit from using objects throughout their design, but a naive implementation would be prohibitively expensive. A flyweight is a shared object that can be used in multiple contexts simultaneously. The flyweight acts as an independent object in each context, it's indistinguishable from an instance of the object that's not shared. Flyweights cannot make assumptions about the context in which they operate. The key concept here is the distinction between intrinsic and extrinsic state. Intrinsic state is stored in the flyweight; it consists of information that's independent of the flyweight's context, thereby making it sharable. Extrinsic state depends on and varies with the flyweight's context and therefore can't be shared. Client objects are responsible for passing extrinsic state to the flyweight when it needs it. Figure 49

186 186 The following object diagram shows how flyweights are shared: Figure 50 The Flyweight pattern's effectiveness depends heavily on how and where it's used. Apply the Flyweight pattern when all of the following are true: An application uses a large number of objects. Storage costs are high because of the sheer quantity of objects. Most object state can be made extrinsic. Many groups of objects may be replaced by relatively few shared objects once extrinsic state is removed. The application doesn't depend on object identity. Since flyweight objects may be shared, identity tests will return true for conceptually distinct objects.

187 187 Proxy: It is used to provide a surrogate or placeholder for another object to control access to it. One reason for controlling access to an object is to defer the full cost of its creation and initialization until we actually need to use it. Structure: Figure 51 Object Diagram: Figure 52 Proxy is applicable whenever there is a need for a more versatile or sophisticated reference to an object than a simple pointer.

188 188 Example: Figure 53 The document editor accesses embedded images through the interface defined by the abstract Graphic class. ImageProxy is a class for images that are created on demand. ImageProxy maintains the file name as a reference to the image on disk. The file name is passed as an argument to the ImageProxy constructor. ImageProxy also stores the bounding box of the image and a reference to the real Image instance. This reference won't be valid until the proxy instantiates the real image. The Draw operation makes sure the image is instantiated before forwarding it the request. GetExtent forwards the request to the image only if it's instantiated; otherwise ImageProxy returns the extent it stores.

189 Behavioural Patterns: Behavioural patterns are concerned with algorithms and the assignment of responsibilities between objects. Behavioural patterns describe not just patterns of objects or classes but also the patterns of communication between them. These patterns characterize complex control flow that's difficult to follow at run-time. They shift your focus away from flow of control to let you concentrate just on the way objects are interconnected. Behavioural class patterns use inheritance to distribute behaviour between classes. Behavioral object patterns use object composition rather than inheritance.

190 190 Chain of Responsibility: The intention of this pattern is to avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. The idea of this pattern is to decouple senders and receivers by giving multiple objects a chance to handle a request. The request gets passed along a chain of objects until one of them handles it. Figure 54 Use Chain of Responsibility in the next cases: More than one object may handle a request, and the handler isn't known a priori. The handler should be ascertained automatically. You want to issue a request to one of several objects without specifying the receiver explicitly. The set of objects that can handle a request should be specified dynamically.

191 191 Command: The intention is to encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. Figure 55 Use the Command pattern when you want to: Parameterize objects by an action to perform, as MenuItem objects did above. You can express such parameterization in a procedural language with a callback function, that is, a function that's registered somewhere to be called at a later point. Commands are an objectoriented replacement for callbacks. Specify, queue, and execute requests at different times. A Command object can have a lifetime independent of the original request. If the receiver of a request can be represented in an address spaceindependent way, then you can transfer a command object for the request to a different process and fulfill the request there.

192 192 Support undo. The Command's Execute operation can store state for reversing its effects in the command itself. The Command interface must have an added Unexecute operation that reverses the effects of a previous call to Execute. Executed commands are stored in a history list. Unlimited-level undo and redo is achieved by traversing this list backwards and forwards calling Unexecute and Execute, respectively. Support logging changes so that they can be reapplied in case of a system crash. By augmenting the Command interface with load and store operations, you can keep a persistent log of changes. Recovering from a crash involves reloading logged commands from disk and reexecuting them with the Execute operation. Structure a system around high-level operations built on primitives operations. Such a structure is common in information systems that support transactions. A transaction encapsulates a set of changes to data. The Command pattern offers a way to model transactions. Commands have a common interface, letting you invoke all transactions the same way. The pattern also makes it easy to extend the system with new transactions.

193 193 Interpreter: this pattern is used when given a language; we want to define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language. Structure: Figure 56 It s recommended to use the Interpreter pattern when there is a language to interpret, and you can represent statements in the language as abstract syntax trees. The Interpreter pattern works best in the following cases: The grammar is simple. For complex grammars, the class hierarchy for the grammar becomes large and unmanageable. Tools such as parser generators are a better alternative in such cases. They can interpret expressions without building abstract syntax trees, which can save space and possibly time. Efficiency is not a critical concern. The most efficient interpreters are usually not implemented by interpreting parse trees directly but by first translating them into another form. For example, regular expressions are often transformed into state machines. But even then, the translator can be implemented by the Interpreter pattern, so the pattern is still applicable.

194 194 Example: Figure 57

195 195 Iterator: It provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation. An aggregate object such as a list should give you a way to access its elements without exposing its internal structure. Moreover, you might want to traverse the list in different ways, depending on what you want to accomplish. But you probably don't want to bloat the List interface with operations for different traversals, even if you could anticipate the ones you will need. You might also need to have more than one traversal pending on the same list. The Iterator pattern lets you do all this. The key idea in this pattern is to take the responsibility for access and traversal out of the list object and put it into an iterator object. The Iterator class defines an interface for accessing the list's elements. An iterator object is responsible for keeping track of the current element; that is, it knows which elements have been traversed already. Structure: Figure 58

196 196 Cases when we should use this pattern: To access an aggregate object's contents without exposing its internal representation. To support multiple traversals of aggregate objects. To provide a uniform interface for traversing different aggregate structures (that is, to support polymorphic iteration). Example using lists: Figure 59

197 197 Mediator: the idea is to define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. Though partitioning a system into many objects generally enhances reusability, proliferating interconnections tend to reduce it again. Lots of interconnections make it less likely that an object can work without the support of others; the system acts as though it were monolithic. Moreover, it can be difficult to change the system's behavior in any significant way, since behavior is distributed among many objects. As a result, you may be forced to define many subclasses to customize the system's behavior. The mediator is used to avoid problems handling the relations between multiple objects. The idea is encapsulating collective behavior in a separate mediator object. A mediator is responsible for controlling and coordinating the interactions of a group of objects. The mediator serves as an intermediary that keeps objects in the group from referring to each other explicitly. The objects only know the mediator, thereby reducing the number of interconnections. Structure: Figure 60

198 198 We use the Mediator pattern when: A set of objects communicate in well-defined but complex ways. The resulting interdependencies are unstructured and difficult to understand. Reusing an object is difficult because it refers to and communicates with many other objects. A behaviour that's distributed between several classes should be customizable without a lot of subclassing.

199 199 Memento: The intention is that, without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later. Sometimes it's necessary to record the internal state of an object. This is required when implementing checkpoints and undo mechanisms that let users back out of tentative operations or recover from errors. You must save state information somewhere so that you can restore objects to their previous states. But objects normally encapsulate some or all of their state, making it inaccessible to other objects and impossible to save externally. Exposing this state would violate encapsulation, which can compromise the application's reliability and extensibility. Structure: Figure 61 Use the Memento pattern when: A snapshot of (some portion of) an object's state must be saved so that it can be restored to that state later, and A direct interface to obtaining the state would expose implementation details and break the object's encapsulation.

200 200 Observer: the goal is to define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. A common side-effect of partitioning a system into a collection of cooperating classes is the need to maintain consistency between related objects. You don't want to achieve consistency by making the classes tightly coupled, because that reduces their reusability. The Observer pattern describes how to establish these relationships. The key objects in this pattern are subject and observer. A subject may have any number of dependent observers. All observers are notified whenever the subject undergoes a change in state. In response, each observer will query the subject to synchronize its state with the subject's state. Structure: Figure 62

201 201 Use the Observer pattern in any of the following situations: When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets you vary and reuse them independently. When a change to one object requires changing others, and you don't know how many objects need to be changed. When an object should be able to notify other objects without making assumptions about who these objects are. In other words, you don't want these objects tightly coupled.

202 202 State: The intent is to Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. Structure: Figure 63 We recommend using this pattern in either of the following cases: An object's behaviour depends on its state, and it must change its behaviour at run-time depending on that state. Operations have large, multipart conditional statements that depend on the object's state. This state is usually represented by one or more enumerated constants. Often, several operations will contain this same conditional structure. The State pattern puts each branch of the conditional in a separate class. This lets you treat the object's state as an object in its own right that can vary independently from other objects.

203 203 Example: Figure 64 The class TCPConnection maintains a state object (an instance of a subclass of TCPState) that represents the current state of the TCP connection. The class TCPConnection delegates all state-specific requests to this state object. TCPConnection uses its TCPState subclass instance to perform operations particular to the state of the connection. Whenever the connection changes state, the TCPConnection object changes the state object it uses. When the connection goes from established to closed, for example, TCPConnection will replace its TCPEstablished instance with a TCPClosed instance.

204 204 Strategy: The idea is to define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Many algorithms exist for breaking a stream of text into lines. Hardwiring all such algorithms into the classes that require them isn't desirable for several reasons: Clients that need linebreaking get more complex if they include the linebreaking code. That makes clients bigger and harder to maintain, especially if they support multiple linebreaking algorithms. Different algorithms will be appropriate at different times. We don't want to support multiple linebreaking algorithms if we don't use them all. It's difficult to add new algorithms and vary existing ones when linebreaking is an integral part of a client. We can avoid these problems by defining classes that encapsulate different linebreaking algorithms. An algorithm that's encapsulated in this way is called a strategy. Structure: Figure 65

205 205 Use the Strategy pattern when: Many related classes differ only in their behaviour. Strategies provide a way to configure a class with one of many behaviours. You need different variants of an algorithm. For example, you might define algorithms reflecting different space/time trade-offs. An algorithm uses data that clients shouldn't know about. Use the Strategy pattern to avoid exposing complex, algorithm-specific data structures. A class defines many behaviours, and these appear as multiple conditional statements in its operations. Instead of many conditionals, move related conditional branches into their own Strategy class.

206 206 Template Method: The goal is to define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure. Structure: Figure 66 The Template Method pattern should be used in the following cases: To implement the invariant parts of an algorithm once and leave it up to subclasses to implement the behaviour that can vary. When common behaviour among subclasses should be factored and localized in a common class to avoid code duplication. To control subclasses extensions. You can define a template method that calls "hook" operations (see Consequences) at specific points, thereby permitting extensions only at those points.

207 207 Visitor: The intention is to represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates. Structure: Figure 67

208 208 Use the Visitor pattern when: An object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes. Many distinct and unrelated operations need to be performed on objects in an object structure, and you want to avoid "polluting" their classes with these operations. Visitor lets you keep related operations together by defining them in one class. When the object structure is shared by many applications, use Visitor to put operations in just those applications that need them. The classes defining the object structure rarely change, but you often want to define new operations over the structure. Changing the object structure classes requires redefining the interface to all visitors, which is potentially costly. If the object structure classes change often, then it's probably better to define the operations in those classes.

209 ENTERPRISE APPLICATIONS DESIGN PATTERNS No we will take a closer look to the patterns that are commonly used on the development of enterprise applications. These patterns are call J2EE Core patterns and are essential for the design of enterprise application using the J2EE platform. Most of them are related with the EJB technology; trying to solve the main problems the developers face when using this technology. We are going to focus on the patterns from the Data and Model layer. We will use the following convention to describe the patterns (when available): Intention Also know as Motivation Applicability Structure Participants Collaborations Consequences Implementation Related patterns

210 Session Facade Intention To provide a simple interface that supports a group of related use cases. It is an application of the Facade pattern. It represents workflow and not persistence. It can be use with EJB or not. Motivation Provide a simple interface that supports a group of related use cases (in general, an operation for each use case), hiding those existent relations on the implementation of each use case. Additionally, when EJB is used, tries to decrease the number of remote invocations and to avoid that the client has to use the transactions API. Applicability o When we want to offer a simplified version of a group of EJBs. o When we want to decrease the number of remote invocations from the client layer.

211 211 Structure (EJB): Figure 68 Participants o Client: Can be a Business Delegate or another Session Facade. o SessionFacade: Usually, a Session Bean. Provides a simple interface to the client, hiding the relations among numerous business objects. o Business Object: Provides data (Entity Bean or DAO) or a service (Session Bean). Collaborations A SessionFacade coordinates a group of business objects to implement a group of related use case. Consequences o Simplifies the maintenance. o Reduces the number of remote invocations. o Simplifies the transactions administration.

212 212 Implementation It can be done with SLSB or SFSB EJBs depending if we want to save the state or nor when using EJB. Without EJB is implemented with a Java class. One problem with this pattern is that sometimes the Session Facade is too big and gets difficult to maintain and the performance decreases considerably. It recommendable that the Session Facade only implements operations that are 4 or 5 lines of code, delegating in other classes to implement bigger operations. Related patterns o Facade o Data Access Object o Service Locator o Business Delegate

213 Business Delegate Intention Hides the technologies used in the model. Business Delegate usually always hides a Session Facade. o Without EJB, Business Delegate and Session Facade will be the same (no distributed environment). o With EJB, Business Delegate will be a proxy (local object) of Session Facade (remote object) Motivation In EJB, it facilities the client access to the EJB layer, hiding the EJB API. The Controller will access the model thru an interface that hides the technology used to implement the business logic. Applicability When we want to provide an access layer to the model that hides the technology used in the implementation. Structure Figure 69

214 214 Participants o BusinessDelegate: Uses ServiceLocator to obtain a reference to the BusinessServiceFactory. It creates a BusinessService (using BusinesServiceFactory) who is the one that we delegate the operations. o BusinessService: it is Usually a Session Bean. o BusinessServiceFactory: Usually the Home interface of a Session Bean. o ServiceLocator: Allows to obtain a reference to BusinessServiceFactory (usually using JNDI). Collaborations The BusinessDelegate constructor uses a ServiceLocator to obtain a BusinessServiceFactory and to create a BusinessService in which will delegate all their operations. Consequences o Improves the maintenance. o Allows jobs separation: client layer developers and EJB layer developers. o Can provide cache to improve the efficiency. Implementation It is Java class with its methods synchronized. They have to be serializable when we need to keep the session. Related patterns o Proxy o Service Locator o Session Facade

215 Service Locator Intention Have a generic mechanism that allows to obtain and to search references to Home interfaces. Also know as EJBHomeFactory Motivation The references to any Home Interface, local or remote, are obtained in a similar way. To obtain a reference to a Home Interface has certain computational cost associate, especially when the name service is on another machine. Figure 70 EJBLocalHomeLocator and EJBHomeLocator search the references to the Home interfaces.

216 216 Applicability When we need to obtain references to Home interfaces. Structure Figure 71 Participants o ServiceLocator: Obtains and searches references to Home interfaces. o Client: An EJB (usually a Session Bean) or a Business Delegate. o EJBHome: The Home interface of an EJB (Session Bean or Entity Bean). Collaborations A Service Locator obtains and it searches references to Home Interfaces. Consequences o Abstracts the way to obtain references to interfaces Home o Avoids replying code of obtaining references to Home interfaces. o Cache improves the efficiency. Related patterns o Factory

217 Value Object Intention Group attributes coming from one or several domain objects. Also know as Transfer Object, Data Transfer Object, Replicate Object. Motivation Data access. Applicability When we need to represent a group of attributes coming from one or several domain objects. Structure <<Interface>> java.io.serializable <<Interface>> DAO VO Attrbutes get/set() Figure 72

218 218 Participants o VO: Offers get/set methods to access to its attributes. o DAO: Has access to the values that are copied in the VO. The Session Facade (Business Delegates) also work with VOs. Collaborations A DAO returns VOs in its methods findxxx, and receives them in their methods create and update Consequences o Benefits In the EJB context, efficiency. The CMP Beans are too slow and sometimes is better to write VOs and DAOs. Also produces less remote calls. In the JDBC context, to be able to represent a group of attributes coming from one or several domain objects. o Risks A VO can contain obsolete information if we pretend to use it in a later update in another transaction.

219 219 Implementation We have to differentiate two kinds of VO: Domain Value Objects: This kind of VO contains all attributes from the domain object and is reusable between applications because it has an exactly correspondence with a domain object. DAOs should only work with this kind of VOs to maintain the reusability. Custom Value Objects: These VOs only have the necessary attibites to implement one use case. They are dependent from the application and are not reusable. This objects shouldn t be used with DAOs, instead, they should be use by the Session Facades because they are application specific. These VOs are use to increase efficiently when implementing a specific use case. For example, if we have an object Car with 100 attributes and one use case only needs to get the engine attributes a custom value object can be use to represent that information and should be used only for the session facade. Figure 73 HashMaps: It is possible than in an application we need a big number of VOs and this cause a maintenance problem. In this case, the solution is to use Java HashMaps to retrieve pairs: <attribute, value> Related patterns o Page-by-Page Iterator. o Session Facade.

220 Value Object (EJB) There are some differences when we use EJB with this pattern. Intention To allow efficient exchange of data between the client and EJB layers. Also know as Transfer Object, Data Transfer Object, Replicate Object Motivation Decrease the number of remote calls. Applicability When we need to access (read or modification) to a group of data coming from one or several business objects.

221 221 Structure <<Interface>> java.io.serializable <<use>> VO Attrbutes get/set() <<use>> <<create>> Client Bussines Object Bussines Entity <<use>> Bussines Sesion <<use>> <<Interface>> DAO Figure 74 Participants o Client: receives or sends value objects. o BusinessObject: create the value object and returns it to the client. It can also receive the client's value objects to update. o VO: offers get/set methods to access to its attributes. Collaborations A client receives or sends value objects from or toward a business object.

222 222 Consequences Less remote invocations. But we have to be careful because the VO can content obsolete information. Related patterns o Data Access Object o Session Facade o Fast-Lane Reader o Page-by-Page Iterator

223 Data Access Object Intention Uncouple the business logic of the data access logic, so that you can change the data source easily. Also know as Data Access Component. Motivation Access to the database to retrieve data. Applicability o Separate the business logic of the data access logic. o To be able to select the type of data source during the installation/configuration of an application (plug-n-play). Structure Figure 75

224 224 Participants o SessionFacade: abstracts the business operations. Uses DAO and It doesn't depend on a concrete data source. o DAO: abstracts the operations on the data source. Also, provides an API to access and manipulate data. o DAOImpl: adapts the interface to a specific data source. o Source (MySQL, PostgreSQL, Oracle, Informix, Sybase, SQL Server, OODB, plain files, LDAP server, etc.): provides access and/or data storage using an API that needs to be adapted. Collaborations A SessionFacade access to the data through a DAO, the DAO adapts the API that offers the data source. Consequences o Benefits Flexibility in the installation/configuration of an application. Independence of the database vendor. Independence of the resource (relational DB, OODB, plain files, LDAP servers, etc.). Really this will only get it with EJB, where the DAOs don't need to receive the connection in their methods. Extensibility Reduces the complexity of the implementation of the logic (Session Facades). o Risks More complexity.

225 225 Implementation We use the Abstract Factory pattern to select the appropriate DAO implementation. When you cannot use EJB, the methods of the DAOs need to receive the connection (to be able to group several operations in one transaction). The DAO pattern is not only useful to access to DBs, also it can be used to access to other sources like to access to configuration information described in XML files. If the requirements are simple, it can be thought of creating one tool that generates the DAOs code automatically. If the requirements are more complex, it can be considered the use of an Object-Relational mapper like Hibernate. Related patterns o Adapter o Abstract Factory o Page-by-Page Iterator EJB Considerations There are some differences when we use EJB: o A DAO is used by a Session Bean (Session Facade) or Entity Bean BMP. o The operations of the DAO interface don't receive the connection to the DB. The container negotiates the transactions transparently. o The DAO interface totally hides the type of storage used (relational DB, OODB, etc.)

226 Page-by-Page Iterator Intention To access to a big list of Value Objects in a efficient way. Also know as Value List Handler. Motivation Retrieve big amounts of data. Applicability o The user is interested in visualizing the list of it Value Objects in pieces, being able to go forward or backwards. o The complete list would not fit in the screen. o The complete list would not fit in memory. Structure Figure 76 Participants o PageByPageIterator: can be a class that implements an interface with setcursor(int), setpagesize(int), getcurrentlist (), hasnext (), etc. operations. Usually is any class that invokes repeatedly an operation findxxx(startindex, count,...). o BusinessDelegate/SessionFacade: provides access to the list of VOs

227 227 Collaborations The PageByPageIterator takes care of the client current position, allowing to obtain the next or previous piece using BussinessDelegate/SessionFacade Consequences o Benefits Efficiently access. o Risks Inserts and erased that are made to the list (in the data source) while a client access to the list, can cause that the list doesn't see one of the elements or sees it more than once. Implementation The connections must be closed after the access to a piece of the list. Related patterns o Iterator o Data Access Object o Value Object EJB Considerations Differences when we use EJB: o It is used with the Fast-Lane Reader pattern. o The DAO that this pattern uses only provides search operations that don't receive the connection parameter. The DAO totally hides the storage type used.

228 Fast-Lane Reader Intention Efficiently implement use cases that correspond to searches that return a collection of objects. Also know as JDBC for Reading. Motivation Visualize in an efficiently way the data. Applicability When we have use cases that correspond to searches multiple and the efficiency is an important factor, Structure Figure 77

229 229 Participants o Business Delegate: delegates the operations of multiple searches in a Session Facade (that uses a DAO) or directly in a DAO. o SessionFacade: a Session Bean that implements the operations of multiple searches delegating in a DAO. o DAO: provides the search operations accessing directly to the DB. Collaborations A Business Delegates implements the multiple search operations delegating in a Session Facade (that uses a DAO) or directly in a DAO. Consequences o Benefits More efficient alternative that findxxx operations in the Home interfaces that returns multiple Entity Beans. o Risks Obsolete information.

230 230 Implementation It is used typically with the Page-By-Page Iterator patternwhen the search operations can return a big collection (more than what you can present in a results screen) If the Entity Beans are CMP, the DAOs only need to have the corresponding search operations. Business Delegate that access directly to the DAO: o A remote invocation is avoided. o Is not an architecture in pure 3 layers: The implementation of the searches resides in the client and needs drivers for the DB. Fast-Lane Reader vs findxxx methods in CMP Entity Beans EJB 2.x improves a lot the support to the findxxx methods using the EJB-QL language and the support for the relations; allowing also the container to carry out several optimizations. However, the Fast-Lane Reader pattern is still necessary when a use case returns a big collection and efficiency is an important factor. Also, there are some searches that we can t express using EJB-QL. Related patterns o Data Access Object o Page-by-Page Iterator o Session Facade o Business Delegate

231 CASE STUDY: J2EE INTERNET STORE On this section we will explain a web application build using the J2EE platform. The application is just a small internet store where the customers can buy products. The intention is to show how to build applications using this platform and the application doesn t pretend to be a real web application because it only has a subgroup of the usual and necessary functions of a real systems. But, been smaller helps to follow the application and learn about the Java 2 platform and all its technologies. Also, the reader will be able to see a real application of the Struts framework and the EJB technology. He will see the application of many design patterns discuss before on the theory. We begin explaining the main functions of the application. Then we take a look on the architecture where the application will work and also the software used to develop the application, which is, of course, open source. After that, we will analyze more carefully the requirements of the application using use case diagrams to model the functionality of the system. Then we will see the static internal architecture of the system taking a close look to the packages and its relations. Finally, we explain some important issues about the implementation.

232 MAIN DESCRIPTION The application will be an example of a small web application using the J2EE platform. It will consist in a simplified version of an Amazon like internet store. The goal is to show how to build enterprise applications using the JAVA 2 platform by creating a scalable and reusable web application that can be use for academic purpose or as base to build a real internet shop. So, I don t pretend to build a complicated web application with hundreds of use cases, the goal is just to show how the J2EE platform works, so the application it will only have the basics functionalities of an usual internet store, that we will describe now. The electronic trade store allows users to buy products over internet. It s wanted to use the store for the sale of books and CDs, but in a short term it can be used to sell another type of products, for that the software will be the most independent of the types of products as possible. The information of each product will include: names, brief description, quantity in stock, dates and price. Also, the books and the CDs have specific information. This way, for each book we will also keep the names of the authors, editorial name, the ISBN and the number of pages. By each music CD, we will save the name of the band and the name of the company. An inventory will also exist that registers the number of units available of each product. All the products are classified in categories. A category can contain subcategories, and each category has associate an unique father category, except the root category. A product only belongs to only one son category. For example, one could consider a father category, Products, with son categories Books and CDs of Music. The category Books could have the subcategories: Art, Literature, History, Trips, Computer science, etc. Computer science category at the same time could be structured in subcategories: Nets, software Development, etc.

233 233 Each user can register in the store giving his registration information that will include: login name, password, name, last name, address, street address, city, state, country, postal code and data of the credit card (name, number and expiration date). Each user can search for products and add them to his shopping cart, and finally buy all the products that are in the shopping cart. The shopping cart will be persistent, that means, an user can add products to his car today, leave the session, and return tomorrow and continue updating the car. When the user decides to buy all the products of his cart, an order will be generated that will be composed of several order lines. An user can have several orders in course. For each order we will save: the date in which was made, sending address (names, last names, street address, city, state, country, postal code, way of transport), credit card data (names, number and expiration date) and its state (served or not served). The shipment address and the data of the credit card can be different to those that appear in the registration information. For each order line we will save the number of the product requested units and the unitary price. The store can deliver the products using different kinds of transport (e.g.: normal mail, urgent mail by air, etc.), having different prices for each kind. The price of an order will be the sum of products cost plus the transport costs. The store will use Euros as the currency.

234 Functional Requirements of the System Next, the functionality that the store will offer to the user is detailed: 1. Users' registration: The application should allow to register new users, as well as to allow change the registration information later on. 2. Authentication and logout: A user will be authenticated giving his login name and password, with the possibility of remembering the password not having to type it the next time. The user will be able to leave the store explicitly that causes that the password is no longer remembered, in the case of having selected this option previously. Whenever the user is authenticated, explicitly or implicitly (the password had been remembered), we greet with his name in the first page and maybe their name appears in others pages. 3. Products searches: Any user will be able to make several types of searches: with title key words and with by categories. The key words has to be all contained in the name of the title as words or part of words, without distinguishing among uppercase and minuscule, and in any order. The selection of a category causes the visualization of all the son categories except a root category, in which case, all the products of that category are shown. The results of one search with key words categories generate the results in groups of n, that is to say, if the result of a search is 40 products, you can generate a HTML exit that shows 10 and a link (or several connections) to see the following or previous. Each product will be visualized as a link that it shows the title, so that when selecting the link, show us all the information of that product. 4. Product Info. Visualization: Any user will be able to visualize the information of a product (e.g.: name, price, the authors, etc.) that has appeared as consequence of a search.

235 Administration of shopping cart: An authenticated user will be able to add or to remove products of his shopping cart, as well as to modify the number of units of each product. The shopping cart will be persistent, for that the user will be able to update his car among different sessions. When the user decides to buy the products of the cart, an order will be generated (composed of order lines) that will stay in database, and the car will empty. The data of the shipment address of the order, as well as the data relative to the payment, will be generated automatically in function of the information from the user's registration, although, the user will be given the possibility to modify them for each order that makes, it could happen that exceptionally wants to send the order to another address or to pay it with another card. 6. Orders Visualization: An authenticated user will be able to visualize all the orders that he has made to know the state in which they are.

236 Non-Functional Requirements of the System The application must have a clear, simple and quick interface (it should even be sacrificed visual details to speed up browsing). It should not be fill the screens a lot since can slow down the application and the performance is fundamental. The access to the database has to be minimized to speed up the requests the maximum as possible. The application should have a minimum of security.

237 ARCHITECTURE Now we will analyze the application architecture: Client Tier Presentation Tier Model Tier Database Tier Web Browser JSP Container Tomcat EJB Container JBoss JSP Pages Entity Beans DB PostgreSQL Servlets Session Beans STRUTS The application, as we can see in the figure, it uses a common architecture in the development of J2EE applications. The client will use a web browser to access the application, since is just a web application no other UI will be used, but the application could support other kinds of UI very easily. The client will use the HTTP protocol to send and receive the information.

238 238 On the server part we have logically divide the application in three different layers. The presentation layer is in contact with the client, receiving request and then asking the model layer to execute the desire operation. Then, the presentation layer will receive and answer and it will generate the response for the client to see in the browser. We have use Tomcat as the JSP container, been in charge to compile the JSP in the corresponded servlets. Also, we are using Struts framework as an implementation of the MVC pattern. In the model layer, we have the EJB container, which is in charge of these distributed objects. We are using Session Beans to control the application operations and Entity Beans and data objects. We use JBoss as the implementation of the EJB container. Finally, we have the database tier, which is the DBMS. In our case, we are using PostgreSQL.

239 Software Used First, is important to mention that in the develop of this enterprise application all the software used is free source, so no proprietary solutions have been used. As a JSP container we are using Jakarta Tomcat. It implements the official reference from Sun of the Java Servlet and JavaServer Pages technologies. Tomcat is developed in an open and participatory environment and released under the Apache Software License. Tomcat is intended to be a collaboration of the best-of-breed developers from around the world. With no doubt, Tomcat is the most famous JSP/Servlet container; it is a very powerful, fast and reliable implementation of the Sun reference; and of couse, is free of charge. As EJB container we use JBoss. JBoss is an Application Server that has become a recognized leader in the Java application server market and is to date the only major application server on the market to deliver a production-ready J2EE 1.4 certified product. JBoss is free to download, deploy, and embed. Also, JBoss AS is the only major production-ready application server to achieve J2EE 1.4 certification. Here we list some of its features: Clustering: JBoss offers full clustering of any Java object (EJB, HTTP, POJO). Performance: Based on their own internal benchmark tests, companies have found that JBoss offers improved performance and superior server utilization to other leading J2EE application servers. Modular and elegant architecture: JBoss offers a unique architecture built on a microkernel-based design that leverages JMX extensions. The result is a lightweight component model that delivers advanced class-loading features and full lifecycle management.

240 240 Services-Oriented Architecture: Services can be easily added or removed based on your specific needs. All services are neatly packaged and fully hotdeployable. You can also create and add your own services easily. Aspect-Oriented Programming (AOP) model: With AOP you can take advantage J2EE-like functionality for any plain old Java objects (POJOs). Free documentation and an extensive and active user community Expert professional support that comes from the source. As we can see, JBoss is a quite famous Application Server and is widely used in the J2EE platform. As a DBMS we use PostgreSQL. This DBMS is historically used in Linux based development environments and although is not as famous as MySQL it has many more features than this one. PostgreSQL is a highly scalable, SQL compliant, open source object-relational database management system. It has more than 15 years of development history and it is quickly becoming the de facto database for enterprise level open source solutions. Finally, the last version 8.0 is supported by Windows systems. PostgreSQL is open source but it has features as sophisticated as the number one commercial database beating all the other open source DBMSs. PostgreSQL has most features present in large commercial DBMSs, like transactions, subselects, triggers, views, foreign key referential integrity, and sophisticated locking. It also has some features they do not have, like user-defined types, inheritance, rules, and multiversion concurrency control to reduce lock contention. PostgreSQL provides identifier generators which is much better than counter columns used for example in MySQL. I use Eclipse as a main IDE for the development of this application. Also, I use the EMF plug-in for UML description.

241 USE CASE VIEW Now we will describe the elements that are obtained from the requirements before mentioned. A model of the system will be elaborated using use case diagrams, being obtained a detailed requirement analysis. Each use case will reflect in a formal way a functional requirement of the system. We will begin recognizing the actors that interact with the system and then the use cases will be identified giving a detailed explanation and relating them with the functions that they have to make. That is to say, identifying the actors will obtain the users, entities, etc. that interact with the system and with the use cases we will obtain the functionalities of the system (different operations of the system, a tangible work that one can see from the exterior and to deduce starting from the requirements). System actors: Unregistered Users: These kind of users, only can visit the store as visitors and can only consult the catalogue but they can not buy any products. Registered Users: These users are the ones that have fill the registration form with his information, for that they are allow to add products to the cart and buy them.

242 General Diagram Next, we show a general use case diagram that shows the basic functionality of the system: Figure 78 As we can see in the figure; we show the registered actor as a specialization of the unregistered actor because it can do the same than the unregistered actor but also other functionalities more. The unregistered user can perform product searches, view products information and also he can register into the application. Also, if he is already registered but he didn t log-in he can do it anytime. The use case are represented as abstract because they are not implemented, they are just a general description, later we will show other diagrams for each of these use cases; except for visualize orders and user validation that are already a atomic functionality and they are nor split in more use cases. The registered user is the only one who can visualize orders and do the shopping cart administration.

243 243 The user validation use case means that the user in order to do other functionalities like visualize orders the system first must check that is already log-in User Registration Diagram Now we show, the use case diagram for the user registration functionality: Figure 79 An unregistered user can anytime register in the application in order to be able to order products; this operation causes an update in the user database. Also, a registered user may want to change its register information, before do that the application must check that the user is already logged-in.

244 User Authentication Next, we show the use case diagram related to the user authentication functionality: Figure 80 An unregistered user can log-in to be able to buy products, also a registered user can explicit log-out from the application in anytime.

245 Product Visualization This is the diagram that shows the use cases related to the product visualization functionality: Figure 81 As we can see, an unregistered or registered user can view any product after they have search for it (Find Product). Show product is an abstract use case with two different implementations, one to show books and other to show CDs. Also, is important to realize that if the user wants, he may add the product to his shopping cart to buy it later. The Find Products use case it will be discussed next.

246 Product Searches Product searches use case diagram: Figure 82 The main use case is find product, which can be implemented in two different ways: find by title and find by category. Also, if the user wants he can click on the title from the search result too view the product information.

247 Shopping Cart Administration Next, we show the use case diagram of the shopping cart administration use case: Figure 83 This diagram show the main functionalities that a registered user can perform related to the shopping cart management. The user may add a product to his cart or remove it; he may also change the number of units of a product on his shopping cart. When the user wants, he can buy all the products that are in the shopping cart, this will generate an order, which includes the removal of all products from the cart. Also, a user may want to use different order information to send the products to another location different from the one that is on the registration information.

248 LOGICAL VIEW On this section we will take a close look to the internal structure of the application analyzing each package classes and the relations between the packages that constitute the application. The packages have been named using the standard: Country Code: fi Organization Code: mamk Author name: jramos Global application name: j2ee Subsystem name: j2eestore Packages names: model, http GLOBAL ARCHITECTURE Next, we will show the general architecture of the system. We will show the main packages and their relations. Since one diagram is too big, I have divided the main diagram in several package diagrams, one for each system facade. Please, review the Struts MVC pattern and the J2EE core patterns section to be able to follow the diagrams.

249 Item Facade Figure 84 The actor interacts with the actions of struts http controller that uses the actionforms from the view layer. The controller is in charge to call the Business Delegate, in this case itemfacade.delegate. The itemfacade use the Session Bean from the itemfacade.ejb package. From the Session Facade we use the item and category DAO to perform the main operations like the searches and we use also the VOs that they return. This is an example of the Fast-Lane Reader pattern, where the Business Delegate uses DAOs instead of entity beans.

250 User Facade Figure 85 This structure is very similar to the last one. In this case, we don t use DAOs as is not necessary. Also, we use the util package to use GlobalNames (where we keep the global names of the application) in UserFacadeHelper.java. UserFacadeEJB.java (in the userfacade.ejb package) is the implementation of the Session Bean (the facade). It uses the UserFacadeHelper.java. as final class with additional functions and the userfacade.ejb.actions package to perform other functions like change password, log-in or register a new user.

251 Util Facade Figure 86 In this case, we are using the fast-lane reader design pattern to perform the search operations. The Business Delegate needs to perform search operations that return a great amount of objects: Transport VO, Country VO or both. So, the business delegate (utillfacade) uses directly the DAOs and no Entity Beans are used for efficiently reasons.

252 Shopping Facade Figure 87 This structure is the same until we reach the Session Facade (shoppingfacade.ejb). The different is that in this case we use three entity beans: shoppingcart in the shoppingcart.ejb package and order and orderline in the order.ejb package.

253 253 So, as we can see the architecture is very simple and similar, the only differences is that sometimes we implement the fast-lane reader pattern and other not, depending in the amount of objects returned on the searches. The structure is basically the implementation of the Struts framework on the view and controller layer. The user, request an operation that is catch by the http controller that uses the package http.controller.actions to perform the operation calling the business delegate in the model layer. The business delegate calls the session facade that is a session bean that takes care of everything. Usually, it will rely on another package ejb.actions that contents the classes which perform the actions. Then, depending if we implement the fast-lane reader pattern or not, the session facade will call DAOs or entity beans to access the VOs.

254 PACKAGE DESCRIPTIONS Next, we will take a closer look to each packet on the application. We will tell the objective of the packet, its structure (class diagram) and its relation with other packages on the system Package fi.mamk.jramos.j2ee.j2eestore.model.category.dao Objective: This package implements the access to the database for the categories of our store. The categories are use to group similar products and they follow a tree structure (it exists a father category and several sons). This object is necessary to be persistent to be able to visualize it correctly. Structure: Figure 88

255 255 In the diagram we can see that the package implements the pattern Data Access Object (DAO) to hide the access to the database and be able to obtain the data of each category. This pattern will be used many times along the application. The SQLCategoryDAOFactory is a factory (see factory design pattern) that allows us to obtain the DAOs. The interface SQLCategoryDAO defines methods to access to the categories (to find the children of the category, to find for key and to find the articles of a category) and in our case it is implemented by StandardSQLCategoryDAO that represents the access to a DB using Standard SQL. Also, for this application, since we use EJB and we also make use of the Fast-Lane Reader pattern, we need additional classes (the Generic classes) because in EJB we should not receive the connection to access to the DB, since it is the own container the one that negotiates the connections by using DataSources. For this reason we see the parallel structure of the Generic, very similar to that commented previously (with his factory, etc.) but whose SQLGenericCategoryDAO has a DataSource that is used to obtain the connection and then use the normal DAO (via its corresponding factory) to finally carry out the access to DB.

256 256 Package Dependences: Figure 89

257 257 As we can see this package uses the category VO and the Item VO packages, because the category DAO will create the VOs. Also, three util packages are used for many other packages and content some general functions: Configuration package: This packet contains ConfigurationParametersManager class that takes care of the main configuration of the application like JNDI service. It used the ConfigurationParameters.properties file to read the options. SQL package: It has many classes concerning to the DB, like the DataSource Locator or the identifier generator. As well, as other general operations like closing the resultset or statement. Exceptions package: In this package we keep our Java exceptions like: InstanceException, InternalErrorExeption, InstanceNotFoundException

258 Package fi.mamk.jramos.j2ee.j2eestore.model.category.vo Objective: This package is related with the last one. This package represents a business model object or a group of them. Concretely it represents a category. It is use for the package category.dao to group the info taken from the DB into one object. The DAO hides the database access. Structure: Figure 90 This package implements the Value Object pattern. In this case we have two VO: CategoryVO and CustomCategoryVO. The first one is a Domain VO that is used to contain a group of attributes belonging to a category, that is, the ID and the name. The second is a Custom VO that is used to be able to access to the items that are on a low category and we want to know if a category is "leaf ", that means, there are not sons categories and we can already find items related with this category.

259 Package fi.mamk.jramos.j2ee.j2eestore.model.country.dao Objective: This package implements the access for the countries of our store. The patron DAO pattern also is implemented and its structure is very similar to the category.dao. The difference in all the implementations of the DAO pattern that we will see, is that each domain object has different access methods to the database, in this case we need only to find a country using primary key and to look for all the countries. Structure: Figure 91

260 260 Package Dependences: Figure 92 We can see that this diagram is very similar to the category.dao. We use the same util packages. But we change the VO and we use country.vo package.

261 Package fi.mamk.jramos.j2ee.j2eestore.model.country.vo Objective: Here we have another implementation of the VO pattern that is simplier than case of the categories, since we don't have Custom VO, so only we have a Domain VO that is used to represent to a country. Structure: Figure 93

262 Package fi.mamk.jramos.j2ee.j2eestore.model.idegenerator.ejb Objective: This package represents an EJB component (Entity Bean) that is used to generate the ID of the EJB Order, OrderLine and ShoppingCartItem component. We can access to it and request that it returns us the ID that corresponds to an object before creating it. We will have a row in the table associated to each entity that needs the generation of ID. Structure: Figure 94 The architecture of this package is the typical of an Entity Bean. On one hand we have the local interface (IDGeneratorLocal class) that provides simple operations that get the following ID. This Entity Bean is a CMP type, which means that the persistence is managed by the own container. The Local Home interface (IDGeneratorLocalHome class) it is a factory of IDGeneratorLocal that also allows to look for a IDGeneratorLocal based on the name of the associate entity. When an ID is needed, we will interact with this interface requesting the key starting from the name of the Entity Bean.

263 263 The class IDGeneratorEJB is the implementation class of the Entity Bean. In this class they are usually implemented the actions of the local interface and of the home interface. In this case because its a CMP EntityBean the operations are implemented in a trivial way (the responsibility is of the EJB container).

264 Package fi.mamk.jramos.j2ee.j2eestore.model.item.dao Objective: This package implements the database access for the products of our store. The DAO pattern is also implemented and its structure is very similar the other DAOs. As we mention before, The difference in all the implementations of the DAO pattern that we will see, is that each domain object has different access methods to the database, in this case we need only to find a product by primary key, to check if a product exists and also a search by key word that allows the clients to find what they need. Structure: Figure 95 Again we have, the same structure, the StandarSQLItemDAO which implements the data access methods using standard SQL and the GenericItemDAO that is used to avoid the EJB from receiving directly the connection.

265 265 Package Dependences: Figure 96 We use the model.util package to access to the global names.

266 Package fi.mamk.jramos.j2ee.j2eestore.model.item.vo Objective: Here we have another implementation of the VO pattern. In this case we have only a Domain VO that has operations get/set for the attributes that a product need (Names, ID, type, stock, etc.) Structure: Figure 97

267 Package fi.mamk.jramos.j2ee.j2eestore.model.itemfacade.delegate Objective: In this package we have the facade with the use cases relative to the products, that is, the search of a product for name, the search of the specific product (book or CD), from a generic product as well as the search of products of a certain category. The objective is to group the use cases that have to do with the products to avoid joinings. Structure: Figure 98 We have a class ItemFacadeDelegate that is the interface that defines the search methods commented before. The methods return VOs or collections of VOs except in the case of findspecific that returns an serializable object since we don't know if it is a book or a CD, this aspect will be discuss again when we explain the VO relative to the specific products. This interface will be implemented in a different way if we use EJB or not (PlainItemFacadeDelegate or EJBItemFacadeDelegate). It is based on the Business Delegate pattern to represent a group of use cases related and also to hide the technologies of the model. In EJB the Business Delegate it will be a local object (proxy) and the Session Façade a remote object. We will discuss this on the next section. We also have a factory (ItemFacadeDelegateFactory) that provides us a method to obtain the facade.

268 268 Package Dependences: Figure 99 As we can see, this package uses the category and item VOs.

269 Package fi.mamk.jramos.j2ee.j2eestore.model.itemfacade.ejb Objective: This package contains the implementation of the articles facade for EJB, that means, it takes charge of carrying out the actions of articles search commented previously. Structure: Figure 100 This facade is a Session Bean that it is not persistent and it is habitually used to implement the facades of the model. In this case, the facade doesn't have state and for that reason the Session Bean is Stateless (SLSB).

270 270 In the package we have the class ItemFacade that is the remote interface of the Session Bean and it provides the operations of the facade representing the whole business logic associated to the products. The class ItemFacadeHome is the remote interface home of the Session Bean and is used to create an instance of the facade. And on the other hand, the class ItemFacadeEJB is the implementation class of the facade. The class EJBItemFacadeDelegate is an application of the Business Delegate pattern, and therefore is used to hide the technology used on the model, in this case EJB. It serves as proxy of the SessionFaçade and it acts looking using JNDI a reference to the home interface by means of the EJBHomeLocator and delegating the operations in the facade that provides him the home interface using the method create..

271 271 Package Dependences: Figure 101 It uses the category, item and specific item DAOs to perform the searches. Also, it uses the util packages.

272 Package fi.mamk.jramos.j2ee.j2eestore.model.order.ejb Objective: This package contains the implementation from all the relative to the orders in EJB. There are two components: the order and the lines that compose it. The order has attributes like the date, the shipment address, the total price, etc. and for each line we have the product to which refers, the number of units and the price. In this package we have the implementation of two CMP Entity Beans whose structure is very similar to that of the package idgenerator.ejb it differs in that the home interface of the order includes another search operation besides the search for primary key that returns us a collection of orders for a user in short. Structure: Figure 102

273 273 The structure may seem a little bit more complicated but this is due because there are to EJB involved on the package with their corresponded local and local home interfaces. So, we have the EJB order and orderline with their interfaces. Also, we are show in the Value Objects. The structure is the normal EJB structure, commented before. Package Dependences: Figure 103

274 Package fi.mamk.jramos.j2ee.j2eestore.model.order.vo Objective: In this package we have again an implementation of the VO pattern but this time it is not used together with a DAO, it is used to access in an appropriate way the information contained in the EJB components at client's level. Besides the usual Domain VO, relating to the orders and the order lines, we have three CustomVO: CustomOrderLineVO is used to be able to see data that belong to different domain objects, at the same time, in this case, the names of the products that belong to the object Item and at the same time, the number of requested articles that it belongs to the object OrderLine. CustomVisualOrderVO is used for the visualization of the orders in.jsp pages. A similar function has the class CustomOrderVO.

275 275 Structure: Figure 104 We can see the two VOs OrderVo and OrderLineVO and the three Custom VOs.

276 276 Package Dependences: Figure 105

277 Package fi.mamk.jramos.j2ee.j2eestore.model.shoppingcart.ejb Objective: Here we have the component EJB that represents to the articles of each user's car. In the application a cart object doesn t exist, each user has associates some products that are part of the cart itself. The implementation is very similar to rest of the Entity Beans's that we have seen previously, although again, the home interface has search some extra operations to find the whole content of the cart of a user and also to find a line of a cart when we have the user and the product. This last operation is necessary to check if an user already has a product in his cart and in affirmative case to add an unit and not add it again. Structure: Figure 106 This is a usual structure of an Entity Bean. We have the Bean, and its local and local home interface.

278 278 Package Dependences: Figure 107 This package access to the shoppingcart.vo package to create the ShoppingCartItemEJB using the ShoppingCartItemVO. Also, it need to access to the idgenerator.ejb package to create the entity bean.

279 Package fi.mamk.jramos.j2ee.j2eestore.model.shoppingcart.vo Objective: In this package is another implementation of the VO pattern but again this time it is not used together with a DAO, it is used to present in an appropriate way the information contained in the EJB component. Besides the usual Domain VOs, we have two CustomVO: CustomShoppingCartVO: It represents to the cart has a whole. It includes a collection with the products and the global price of the cart. CustomShoppingCartItemVO: It is similar to the seen in the orders and it is use to be able to represent data that belong to different domain objects, in this case we mix attributes of the articles of the cart and of the products of the store.

280 280 Structure: Figure 108 This diagram shows the VOs classes.

281 Package fi.mamk.jramos.j2ee.j2eestore.model.shoppingfacade.delegate Objective: In this package we have an implementation of the Business Delegate pattern again, in this case it is the facade that allows to carried out all the use cases relative to the purchase of the products of the cart, generation of orders, orders search based on different parameters, orders modification, empty of the car, etc. The use cases of this section use the VOs seen on the section before (CustomVisualOrderVO, CustomOrderVO, CustomOrderLineVO) to return the relative information to the orders in an appropriate way to show it on screen. Structure: Figure 109 The structure is like the usual facade delegate. See for example, itemfacade.delegate

282 282 Package Dependences: Figure 110

283 Package fi.mamk.jramos.j2ee.j2eestore.model.shoppingfacade.ejb Objective: Here we have the implementation of the shopping facade (last section) for EJB, using the Session Façade pattern. We implement the use cases in a similar way to the itemfacade.ejb but in this case the facade it is something more complex and it will require the creation of new classes that we detail next. Structure: Figure 111

284 284 As we can see in the diagram, the architecture is very similar to the itemfacade.ejb package and the implementation of any EJB Session Bean. The different is in the class ShoppingFacadeHelper that is a support class to the implementation of the facade that carries out diverse actions that are not implemented in the own ShoppingFacadeEJB due to its complexity. The first methods of this class are use to obtain references to the local interfaces and home interfaces of the products on the cart, the orders and the lines of the orders, using for it the Service Locator pattern. This is necessary so that the shopping facade can obtain the products of the cart and the necessary orders to carry out its actions. For example, we see that to carry out the removal of a product on the cart ShoppingFacadeEJB calls to the ShoppingFacadeHelper to obtain the reference to the local interface of this product and it simply executes the remove method. The own EJB container takes charge of removing the product. On the other hand the ShoppingFacadeHelper implements a series of operations directed to transform a local interface (or a collection of them) in one of the VOs mentioned in the shoppingcart.vo section (or a collection of them). These operations have names like toxxxx indicating the type of VO that returns. For example, toordervo returns the OrderVO corresponding to a OrderLocal. The implementation of each one of the toxxxx methods is very similar, it is obtain the value of the attributes using the methods get of the local interface and to generate a VO from them, for example, the toshoppingcartitemvo code is, simply: return new ShoppingCartItemVO(shoppingCartItemLocal.getShoppingCartItemID (), shoppingcartitemlocal.getnumberitems (), shoppingcartitemlocal.getitemid ()); The rest of methods are very similar, those that simply return collections they interact on the collection of local interfaces generating another collection of VOs.

285 285 It is necessary to highlight that ShoppingFacadeEJB not only uses the class helper, also the actions (explained next) access to him. This obvious since, like it will be explained, the package actions is an extension of the facade so that this it is not too big.

286 286 Package Dependences: Figure 112 As we can see, this package uses the other VOs and also the ejb.actions that we will explain next.

287 Package fi.mamk.jramos.j2ee.j2eestore.model.shoppingfacade.ejb.actions Objective: In this package we have several action classes that belong together to some of the use cases that it should implement the facade. In the shopping facade, due to their complexity, we have decide to separate the actions so that the class of the facade (ShoppingFacadeEJB) it is not too big. Structure: Figure 113 In the diagram we see the group of actions that we need. Every time that we call to a method on the facade, this it will create an instance of the action with the values that indicate who affects the action in his constructor. For example, to add a product to the car, a CreateShoppingCartItemAction is created and in the constructor is passed the ShoppingCartItemVO and the user.

288 288 Package Dependences: Figure 114

289 Package fi.mamk.jramos.j2ee.j2eestore.model.specificitem.dao Objective: In this package we have implemented the access to data for each one of the specific articles that we have in our store (books and CD's). Again the pattern that has been used is DAO but in this case the architecture is different from what we have seen. Structure: Figure 115

290 290 The architecture that we see is similar to the DAO of the category.dao package, but here we don't have only an implementation of SQLSpecificItemDAO and GenericSpecificItemDAO. This is because each product type requires a different access to the DB. In this case, the method getdaoclass of the factory requires to be passed a ItemVO that indicates the product type for which is wanted to obtain a DAO. Then, using a name convention with the name of the type (Book or CD) we instance the class of the appropriate DAO. This happens as much for SQLSpecificItemDAO as for GenericSpecificItemDAO. The operation of GenericSpecificItemDAO is similar to the one seen previously; this class is used with EJB to avoid passing the connection to the DAO. It is also necessary to point out that the DAO returns a serializable object since it doesn't know if a book or a CD will be returned, in fact one of the two VO will be returned that are described in the following section.

291 291 Package Dependences: Figure 116

292 Package fi.mamk.jramos.j2ee.j2eestore.model.specificitem.vo Objective: Again, this package goes related with the previous one, it is an implementation of the Value Object pattern that is used by the DAO to represent the obtained information of the database. We have a VO for the books (BookVO) and another for the CD's (CDVO). Later on, in the case of adding more kinds of products in our store we would need to define their DAO and their corresponding VO. The two VO that are in this package can be returned by the SQLSpecificItemDAO (each one of their implementations returns concretely one). The structure is similar to the categoty.vo package. Structure: Figure 117

293 Package fi.mamk.jramos.j2ee.j2eestore.model.transport.dao Objective: This package implements the access database for the types of transport of our store. It also implements the DAO pattern and its structure is very similar to the categoty.dao package. The types of transport refer to the different ways of sending an order (urgent mail, by air, etc.). In this case the implementation is very simple, and the two only accesses that are made to the database are the search of a concrete kind of transport (by primary key) or the search of all the types of transport (useful so that the user can choose when carrying out an order). Structure: Figure 118 The structure is the usual for a DAO.

294 294 Package Dependences: Figure 119

295 Package fi.mamk.jramos.j2ee.j2eestore.model.transport.vo Objective: This is another implementation of the VO pattern. In this case the implementation is very simple, nothing is required but that a Domain VO that represents a type of transport (its ID, its name and the sending charges). It will be what the methods of the previous DAO return (an unique VO or a collection). Structure: Figure 120

296 Package fi.mamk.jramos.j2ee.j2eestore.model.userfacade.delegate Objective: In this package we have an implementation of the Business Delegate pattern again, in this case it is the facade that allows us to make all the use cases related to the registration of users, authentication, password change, search of user's profiles and modification of this profile. This facade uses, as input of its methods, as well as their output, the UserProfile VO s that will be defined later and a particular VO of this facade (LoginResultVO) that will also be explained later on. Structure: Figure 121 The structure is like the itemfacade.delegate package.

297 297 Package Dependences: Figure 122

298 Package fi.mamk.jramos.j2ee.j2eestore.model.userfacade.ejb Objective: Here we have the implementation of user's facade (previous section) for EJB, using the Session Façade pattern again. We implement the use cases in a similar way to the itemfacade.ejb package and we have separated the actions so that the class of implementation of the facade is not too big in the same way that in the shoppingfacade.ejb package. And also the same as in the shoppingfacade.ejb package we have a class UserFacadeHelper that in this case only makes functions of locating local interfaces and Home interfaces.

299 299 Structure: Figure 123

300 300 Package Dependences: Figure 124

301 Package fi.mamk.jramos.j2ee.j2eestore.model.userfacade.ejb.actions Objective: This package is very similar to that of the shoppingfacade.ejb.actions package. It contains the classes action that implement the use cases defined in the facade. The actions it has been decided to create a class for are the authentication (LoginAction), the registration of an user (RegisterUserAction) and the password change (ChangePasswordAction) Structure: Figure 125

302 302 Package Dependences: Figure 126

303 Package fi.mamk.jramos.j2ee.j2eestore.model.userfacade.exceptions Objective: This package so only contains the exception for incorrect password and it notifies user's name which it refers to. In the future new user exceptions can be added. Structure: Figure 127

304 Package fi.mamk.jramos.j2ee.j2eestore.model.userfacade.util Objective: This package contains two classes that are used for making the key crypting. It is necessary in the facade to be able to crypt each user's password. The class jcrypt contains a similar crypting algorithm to that of the command crypt of UNIX. The class PasswordEncrypter uses this algorithm to carry out the crypting. Structure: Figure 128

305 Package fi.mamk.jramos.j2ee.j2eestore.model.userfacade.vo Objective: This package contains a specific VO of the facade, LoginResultVO, that is used to return the result of an authentication. Concretely it returns the crypted password, user's name and the country information and language. This VO is necessary so that the application view can know these data once login has been made and then present them in the screen. Structure: Figure 129

306 Package fi.mamk.jramos.j2ee.j2eestore.model.userprofile.ejb Objective: Here we have the EJB component that represents each user's profile. The implementation is very similar to Entity Beans that we have seen before. In this case, the home interface only defines the search method for primary key besides the creation method. This CMP Entity Bean contains all the relative to the user (name, address, credit card, password, , etc.) The class of the Entity Bean uses the VOs that we will see next, for the creation of an instance (method ejbcreate).

307 307 Structure: Figure 130 This is a usual Entity Bean structure.

308 308 Package Dependences: Figure 131

309 Package fi.mamk.jramos.j2ee.j2eestore.model.userprofile.vo Objective: Again, we have another VO pattern. In this case, we have two Domain VO related. One (UserProfileVO) contains the most used user data (login and password) and the other one (UserProfileDetailsVO) it contains the rest of attributes, that is, the user's details. It has been carried out the division in two related VO to not having to load the entirety user's data when we don't need them. Structure: Figure 132 As we see in the diagram, in the UserProfileVO we have a reference to UserProfileDetailsVO (using getuserprofiledetailsvo and setuserprofiledetailsvo) in such a way that the VO corresponding to the details of the profile is not used in an isolated way.

310 Package fi.mamk.jramos.j2ee.j2eestore.model.util Objective: This package contains classes that perform operations or contain data that serve as support to the rest of the model. We will define them next: DateOperations: This class contains operations to convert a date format to another. In short, we need to be able to pass from a type Dates to a type Calendar and vice versa, the two types are used in the application. GlobalNames: This class contains a series of public attributes that we need to obtain the JNDI name of the home interfaces. This name will be passed as parameter to the EJBHomeLocator to obtain a reference to the home interface. QueryProcessor: this class is needed to carry out the query to the database to be able perform searches for key words. An example, if we look for key word Led, the query would find all those products whose name is Led Zeppelin. Structure: Figure 133

311 311 Package Dependences: Figure 134

312 Package fi.mamk.jramos.j2ee.j2eestore.model.utilfacade.delegate Objective: In this package we have an implementation of the Business Delegate pattern, in this case it is an additional facade that allows to be carried out a series of operations that they don't fit in a logical way in the other facades, in this case is the countries search and type of transport, to look for one concrete or to return all. Structure: Figure 135

313 313 Package Dependences: Figure 136

314 Package fi.mamk.jramos.j2ee.j2eestore.model.utilfacade.ejb Objective: Here we have the implementation of the util facade for EJB. We implement the cases of use in a similar way to the itemfacade.ejb. In this case, due to the simplicity of the operations and that the implementation class is not too big it has not been opted to create a separate package for the actions. This facade access directly to the DAO, and we use a Page-by-Page Iterator pattern because its methods can return a great amount of elements.

315 315 Structure: Figure 137

316 316 Package Dependences: Figure 138

317 Package fi.mamk.jramos.j2ee.j2eestore.http.controller.actions Objective: This package has as aim to develop a controller that separates in the most transparent possible way the view of the application from its model. For it, a set of actions were implemented so they will catch the parameters hooked to the request (via an Action Form associated), and invoke the use case through the facade (via delegate) with the captured parameters. Once executed the use case, and in function of the result returned by the pattern, the action determines which is the following URL that should be invoked. Structure: Figure 139