Recently I’ve been evaluating the landscape of J2EE-based portals that are available. As usual, there are the 2 main camps – commercial and open-source. With the exception of offerings like Epicentric (very expensive), most commercial portals seem tied to the application server of the vendor (Sun, BEA, etc), and as such, aren't options at the moment – portability is a requirement. On the open source front, I've narrowed the field to what seem to be the “Big 3” options – Liferay, Jetspeed, and Exo, but whether any of them are production-ready is another question.

Jetspeed is the Jakarta option, but won't be JSR-168 compliant until Jetspeed2. Since we're looking at an initial deployment before the end of the year, this is a showstopper. Other than that, their DB2 scripts were completely screwed up (they’d declare a column to ALWAYS be generated by an identity (serial field), and then try and specify a value for it in their insert scripts). Other than that, Apache Jakarta seems to have a servicable portal here. One key shortcoming is the lack of bundled portlets. When executives think that they want a portal, it's more than a framework and a load of built-in functionality (news aggregators, e-mail, etc). Jetspeed doesn’t have much of this functionality out of the box.

I've played around with the Exo Platform for a little bit, and didn’t have much of a problem getting it running. Both their blessing and their curse is their dependency on JBoss. On the one hand, it's ingenious – they've achieved the portal-nirvana of being able to hot-deploy your portlets in a .war separate from the portal itself. This does come at a cost, however. It appears they've integrated heavily with JMX and some JBoss-specific details to achieve this goal, and so I honestly have no idea how I would even begin to deploy it on an existing JBoss installation – the bundled download seems to be the only sane option. Also, after playing around with it for a bit, I found the documentation rather lacking in many respects, such as LDAP integration. In one sense, it's easy – simply changed the auth realm to work with LDAP. On the other hand, there’s no indication of what roles need to be assigned to your LDAP users to permit them to access portal resources. Both admin and use of this portal could be best summarized as confusing.

Lastly, Liferay. I looked at Liferay first, and have come back to it again after looking at everything else. It is by far the most complete portal when it comes to pre-built portlets, including e-mail, RSS, wiki, news, weather, etc. I'm still dealing with some DB2 issues, and it seems that portlet deployment on Liferay is no picnic, but LDAP authentication is now working (although not trivial to accomplish – you have to write your own LDAP authentication), and the problems I'm having are problems that I didn't even get far enough along with the other portals to experience. They also seem to have portlet hot-deployment high on their list. The SourceForge forums are worthless, but the mailing list is decently responsive, and while there may be some shortfalls in documentation, the documentation that does exist is very thorough, particularly the meticulous instructions on deploying Liferay from scratch on almost every major J2EE app server.

At this point, no J2EE portal seems to be the full solution. If you're already tied to a vendor, you might be best off considering their offering, since you've already sunk partly into their proprietary land. If you're looking for an open-source alternative, I think Liferay is the closest. Its ease-of-use clearly outshines the other 2 platforms, and its development team seems to be the most active. Regardless, my battles with the portals are far from over, and I'll try to give continued coverage as things unfold.

So as I indicated yesterday, last night was James Gosling’s visit to the Atlanta Java Users Group. Standing room only, as expected.

The evening started off with a Sun representative giving the pitch about how Sun is reinventing itself. I'll save my rant about their hardware business, the Java Desktop System, and the Java Enterprise System for another day.

Probably the weak point of the evening was the structure of the session. We had the creator of Java available to us, and all we had was a question and answer session which, by its nature, was all over the map – put a bunch of techies in a room with an expert, and each techie is likely to ask veiled questions to address immediate problems of agendas of theirs.

James has recently moved into the job of CTO of Sun's tools group, which he said is responsible for NetBeans, SunOne Studio, and Project Rave. He says the technology preview for Rave should be out any day now. He expressed some regret that so much of his job is PR (such as this session) and meetings rather than dedicated development and research.

He mentioned that Java is now being used even in 3D gaming, such as The Sims Online and Harry Potter. It's not Doom III, but it's respectable. Other recent interests of his include the work that's being done with Java on the Mars landers. Apparently this generation of landers is remotely controlled, and the code hasn’t even been installed yet (they'll beam it to the landers when it's done). The next generation will be largely self guiding.

He doesn't seem worried about the “weight” of Java/J2EE becoming too cumbersome, nor about the ability of Microsoft to dictate the .NET agenda outpacing the slower JCP in innovation. Both answers were framed as a comparison of advantages and disadvantages. The expansion of Java has been to meet the needs of developers, and you can ignore what you don't need. The JCP meets the needs of the community better when the solution does arrive compared to .NET.

The evening was definitely worthwhile, but I would have wanted to hear him give even a 10-minute blurb on what has been interesting to him lately. The closest we got to that was an animated blurb on how much he enjoys developing on his PowerMac – this seems to be a trend amongst the tech elite.

Perhaps the most amusing part of the evening was Marc Fleury's question – he asked an extension of someone else's question while subtly riffing on several of the features in JBoss 4 (with actual mention of JBoss) such as AOP, JMX, etc.

For anyone remotely near Atlanta, Java creator James Gosling will be speaking at the Atlanta Java Users Group. It’s being billed as a technical chat and Q&A session. I’ll certainly post details of it tomorrow. Check the AJUG Web Site for meeting details and directions.

It’s tough to avoid someone or another touting the joys of MDA (Model Driven Architecture). Another session I attended at the AJSS was “Agile MDA”. While I certainly was apprehensive that it was going to be a load of fluff, I felt the need to attend anyhow primarily because my gracious employer has been entertaining sales calls from IBM/Rational and CompuWare. IBM is telling them they need an MDA tool, so they believe it. Rather than stand idly by and watch, I felt the need to have a clue about MDA, so I went.

First things first, if you are thinking about attending this session at one of these conferences, and you aren’t in a similar predicament (i.e. – you actually hope to learn something), don’t bother. It’s little more than a thinly veiled marketing presentation. No product is directly sold, but it is more propaganda than proof.

The session abstract claimed, “Model-Driven Developers Do It Faster”, and that they would “get into the details of model-driven, pattern-based development”. The claim is that you draw some pretty UML-style pictures using a tool, hit the big green button, and it generates 65% of the code for your application. From there, you edit “free blocks” of code where you fill in the blanks of the business logic, and voila, you have your application. Funny thing is, anything you change outside of these free blocks can't be round-tripped back into the model.

Their primary “evidence” for the benefits of MDA was TheServerSide's Productivity Study which happened to be sponsored by them, a vendor of MDA tools. The more the attendees delved into the inner workings of their product, the more suspect it sounded. All of the data access, including the SQL generation, is generated directly from the model. If the model changes, you get to generate the code over again. Now recall that they don’t support any round-tripping of code. I understand this, because honestly, it seems as though full round-tripping is an exceedingly tough nut to crack. Too bad they didn’t frame it that way – they said that they didn’t support it because “it's a bad idea”, since “round-tripping can allow bad code to be propagated up into the model”. Well then don’t write bad code, or at least admit that it’s a tough problem instead of trying to justify the design decision by promoting the alternative as a bad idea.

The end result is, of course, that supposedly the MDA group accomplished the same task (functionally) as the “traditional” group, and with slightly fewer defects. The magic is that the MDA tool generates all of your architecture for you, and supposedly you just fill in the business rules, but it sounds a bit far fetched. Furthermore, any changes made outside of the “free blocks” has to be re-integrated each time you generate the model again. This includes any performance tweaks at the data access level – a common place for application bottlenecks, and I find it highly unlikely that their generated SQL provides the most highly optimized query for every situation.

Now spread this issue into every tier because, after all, THEY are dictating, err, deciding the architecture for you. So now, you have no control over the architecture in any tier unless you want to rewrite your changes every time your business requirements change. You can’t choose your web tier architecture, your business tier architecture (which is unfortunate, because they are crazy for EJBs), or your data access architecture. In many cases, you can’t even change your implementation – their approach replaces your EVERY time requirements change.

Full, true round-tripping is pie-in-the-sky, and enterprise apps require more care in design than just pushing the big green button. As such, MDA seems mostly useful for the bonehead applications that you’d turn your least educated VB developers loose on – the non-critical departmental apps. For these apps, I’d then question why you want to spend so much money on an MDA tool for a non-critical tool?

At one of the discussion panels at the symposium, Dave Thomas quipped (paraphrased), “It seems to me to be extremely bad practice to believe that you can write an application by drawing pictures.” Also, when the panel was asked about MDA, I believe it was Stuart Halloway who added, “I find MDA every bit as essential to the development of quality software as UML.” I couldn’t say it any better.

Update: In an amusing twist of fate, it seems that one of these vendors is coming in today to give a demo of their product. Oh joy.

I seized the opportunity at the recent Atlanta Java Software Symposium to attend both of David Geary's sessions on JavaServer Faces, and left the sessions terrified. I mean seriously, what's with running JavaServer together? Is this a new Sun marketing term, the JavaServer?

So what's the scoop? First of all, make no mistake about it – JSF is designed to replace Struts, Tapestry, etc. as THE standard J2EE model for MVC. So what's the problem? Some problems in the current version will, in fact, go away. David seems to be very aware of some of the pain points developers have found in the current rev of JSF, and committed to getting those things remedied. That being said, there are still some very deep seated problems that will certainly affect my eagerness to adopt this new standard. (Being practical, I will certainly learn enough to remain current, and enough to maintain/attain whatever form of employment I’m after.) I believe the main problems revolve around redundancy with Struts and indecision in the API.

The redundancy angle is somewhat necessary, in that it needs to replace Struts in order to justify its existence, but think of it in terms of taking Struts and making it more cumbersome. JSF has an Action to match Struts' actions, a Form much like ActionForm, a hidden controller powered by faces-config.xml (much like struts-config.xml). It has validation, and message bundle support for internationalization. At present, you have to specify WHICH bundle to use for pretty much every message you want to output, but it seems like that will be fixed. In essence, you have MOST of the things you’ve come to expect from Struts, plus a “LifeCycle”, which may or may not be exposed to the developer in the end, plus an event model, and with some glaring omissions.

It lacks some of the Struts 1.1 features that made life easier, such as the DynaForm, so we're back at the Struts 1.0 square-one of proliferating an inordinate number of classes to make a simple app.

Now for the indecision in the API. This was glaringly exposed to me in an example of how to log inside of a JSF action using Servlet logging. The line of code to do this was:

((ServletContext) FacesContext.getCurrentInstance().getExternalContext().getContext()).log(“What a pain!!”);

The JavaDoc for FacesContext indicates that this approach is taken so that the application isn’t necessarily aware of its container. But wait – getContext() returns an Object, so in order to do ANYTHING meaningful, we need to be aware of our container. The example cited is a ServletContext vs. a PortletContext. The Portlet spec states this about a PortletContext: “The PortletContext must offer access to the same set of resources the ServletContext exposes.” So one would HOPE that PortletContext would actually extend ServletContext, but this seems to have been left hanging in the Portlet specification.

The overall point here is that so much trouble has been taken to remain independent of context of the container and of the client, yet certain things baked into the fabric of JSF are implicitly dependent on aspects of the container or client. A key example of this is one of JSF’s new concepts (compared to Struts) of an event listener – there are two types of listeners – an action listener, and a value-changed listener. The value-changed listener supposedly responds to changes to a form field – the example given was that of changing the country, and adjusting the address fields to match the new locale. The problem with this concept is the assumption that the client has a meaningful way to relay this event back to the server. For any sort of wireless device, this is a non-starter. It certainly applies for standard HTML and possibly XUL, but this concept is VERY MUCH tied to the capabilities of the client. Even when you want to place the event in an HTML page, you have to code your own Javascript to submit the form on update of the field, and it’s hardly distinguishable from submitting the form (sadly, it even causes validation errors to show up, even if your only intent was to reconfigure the form, and even if the user didn’t even have the opportunity to fill in that field yet!).

So in general, some of JSF seems to trip over itself to remain independent of environment, while at other times, it paints itself into a corner to match Microsoft WebForm functionality. One things Struts, when combined with the JSTL tags, does is that it picks what it wants to do, and does it well. In its current state, JSF seems to be completely unfriendly to developers unless they have a tool to handle all the nasty under-the-covers stuff, which may, perhaps, be the point (sell licenses of Project Rave). Another inevitable and unfortunate consequence is the pending arrival of <vendor>-faces-config.xml. I blame the vendors for this, mostly – both in their desire to lock you into their platform, and their influence in the JCP that leaves so many things intentionally ambiguous so that they NEED to provide vendor-specific deployment descriptors.

Perhaps JSF 2.0 will be ready for prime time, but unless you plan to start “Rave”-ing from Day 1, developers seem best served continuing work with their framework of choice – JSF doesn't buy you anything you need, and forces you into a whole lot that you don't.