The programmer's guide shall explain some of the more fundamental design decisions. We will not attempt to deliver a “blue print” of our design.
We wanted to use Enterprise JavaBeans (EJB), Sun's reference implementation of a J2EE-compliant server implementing it (RI), leave it as it comes out of the box, and use container-managed persistence as this is the single one feature which seemed to be the most over-hyped to us.
Behind this constraint is the decision that we both wanted to release this v1.1 release into the open source domain (RI may be used free of charge for evaluation purposes) and deliver a working example of EJB to the audience of the Net.ObjectDays 2000 conference. This has been done.
A release v2.0 may be based on bean-managed persistence and a different J2EE server. If LivingTalks gets adopted by the Open Source community, this may well be Apache/Tomcat and an OSS-implementation of an EJB-server...
Experiences gathered throughout the development may be found in our presentation slides presented during the Net.ObjectDays 2000 conference.
A class overview is found here in the API docs.
There are 7 fundamental base entities defined:
Author
Talk
Authorship (representing the many-to-many relationship of authors and talks)
Type (category)
Block (container for talks and scheduling unit)
Track
Pitem (program item, the set of them makes up the program)
Each entity is implemented as the following set of objects:
EJB entity bean with container-managed persistence (e.g., Author, AuthorEJB, AuthorHome)
A model class with common base class (AbstractModel) (e.g., AuthorModel)
JSP Java server pages for master view and detail (e.g. authors.jsp and author.jsp)
A JavaBean for manipulation within the JSPs (e.g. AuthorWebImpl)
An XML tag with sub tags (e.g. <author>...</author>)
The entity beans are not accessed directly. There is a stateless session bean (Manage, ManageIF, ManageEJB, ManageHome) acting as a facade to all seven entity beans.
This architecture allows to implement a cache within the Manage bean (EntityHandler, CachingEntityHandler, DataHandler, WriteThroghCache, ...). Without this cache, the performance of the RI (Sun's J2EE server) proved totally unacceptable. However, the cache relies on a static instance variable of the Manage bean. This approach will fail when the server spans multiple VMs.
We do not know a truly correct way to cache entity beans (except in an external server accessed via sockets which again is only legal when using a JDBC connection...). The problem is that several instances of an entity bean may co-exist within a J2EE server representing the same data (sharing the same PrimaryKey), possibly but not necessarily on several VMs. For this reason, the entity bean itself must not be considered to act as a cache of the date it represents; not even dirty-flags and bean-managed persistence help. The only hope with EJB 1.1 is that the database is good enough in doing the caching and not touching any data when not modified. Cloudscape definitely is poor in this. For the time being, we feel that our approach is better at least than the caching in Sun's blue print Pet Store demo...
These functions are accessed using a stateful session bean (Publish, PublishIF, PublishEJB, PublishHome). It uses various helper classes doing all the XML stuff (com.livis.livingtalks.xml.*). The publish bean in turn is a client of the manage bean.
Actual rendering is done using the Xalan XSLT stylesheet processor.
We feel that this pattern is overemphasized. We found that the LivingTalks architecture could be kept much more comprehensible and clear by not making all entities depend on each other via a common controller. Each entity has its own view (its own set of JSPs) which is selected at the moment of request already (by the kind of link clicked). There is no central controller. The JSP acts as view, the WebImpl JavaBean acts as controller, and the entity bean (via the facade bean) acts as model.
The rendering of web pages (within the publish feature) does rely on 3 template mechanisms:
XSLT stylesheet transformation from XML to HTML.
Embedding of output into a Dreamweaver template-compliant JSP file.
Finetuning using a linked CSS style sheet.
All entity beans use container-managed persistence. The persistence fields are inherited from model JavaBeans (bean properties with instance variables made public to convince the deploytool about which fields to consider persistent...).
All entity beans use transaction attributes of Required. This is necessary to make sure data is actually read from and written to the database.
Most methods of the manage bean use the Supports attribute. While not recommended, this is the only way to pass transaction contexts and attributes through the facade.
Most methods of the publish bean use the the NotSupported attribute. One method (“import in one transaction”) uses a transaction attribute of Required.
Importing in one transaction is safe in the respect that importing either entirely succeeds or fails. This is a useful feature to ensure database integrity... It turned out that the price in terms of performance is horrible when every method would run with a transaction attribute of Required. Therefore, we restricted it to a single method accessible by a client. However, we update entity beans together in one transaction if referential integrity is not ensured otherwise.
The web JSP page offering the import feature offers two options: import within a single transaction or allowing errors (which then runs outside a common transaction context). We measure a difference of a factor of hundred in speed and disk space between the two methods, measuring up to 3 hours run-time and 400 MB temporary disk space usage when importing in a single transaction. This is a behavior which we definitely would like to see a clarification from Sun for.
The LivingTalks project is an open project we invite interested parties to contribute or to take over a leading role. Our aim is to provide a conference tool to manage a conference we co-organize. In the next release we will likely need to support the phase of CFP paper submission and reviewing as well.
We see contributing partners from two areas:
Parties adopting the tool to support their conference.
Parties adopting the tool as an Open Source EJB technology project.
Both parties are welcome. As the license states, everything is possible as long as the result stays in the Open Source.
The current source is about 6000 lines of Java in 72 files, about 2700 lines of JSP code, and about 1400 lines of XSLT code, totaling some 10000 lines of code.
The entire project may be found in the /usr/src/livingtalks-v1.1/dev/ directory.
The index to the API docs is found at /usr/src/livingtalks-v1.1/dev/doc/index.html
continue with the development project file
Copyright © 2000 Living Pages Research
GmbH, Munich, Germany www.living-pages.de
See full copyright
notice. (the copyright terms are the same as those of The Apache
Group).