An Example of Building an Enterprise Web Applicationpeople.cis.ksu.edu/~jramos/DIPLOMA...
336
Javier Ramos Rodríguez J2EE Internet Store An Example of Building an Enterprise Web Application Bachelor’s Thesis Information Technology May 2005
Transcript of An Example of Building an Enterprise Web Applicationpeople.cis.ksu.edu/~jramos/DIPLOMA...
Javier Ramos Rodríguez
J2EE Internet Store An Example of Building an Enterprise Web
Application
Bachelor’s Thesis Information Technology
May 2005
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
List of figures
Chapter 2: FIGURE 1 .................................................................................................................................................... 33 FIGURE 2 .................................................................................................................................................... 34 FIGURE 3 .................................................................................................................................................... 35 FIGURE 4 .................................................................................................................................................... 38 FIGURE 5 .................................................................................................................................................... 39 FIGURE 6 .................................................................................................................................................... 43 FIGURE 7 .................................................................................................................................................... 49 FIGURE 8 .................................................................................................................................................... 57 FIGURE 9 .................................................................................................................................................... 57 FIGURE 10 .................................................................................................................................................. 66 FIGURE 11 .................................................................................................................................................. 88 FIGURE 12 .................................................................................................................................................. 92 FIGURE 13 .................................................................................................................................................. 95 FIGURE 14 .................................................................................................................................................. 96 FIGURE 15 .................................................................................................................................................. 97 FIGURE 16 ................................................................................................................................................ 102 FIGURE 17 ................................................................................................................................................ 104 FIGURE 18 ................................................................................................................................................ 105 FIGURE 19 ................................................................................................................................................ 106 FIGURE 20 ................................................................................................................................................ 107 FIGURE 21 ................................................................................................................................................ 109 FIGURE 22 ................................................................................................................................................ 114 FIGURE 23 ................................................................................................................................................ 116 FIGURE 24 ................................................................................................................................................ 128 FIGURE 25 ................................................................................................................................................ 129 FIGURE 26 ................................................................................................................................................ 132 FIGURE 27 ................................................................................................................................................ 133 FIGURE 28 ................................................................................................................................................ 134
Chapter 3: FIGURE 29 ................................................................................................................................................ 155 FIGURE 30 ................................................................................................................................................ 156
4
Chapter 4: FIGURE 31 ................................................................................................................................................ 169 FIGURE 32 ................................................................................................................................................ 170 FIGURE 33 ................................................................................................................................................ 171 FIGURE 34 ................................................................................................................................................ 171 FIGURE 35 ................................................................................................................................................ 172 FIGURE 36 ................................................................................................................................................ 173 FIGURE 37 ................................................................................................................................................ 174 FIGURE 38 ................................................................................................................................................ 175 FIGURE 39 ................................................................................................................................................ 176 FIGURE 40 ................................................................................................................................................ 176 FIGURE 41 ................................................................................................................................................ 177 FIGURE 42 ................................................................................................................................................ 178 FIGURE 43 ................................................................................................................................................ 179 FIGURE 44 ................................................................................................................................................ 180 FIGURE 45 ................................................................................................................................................ 181 FIGURE 46 ................................................................................................................................................ 182 FIGURE 47 ................................................................................................................................................ 182 FIGURE 48 ................................................................................................................................................ 184 FIGURE 49 ................................................................................................................................................ 185 FIGURE 50 ................................................................................................................................................ 186 FIGURE 51 ................................................................................................................................................ 187 FIGURE 52 ................................................................................................................................................ 187 FIGURE 53 ................................................................................................................................................ 188 FIGURE 54 ................................................................................................................................................ 190 FIGURE 55 ................................................................................................................................................ 191 FIGURE 56 ................................................................................................................................................ 193 FIGURE 57 ................................................................................................................................................ 194 FIGURE 58 ................................................................................................................................................ 195 FIGURE 59 ................................................................................................................................................ 196 FIGURE 60 ................................................................................................................................................ 197 FIGURE 61 ................................................................................................................................................ 199 FIGURE 62 ................................................................................................................................................ 200 FIGURE 63 ................................................................................................................................................ 202 FIGURE 64 ................................................................................................................................................ 203 FIGURE 65 ................................................................................................................................................ 204 FIGURE 66 ................................................................................................................................................ 206 FIGURE 67 ................................................................................................................................................ 207 FIGURE 68 ................................................................................................................................................ 211 FIGURE 69 ................................................................................................................................................ 213 FIGURE 70 ................................................................................................................................................ 215 FIGURE 71 ................................................................................................................................................ 216 FIGURE 72 ................................................................................................................................................ 217 FIGURE 73 ................................................................................................................................................ 219 FIGURE 74 ................................................................................................................................................ 221 FIGURE 75 ................................................................................................................................................ 223 FIGURE 76 ................................................................................................................................................ 226 FIGURE 77 ................................................................................................................................................ 228
5
Chapter 5: FIGURE 78 ................................................................................................................................................ 242 FIGURE 79 ................................................................................................................................................ 243 FIGURE 80 ................................................................................................................................................ 244 FIGURE 81 ................................................................................................................................................ 245 FIGURE 82 ................................................................................................................................................ 246 FIGURE 83 ................................................................................................................................................ 247 FIGURE 84 ................................................................................................................................................ 249 FIGURE 85 ................................................................................................................................................ 250 FIGURE 86 ................................................................................................................................................ 251 FIGURE 87 ................................................................................................................................................ 252 FIGURE 88 ................................................................................................................................................ 254 FIGURE 89 ................................................................................................................................................ 256 FIGURE 90 ................................................................................................................................................ 258 FIGURE 91 ................................................................................................................................................ 259 FIGURE 92 ................................................................................................................................................ 260 FIGURE 93 ................................................................................................................................................ 261 FIGURE 94 ................................................................................................................................................ 262 FIGURE 95 ................................................................................................................................................ 264 FIGURE 96 ................................................................................................................................................ 265 FIGURE 97 ................................................................................................................................................ 266 FIGURE 98 ................................................................................................................................................ 267 FIGURE 99 ................................................................................................................................................ 268 FIGURE 100 .............................................................................................................................................. 269 FIGURE 101 .............................................................................................................................................. 271 FIGURE 102 .............................................................................................................................................. 272 FIGURE 103 .............................................................................................................................................. 273 FIGURE 104 .............................................................................................................................................. 275 FIGURE 105 .............................................................................................................................................. 276 FIGURE 106 .............................................................................................................................................. 277 FIGURE 107 .............................................................................................................................................. 278 FIGURE 108 .............................................................................................................................................. 280 FIGURE 109 .............................................................................................................................................. 281 FIGURE 110 .............................................................................................................................................. 282 FIGURE 111 .............................................................................................................................................. 283 FIGURE 112 .............................................................................................................................................. 286 FIGURE 113 .............................................................................................................................................. 287 FIGURE 114 .............................................................................................................................................. 288 FIGURE 115 .............................................................................................................................................. 289 FIGURE 116 .............................................................................................................................................. 291 FIGURE 117 .............................................................................................................................................. 292 FIGURE 118 .............................................................................................................................................. 293 FIGURE 119 .............................................................................................................................................. 294 FIGURE 120 .............................................................................................................................................. 295 FIGURE 121 .............................................................................................................................................. 296 FIGURE 122 .............................................................................................................................................. 297 FIGURE 123 .............................................................................................................................................. 299 FIGURE 124 .............................................................................................................................................. 300 FIGURE 125 .............................................................................................................................................. 301 FIGURE 126 .............................................................................................................................................. 302 FIGURE 127 .............................................................................................................................................. 303 FIGURE 128 .............................................................................................................................................. 304 FIGURE 129 .............................................................................................................................................. 305 FIGURE 130 .............................................................................................................................................. 307 FIGURE 131 .............................................................................................................................................. 308 FIGURE 132 .............................................................................................................................................. 309 FIGURE 133 .............................................................................................................................................. 310 FIGURE 134 .............................................................................................................................................. 311 FIGURE 135 .............................................................................................................................................. 312
6
FIGURE 136 .............................................................................................................................................. 313 FIGURE 137 .............................................................................................................................................. 315 FIGURE 138 .............................................................................................................................................. 316 FIGURE 139 .............................................................................................................................................. 317 FIGURE 140 .............................................................................................................................................. 319 FIGURE 141 .............................................................................................................................................. 320 FIGURE 142 .............................................................................................................................................. 322 FIGURE 143 .............................................................................................................................................. 323 FIGURE 144 .............................................................................................................................................. 324 FIGURE 145 .............................................................................................................................................. 325 FIGURE 146 .............................................................................................................................................. 327 FIGURE 147 .............................................................................................................................................. 328 FIGURE 148 .............................................................................................................................................. 329
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
− 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
− 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
TABLE OF CONTENS
Description.................................................................................................................................................. 2
List of figures.............................................................................................................................................. 3
Abbreviations ............................................................................................................................................. 7
PREFACE ................................................................................................................................................ 15
1. INTRODUCTION.......................................................................................................................... 18
1.1. OPEN SOFTWARE SOLUTIONS...................................................................................... 19 1.2. ENTERPRISE ARCHITECTURE AND THE PRESENT PANORAMA........................ 21
1.2.1. LAMP ................................................................................................................................ 24 1.2.2. CORBA .............................................................................................................................. 25 1.2.3. .NET .................................................................................................................................. 26 1.2.4. J2EE .................................................................................................................................. 28
2. JAVA 2 ENTERPRISE EDITION OVERVIEW ........................................................................ 30
2.1. J2EE DEFINITION .............................................................................................................. 30 2.2. MULTITIER ARCHITECTURE........................................................................................ 32
2.2.1. 2-tier approach .................................................................................................................. 33 2.2.2. Multitier approach ............................................................................................................ 34
2.3. MAIN ARCHITECTURAL PATTERNS USED IN ENTERPRISE APPLICATIONS . 36 2.4. J2EE MODEL ....................................................................................................................... 39 2.5. J2EE TECHNOLOGIES...................................................................................................... 42
2.5.1. JDBC ................................................................................................................................. 42 2.5.1.1. Types of JDBC technology drivers .......................................................................................44 2.5.1.2 Establishing a connection......................................................................................................45 2.5.1.3 Concurrence problems with the database ...........................................................................46
2.5.2 XML................................................................................................................................... 48 2.5.2.1 DTDs .......................................................................................................................................52
2.5.3 SERVLETS ....................................................................................................................... 53 2.5.4 JSP PAGES ....................................................................................................................... 61
2.5.4.1 JSP Pages Overview ..............................................................................................................62 2.5.4.2 JSP Use ...................................................................................................................................64 2.5.4.3 Language Syntax....................................................................................................................67
2.5.4.3.1 Directives...........................................................................................................................68 2.5.4.3.2 Script Elements................................................................................................................69 2.5.4.3.3 Comments .........................................................................................................................70 2.5.4.3.4 Actions ...............................................................................................................................71
2.5.4.4 JavaBeans ...............................................................................................................................72 2.5.4.5 JSP example ...........................................................................................................................74 2.5.4.6 JSP Architecture....................................................................................................................75
11
2.5.4.7 JSP vs. ASP ............................................................................................................................78 2.5.4.7.1 Examples ...........................................................................................................................81
2.5.5 JSP 2.0............................................................................................................................... 82 2.5.5.1 Expression Language (EL)....................................................................................................83
2.5.6 JAVA STANDARD TAG LIBRARY (JSTL).................................................................... 85 2.5.7 JAKARTA STRUTS .......................................................................................................... 87
2.5.7.1 MVC in web applications ......................................................................................................89 2.5.7.2 Servlet Front Controller pattern ..........................................................................................92 2.5.7.3 Model View Controller architecture using Struts ...............................................................94 2.5.7.4 Struts Example.......................................................................................................................95
2.5.8 DISTRIBUTED APPLICATIONS ................................................................................. 100 2.5.8.1 Distributed Applications on Internet .................................................................................101 2.5.8.2 Intranet Applets ...................................................................................................................101 2.5.8.3 Distributed Computation Environment (DCE) .................................................................101 2.5.8.4 Distributed Component Object Model (DCOM)...............................................................103 2.5.8.5 Common Object Request Broker Architecture (CORBA) ...............................................105 2.5.8.6 Java Remote Method Invocation (RMI) ............................................................................107
2.5.8.6.1 Java RMI as a technology for development enterprise applications ..........................112 2.5.9 JAVA NAMING AND DIRECTORY INTERFACE (JNDI) ........................................ 114
2.5.9.1 JNDI Architecture ...............................................................................................................116 2.5.10 ENTERPRISE JAVABEANS (EJB) ......................................................................... 118
2.5.10.1 EJB Architecture .................................................................................................................120 2.5.10.1.1 Distributed components .................................................................................................120 2.5.10.1.2 Implicit or Declarative Middleware..............................................................................121 2.5.10.1.3 Physical situation transparency ....................................................................................122 2.5.10.1.4 Local interfaces...............................................................................................................122
2.5.10.2 TYPES OF COMPONENTS ..............................................................................................123 2.5.10.2.1 Session Beans (SB)..........................................................................................................123 2.5.10.2.2 Entity Beans ....................................................................................................................125 2.5.10.2.3 Message-Driven Beans ...................................................................................................127
2.5.10.3 J2EE EJB Structure ............................................................................................................128 2.5.10.4 EJB Operation ................................................................................................................130
2.6 J2EE vs. .NET ................................................................................................................. 139 2.6.2 Similarities between J2EE and .NET ......................................................................................139 2.6.3 Advantages of .Net over J2EE..................................................................................................140 2.6.4 Advantages of J2EE over .NET ...............................................................................................142 2.6.5 The Future .................................................................................................................................144
12
3. NEW APPROACHES USING JAVA 2 PLATFORM .............................................................. 147
3.1 MVC FRAMEWORKS............................................................................................................ 149 3.1.1 JavaServer Faces (JSF) .................................................................................................. 149 3.1.2 Spring .............................................................................................................................. 150 3.1.3 Struts vs. JSF vs. Spring ................................................................................................. 151
3.2 HIBERNATE .......................................................................................................................... 153 3.2.1 Hibernate Structure ........................................................................................................ 155 3.2.2 Hibernate Overview......................................................................................................... 156 3.2.3 Hibernate Features ......................................................................................................... 157 3.2.4 Hibernate Example ......................................................................................................... 160
4. DESIGN PATTERNS .................................................................................................................. 168
4.1 USUAL OOP DESIGN PATTERNS ................................................................................. 169 4.2 ENTERPRISE APPLICATIONS DESIGN PATTERNS ................................................ 209
4.2.1 Session Facade ................................................................................................................ 210 4.2.2 Business Delegate ........................................................................................................... 213 4.2.3 Service Locator................................................................................................................ 215 4.2.4 Value Object .................................................................................................................... 217 4.2.5 Value Object (EJB) ......................................................................................................... 220 4.2.6 Data Access Object .......................................................................................................... 223 4.2.7 Page-by-Page Iterator ..................................................................................................... 226 4.2.8 Fast-Lane Reader............................................................................................................ 228
5. CASE STUDY: J2EE INTERNET STORE............................................................................... 231
5.1 MAIN DESCRIPTION....................................................................................................... 232 5.1.1 Functional Requirements of the System......................................................................... 234 5.1.2 Non-Functional Requirements of the System ................................................................ 236
5.2 ARCHITECTURE.............................................................................................................. 237 5.2.1 Software Used.................................................................................................................. 239
5.3 USE CASE VIEW ............................................................................................................... 241 5.3.1 General Diagram............................................................................................................. 242 5.3.2 User Registration Diagram ............................................................................................. 243 5.3.3 User Authentication ........................................................................................................ 244 5.3.4 Product Visualization...................................................................................................... 245 5.3.5 Product Searches............................................................................................................. 246 5.3.6 Shopping Cart Administration........................................................................................ 247
13
5.4 LOGICAL VIEW................................................................................................................ 248 5.4.1 GLOBAL ARCHITECTURE.......................................................................................... 248
5.4.1.1 Item Facade ..........................................................................................................................249 5.4.1.2 User Facade ..........................................................................................................................250 5.4.1.3 Util Facade ...........................................................................................................................251 5.4.1.4 Shopping Facade..................................................................................................................252
5.4.2 PACKAGE DESCRIPTIONS ......................................................................................... 254 5.4.2.1 Package “fi.mamk.jramos.j2ee.j2eestore.model.category.dao” .......................................254 5.4.2.2 Package “fi.mamk.jramos.j2ee.j2eestore.model.category.vo” .........................................258 5.4.2.3 Package “fi.mamk.jramos.j2ee.j2eestore.model.country.dao” ........................................259 5.4.2.4 Package “fi.mamk.jramos.j2ee.j2eestore.model.country.vo”...........................................261 5.4.2.5 Package “fi.mamk.jramos.j2ee.j2eestore.model.idegenerator.ejb” .................................262 5.4.2.6 Package “fi.mamk.jramos.j2ee.j2eestore.model.item.dao” ..............................................264 5.4.2.7 Package “fi.mamk.jramos.j2ee.j2eestore.model.item.vo” ................................................266 5.4.2.8 Package “fi.mamk.jramos.j2ee.j2eestore.model.itemfacade.delegate” ...........................267 5.4.2.9 Package “fi.mamk.jramos.j2ee.j2eestore.model.itemfacade.ejb ......................................269 5.4.2.10 Package “fi.mamk.jramos.j2ee.j2eestore.model.order.ejb” .............................................272 5.4.2.11 Package “fi.mamk.jramos.j2ee.j2eestore.model.order.vo” ..............................................274 5.4.2.12 Package “fi.mamk.jramos.j2ee.j2eestore.model.shoppingcart.ejb” ................................277 5.4.2.13 Package “fi.mamk.jramos.j2ee.j2eestore.model.shoppingcart.vo”..................................279 5.4.2.14 Package “fi.mamk.jramos.j2ee.j2eestore.model.shoppingfacade.delegate”....................281 5.4.2.15 Package “fi.mamk.jramos.j2ee.j2eestore.model.shoppingfacade.ejb” ............................283 5.4.2.16 Package “fi.mamk.jramos.j2ee.j2eestore.model.shoppingfacade.ejb.actions” ...............287 5.4.2.17 Package “fi.mamk.jramos.j2ee.j2eestore.model.specificitem.dao”..................................289 5.4.2.18 Package “fi.mamk.jramos.j2ee.j2eestore.model.specificitem.vo”....................................292 5.4.2.19 Package “fi.mamk.jramos.j2ee.j2eestore.model.transport.dao”......................................293 5.4.2.20 Package “fi.mamk.jramos.j2ee.j2eestore.model.transport.vo”........................................295 5.4.2.21 Package “fi.mamk.jramos.j2ee.j2eestore.model.userfacade.delegate”............................296 5.4.2.22 Package “fi.mamk.jramos.j2ee.j2eestore.model.userfacade.ejb” ....................................298 5.4.2.23 Package “fi.mamk.jramos.j2ee.j2eestore.model.userfacade.ejb.actions” .......................301 5.4.2.24 Package “fi.mamk.jramos.j2ee.j2eestore.model.userfacade.exceptions” ........................303 5.4.2.25 Package “fi.mamk.jramos.j2ee.j2eestore.model.userfacade.util”....................................304 5.4.2.26 Package “fi.mamk.jramos.j2ee.j2eestore.model.userfacade.vo”......................................305 5.4.2.27 Package “fi.mamk.jramos.j2ee.j2eestore.model.userprofile.ejb” ....................................306 5.4.2.28 Package “fi.mamk.jramos.j2ee.j2eestore.model.userprofile.vo” .....................................309 5.4.2.29 Package “fi.mamk.jramos.j2ee.j2eestore.model.util” .......................................................310 5.4.2.30 Package “fi.mamk.jramos.j2ee.j2eestore.model.utilfacade.delegate” .............................312 5.4.2.31 Package “fi.mamk.jramos.j2ee.j2eestore.model.utilfacade.ejb”......................................314 5.4.2.32 Package “fi.mamk.jramos.j2ee.j2eestore.http.controller.actions” ..................................317 5.4.2.33 Package “fi.mamk.jramos.j2ee.j2eestore.http.controller.frontcontroller” .....................320 5.4.2.34 Package “fi.mamk.jramos.j2ee.j2eestore.http.controller.session”...................................323 5.4.2.35 Package “fi.mamk.jramos.j2ee.j2eestore.view.actionforms” ...........................................325 5.4.2.36 Package “fi.mamk.jramos.j2ee.j2eestore.view.applicationobjects”.................................328 5.4.2.37 Package “fi.mamk.jramos.j2ee.j2eestore.view.messages” ................................................330
5.5 PROJECT INFORMATION ............................................................................................. 331
14
6. CONCLUSION............................................................................................................................. 332
7. REFERENCES............................................................................................................................. 335
7.1 INTERNET REFERENCES ...................................................................................................... 335 7.2 BOOKS REFERENCES............................................................................................................ 336
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
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
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
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
1.1. 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
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
1.2. 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
• 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
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
1.2.1. 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
1.2.2. 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
1.2.3. .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
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
1.2.4. 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
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
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
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
2.2. 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
2.2.1. 2-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
2.2.2. 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
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
2.3. 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.
• 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
PRESENTATION
LOGIC
DATABASE
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
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 1980. 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
2.4. 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
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
• 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
2.5. J2EE TECHNOLOGIES
2.5.1. 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
The package diagram looks like it follows:
Figure 6
44
2.5.1.1. 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
2.5.1.2 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
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.
2.5.1.3 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
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
2.5.2 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 business-
to-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
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>10-29-52</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
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
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
2.5.2.1 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
2.5.3 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
• 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
• 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
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
The class diagram look like this:
Figure 8
Figure 9
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
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
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
2.5.4 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
2.5.4.1 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
• 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
• 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.
2.5.4.2 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
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
The main packages are javax.servlet.jsp y javax.servlet.jsp.tagext.
Figure 10
67
2.5.4.3 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
2.5.4.3.1 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
2.5.4.3.2 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
2.5.4.3.3 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
2.5.4.3.4 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
2.5.4.4 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
• 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
2.5.4.5 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
2.5.4.6 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
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.
SERVLETH T T P
CAPA 2Controller
JSP
CAPA 1View
CAPA 3Data Model
JavaBean
create
CLIENT BROWSER
REQ
RES
DB
76
A usual architecture was:
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.
CLIENT BROWSER
TOMCAT JSP PAGES
APACHESERVER
HTML PAGES
DB
JavaBeans
JAVASCRIPT
HTTP
SERVLETS(LOGIC)
JJDDBBCC
CCRREEAATTEE
UUSSEE
VVIIEEWW
DDAATTAA
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
2.5.4.7 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
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
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
2.5.4.7.1 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 = 1000000; %> 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 = 1000000; %> It would take a long time, however, to count to <%= i %>.
82
2.5.5 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
• 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.
2.5.5.1 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
${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
2.5.6 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 11th of July 2002. 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
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
2.5.7 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
The MVC pattern architecture look like it follows:
Figure 11
89
2.5.7.1 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.
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.
1. Request
3. Results
5. Uses 6. Result
4. Redirect
2. Action
WEB
BROWSER
VIEW (JSP/TagLibs)
CONTROLLER
(Servlet)
MODEL (EJBs)
STRUTS
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
• 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
2.5.7.2 Servlet Front Controller pattern
The Servlet Front Controller pattern that Struts implements is show bellow:
Figure 12
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
2.5.7.3 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
2.5.7.4 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
http://jakarta.apache.org the Struts implementation.
Then, inside the WebApp directory we create the web.xml file with the main
configuration.
Figure 13
96
A standard configuration could be:
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <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
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
<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
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:
http://localhost:8080/struts-blank/Exaction.do
100
2.5.8 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:
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.
USER INTERFACE
LEVEL
INFORMATION PROCESS
LEVEL
DATA STORAGE
LEVEL
101
2.5.8.1 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...
2.5.8.2 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.
2.5.8.3 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 (http://www.opengroup.org).
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
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
2.5.8.4 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
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
2.5.8.5 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
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
2.5.8.6 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
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
� 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
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
} 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 3 + 5 -> 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
2.5.8.6.1 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
• 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
2.5.9 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 people-
friendly names (such as www.etcee.com) into computer-friendly IP (Internet
Protocol) addresses in dotted-quad notation (207.69.175.36). Interestingly, DNS
is a distributed naming service, meaning that the service and its underlying
database is spread across many hosts on the Internet.
115
3. 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
2.5.9.1 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
� 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
2.5.10 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
• 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
2.5.10.1 EJB Architecture
2.5.10.1.1 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
2.5.10.1.2 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
2.5.10.1.3 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.
2.5.10.1.4 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
2.5.10.2 TYPES OF COMPONENTS
At the moment the standard EJB defines three types of EJB:
2.5.10.2.1 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
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
2.5.10.2.2 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
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
2.5.10.2.3 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
2.5.10.3 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
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
2.5.10.4 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
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.
create() find() remove()
debit() credit() getBalance()
<<Enterrpise Bean class> AccountBean
ejbCreate() ejbFind() ejbRemove() debit() credit() getBalance()
Deployment Descriptorname = AccountEJB class = AccountBean home = AccountHome remote = Account type = Entity transaction = required …..
<<Remote Interface>> Account
<<Home Interface>> AccountHome
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
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
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
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
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
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
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
2.6 J2EE vs. .NET
We have been talking a lot so far about these two rival platforms, now let’s summarize
everything.
2.6.2 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
2.6.3 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
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
2.6.4 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
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
2.6.5 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
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
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
3. 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
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 plug-
in. 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
3.1 MVC Frameworks
3.1.1 JavaServer Faces (JSF)
JavaServer Faces has been standardized recently (JSF)
(http://java.sun.com/j2ee/javaserverfaces).
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
3.1.2 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
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.
3.1.3 Struts vs. JSF vs. Spring
• Struts
o Advantages:
� Is the “Standard”. Many web applications have been
implemented using this framework that is running since 2001.
� 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
• 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
3.2 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
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
3.2.1 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
3.2.2 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
3.2.3 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
• 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
• J2EE integration
− JMX support
− Integration with J2EE architecture (optional)
− New JCA support
160
3.2.4 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_EMAIL` 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
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 userEmail;
162
/** persistent field */ private Date userCreationDate; /** persistent field */ private Date userModificationDate; /** full constructor */ public Applabsuser(String userName, String userPassword, String userFirstName, String userLastName, String userEmail, Date userCreationDate, Date userModificationDate) { this.userName = userName; this.userPassword = userPassword; this.userFirstName = userFirstName; this.userLastName = userLastName; this.userEmail = userEmail; 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
public void setUserFirstName(String userFirstName) { this.userFirstName = userFirstName; } public String getUserLastName() { return this.userLastName; } public void setUserLastName(String userLastName) { this.userLastName = userLastName; } public String getUserEmail() { return this.userEmail; } public void setUserEmail(String userEmail) { this.userEmail = userEmail; } 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
3. 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" "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd"> <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" not-null="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_EMAIL" length="255" name="userEmail" 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
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" "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd"> <hibernate-configuration>
<session-factory> <property name="show_sql">true</property> <property name="hibernate.dialect">org.hibernate.dialect.MySQLMyISAMDialect</property> <property name="hibernate.connection.driver_class">org.gjt.mm.mysql.Driver</property> <property name="hibernate.connection.url">jdbc:mysql://localhost:3306/applabs</property> <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
5. 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.setUserEmail("[email protected]"); user.setUserFirstName("userFirstName"); user.setUserLastName("userLastName"); user.setUserName("userName-1"); user.setUserPassword("userPassword"); session.saveOrUpdate(user); tx.commit(); session.close();
167
6. 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
4. 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
4.1 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
• 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
� 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
� 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
� 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
� 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
2. 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
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
� 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 run-
time.
• 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
• 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
� 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
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
� 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
� 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
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
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
� 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
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
� 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
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
3. 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
� 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
� 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 object-
oriented 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 space-
independent way, then you can transfer a command object for the
request to a different process and fulfill the request there.
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
� 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
Example:
Figure 57
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
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
� 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
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
� 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
� 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
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
� 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
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
� 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. Hard-
wiring 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
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
� 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
� 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
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
4.2 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
4.2.1 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
� 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
� 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
4.2.2 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
� 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
4.2.3 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
� 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
4.2.4 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
VOAttrbutes
get/set()
DAO<<Interface>>
java.io.Serializable<<Interface>>
Figure 72
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
� 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
4.2.5 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
� Structure
java.io.Serializable<<Interface>>
DAO<<Interface>>Bussines
SesionBussines
Entity
VOAttrbutes
get/set()
Client BussinesObject
<<use>>
<<use>><<create>>
<<use>><<use>>
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
� 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
4.2.6 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
� 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
� 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
4.2.7 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
� 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
4.2.8 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
� 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
� 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
5. 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
5.1 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
Each user can register in the store giving his registration information that will include:
login name, password, name, last name, e-mail 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
5.1.1 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
5. 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
5.1.2 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
5.2 ARCHITECTURE
Now we will analyze the application architecture:
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.
DB PostgreSQL
EJB Container
JBoss
Entity Beans
Session Beans
JSP Container
Tomcat
STRUTS
JSP Pages
Servlets
Web Browser
Presentation Tier
Model Tier
Database Tier
Client Tier
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
5.2.1 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
� Services-Oriented Architecture: Services can be easily added or removed based
on your specific needs. All services are neatly packaged and fully hot-
deployable. 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 multi-
version 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
5.3 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
5.3.1 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
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.
5.3.2 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
5.3.3 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
5.3.4 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
5.3.5 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
5.3.6 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
5.4 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…
5.4.1 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
5.4.1.1 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
5.4.1.2 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
5.4.1.3 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
5.4.1.4 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
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
5.4.2 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.
5.4.2.1 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
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
� Package Dependences:
Figure 89
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
5.4.2.2 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
5.4.2.3 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
� 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
5.4.2.4 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
5.4.2.5 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
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
5.4.2.6 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
� Package Dependences:
Figure 96
We use the model.util package to access to the global names.
266
5.4.2.7 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
5.4.2.8 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
� Package Dependences:
Figure 99
As we can see, this package uses the category and item VOs.
269
5.4.2.9 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
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
� Package Dependences:
Figure 101
It uses the category, item and specific item DAOs to perform the searches. Also,
it uses the util packages.
272
5.4.2.10 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
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
5.4.2.11 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
� Structure:
Figure 104
We can see the two VOs OrderVo and OrderLineVO and the three Custom VOs.
276
� Package Dependences:
Figure 105
277
5.4.2.12 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
� 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
5.4.2.13 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
� Structure:
Figure 108
This diagram shows the VOs classes.
281
5.4.2.14 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
� Package Dependences:
Figure 110
283
5.4.2.15 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
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
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
� 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
5.4.2.16 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
� Package Dependences:
Figure 114
289
5.4.2.17 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
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
� Package Dependences:
Figure 116
292
5.4.2.18 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
5.4.2.19 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
� Package Dependences:
Figure 119
295
5.4.2.20 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
5.4.2.21 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
� Package Dependences:
Figure 122
298
5.4.2.22 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
� Structure:
Figure 123
300
� Package Dependences:
Figure 124
301
5.4.2.23 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
� Package Dependences:
Figure 126
303
5.4.2.24 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
5.4.2.25 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
5.4.2.26 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
5.4.2.27 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, e-mail, etc.)
The class of the Entity Bean uses the VOs that we will see next, for the creation
of an instance (method ejbCreate).
307
� Structure:
Figure 130
This is a usual Entity Bean structure.
308
� Package Dependences:
Figure 131
309
5.4.2.28 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
5.4.2.29 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
� Package Dependences:
Figure 134
312
5.4.2.30 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
� Package Dependences:
Figure 136
314
5.4.2.31 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
� Structure:
Figure 137
316
� Package Dependences:
Figure 138
317
5.4.2.32 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
318
The Structure is too big to be show entirely here. So we are showin only some of
the classes. We have a package of actions that constitute the set of operations
that the user can carry out. These actions implement DefaultAction and use the
ActionForms (explained later on) to obtain the user's parameters. Once those
parameters are obtained, they (the actions) will invoke a use case in the facade
that corresponds. The facade, like it has been explained, is obtained by its
factory. This represents the relationship between the view and the model. It is
necessary to point out that the item facade is not directly accessed, but by the
SessionManager that will be explained later on.
319
� Package Dependences:
Figure 140
320
5.4.2.33 Package
“fi.mamk.jramos.j2ee.j2eestore.http.controller.frontcontroller”
� Objective:
This package contains the specialization of the FrontController of Struts for the
application; and several related classes that implement pre-processing filters.
� Structure:
Figure 141
321
The Front Controller of Struts (DefaultActionServlet) uses the RequestProcessor
in which delegates the petitions it receives. In the diagram we can see our
particular specializations of these two classes (J2eeStoreRequestProcessor and
FrontController) in our Front Controller we register the “Application Objects”,
in this case the ranges of the dates.
J2eeStoreRequestProcessor uses a chain of pre-processing filters (Chain of
Responsibility pattern), concretely a SessionPreProcessingFilter filter followed
by an AuthenticationPreProcessingFilter. The first filter makes sure that we
have in the session all the necessary objects if the user has been authenticated or
he/she has chosen “remember my password.” The second,
AuthenticationPreProcessingFilter checks if the action requires that the user has
been authenticated and in affirmative case, if the user has not still made login,
he/she is redirected to the appropriate page to be authenticated.
322
� Package Dependences:
Figure 142
323
5.4.2.34 Package “fi.mamk.jramos.j2ee.j2eestore.http.controller.session”
� Objective:
This package only contains the class SessionManager that is used for negotiate
session objects and cookies transparently.
� Structure:
Figure 143
We have only a class, but it is important to review the diagram of the
controller.actions package where you see the operation of this class with regard
to the other ones. The actions that require of objects of the session and/or
cookies interact with the SessionManager instead of working against the facade
of the model. And this pattern checks all the session objects and cookies,
updating them or removing them as it is necessary.
324
� Package Dependences:
Figure 144
325
5.4.2.35 Package “fi.mamk.jramos.j2ee.j2eestore.view.actionforms”
� Objective:
The main objective of this package is to have some classes that allow the simple
access to the parameters hooked to a request. Also, it is also included in this
package a support class which function is to validate the parameters that are
obtained of the forms of the .jsp pages.
� Structure:
Figure 145
326
We only have all our ActionForms inside the package and all these classes
extend the DefaultActionForm of Struts. Also, we also have
J2eeStorePropertyValidator that carries out validation operations on the fields
that require it.
327
� Package Dependences:
Figure 146
328
5.4.2.36 Package “fi.mamk.jramos.j2ee.j2eestore.view.applicationobjects”
� Objective:
In this package we have objects used by our application, concretely, a list of all
the countries, the languages, the kinds of transport and the ranges of the dates.
� Structure:
Figure 147
These classes are used for providing Struts with the lists of the countries,
languages, etc. for their later visualization. They access to the UtilFacade in the
case of the kinds of transport and the countries, to request those data that are
kept in DB.
329
� Package Dependences:
Figure 148
330
5.4.2.37 Package “fi.mamk.jramos.j2ee.j2eestore.view.messages”
This is a special package where we have a file with the messages that are show to the
user, so we can have several languages on the application.
331
5.5 PROJECT INFORMATION
Now we will show some information about the development of the application.
− Project Length: 9 months. From September 2004 to May 2005.
− Lines of Code: 46.532
− Number of Files: 591
− Documentation Information:
o Number of pages: 336
o Number of lines: 7.503
o Number of words: 43.125
332
6. CONCLUSION As a conclusion, I would say that I have learned a lot doing this diploma work. I really
like the topic and I believe that is a very interesting field that may help me considerably
in the future in my working life. Maybe, is not an easy field because there are a lot of
concepts involved but once you get the main idea you can see how these technologies
help you to avoid the usual problems in software development.
I hope that the reader after reading this diploma work will be able to develop enterprise
application using the J2EE platform; I think it will be really easy to develop a good
internet store starting from my example and using my diploma work information. I
believe, that this is a good summary about the J2EE platform that I wish it will be
helpful to someone.
I began studding Java already four years ago; I think that right now I’m prepared to
develop applications for real purposes. This is the second diploma work that I’m
writing; the first one I did it two year ago in Spain and it was also about Java. The topic
was also a Java web application, but at that time I did it just using the
JavaBean+JSP+Servlets approach. When I finished it, I realize that the applications had
many flaws, mostly related two the low scalability. The view was very dependent of the
model and also the model was dependent of the database. A change in the application
would involve a lot of work. For that reason, I began looking for a solution and that was
when I discover the EJB technology and the Struts framework.
Last year was when I got introduced two de J2EE platform and the design patterns. For
me it was a big change because at that time I knew how to build applications but they
lacked in quality and I was not be able to build real applications for real customers,
there was something missing and I was far away from develop real software. The J2EE
and the design patterns allow me to learn to develop good quality, scalable, reusable
applications for real purposes.
333
The design patterns helped me to avoid the usual troubles in the develop of enterprise
applications and the J2EE platform and the Struts framework provide me a useful tool
to develop software.
So, after finishing my fourth year in Spain knew what my topic would be. I wanted to
improve my knowledge about the Java 2 platform and continue the work that I did on
my third year. I began with my diploma work on September of 2004, learning all the
technologies and tools used to develop applications with the J2EE platform. I decided to
choose to build an Internet store because it is a usual application that everybody knows
how it works and I didn’t have to explain too much the functionality of the application
because it is well know. The idea is just to show how to build enterprise applications
and an internet store is the best and easiest example.
I would like to say that I think that develop a real application is the best way to learn
but, of course, the theory is fundamental and I had to learn all the technologies and
design pattern first. I would recommend anyone to start building an application without
learning the design patterns first, for me they were very helpful and solved many
problems that I had before.
Also, this project is all based on free software, no proprietary solutions where used. I
am very glad of the tools that I have used. I hope the actual panorama changes and more
companies begin using free source solutions. It is true that you don’t have a company
that supports your application but instead, you have thousands of developers willing to
help you and answer your questions. In the case of Java, there are more seven hundred
companies involved in the Java community.
I’m really happy with this platform and I will choose it instead of the Microsoft .NET
because all the reasons that I explain on the diploma work.
334
Finally, I just hope that this diploma work can be useful for the reader; I spend so much
time working on it. I would like to work as a software developer once I finish my career
and I think this diploma work is going to help me to find a good job when I’m finally
done with the school
335
7. REFERENCES
7.1 Internet References:
• Sun Microsystems, JSP Documentation. http://java.sun.com/products/jsp
• Sun Microsystems, XML Documentation.
http://java.sun.com/xml
• Sun Microsystems, Code Conventions. http://java.sun.com/docs/codeconv/index.html.
• Sun Microsystems, EJB 2 Specifications.
http://java.sun.com/products/ejb/2.0.html
• Sun Microsystems, J2EE 1.4.1. Specifications. http://www.sun.com/j2ee/
• Microsoft Corporation, .NET Platform. www.microsoft.com/net/
• Hibernate Org, Hibernate Information. www.hibernate.org/
• Eclipse Org, Eclipse Information. www.eclipse.org/
• Spring Org, Spring Framework Information. www.springframework.org/
• Sun Microsystems, JDBC architecture. http://java.sun.com/products/jdbc/
• W3 Org, XML Information. www.w3.org/XML/
• Sun Microsystems, Java Servlets.
http://java.sun.com/products/servlet/
• Sun Microsystems, JSF Specification. http://java.sun.com/j2ee/javaserverfaces
• Amazon, Internet Store Structure. http://www.amazon.com
336
7.2 Books References:
• Brett McLaugblin, Java & XML, 2nd edition,
O’Reilly, 2001.
• Deepak Alur, John Crupi, Dan Malks. Core J2EE Patterns, Best Practices and Design Strategies.
• Chuck Cavaness. Programming Jakarta Struts. O’Reilly.
• Ted Husted, Cedric Dumoulin, George Franciscus, David Winterfeldt, Struts in
action, Manning, 2003.
• James Goodwill, Mastering Jakarta Struts. Wiley Publishing Inc, 2002.
• Floyd Marinescu, EJB Design Patterns. John Wiley and Sons, 2002.
• Ed Roman, Scott Ambler, Tyler Jewell, Mastering Enterprise JavaBeans, Second Edition. John Wiley and Sons, 2002.
• Sun Microsystems. JavaServer Pages™ Standard Tag Library. 2002.
![Diploma in Software Engineering [DSE] - KELTRON …keltronrec.com/downloadsyllabus.php?filename=pgdene.pdf · Post Graduate Diploma in Enterprise Network Engineering ... Let's have](https://static.fdocuments.in/doc/165x107/5b87b3c87f8b9a3d028b80cb/diploma-in-software-engineering-dse-keltron-post-graduate-diploma-in-enterprise.jpg)
