You are here: Enhydra Application Framework
Move back to: Open Source Technologies
Common:
(c) 2007 Together Teamlösungen
There are lots of standards available out there but some areas in web application development are still in danger of introducing dependencies on vendor specific APIs. Enhydra application framework EAF is a portable set of APIs making development of typical web applications a lot easier but still keeping portability to the application server of your choice by using plug-ins to adopt the EAF API's to the specific environment.
Currently EAF is supported for Tomcat in Enhydra Server, JOnAS with Tomcat or Jetty and JBoss with Tomcat in Enhydra Enterprise. Other Servers packages like Apache Geronimo and add-ons for IBM Websphere, BEA Weblogic, Oracle and Sun J2EE server will follow with upcoming demand.
Standalone usage of EAF is also tested for applications running under native Tomcat and Jetty.
The ObjectWeb GForge project for the Enhydra Application Framework contains all the needed links for mailing lists, News, CVS access and Downloads.
A good analogy is to think of the Enhydra Application Framework as an abstract class in Java. An abstract class specifies a list of methods, defines variables, sets constants, and provides default implementations of some functions. But you cannot instantiate it. In order to use it you must create a new class that extends the abstract class. This class you write has certain responsibilities (the methods you must write). Once your class provides the missing pieces, you have a usable Java class.
The Enhydra Application Framework is like an abstract class in that it does most of the work, and it specifies what pieces you must provide. But rather than being a single class, it is a collection of cooperating classes. Together these classes implement a Servlet which is an almost complete Web application. Similar to how an abstract class can not be instantiated, the Enhydra Application Framework does not implement a complete, usable, application. It has two places where you need to provide Java classes. Your classes fill in the gaps, resulting in a complete application.
You must provide one application object, and a set of presentation objects (one for each URL you want in your application).
You are strongly urged to run the Application Wizard of the Enhydra IDE to create a sample Enhydra application so you can see how applications are laid out. It creates Java code that implements an application object and two presentation objects. Throughout this description examples will refer to the files the wizard creates.
The application object is the central hub of your application. It is responsible for holding all application-wide data needed by the framework. Some examples of this data are the current running status (started/stopped/dead), the config file used to initialize the application, the name of the application, the log channel to use for logging, pointers to parts of the framework (session manager, database manager), and to provide a preprocessor function used on all requests.
Don't worry! Enhydra provides a class, StandardApplication, that does all this work for you, leaving you free to override only the pieces you need for your application. Applications typically do three things to the application object: read settings from the configuration at startup, extend the preprocessor (to check for HTTP basic authorization, for example), and store application-wide data structures. As an example of the latter, suppose your application has a dozen URLs (pages), but they all share a single hashtable or vector of some kind of data. You could make this a field of your application object and all the pages can easily access it. See also business objects, below.
Aside from the preprocessor function, which is optional, application objects do not deal with HTML, handle requests or otherwise talk to the net. This is the job of the presentation objects.
You must provide a presentation object for each URL (page) in your application. The presentation object is given the request in object form and is responsible for servicing the request. It is also given a response object to use to write data in response (very similar to the Servlet API's service() method). Almost all presentation objects handle GET requests and respond by writing HTML to the Net, but they may also, for example, read in files sent by a POST request, or send Java serialized objects to an Applet.
Presentation objects were given that name because they are in charge of how your application's data and results are presented to the client (the Web browser).
When a request is sent to your application, the framework receives it (through the Servlet interface), and determines which presentation object to pass the request on to. The presentation object is then located (via the class loader), instantiated and called. All this happens automatically. Presentation objects do not need to notify the framework that they exist. The framework, driven by the URLs it is asked for, will attempt to locate the corresponding Java classes.
Only requests for URLs that end in ".po" (presentation object) will result in calling a presentation object. All other types of requests are handled by serving a static file, just like a normal Web server. This lets you mix dynamic content pages (.po) in with normal html files (.html) and images (.gif, .jpeg). Rather than being files on a disk, these are typically archived into the application's jar file. The class loader is used to read the files (getResourceAsStream()). This lets you archive your entire application, pictures and all, into a single jar file.
Because most presentation objects emit dynamic HTML, they can be written using Document Object Model (DOM) access to the HTML (see Writing Presentation Objects with XMLC below). They can also be written by hand, by simply writing a Java class that implements HttpPresentation.
The XML Compiler (XMLC) reads normal HTML files and creates Java classes that contain and represent the exact same HTML content. The Document Object Model (DOM) is used to provide access methods to read and modify the content. You would then write a "by hand" presentation object which uses the XMLC generated classes as a library.
In the HTML, you add "ID=Name" to whatever tag you want access to. For example:
<B ID=FirstName>John</B> <I ID=LastName>Doe</I>
The resulting class will have getFirstName(), setFirstName(), getLastName() and setLastName() classes. You simply call the set method, then call the class's toHtml() method to get the HTML for the entire page (which you would then write out to the Net). If you want DOM access to the whole page, simply add an ID field to the <BODY> tag.
We have found that for large projects is it very important to minimize the interference between the software engineers and the graphic designers, who use use HTML tools that have a tendency to reformat entire files. The small amount of extra work to coordinate with designers in the beginning of the project will be paid back many times over at the end of the project when the engineers can fix bugs while the graphic artists redo the entire style of the site, and the two changes will not interfere with each other.
DOM allows access to XML files. So the XML Compiler will also allow for presentation objects to serve dynamic content XML.
At times you will have a presentation object that does not emit HTML, or needs to do a lot of computation in Java. An example of this is if you have a login screen (with an HTML form) that sends the results to a presentation object LoginProcessor.po. This presentation object examines the username and password and decides if the user is allowed to log in. If they are, the user's session object is marked as logged in, and an HTTP redirect to Main.po is returned. If they aren't, an HTTP redirect back to Login.po is returned. So either way the presentation object does not need to handle any HTML. In this case you would simply write a Java class to do the work. By providing a run() method, it meets the requirements to implement HttpPresentation.
A good rule of thumb is: if you have a lot more code than content, you may want to simply write the class yourself. The framework does not differentiate between presentation objects.
Through years of experience, Enhydra strongly recommends that you break your application up into three categories of objects: presentation objects, business objects, and data objects. Presentation objects handle how the application data is presented to the clients (Web browsers). Any and all HTML is kept in the presentation objects. Data objects get and set the data your application manipulates, from a file, a database or even a hard-coded list. All database code, or file reading code, is kept in the data objects. Business objects handle all the "business logic". All the policy decisions, algorithms and data manipulation. Essentially everything left over after you quarantine all the HTML (and HTTP) to the presentation objects, and quarantine all the database/file access code to the data objects.
Designing your application this way minimizes the impact on your application when you switch databases, file formats or URL layouts. The Enhydra Application Framework only requires that you use presentation objects. The business and data classes you create are up to you.
An additional benefit of designing your application this way is that you will be able to use the Data Object Design Studio (Enhydra DODS) to create your data objects for you.
The SessionManager is one part of the Enhydra Application Framework. The framework automatically issues users a cookie and creates a Session object. The cookie is a secure, opaque identifier. All the application data is kept safely inside the application. Every request the user makes, when it is given to the presentation objects, contains the user's session object. Inside the session object is a SessionData object. This is a totally flexible container for whatever the application wants to store. In the DemoCart Online Golf store demo, for example, the user's shopping cart is a Java object. It is simply stored in the SessionData object, so the various presentation objects can easily access it.
Any data that is application-wide (shared across all pages and all users) should be kept in the application object. Any data that is user-wide (needed across all URLs a user goes to, but one copy per user) should be kept in SessionData. Any data that is page-specific (only needed by one page, but shared across all accesses to the page) should be stored as static fields of the presentation object.
The Database Manager is another (optional) part of the Enhydra Application Framework. An application may create an instance of the StandardDatabaseManager class by specifying keys in the application config file.
The database manager maintains an optional pool of JDBC connections to a database or passes connection requests to a JNDI datasource connection pool, allowing for much faster database access. SQL queries are also cached, again allowing for faster database access.