Used Technologies

In this chapter we will present the architectural and technical concerns that must be addressed in the project in the best manner. The following are the main areas of concern:

J2EE application structure
Database
Middle-tier
User Interface(s)
Internationalization (i18n)
Coding Conventions

J2EE application structure.
The following diagram coarsely describes the structure of J2EE application, which our project shall follow:


Database.
The RDBMS of choice is MySQL. The choice is obvious at least for the beginning of the project as this RDBMS is quick, reliable and FREE. Later when the amount of users of the system achieves some considerable figures it will be possible to move to ORACLE or another production level RDBMS. So, the DDL/DML scripts used for database installation have to be RDBMS-independent. Other major concerns/ideas here are following:

• Lack of procedural language. Many features of the application will rely on the possibility to execute complex SQL queries and it will be quite difficult to do it without stored functions. For example, the application provides the possibility to share your libraries with other people. So, a stored function that would return TRUE if a user has access to this library, otherwise FALSE, would be very handy. With absense of such capability we will have to make do either with complex SQL joins, or handle it in the middle tier.
• No partitioning option. Expected amount of records in the biggest table should achieve hundreds of thousands. Should we emulate somehow the partitioning option or keep it simple and rely on proper indexing?
• Internationalization. The database should contain words in various natural languages. The current version of MySQL supports working with UTF-8 encoding, although I saw some messages in news groups that such tables are not reliable for searching and sorting.
• Backup and Recovery. What are the mechanisms in MySQL? Is there anything like hot backup in Oracle? Or only nightly backups?
• Remote administration. Most probably in the beginning the application will be hosted on some JSP hosting solution provider's site. Therefore, there should be some ways to administer the database remotely. Are there ways to run scheduled routines such as cleaning old logs?
• ER-diagramming for MySQL. Is there anything decent for free? Well, the ER-diagram should not be huge, I think under 25-30 tables in the beginning.

• Persistence and domain layers. Domain objects will be presented by Plain Ordinary Java Objects (POJOs). Hibernate will be used for persistence of these POJOs in the database. Entity EJBs are not an options - they are too heavy and unwieldy. JDO: there is no decent free implementation. Besides, it seems like JDO is going to be pushed out of the mainstream by EJB3.0 spec. Meanwhile, Hibernate seems to be very popular and widely used.
  A rule for middle-tier developer: Do not access the database directly, only through the domain layer. The only exception is "JDBC for reading" pattern - using java.sql.RowSet for presenting lists in the UI.
• Services layer is where the business logic is presented in compliance with Service-Oriented Architecture (SOA). This layer is going to consist of stateless (i.e. static) business methods, which optionally can be wrapped by Stateless Session EJBs or even by Web-services.
  When needed, the POJOs created in the domain layer will serve as Data Transfer Objects (DTOs) for passing data to services and retrieving data from them.
  Again, if we go for full-fledged J2EE application server we will wrap services with stateless session EJBs.
• Application layer is going to be presented by Action classes of Struts infrastructure. They will call services and serve as a controller in Model-View-Controller architecture.
  No business logic in Action classes! Only UI use-case workflow, validation and calling services!

• In the future Web-services can be used for third-parties for programmatically communicating with the application. Apache Axis is a good choice for it.

• Presentation layer will be done using JSPs (View part of MVC). The model part of MVC is presented by ActionForms of Struts which serve as transport container between Action classes and JSPs.
  Unfortunate enough, the DTO pattern is no longer very useful here because ActionForms are strictly integrated into Struts. So we will have to replicate DTOs to Forms and back. Struts has copy utility in its BeanUtils but it does not work properly with dates. So, this requires more investigation.
  
  Besides, for the presentation layer the following open source libraries are suggested to use: ValueList for presenting lists of objects in directories, Struts Menu - for building menus. Another very useful JavaScript library is overlib.
• JSTL is to be widely used for JSP development.

• In the future mobile devices such as cell phones or PDAs might be used for accessing the application. It is hard to imaging entering new information. Nevertheless, drilling games are good candidates for this module. What do use for it? J2ME?

• The database should store information in UTF-8 encoding so that data in various languages is stored in the same table.
• The UI has to present information in multiple languages. The challenge here is to present not only ASCII to native encoding pairs but native-to-native pairs, e.g. Cyrillic and French or Urdu and Chinese. Seems like this is possible. Many translating sites can show entries in different languages on the same page.
• All static information presented on JSPs must reside in ApplicationResources.properties files in order to be available in various languages.