Enterprise Java Beans and BOW objects

This fundamental work :) created as result of study of Enterprise Java Beans technology and based on my previous experience in ODBMS and distributed systems.
I'm very sorry for my terrible language and possible inaccuracies.
All you notices and critics will be appreciated.

  Alexander Zemerov.
  azemerov@yahoo.com

J2EE application, J2EE server, J2EE container, bean - all this terms are related to the Enterprise Java Beans specification. I don't consider particular implementation of the J2EE server. Additional information will be added after additional Sun J2EE specification study and Borland Application Server (and may be WebSphere) explore. I'm not very proficient in the J2EE. So the next text could contain some errors and inaccuracies.
BOW term takes its name from the "Bill Of Work" project executed in American Eagle in 2000-2001. Really BOW project is based on DPOS (Distributed Persistent Object System) engine implements described below functionality. But by historical reasons BOW term is more convenient and all the more DPOS designed specially for BOW project. Another words BOW application based on BOW engine and DPOS was synonym for BOW engine.

1. Structure
   • J2EE application consists of container (EJB server itself) and set of business classes delivered and configured in run-time. Another word, J2EE metadata are dynamic.
   • BOW application is integrated in compile time. BOW metadata are static.
2. Dinamic versus static
   • J2EE is configured dynamically during deployment time.
   • BOW system has possibility to be configured through startup parameters. Generally there are well defined engine related parameters. But business classes could use they own parameters also.
3. Distributed bechaviour
   • J2EE has truly distributed nature. Application can reside on different servers. J2EE mechanism makes this complexity transparent to the client.
   • BOW system has asymmetric distributed nature. Application server has to have only one instance. Many clients are supported. You can have several different servers in your system but they should operate different set of objects. Another words - you can not split your system in run time - system configuration should be determined in design time. It is recommended to split your system by modules with different functionality (security server, business server, mail support server, etc.).
4. Primary keys
   • J2EE allows to define custom Primary Key class for each EJB.
   • BOW is designated to work with simple primary key types (integer, strings).
5. Exceptions
   • J2EE has two categories of exceptions - system (javax.ejb.EJBException, NoSuchEntityException) and application - predefined (CreateException, ObjectNotFound, RemoveException) and customized.
   • BOW supports only one type of exception.
6. Session and entity objects
   • J2EE dedicates separate classes for session instances and entity instances.
   • BOW has "temporary object" entity - exemplar of regular persistent class without behavior of persistency.
7. Interfaces
   • J2EE uses Home interfaces as holder of "class methods" - Create, FindByPrimaryKey, etc. Each bean class has correspondent Home interface. As result container has possibility management bean instances.
   • BOW delegates description and implementation of "class method" handler class to the application developer ("Global" interface). As result it is not possible to automatically locate any persistent object in the system.
8. Implementations
   • J2EE implementation class doesn't implements Remote or Local interfaces. Instead single IDL interface definition J2EE gives you possibility to choose local or remote interface. Declaration and implementation are tied together by bean declaration and methods signatures.
   • Implementation of BOW object is accessible as Delphi class (inside of server) and as IDL reference (inside or outside of server).
9. Compilation and deployment
   • J2EE provides dynamically updateable container. It is not necessary to recompile whole application after change single class. Implementation of bean has to follow some J2EE patterns. Deployment descriptor (XML file) is used by EE container to dynamically compile bean's helper classes. It is possible because of powerful support of metadata in the Java language and Java VM's interpreter nature. Application deployment is very flexible and complicated process.
   • Any change in the BOW business classes requires application compilation and server restart. It improves server performance but we lost in application flexibility.
10. Database connections
    • The J2EE container operates with external database through JDNS. Bean's code doesn't have to know parameters of database connection (even database type). Each database connection is accessible by its name. Connection parameters are described in the deployment descriptor.
    • BOW uses similar mechanism. Server keeps pool of database connections. Object calls database connection by its name. Current implementation is limited by one type of connection, but it is not architect restriction. Connection information comes from application start up parameters.
11. Persistence control
    • The J2EE beans can be container managed or bean managed. It depends on deployment descriptor information. Bean does not have to be inherited from particular class. All persistence mechanism is implemented by the container engine.
    • BOW object has automatically persistence support inherited from the parent TObj class. Mapping between class and database is implementing through RTTI mechanism (published properties are used). Object can override inherited methods to implement its own persistence mechanism.
12. Class ierarchy
    • The J2EE Bean code is compact - it contains only business logic. It is very important because application is deployed as set of many pieces.
    • BOW object code depends on parent classes code. Because BOW system delivered as single, one-time compiled unit the inheritance mechanism doesn't impact application module size restrictions.
13. Object life time
    • The J2EE Bean can be deactivated by container. After reincarnation it could be assigned to the other instance. As result it has to be reloaded.
    • BOW object can not be reassign to the other instance. And more - once incarnated and loaded it still exists in the list of object until system shutdown. The are no internal reason to reload object state from database. As result we have extended system resource requirements (memory) but we have significant performance benefit. It matches to an applications with limited object numbers and extensive operations with wide set of objects.
14. Helper classes
    • The J2EE container support Find... methods in the Home interface which can return set of objects.
    • BOW has special defined TObjCollection class. This core class allows easy support many-to-one and many-to-many relationship. The main benefit of BOW collection is its persistence.
15. More about dynamic and static configuration of data mapping.
    • The J2EE mapping is based on deployment descriptor (XML file). So it could be considered as dynamic. But remember - J2EE server recompiles bean's environment (bean's helper classes) each time you deploy bean.
    • Current implementation of BOW system uses published properties and RTTI mechanism to map database data to the object. So it uses truly compile time mapping. But internally is implemented as dynamic - RTTI information is used to bind the object structure with the database structure. So BOW system can be easily implemented to use external configuration information - from plain text file, ini file, system registry, XML file - it doesn't matter. In such case it will be truly runtime dynamic mapping.
16. Transaction support.
    • J2EE supports transactions. Support mechanism depends on implementation but J2EE provides standard interfaces to control transaction execution.
    • BOW doesn't support transactions. It is very sad fact. BOW provides another technique - object locking. Programmer should place locks on all objects involved in the transaction, execute all operations and finally unlock all locked objects. If some kind of problem takes place - all changes should be rolled back manually. Of course such approach can be considered only as temporary substitution of real transaction support.
17. Object-table mapping
    • J2EE provides dynamic, deployment time object-table mapping (relationship between classes). But in reality, it is not absolutely dynamic mechanism - programmer must execute some preparatiion work while coding time (implements finder methods). The main advantage of J2EE is possibility dynamically change relationship from one class to another.
    • BOW declares static object-table mapping. He codes all necessary code inside getter and setter methods. But again, this is only current BOW implementation restriction. All this methods look very trivial and similar to each other. So all this hardcoded work can be substituted by usage of external configuration information. And more - current implementation uses so named "SQL Manager". The SQL Manager is repository of SQL statements. The repository is filled from configuration file. Additionally SQL Manager has ability automatically generate statements. As result we have static mapping with configuration possibility. BOW definitely doesn't allow you to change types or related classes dynamically.

Borland Application Server

• BAS allows you to map composite attributes (attributes of object type). BAS uses "public beans" - objects like JavaBeans but with public attributes and/or getter and setter methods.