Sun, IBM deliver Java portal spec
Even archenemies will work together when enough is at stake.
On Monday, the first day of the Java One conference, Sun and IBM--often bitter rivals--will make a joint announcement that proposes a standard API for Java portal servers. Think of this collaborative effort as adding another story to Java's house: Until now, J2EE has covered the server side, but Sun's and IBM's Java Specification Request (JSR) 168 will extend the framework all the way up to the browser, with the first portal software implementations arriving in 2003.
All the major providers of J2EE-based application servers already have a portal server to go with them. But the portal APIs are proprietary to each implementation. Standardization changes everything: Developers can write portlets (special servlets that expose application functions in a browser) once and deploy them to any portal server. As with other market segments, standards like this allow IT departments to be in more control their portal infrastructure. For example, if you become dissatisfied with the performance, reliability, or cost of your current choice, the elimination of proprietary portal APIs takes a significant amount of pain out of switching to a competing solution. All the portal providers have lined up behind JSR 168, including BEA, Epicentric, Plumtree, SAP, and Oracle (which proposed its own Web services portal spec to OASIS last January).
Just as intriguing is that a standardized API may promote portal integration that bypasses the application server. Sun's iPlanet Portal Server 3.0, for example, already uses adapters based on the Java Connector Architecture (JCA). Since the JCA's introduction last fall, the spec has fostered a new class of easy-to-build adapter for mainframe databases, ERP software, and so on. On one end, you plug a JCA adapter into DB2 running on an OS/390, and on the other end, you hook up the portlet--and presto, up pops mainframe data. IBM gained similar but proprietary adapter-like functionality for enterprise applications like SAP and Peoplesoft when it acquired CrossWorlds. On the client side, JSR 168 also stipulates that multiple devices must be supported, which makes me wonder whether the device specific features of some mobile application servers have just become obsolete.
Although GUI simplicity and easy personalization underlie the whole portal idea, a browser-based portal can't supply the rich client functionality of, say, a Windows application. What standardized portal servers can provide, however, are rapid development of friendly little apps and easy connections to all corners of the enterprise--not to mention instant deployment on any device or platform. That proposition was compelling enough to rally the whole Java tribe. In part, perhaps, because you'll have one less reason to focus your enterprise development efforts on Windows.
Have portals changed your life? Or have you had enough of thin clients? E-mail Eric or Talk Back below.