Java, .NET Devs Get New Site for Portal Help

A group of software tools providers have gotten together to provide Java and .NET devs some help with their portal and custom UI projects using some of the latest standards. Launched last week at SourceForge, the portal features support for JSR 168, as well as cross-platform support via the emerging set of WSRP standards. See how the new POST portal, fitted with open tools and patterns, may change your next portal project.

Tags: Portlets, Java, Portals, Developers, Duffner, WSRP, JSR,


A group of tools and portal platform vendors, including BEA, Sun and Plumtree Software, have pooled resources with the aim of making it easier to Java devs to develop and deploy portal applications, using Java and non-Java technologies, including .NET.

The Portlet Open-Source Trading (POST) site, hosted by Sourceforge, is aimed to provide devs a one-stop Open Source site for tools, techniques and Best Practices to show developers how to build portlets in a more economical way with standards-based reuse principals from web services and SOA (service oriented architecture) movements.

In specific, POST resources comply with two key open standards ratified in just the last several weeks. They are:

1. JSR 168 (adopted in early October by the Java Community Process) and

2. WSRP 1.0 (Web Services for Remote Portlets) adopted by OASIS in September
Separate areas within POST exist for sharing JSR 168 and WSRP information components. Developers will be able to:
  • see lists of newly available portlets;
  • post requests to the community for the development of new portlets;
  • search for portlets;
  • upload new portlets;
  • download available portlets;
  • submit modified or enhanced versions of downloaded portlets; and
  • discuss portlet development best practices, issues and solutions.


  • So, What's Hard About Java Portals?
    There is a problem of scale and economics when it comes to building portals in Java, Duffner said which JSR 168 looks to start to solve. "Too often, enterprise IT [managers] have simply taken their data model and then provided users web access to it," Robert Duffner, portal prodocut manager at BEA told IDN. "[This] has given rise to what we call context-less portals that do not understand the user, or the data or how the user interacts with the data or the application" at the backend.

    Duffner relates a story that may sound familiar to many Java developers who have worked on context-less portal solutions. "Initially, when we rolled out a PeopleSoft HR portal at BEA all they did was put in an HTML front-end on their [client/server] application. So, if you didn't understand the seven Best Practices for changing an employee from one manager to another, it was a problem. I had to spend lots of time on the phone with HR people to walk me through that process."

    The Beginnings of JSR 168 and WSRP
    "JSR 168 provides a way of rationalizing [my assets] and the ability to start providing standards at the UI level," Duffner said. "but it doesn't obviate the need for enterprises to determine what their underlying infrastructure is going to be.

    In other words, Duffner said, JSR 168 puts the definitions for a Java/J2EE portlet in place. "168 simply says my definition of a portlet is your definition of a portlet, so long as you're running on a J2EE infrastructure," he added.. "Today, for the most part, all a portlet is a Java Server Page with very specific attributes , such as a header, a footer, defines a container and some workflow, and such."

    JSR 168 is a good start," Duffner said, but it doesn't address some of the other, more complex issues that surround reusability when building portlets, such as user properties/portal properties and intra-portlet communication capabilities, Duffner said. So, vendors will need to "roll our sleeves up" and get to work on the next iteration on JSR 168, which he hopes will address these issues.

    As a parallel track, Duffner told IDN that BEA also finds OASIS WSRP work very eye-catching. "WSRP is even more exciting is because WSRP is platform agnostic, and takes portlet development to the next layer of abstraction," he said. Materials for WSRP 1.1 and WSRP 2.0 are already under discussion at OASIS, and topics include support for
  • security,
  • cross-portlet coordination,
  • VoiceXML documents,
  • complex data-type transport, and
  • information modeling to comply with UDDI and ebXML standards.
  • . Aside from the Java community vendors supporting JSR 168, the added appeal of OASIS' WSRP work is that it includes many notable Java and non-Java vendors, including Microsoft, Oracle, Novell, IBM and others.

    Noting BEA's keen interest to support Java developers looking to work with Microsoft .NET-related technologies, Duffner also said BEA is working with Microsoft on its InfoPath technology, which instead of saving a document as a .doc or a .xls file, saves documents as XML documents. "We're excited about that because that provides us with a deeper level of integration with .NET," he said.

    Getting onto POST
    As with any open-source site on SourceForge.net, any registered organization can contribute portlets to POST, which become available to all other members of the open-source community. Thus, organizations that submit portlets to the site benefit from enhancements to their portlets developed by other POST members.

    To register as a member of POST, developers can visit http://sourceforge.net/projects/portlet-opensrc/. Companies interested in joining the coalition of companies supporting the site should e-mail postsite@users.sourceforge.netfor more information.



    back