Building WebSphere with prototypes

Building WebSphere with prototypes

Most of our projects are developed by building prototypes and refining them as requirements are being gathered. This approach works well for custom applications, but I have some concerns about building and deploying WebSphere Portals this way. Any thoughts?

    Requires Free Membership to View

    Login

    Register today to access targeted resources from our editorial writers and independent industry experts focused on Lotus Domino, Notes, Workplace and other related technologies.

    By submitting your registration information to SearchDomino.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchDomino.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

The Portal Technology Team at IBM (which I am lucky enough to be a part of) advocates the concept of using visual prototyping (wire frames), followed by portlet sourcing (where we gather requirements about the location and owner of the content for each portlet and other key design information). When we know what portlets are going to be on what pages with which access controls for which users, we can then start to prototype the portlets and use those prototypes to validate our assumptions.

If I understand your question correctly, I think you're asking whether or not we'd advocate a rapid application development or Agile approach to portal applications. The answer to that question is that yes, we absolutely advocate that approach because portal fits well into the paradigm. That said, it's important to take a more traditional approach to your first implementation so that you gain experience with the technologies. Don't get bogged down in long and drawn-out requirements processes. For the first implementation, define a pilot that can be well understood and built within a reasonable timeframe. Most pilot projects in my experience take about four months -- mostly due to the infrastructure work that has to be put into place before you can start development. Once you've got the infrastructure in place and your pilot is successful, then you can evolve the pilot in short iterative development cycles (4-6 weeks typically) evolving the applications as your understanding of the requirements evolves. Because you're building a bunch of true components (portlets), which should, by the way, be kept as simple as possible and also be designed to interact with each other (pass data to each other), if you have to throw away some code it's not that big of a deal.

Another thing that I like to stress is that you don't have to be a J2EE expert to write effective portlet applications. The portal provides a great deal of the foundation and encourages you to keep things simple. You will need to understand Java and design patterns such as model-view-controller work. But the wizards that Rational Application Developer (RAD) provide, which comes with Portal at no charge, generate base code structures that follow best practices that I highly encourage you to use. Remember it's not a "code generator"; believe me, we all hate those. It's simply a set of foundation code that follows best practices. As you go through the wizard, you choose options which either include or not include additional bits of code for accessing things such as the Credential Vault. At the end of the wizard you've got a working portlet that you can extend to your heart's content.

The Portal Technology Team at IBM has lots of best practices that we are happy to share with our customers upon request.

This was first published in August 2005

Back to top