Index News FAQ TUTORIALS Contact Mailing List Partners DeskTop

Demo dB
Pojo Application Server

 

 

This demonstrates:

• How to create a standalone dB pool for any application.
• How to create a CD Unit to do staged loading of the UI components. 
• How to use a handy Pojo Persistence library that makes this all very easy.
• How to create an embedded dB.
• How to do transactions using FlexiBeans, and using plain old SQL.

We opted for a very simple Visitors Book, people can leave their name and comment on the system. Just enough to demo the technology, and give you a framework for your own powerful biz applications.

To Test the dB Demo
http://localhost:8080/harbor/ships/Harbor_dB_Demo_Ship.jar
and the UI will jump out of your browser
and let you play with the demo.

Design Philosophy:

Its important to understand a little of how we think about this... 

We don't believe in putting beans in front of a dB, and then doing dB design through the beans, via XML.
It may be needed in an IOC container, but the added complexity is unnecessary in Pojo. Anyone that has used well established SQL tools to design a database, will tell you that even at that level getting a dB design perfect is an accomplishment. 
Making sure different tables merge into the correct views, making sure the software cant delete something that breaks the referential integrity, and wanting to do that from behind beans, is madness, and will lead to a weak dB design.
We believe in designing the dB first, not only is it a great systemic view of the whole application, it also gives one something to show the client, to demonstrate before coding, that it generates the right reports, can answer the needed questions, and takes the right input.

So does this mean we don't believe beans can help, no, not at all, it just means we believe in putting beans after the db, in other words, the bean follows the dB.
Introspection and all the elaborate glue flies out the window, and it becomes very simple. We call these beans Flexi-Beans and all they really amount to is a very simple record holder, and all they do is reduce the amount of SQL one has to write. When you look at the code, the simplicity will be apparent.
Then lastly, we don't like getting too far away from the raw power of SQL.
Yes, it is a pain to work with, but its a very powerful core technology, and if Flexi-Beans are not appropriate for something, dropping down to SQL must always be an option.
You will see that SQL is just under the surface of the tools we use.
In the example code we use Flexi-Beans, but there is also an example of where we drop down and do a transaction in plain old SQL.
Its Pojo, so nothing stops one from using any tool they wish to, but with all this freedom, it just seems silly to introduce the glue that holds an IOC container together, into a Pojo container.

PojoPersist Lib

Another thing that one may find a little strange at first is that this utility class and dB Pool is not exposed via JNDI in the container. 
A POJO container as policy does not tie one to the container. The idea is to use this library or the source for this library in your external stand alone project.

One does not need JNDI in this environment, although it is available through the servlet container. For example if you would like to share this library between servlets and the application server, move the library to web-app/lib.

If you would like to share this library across all web applications, move it to common/lib, across a whole machine, move it to the machines class path.

What you will find like with JNDI, is as you move up above the web-app level, so portability starts becoming an issue, i.e. the user has to setup something to make it work. If you stop at web-app/lib level, not only is there no chance of mixing libraries, the user just drops the web-app in and runs.

In this way, one is able to build external to the application server, and swap out this utility lib for any one of your choosing. 
POJO containers never tie you to a tool.