Standards like JSR168 and JSR127 make your life easy, or ….
Wednesday 17 May 2006 @ 3:39 pm
Filed under:

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…..?  JCP

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 :-)

  The Tacoma Narrows Bridge
 

— By Erik Pronk   Comments (1)   PermaLink
Uninvited advice regarding SAP and Java
Wednesday 5 October 2005 @ 3:39 pm

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).

— By Okke van 't Verlaat   Comments (2)   PermaLink

Menu


Sha256 mining

Blog Categories

Browse by Date
September 2007
M T W T F S S
 12
3456789
10111213141516
17181920212223
24252627282930

Upcoming Events

Monthly Archives

Recent Comments

Links


XML Feeds Option


Get Firefox  Powered by WordPress

code validations
Valid RSS 2.0  Valid Atom 0.3
Valid W3C XHTML 1.0  Valid W3C CSS