Now that that is done, the next step is to build the processing side of the system.
Since I do most of my work building Java webapps that run on Apache Geronimo...I will lay out how I would build the back end running on Geronimo.
First of all, the information would have to be stored in the database tables. As I said, MySQL is my (current) favorite database so, that is where the data would live. What I have not recently mentioned is that the Java Persistence API (JPA) is Amazing!
Before I discovered JPA, all of the data access I did was done by manually coding the commands in SQL using JDBC to perform the connection to the database. This was slow, error prone, painful to debug problems, and tedious.
Using JPA, all you have to do is to create Java classes that correspond to your database tables, add some fairly straightforward annotations to them, and list them in a configuration file. And voila, reading and writing to/from the database is nearly as effortless as creating POJOs.
Geronimo comes with Apache OpenJPA baked in - so there is nothing extra to do except use it.
Here is a link to the persistence.xml that I made for my litterBox sitting in github:
And, to add to the attractiveness of XML, there is a built in standard to convert Java objects into XML - JAXB (Java Architecture for XML Binding). In the same way that JPA makes it possible to simplify database access using annotations - JAXB makes it possible to marshal Java objects into XML using a essentially a block of boilerplate code (after those same POJO entity classes get a couple of JAXB annotations added).
Here is a link to the first entity class fully annotated (both for JPA and JAXB):
And, that takes care of making Java aware of the data. Now we need to establish the API between the web client and the server. The interface we will be using should support all regular adding and updating functions. Sometimes this is referred to as CRUD (create, read, update, delete) - but I hate actually deleting. So instead, we will just mark things as being deleted with a 'deleted' attribute (so no table change needed). We will also combine the 'create' and 'update' functions be having update automatically do the create if the record is not found. That gets us down to only needing two functions: read and update. We'll add one extra 'selectList' that will send back a simplified list of all of the records.
And our final interface becomes:
- sendXML() - send the full XML of a table row to the client (identified by its ID).
- selectList() - send a simplified XML of each table row as a part of a big list for use in populating drop down boxes.
- update() - update existing table row or create new (and then update)
And a link to the interface for the attribute session bean:
Both the sendXML and selectList methods will return a string of XML data (to be interpreted by the client). The update method will return the ID of the row that was just updated (or created). That way, the program will be able to request the XML data if needed.
The update method is going to use an object that contains XML data parsed and processed from the message sent from the browser client (along with an XPath object for pulling the data out of it). This will move the need for the servlet layer to understand the information that it is handing back and forth all of the way back to the session beans that will actually be doing the work.
So that is the rough (very rough) run down of how processing will be managed.
The github repo will be updated (as I have time) to fill in all of the functionality that is described here. I really do plan on having a complete (if rudimentary) working app when all is said and done.