OpenSubsystems

Business Components for Java Applications

Open Core

Tutorial

Documentation
Last modified

$Author: bastafidli $
$Date: 2007/03/11 06:30:45 $
$Revision: 1.11 $
$RCSfile: tutorial_summary.html,v $

Summary

We have finished development of OpenChronicle after seven easy-to-follow steps. Lets summarize how Open Core helped us develop our application faster and easier.

Architecture

Open Core comes not only with set of Java libraries and full source code to make the coding easier. It is also accompanied by a simple, flexible, clearly documented and fully supported architecture. We didn't have to start completely from scratch and invent our own approach or follow some best practices and then try to support them by integrating various third party libraries from separate sources. The architecture guided us throughout the entire process and the classes and interfaces provided by Open Core complemented it in every step and sped up our coding effort. The best of all, it doesn't just focus on one or two aspects of application development. Instead, the architecture and Open Core addresses all areas (process, build, development, testing) and all tiers (data, persistence, business logic, user interface) to make the process coherent and smooth.

Structure

Every application starts with establishing a structure of the project that will represent the skeleton, which will be filled with files containing source code, resources, documentation, etc. It takes experience, practice, luck or just simple try-and-fix cycle to get it right. We didn't have to go through the cycle wasting iteration of trying and fixing our structure. Open Core provided us with project structure, which was easy-to-understand and worked for every step we took during development.

Build process

All projects beyond the simplest utilities require more than just a simple compilation of source code to get correctly constructed and packaged application. Common steps often include generations of auxiliary classes, precompilation of interpreted files, source code analysis for correctness and compliance with standards, packaging to deployable assemblies, construction of various standard distribution packages (sources and binaries), etc. It takes a lot of effort that is not directly visible by the user to get all these steps right. With Open Core we didn't have to spend any time on this task and we still got all of the above and even more. By simply reusing the template build file shipped with Open Core we have immediately got a working Ant-based build process integrated with XDoclet for EJB support, Checkstyle for coding style compliance checks, JSP precompilation, JAR, WAR and EAR generation as well as creation of multiple distribution packages.

Data model

It takes more than a thorough understanding of a problem domain to design and implement efficient, flexible, maintainable and most of all easy-to-implement data model. The designer and developer has to think how will be the data objects persisted and used and often include attributes that are not related to the business logic of the application. Open Core provided us with set of interfaces and classes, which we have used to implement our data model quickly. The attributes and characteristics we have gained with these classes took care of easy identification of data objects in the persistence store, gave us an option to partition the data set into multiple domains and provided us with ability to perform optimistic locking to prevent user's from overwriting each other's data.

Persistence

Persistence is often considered the most tedious coding tasks and developers often attempt to use various shortcuts to make their life easier. Variety of available object-relational mappers and code generators can speed up certain steps in the development but almost always come with steep learning curve, problems with maintainability of the code and various files they require, and loss of flexibility in either supporting the proprietary features of various databases or easily supporting multiple databases at the same time. Open Core provided us with easy-to-follow model of factories and schemas that allowed us to quickly code our persistence logic. We have used simple JDBC and had control over the persistence of our data object in every step of the process. Even though we have coded every operation manually, it often didn't take more than two commands to create, read, modify or delete one or multiple data objects from the database and we didn't have to worry about resource (connections, statements, results sets) allocation and deallocation and therefore avoid hard-to-find resource leaks. We were able to easily support 9 different database systems with minimal effort on our side. If a problem would have occurred we would be able to use special tricks provided by each supported DBMS to resolve it. And as a bonus, our application is able to automatically initialize and create all necessary objects for each of the supported databases upon its installation. The best of all is that even if we had decided to use one of the mentioned object-relational mappers by simply providing different implementation of our factories, Open Core would still support us and integrate our implementation with the rest of the code.

Business logic

One of the challenges developers face is to clearly separate the business logic from the application user interface and the persistence layer. Failing to do so makes the application difficult to enhance and maintain. Open Core provided us with concept of controllers and a way in which to easily access them that clearly separated the OpenChronicle business logic from our servlet tier. The controllers used the already implemented data factories to retrieve or manipulate data objects without any knowledge what persistence mechanism is our application using. Open Core also allowed us to effortlessly deploy the same business logic we have developed as a simple java objects for better performance and smaller footprint or as EJBs for compliance with enterprise architecture and to allow remote access.

User interface

User interface is often the single most important element that the application is judged by. Users may not care how is the business logic constructed or how flexible is our persistence layer but they do care if the application is easy to use, consistent and fast. User interface also changes often to adapt to new needs or features and therefore it has to be easy to enhance and maintain. Open Core provided us with a way to easily create web user interface for OpenChronicle without too much knowledge of HTML by reusing the supplied layout templates. It also allowed us to quickly map all actions that user can take to our business logic by implementing simple servlet tier consisting of two servlets. It simplified our error handling and provided us a way to make our interface easily configurable. Even though we have implemented OpenChronicle as a web application, Open Core also provides many features that make implementation of desktop application as easy.

Security

Security if one of the most critical requirements when developing web applications. Open Core provided us with a simple way how to integrate the login and logout process we have designed and implemented with the rest of the application. It allowed us to easily identify currently active user anywhere in our code and also ensure that only the authorized users can access our entire application if we wish so.

Configuration and deployment

Even though OpenChronicle is a simple tutorial application, it includes lots of functionality, such as support for 9 databases, powerful persistence layer with connection pooling and JTS/JTA compatible transaction management, business logic that can run as a simple java objects or as EJBs, skinable user interface, etc. It takes an effort to get all these pieces working together and Open Core simplified our configuration and packaging. It provided us with place to put our configuration files so that they are automatically used by our application during test or during real operation. It allowed us to configure logging and special features provided by various servlet containers and J2EE application servers. At last, Open Core ensured that our configuration files are correctly packed at the required locations in JAR, WAR and EAR deployment packages.

Conclusion

Following the entire process of design and development of OpenChronicle makes easy to see how Open Core and the rest of OpenSubsystems project make the development of Java applications easier and faster. The main gains in efficiency come from our unique approach that goes beyond the code and provides the process and framework allowing to avoid confusion and dead ends during the design, testing and distribution phase as well as the reusable code making the implementation faster, simpler and easier to maintain and enhance.

OpenChronicle source code

Following list includes all the files we have developed and discussed in this tutorial:

Previous: Configuration, packaging and deployment