evelopers eager to see the words “Java” and “ease of use” used together more frequently should probably keep a close eye on what IBM does with its WebSphere family of products. One product in the WebSphere suite, the new WebSphere Portal4.2, gives Java developers a very simple, point-and-click interface for creating Web-based applications (IBM calls them “portals”) using combinations of Java servlets.

Basically a framework for building customized Web apps, developers use the product to piece together components of a page. The components, or “portlets,” are a subclass of HttpServlet, and are basically complete applications running within a portlet container on a portal server in a manner similar to the way Java servlets run on an application server. Portlets can display either static or dynamic content, and can easily capture existing content from database queries or pre-existing HTML pages. Most portal pages consist of several portlets?in other words, you should think of each portlet as the controlling code behind a specific portion of a page. The portal framework renders the portlet content and links it together at runtime.

Portlets use model-view-controller architecture, and encapsulate several states and “views” of information within their portion of the page. They can also raise events and send messages. The developer thought process required to build a portlet is different from that for building a complete Web page.

“Developers need to think about building a portion of a page [rather than the whole page]” said Carol Jones, WebSphere Portal Chief Architect in an interview Tuesday. Jones said the framework includes standard portal features such as registration, personalization, and security, simplifying developers’ tasks considerably.

New administrative portlets simplify many common tasks, such as building forms to display data or capture existing content. Jones compared the functionality of the product to Visual Basic, saying it essentially lets developers hook up back-end data to front-end forms using a point-and-click interface.
Because most developers already have a huge repository of usable Web content available, the WebSphere portal product lets developers identify existing content they wish to capture for a portlet, by selecting it visually or by identifying content between specific tags?a process Jones called “clipping” pages. The source information becomes part of the application at runtime, so that changes to any source document are automatically reflected in the portlet content as well.

However, developers always have the option to grab the content and separate it from the source, essentially moving content into the portlet as local data rather than having the portlet query a Web page for that content.

This flexibility extends to enterprise business applications?developers can automatically generate portlets from database queries or from defined SAP, Siebel, PeopleSoft and Oracle Financials functionality. The portlet generation engine queries the metadata for the fields and data types to build the default UI. So, for example, if you wanted to build a page that exposed employee names, locations and addresses, and you already had a database stored procedure that provided the data, you could wire the portlet to the query and the portlet tools would automatically write the code to connect to the database, perform the query, and output the HTML.

This release supports the Struts 1.1 (a Jakarta open source project) to let developers implement model-view-controller design patterns within their Web applications, simplifying page and action sequencing and validation.

Developers can also use the portal software to create and then selectively serve different versions of the portal that are optimized for specific client types. Called “views,” the portal framework identifies a particular client type (for example, IE 6) using the user agent string sent by the client during a Web request. Jones said the view functionality is most useful in customizing portals by client classification, for example, one view for a desktop browser and another for a WAP client.

Unlike most of IBM’s developer-targeted products, WebSphere Portal ships with a working portal out-of-the-box. While the inclusion of that level of out-of-the-box functionality seems to blur the target user of the product, Jones says she doesn’t expect many organizations to use the built-in portlets as shipped, saying they’re provided more for example than for production use. Instead, she said developers will use the familiar WebSphere Studio interface to build their portlets.

So why does the product generate only Web interfaces? Why not generate rich clients in a native Java UI? Jones says IBM is aware that building lowest-common-denominator browser-based clients is not always the best solution, but that she doesn’t think Swing is the appropriate technology for building rich clients. She said that IBM has a two-pronged strategy for providing more interactivity for rich client development in the future. First, IBM hopes to selectively move portlet functionality and capabilities from the server to the client by relying on JavaScript (but still in a browser-based front end). Second, the company is looking at ways to use functionality in the Eclipse project to generate rich client forms; however, such capabilities are “at least a year” away Jones said.

WebSphere Portal integrates with the WebSphere Translation server for organizations that rely on machine language translation. It ships with the WebSphere application server. Pricing starts at $72,000 per processor for enterprises; a midmarket (intranet/extranet) version, “WebSphere Portal Express,” starts at $77 per user and goes up to $47,820 per processor.