JBoss, Enterprise Java Beans, Webservices and Session Management

This summer term, I chose to work in a group of students to implement a Web 2.0 ‘social’ web filter for children, called “Safer Web”. The basic idea is to let people, especially parents, decide themselves which websites are safe for (their) children, by suggesting and voting for websites in a digg-like process (and tagging, of course! We didn’t forget tagging!). Instead of keeping a blacklist, children are only alllowed to access websites that received enough positive votes. Strangely enough, all current filter I know of use black- and whitelists maintained by some “experts”, instead of a community.
What we decided upon were four basic parts to make this work:
[list=1]
[*]There must be a nifty browser toolbar where people (“parents”) can vote for websites and easily suggest new entries.
[*]A multi-platform filter component (blocker) with regular whitelist updates.
[*]A nice website for children to find websites they’re allowed to visit (and give them school grades), and one for parents to tag, vote and suggest sites.
[*]Server backend logic.
[/list]
While we were working on this, a [url=http://www.fragfinn.de/]similar platform popped up[/url], funded and supported by a large number of companies and the German government (press releases said that Angela Merkel, chancellor of Germany, actually inaugurated the website) – but, good for us, they forgot the social part! Again, experts are working on keeping their whitelist up-to-date.
For some reason, someone suggested to use Enterprise Java Beans for the backend part. None of us has used EJB in a real world project before, but my first experiences were enough to make me feel queasy about it. Unfortunately, the little EJB demo calendar we had to code in Softwaretechnologie II didn’t give me enough reasons against it. It couldn’t be so bad after all, could it? This is what we came up with: The website was to communicate with the backend directly using Enterprise Java Beans, while both filter and toolbar components should use a WebService facade. Nothing special! We thought (and I still think) this is the default setting for Java based web applications with some additional “outside parts”, so we expected to find a lot of material on the web.
Our supervisor suggested to use JBoss as application server. At first glance, it looked good: Documentation (wiki, tutorials, sample code), large community, good website, accompanied by the quote “JBoss Application Server is the #1 most widely used Java application server on the market. “. I have no idea if this decision was a major factor for all the problems we had, or if other application servers suffer from the same flaws.
Within a month of fighting with against JBoss, I’ve learned two important things (in the end, I guess I have to thank JBoss for that):
[list]
[*]I forgot how to code without Internet.
[/list]
Imagine programming without having Internet access – can you still do that? When I started programming in the early nineties on my Commodore 64, I was used to code with, whatever, trial and error, maybe a book or two or some electronical documents (remember [url=http://www.ctyme.com/rbrown.htm]Ralf Brown’s Interrupt List[/url]?). Limited tool support, no googling for problems, no forums, no large base of example code! Today, if I need some advice, or my code throws an exception, I am used to immediately finding a suitable tutorial, or some forum threads where people have already discussed the issue (and someone provided a solution). Why should I actually [i]remember[/i] anything a good IDE or a quick search will find out for me? I guess [url=http://blogoscoped.com/archive/2005-08-24-n14.html]I must be a good programmer[/url].
With JBoss, for the first time, I could not find anything useful for most of the problems I was having. Searches for unexpected exceptions in the log [i](hey, who coined the term “unexpected error”? Microsoft? Can you tell me what kind of errors are not unexpected?)[/i] lead to JBoss source code references where the actual exception was thrown, and to a few abandoned forum posts where people disappeared, leaving their questions unanswered. After a while, I found myself working through the JBoss source code ot find out what was happening…
[list]
[*]Abstraction doesn’t always solve problems, sometimes it generates them.
[/list]
I am among the first to embrace higher abstraction. A good friend of mine went to university to study Computer Science, and when I told him two years later that I’ve decided to follow him on that road, he tried to talk me out of it. He was always impressed how I could just [i]use[/i] things, and never ask [i]why[/i]. At university, he told me, it was important to ask [i]why[/i]. In some respect, I think he was right. I had to learn hard to lose my ignorance towards how things work, and nowadays I even find myself interested in that, but one thing remained: I don’t want to [i]work[/i] low level. Show me a wiring diagram, diodes, capacitors, and I will run away screaming. C programming? Pointers, manual memory management? Please, no! Why should I bother with anything other people have done before, working years and years towards a good solution? Again, I want to believe this only confirms my qualification as a programmer. I am interested in hardware, yes, but after a few years of working in IT support, I just want a working system. I still build my computers, but I slowly find myself interested in buying pre-assembled machines that “just work”.
JBoss impressively showed me the major problem with abstraction: If something goes wrong (and, trust me, it will), you’ll [i]have no idea what[/i]. Working with annotations is great, thank God JBoss generates all XML configuration, WSDL and whatnot for me. But, if an exception forces me to dig through actual JBoss source code to figure out where it was thrown and why, this doesn’t fit my idea of abstraction.
Within a few days we had a collection of forum quotes in our project wiki, directly reflecting our own situation. Excerpt:
[quote]Great news, I’ve finally got this solved, but I do not understand why.
This is not explained anywhere. Did this technique evolve? Did someone randomly hit on this?
(…) I’m sure you’ve loved watching me have a conversation with myself.
I still do not quite understand what is going on but at least it works.
In JBoss 3.2.7, this code logs in the current user so that they can run privileged methods. I can call EntityContext.getCallerPrincipal() and everything works great. In JBoss 4, this code does absolutely nothing! It doesn’t log in the user, it doesn’t throw an exception and it doesn’t provide any indication on why the user isn’t getting logged in. EntityContext.getCallerPrincipal() returns my not-logged-in principal. Horrible!
(…) Is this something new or am I being daft. Please note, I am not a developer, just the unfortunate sole who has to implemtent something that someone developed.[/quote]
What happened to the DRY principle? After digging through some examples, I found out to to properly name my webservice arguments and document operations. I don’t care about technical details, and it’s nice that I can [i]re[/i]name arguments, but I expect from a “mature framework” to use the Java argument names by default, and generate WSDL documentation from JavaDoc comments. With the current JBossWS 2.0.3, I have to manually annotate everything – twice.
Note to self: Avoid JBoss, EJB and JbossWS.
In a small series of articles, I will publish some examples.