One of our users on the EJB 3.0 forum, Chris Malan, talked a few days ago about an EJB 3.0 application he was about to go into production with in the next few weeks. I asked him if he wanted to write a little bit to describe his application and he graciously accepted. Thanks Chris! If you, dear reader, also have an EJB 3.0 success story please post it on our forums or Contact me directly and I'll see about putting it out on our blog. Also, stay tuned for other EJB 3.0 and JBoss Seam testimonials. We have a few in the pipeline from a few small and large customers that we'll be announcing shortly. Have a look at 24/7 Roadservices Australia It runs on shared hosting at Ala cartejava with JBoss-4.0.3 as the application server. The database is MySQL.
For the next few days (today is the 27th Ocotber, 2005) it will still be in a test phase and everyone can enter dummy transa ctions using imaginary credit card details.
And it is a totally EJB3 application.
The development tools were Eclipse 3.1 with the JBoss 1.5 Milestone 1 IDE. During development it was tested in JBoss-4.0.3R C2 and PostgreSQL.
This application uses of course the POJO data objects new in EJB3. It also uses Session beans, Servlets, a few utility classes like one called UserNamePasswordHandler for logging in and a Filter to control access to "secured" content - the staffpage. The only jsp page is the staffpage. There is also a StaffBean (not a data object) which occupies a place between the staffservlet and the relevant Session Bean. The servlet gets a request, forwards it to the st affbean which forwards it to the Session Bean and gets a response, either as a String or a List of objects. The servlet send s a redirect and the staffpage reads the response to its request from the staffbean. The staffpage is almost pure html. Th ere is of course the obligatory JavaScript form checking.
This application uses the MVC architecture. As far as a framework is concerned, it uses a pure J2EE EJB3 framework as far a s that is possible. No Struts or anything else. Of course, much of the functionality is JBoss specific as the full EJB3 spe cification has not yet been decided upon.
All user response pages (only two) are directly generated by a servlet.
To prevent concurrency problems all database access that will result in database changes requires a transaction. We do not anticipate heavy use at all; if there are 10 users at the same time trying to buy the product the owner will be just too ha ppy. Shared hosting is of course also not the way to go if one anticipates heavy use. Be that as it may, there is a pool o f 20 database connections, more than enough for many times that number of concurrent users.
When it went "on air" I had all the office staff (eight) go on and attempt a transaction without help. There were no proble ms, except for one secretary who could not recognise the end-point of the online credit card transaction. However, my inter est has been aroused. I think I'll get it to run on one machine of the local network, use JMeter from another and send the servlet requests to create contracts and see with how many it can keep up. In the real world I suspect the network (Interne t) will be the bottleneck long before the software falls over.
Problems? A few. At first I could not get the application to create the database tables and keep them when the server shut down. Someone on the EJB3 forum suggested:
<property name="hibernate.hbm2ddl.auto" value="update"/>
It works perfectly for both PostgreSQL and MySQL. Then there were problems with the .par archive andI packaged even the ent
ity classes (POJOs) in the .ejb3. That worked. However,
the final package structure looks like this:
<application>
<display-name>247 Roadservices</display-name>
<description>The 247Roadservices Application</description>
<module>
<ejb>rsa.ejb3</ejb>
</module>
<module>
<ejb>rsa.par</ejb>
</module>
<module>
<web>
<web-uri>rsa.war</web-uri>
<context-root>/</context-root>
</web>
</module>
</application>
This structure worked from the word go when deployed at Alacartejava.
Note that this is really a simple application that doesn't do wonderful things. It takes form input from a user, transfers t he user to a secure payment site, comes back from the payment site when a link is clicked after successful payment and write s everything to the database and gives the user his contract ID no. It gets data from the payment site behind the users bac k as a get request. It verifies that this comes from the payment site's IP address. I know about IP spoofing, but one's car registration no needs to be real for this product to work. Who would commit fraud and supply real contact details?
Did JBoss fall short in any way? Not with this application. I am sure this application did not give JBoss a good work-out. I have a few EJB2.1 applications running at Alacartejava. This one seems faster, especially the form pages which are creat ed by a servlet. Is JBoss-4.0.3 faster than the older versions or is this application on newer hardware? I don't know.
There is of course a log-in page for admin staff without even a link to it. Various things can be done on the admin page. In fact, most of the J2EE functionality is to be found on this page.
Well, that's it folks, A simple J2EE EJB3 application that was created on the cheap and runs for about US$55 quarterly. And everything works.
One caveat; don't install JBoss-4.0.3 and expect to run EJB3 applications in it at Alacartejava. Look one place lower down in the drop-down list and install JBoss-4.0.3EJB3.
What about EJB3? Much, much better than EJB2.1. The ability to extend classes (not used with this application but extensiv ely used with a real estate application I am working on - base class Property, extended classes Residential, Commercial etc) is heaven-sent. I managed something similar with 1:1 tables/classes in EJB2.1, but it was much more work. The thinking par adigm is now almost purely Java (Object Oriented) as opposed to thinking in database terms (tables, columns and rows and rel ationships). I became aware that things are now different to what it was in EJB2.1 while coding. Maybe one can say EJB2.1 was closer to the database and EJB3 is almost pure Java programming.
Chris Malan
