So what if you want to develop a rich portal application, let’s use the standards!
Standards are their to make live easy for you, right…..? 
I want to create a Portal application with a rich and easy to build interface, this leads me to the following standards JSR168, the portal standard and JSR127 the JavaServer Faces specification. First of all I want to find a portal that supports this standard and does not provide to much overhead. This lead me to the JSR168 Portal Jetspeed (http://portals.apache.org/jetspeed-1/). Jetspeed 1 also provides support for JSR168 under the codename Jetspeed Fusion.
Yes there are other alternatives like Exo and Liferay that do the job but these provide to much overhead for my “simple” requirementSo the most important step is done I found myself a suitable OpenSource Portal with JSR168 support. Now we need to install it and as always Apache provides a out of the box solution including Jetspeed and Tomcat 5.0.3. The next step should be easy we need to create a rich JSR168 portlet application using JSF technology. In my opinion this should be as simple as 1.2.3. We just need to include the JSF jar into your project and start developing the portlet following the JSR168 API. After that we can just create a war-file which will be automatically deployed by Jetspeed.How wrong can one be, standards are not their to work with each other out of the box one must create a bridge for these two standards to work together. In this case I need to use the Apache Portals Bridges project ( http://portals.apache.org/bridges/ ) for these two standards to work together. The bridge consists of a generic Portlet-class which forwards your actions according to your configuration in the portlet.xml. All in all it’s not the work that triggers me but the bridging method, is this also based on any standards?? Or will we have to build bridges to support bridges?? So why do we need a non-standard bridge, which by the way impacts your flexibility to code portlets, to couple two standards? Aren’t both standards all about presentation? And why isn’t the JSF standard not supported by JSR-168 (or the other way around)? JSR-286 seems to make some promises about a tighter integration but besides to late, it is still a long way to go.So, until then we’re struck with bridges and our history has learnt us how dangerous bridges can be 
This week together with three collegues (Simon Peter Haverdings, Martin Jaspers Focks and Robert Berg) I’m folowing a BEA Portal developers course. The course is given by a BEA trainer from the UK at the LogicaCMG office in Rotterdam. The course gives a nice overview of the BEA Portal product including BEA’s own Workshop IDE and the portal administration console. To give a rough idea the course handles the following subjects: - development installation of BEA Portal inclusing the Workshop IDE - how to set up a basic portal site that consists of a desktop (with header and footer), (sub) books, pages and portlets inside the pages.
- how to customize and override the look and feel and themes of the portal and porlets
- customize the layouts in witch portlets are placed inside a page
- Working with Java Page Flows (JPF for short) including the nifty Workshop graphical editor
- Portlet state management and user profile / property management
- Easy webservice and database integration inside JPF’s
- Integration of content management systems (CMS) inside your portlets
- Personalise content based on simple rules
- Events
- How to create ad compain based on events or user profile
The BEA Workshop IDE can’t match with the Eclipse IDE for pure Java development, but it contains nice wizards and graphical editors to support for BEA portal development. In simple situations it’s simple a case op opening an editor, drag some items from a (data) palette and make some changes in either the property editor or a dialog. In almost all situations the data displayed in the graphical editors is in fact a XML file with a XML Schema attached to it. So using Eclipse 3.1.1 with WTP 0.7 and custom ANT scripts might be an option to kick out the BEA Workshop 
A really nifty graphical editor inside the Workshop is used for the Java Page Flows (JPF for short). It draws a diagram for the JPF classes with the JSP pages and the actions between theme. You can easily drag JSP pages (new or existing) and new actions onto the JPF diagram and also adding simple form data is a super easy. Looking under the hood it appears that the Java Page Flows are implemented using struts. From what I have seen during the course and the labs of the course, BEA Portal handles a lot a portal related stuff that you would normally have to arrange yourself in a struts application. But then again the Lab exercises in the course a quite simple, and in the real world most customers want to have features that a not standard
Today the last day of the course… And after that I will probably not be involved with BEA portal for quite some time, since I have to round up my assignment at NS Reizigers and after that it’s some serious time off until the 24th of november for a large (well deserved ) holiday.
The last year (or maybe even years) I’ve been living in two completely different worlds. The first world is the well known world of java, j2ee, open source, nice discussions about technology and every month a different approach. As one can see, a pretty nice diverged environment that’s inspiring to get creative. The other world is the world of SAP, dominated by the vision of small town german Walldorf. Legacy and slowly moving targets are the keywords in this world. Both worlds seem to be pretty opposite of eachother but I always thought these two worlds get together pretty well.
How wrong I was! My goodness! Yep SAP is breathing Java all over the place. They have a J2EE server, the have a java based enterprise portal, the have an eclipse based development environment and they have a Java API for every product they sell. Sounds nice, doesn’t it. Nope, not at all. Two simple reasons: SAP refuse to adapt any standard except those needed to pass marketing technical interesting certifications (they have their own strange portlet api, strange deploy and manangement models, strange UI solution and so on). But this reason is acceptable (hey, SAP wants to make money and making money is way more simple when you lock in your customers as much as possible, every big player tends to do so). What’s not acceptible is the fact their API’s are designed and written by monkeys! And worse, the same bunch of german bonobo’s are using these API’s to write the their own merchandise. And we, the simple straighforward java developers, are required to either adjust their products or rewrite solutions from scratch using this mixture of rotten bananas and lines of java code. And for the worst (yep we’re diving deep in the bile called SAP), whenever you’ve written a nice solution using their API because the standard products/packages they provide are not sufficient enough to meet business requirements, you are facing (one year later) the invincible fact they have both changed the API and have written their own solutions. Meanwhile the SAP marketing army has overflown your customer with useless ideas and your home brew solution is kicked out for not being visionary enough.
Okay, I have to admit, I’m exaggerating a bit, and indeed this frustration driven (nope, it hasn’t happened to me yet, I’m just trying to figure out how disclose SAP XXX, in this case MDM, through SAP EP) blog is not the complete truth. And yep, those nice german guys sometimes have brilliant ideas and sometimes they even express real vision but keep in mind, this blog is not far away off the truth either! So, whenever you decide, for whatever reason, to do some tailor-made SAP based java development, think twice! Sometimes it’s better to wait a year or two or three (the so called Sit And (do not) Program strategy).
