Print Article: Delving into EJOSA

The previous instalment looked at what makes the development of J2EE applications so complicated and inconvenient. The article took a detailed look at the directory structure of the EJOSA Template and developed a simple "PiggyBank" example to go through the directories. In this article, the author will step you through the specification directory, which is the most important part of EJOSA Template; the business layer, where you implement the specification with available Java technologies; the presentation layer that represents the view of the business logics; and the roadmap for the EJOSA Template.

The EJOSA template consists of Enhydra (Web container), JOnAS (EJB container) and HypersonicSQL (data container for development) or Firebird DBMS (data container for production).

The Specification
The specification directory is the most important part of the EJOSA Template. In this directory, developers only produce the specification of the component and make no implementation. This directory contains mostly Java interfaces and Java utility classes. The component specification is the result of the design phase of component-based software engineering [2] [3]. You can easily use interfaces and build the whole specification totally independent from the implementation part. The result of the specification is often called the Application Programming Interface (API).

So how do you build the specification? We can start with analysing the domain and designing the application with UML as explained in the Model section. The UML models, are built using the PoseidonUML Community Edition, which is free (it has its origins in the ArgoUML Java-based Open Source tool). At the end of this activity we will find two types of interfaces (see Figure 1):

The system interfaces. Mostly we get the system interfaces by modelling the domain with use case diagrams (Use Case Model). The entire use cases will become the system interfaces. The client applications (the presentation layer) should only access the system interfaces. System interfaces can also be referred to as sessions or workflow objects.
The business interfaces. The business interfaces are modelled using class diagrams (Business Concept Model). The entire class diagrams will become the business interfaces, which are also known as entities or business objects.

Fig. 1: Building the Specification

After finding the system and business interfaces, it needs to be deployed in the Java interface. There are three ways to do this:

Dependent interfaces: the simplest option is to use EJB dependent interfaces (EJBHome, EJBObject, EJBLocalHome, EJBLocalObject). However, this solution is surely against the idea of different implementations for a single specification, because as soon as you define those EJB interfaces, you are pushed to implement them in EJB technology.
Physically separated interfaces: if you use pure Java interfaces and throw RemoteException in each of their methods, you are not depending on EJB; you implicitly declare that those interfaces should run on separate JVM. In this case, you can later implement the interfaces with just pure RMI objects or even use EJB technology.
Totally independent, pure Java interfaces with factory classes: if you use pure Java interfaces and only throw application exceptions, your interfaces will be independent of all technologies available in Java. For this purpose you need a factory class, which creates the implementation object to the interface during the runtime. The factory class can take a full-qualified name of the implementation class as a parameter to make the implementation exchangeable.

The EJOSA Template offers a structured directory and some reusable Ant scripts for the component specification. In the build directory you will find the following build files:

build-formatcode.xml uses the Jalopy library to format the source code after Sun's Java code convention. It is important to use code conventions to increase the readability of the code, especially in big projects.
build-javadoc.xml can be used to create the Javadoc of the specification.
build-jdepend.xml gives you a summary of the dependencies between this specification and other component specifications.
build.xml can be used to compile the whole specification in the src directory.
build-deploy.xml can be used to package the whole class files into one jar file, so you can easily publish the specification interfaces for those who may want to implement this specification.
apply-all-build.xml offers you a short cut from having to execute each build file one by one; it automates the activity by calling the build-files one after the other.

Example:
In the example we have defined UserActivity as a System Interface and Coin as a Business Interface. All the specification files can be generated from the model (although it is not a must). We also choose to use the totally independent interfaces (please refer to the specification/src-generated directory for more detail). So the next step is to compile and build the whole specification by running specification/build/apply-all-build.xml. Once this is done, a component implementor can implement the specification JAR file, which consists of Java interfaces, with a chosen business implementation technology.

The Business Layer
The business layer is the implementation of the specification with available Java technologies. After building the system and business interfaces, they have to be implemented with chosen Java technologies. The session objects implement the system interfaces and entity objects implement the business interfaces. There are many options for implementing both interfaces, so we may define many-to-many relationships between session and entity implementation types (see Figure 3). In EJB technology, we can employ Session Beans (SB) and Message Driven Beans (MDB) for system interfaces and Entity Beans (EB) for business interfaces.

EJOSA Template recommends J2EE beginners to use the following options, since the result is used in a production environment:

Stateless SB for implementing synchronous system interface
MDB for implementing asynchronous system interface
Container Managed Persistence EB for implementing coarse grained business interface
Hibernate (OR mapper) for implementing fine-grained business interface

I chose the JOnAS EJB container for EJOSA Template because of the following advantages:

JOnAS does not require packaging the EJB for deployment and not even force the standard EJB directory structure defined by the EJB specification. This means the process of debugging and testing can be done faster. Moreover, the packaging topic in J2EE is not trivial. So beginners will find it easier to know a bit about EJB, before learning how to package it to make them fulfil the standard J2EE deployment.
JOnAS needs a compilation of stubs and skeletons for each EJB (GenIC compiler). This helps beginners to understand more about the idea of Remote Procedure Call (RPC) as the foundation of distributed systems. Additionally, the static link of stubs achieves better performance in a production environment.
JOnAS has comprehensive documentation, so it is easy to use for novices.

The business directory structure in EJOSA Template looks very similar to the specification directory (see Figure 2). Since it is possible to execute the business layer (in case of EJB container) as a stand-alone process, EJOSA Template adds a binary executable directory. This directory includes an Ant script that can be used to start JOnAS in debug mode. We use several configuration files inside the conf directory to configure JOnAS. EJOSA Template offers a build-jonas.xml build file, inside the build directory, to start the creation of the stubs and skeletons by using the GenIC compiler.

Fig. 2: Business Directory Structure

Example:
In our example we need to implement the specification with stateless SessionBean for the System Interface and Hibernate POJO for the Business Interface. Some steps to follow:

To implement the business interface, almost all business objects can be generated automatically (from the src-generated). We only need to extend the generated files to have real implementation files.
For the system interface, only the empty methods need be implemented. The generated code delegates the implementation methods into handleXXX methods. This is a good method since it allows for adding and generating repeated codes within the implementation methods, like try and catch/finally, or security check the implementation without intricating the handleXXX methods.
Files like DataTransferObject (DTO), DTOFactory, and BusinessDelegate are generated automatically from the model.
AndroMDA uses XDoclet to generate necessary EJB files, like Home and Object. Although it is possible to generate everything with AndroMDA, it reuses the concept of XDoclet, so the creation of AndroMDA cartridge won't be too time consuming. All XDoclet generated files will be put into the src-generated directory.
Compile and build the whole business by running business/build/apply-all-build.xml.
Run the business layer by executing business/bin/jonas/jonas-bin.xml.
The data layer will not be shown explicitly in this article. It is important to create the database tables for this component. See the directory data for more details.

Extension with inheritance is one of the key methods to extend the generated files to fulfil your needs. Using an IDE with good code analyzing support, like Eclipse, will help you to create missing methods or rename changed methods. Thanks to Ant for build and execution management, we can use our favourite IDE or a pure Linux shell to do those tasks. In MDA, it is important to understand what source codes have been created in src-generated and how you will use those created codes to fulfil your task.

The Presentation Layer
The presentation layer represents the view of the business logic. EJOSA Template urges the presentation layer to use only the specification directory and does not link directly to the business implementation directory, so it's possible to change the implementation of the business layer without changing the presentation code.

Just like the business layer implementation, there are many options to implement the presentation layer, especially for the server side presentation layer that runs within a Web container. To build the presentation layer we need the following:

View techniques represent the view of the presentation layer such as HTML or WML. For instance, XML Compiler (XMLC) can be seen as the view technology comparable with Java Server Page (JSP) [8].
Framework techniques help developers handle the controller part of the presentation layer: session handling, event handling, multi-language, and workflow. We can define two types of framework: action and event-oriented framework. Action oriented frameworks are based on the request and response model; each request will be executed as an action. Event oriented frameworks work similar with Swing. Each Graphical User Interface (GUI) widget has its own state and behaviour. Figure 3 marks each framework with AO for action oriented and EO for event oriented.

Frameworks and views have a many-to-many relationship (see Figure 3), so it's possible - with a little effort - to combine different views with different frameworks.

Note: SourceForge's Wafer http://sourceforge.net/projects/wafer/ project sums up the view and framework techniques.

Fig. 3: Relationships in Business and Presentation Techniques

EJOSA Template uses two main techniques from Enhydra for the presentation layer: XMLC for the view and Enhydra Application Framework (EAF) for the framework. I chose Enhydra because of following advantages:

A good motivation to use XMLC is that J2EE beginners can learn standard XML at the same time they use XMLC, which is relevant nowadays. If you understand how XML with Document Object Model (DOM) works, you will also understand XMLC easily, and vice versa. The first step in using XMLC is to write the HTML or any other XML files in normal way. Insert "id" within the tags, where you want to change the content during the runtime. The second step is to compile those files. The compilation step translates targeted markup pages of HTML or any XML into W3C DOM templates, represented by Java classes. To use those DOM classes you just need to instantiate them in your servlet [8].
Because you use only Java classes in your servlet, you can easily debug those pure Java classes. You never need to debug JSP.
EAF is just based on standard servlet. The nice thing about EAF is that it's already integrated within Enhydra, and thus easy to use.
Since most J2EE applications use JSP nowadays, it is important to learn other available techniques.

The presentation directory structure of EJOSA Template looks similar to the directory of the business implementation layer. EJOSA Template uses the resource directory to manage resources like HTML files, graphics, and text for multi-language support. The presentation layer supports Swing applications too. The build directory holds two directories - enhydra and common. Within the enhydra directory you can use the build-enhydra.xml Ant file to compile HTML and other XML derivatives into Java DOM files by using XMLC. The common directory also holds a build-jdepend.xml Ant file that can be used to show the dependencies of the presentation layer; you can verify whether the presentation layer only depends on the specification and not directly on any business layer implementation.

Example:
The PiggyBank example can be used to generate Enhydra Framework codes (in src-generated) from the modem, which can be used (by inheritance) just like the business layer implementation:

The Swing implementation is straightforward, since we don't use a framework for building this presentation layer type. For the Enhydra implementation (Web-based), we need a framework for building the presentation layer type.
Compile and build the whole presentation by running presentation/build/apply-all-build.xml.
Run the presentation layer by executing presentation/bin/jonas-tomcat/jonas-bin.xml for Enhydra and presentation/bin/jonas-swing/jclient-bin.xml for Swing.

The presentation implementation layer has the same rules as the business implementation layer: inheritance, separation of src-generated files, and understanding what has been generated and what should be implemented.

To see and test the PiggyBank Web application, point to http://localhost:9000/servlet in your Web browser. You can also build and deploy the specification, business and presentation as an application (one ear file) by executing the build file application/build/apply-all-build.xml. To run the Web application, execute application/bin/jonas/jonas-bin.xml and point your browser to the application context: http://localhost:9000/application. Figure 4 shows the PiggyBank application in action.

Fig. 4: PiggyBank (in Linux and Eclipse) in Action

Conclusion and Future Direction
One aspect that hasn't been explained in detail is that EJOSA Template also supports J2EE beginners with unit tests, which are integrated with JUnit and JUnitDoclet. First, JUnitDoclet generates the skeletons of all unit tests for the business layer implementation. Then developers have to write the unit test code, which can be executed directly within JUnit. After finishing the component we have to load test to see whether the component will work in a production environment under high load. Figure 5 depicts the general process of building J2EE applications using the EJOSA Template.

Fig. 5: Process Matrix Using EJOSA Template

As a beginner in J2EE development you don't need to understand all the processes mentioned in Figure 5, in one go. You can put a beginner's perspective on the top of the EJOSA process and pick the important parts first. An example of a beginner's perspective would be Figure 6. In this perspective, you can directly implement the specification part by using the simplest possibility that consists of the EJB-dependent interfaces: EJBHome, EJBLocalHome, EJBObject, and EJBLocalObject. Later, you can implement the presentation, business and data layer consecutively. You can ignore all the other steps, to begin with. You can open new steps and parts as you wish to create new perspectives. This concept of having your own perspectives is actually what makes Eclipse very powerful. Adding an Eclipse plug-in which supports this multi-perspectivity concept within EJOSA Template would be very interesting, although not a must, since the most important thing is to understand the underlying concept.

Fig. 6: Beginner's Perspective: Process Matrix Using EJOSA Template for Beginners

The EJOSA Template can be of great use to J2EE beginners. A set of reusable build and execution Ant scripts, pre-configured Open Source external libraries, and standardization of the component directory structure and package naming structure (based on multi-tier architecture) simplify the development process. Using Ant for execution and build management allows us not only to be independent of the IDE (NetBeans, Eclipse, Linux shell and DOS prompt), but also allows us the possibility to execute everything automatically (automatic compile, build, run, test and deploy). Adding Open Source MDA on top of development slims the coding activity and makes the development process life cycle with J2EE more agile.

The standardization of UML and J2EE is an advantage for OSS engineering. UML and J2EE application developers can leverage OSS without adding dependency to the product itself. As the model (XMI), Web container (presentation), EJB container (business) and database (data) container are standardized; they can be exchanged without us having to rewrite the whole application. This surely increases the acceptance of OSS. In addition, the Open Source products, which EJOSA Template uses, are suitable for production environments. For instance, the Learning Management System OpenUSS is an application implemented using EJOSA Template and presently it provides eLearning services for more than 17,000 users.

Future plans include extending the EJOSA Template with some new programming techniques, like using AspectJ language in J2EE application development. Also, the existence of an Open Source MDA tool like MTL, which enables us to transform one source model to another target model (Model-to-Model transformation), will help in processing available, well-established reference models to serve our domain model needs. The next part in this JAX Magazine series will show precisely how to use the combination of Model to Model and Model to Code Transformation for building a simple J2EE application - using the familiar PiggyBank example - with the use of MTL and AndroMDA.

Blasius Lofi Dewanto is a Professor Assistant at the Institute for Business Informatics and Controlling, at the University of Münster, Germany. Reach him via e-mail.

References

[1] G. T. Heineman and W. T. Council, Component-Based Software Engineering - Putting the Pieces Together, Addison-Wesley, 2001.
[2] J. Cheesman, and J. Daniels, UML Components: A Simple Process for Specifying Component-Based Software, Addison-Wesley, 2001.
[3] P. Allen, Realizing e-Business with Components, Addison-Wesley, 2001.
[4] R. Sharp, Component Oriented Software: Java Perspectives.
[5] F. Marinescu, EJB Design Patterns, Advance Patterns, Processes and Idioms, John Wiley & Sons Inc., 2002.
[6] The Middleware Company, J2EE Best Practices.
[7] E. Cecchet, J. Marguerite and W. Zwaenepoel, Performance and Scalability of EJB Applications
[8] D. H. Young, XMLC vs. JSP.
[9] Kleppe, A., Warmer, J., Bast, W., MDA Explained, Addison-Wesley, 2003.
[10] Frankel, D. S., Model Driven Architecture, Wiley, 2003

EJOSA Template Links

Project site
Download Revolutions 2.2
Documentation PDF Revolutions 2.2
HOW-TO Installation and Release Document Revolutions 2.2

Open Source Products Links

1. Development

2. Development and Runtime

Free, yet not Open Source, Products mentioned in this Article

PoseidonUML Community Edition