© 2002 International Business Machines Corporation. All rights reserved.

Introduction

This article expands on Part 1 by extending the introduced design model, and offering a more complete solution. Part 2 provides an in-depth discussion on modeling portal applications, and introduces the additional topics of modeling portlet services, EJBs, and other coalesced objects within a portal application design. Within the portal community, developers are want to find consensus in designing and building portal applications. Consequently, this article addresses:

• Why UML? Part 1 discussed how to use UML for modeling portlet designs but did not provide detail on why you would want to use this approach to design your application. This article offers further insight into the benefits of using this approach for your designs.
• Choosing a framework. Several proven frameworks are available for building Web applications. What are some of the advantages of using these frameworks versus the portal framework?
• Complete the portlet design. This article provides a complete MVC portlet design (without the UI) that development teams can follow when designing and building their own applications.

This article, along with Part 1, focuses on services engagements where an architect or specialist is involved in designing and/or developing a complete application. The approach described is derived from real-world experience on several major portal projects; it is a simple, standard, and reusable approach designed so that all team members can follow the same guidelines. A colleague of mine once said, "We want portlet development to become more like an assembly line and less like works of art." This typifies the current state of portal application design and development. Even within teams, everyone is doing their own thing. Because IBM ® WebSphere® Portal (hereafter called Portal) is a relatively new product, this has been an acceptable practice until now. However, now that portal developers have gained more experience, they should have more solid design practices and now take full advantage of the framework. This includes improving the development speed, the robustness of portal applications, and ongoing maintenance.

Back to top

Using a framework

Web and portal developers are working hard to live up to the hype that new technologies claim to provide. Unfortunately, no framework can solve all problems. Having a good understanding of the technology, API, and/or framework is necessary before one can simplify the development process. An architect or specialist needs to weigh the advantages and disadvantages of using one framework over another.

WebSphere Portal

This article assumes that you are building a portal application using WebSphere Portal and that you have some basic knowledge of the application. WebSphere Portal is developed on top of WebSphere Application Server. It is designed to help developers build enterprise portal applications. WebSphere Portal provides a proven and complete API for building portlets that result in high performance, secure, extensible, scalable, and robust applications. The examples provided in Parts 1 and 2 of this series are based on the WebSphere Portal framework.

Jade and other gems

Jade is a framework provided by IBM as part of the Enterprise Application Development frameworks for Java (EAD4J). Jade, along with several other frameworks, Topaz, Ruby, and others, provide a robust, scalable, and supported way to quickly develop J2EE applications. The EAD4J toolset comes with a complete set of architecture documents and blueprints, as well as best practices and examples. Complete source code is also available. These EAD4J frameworks are also available to IBM customers.

Struts

Struts is an open source initiative supported by the Jakarta project that provides commercial-quality open source software to the general public. It also provides a Web application framework similar to Jade and is based on the J2EE standard. As an open source initiative, customers using Struts enjoy the benefits of an open source community but do not receive direct support for the product.

Choosing the right framework

The frameworks described above are designed to let projects quickly implement the business logic of an application without worrying about the underlying plumbing of the application. All three provide similar functionality although they differ in the implementation. Both Jade and Struts are application server-independent, while WebSphere Portal simply supports WebSphere Application Server.

Several independent initiatives are underway to integrate Jade and Struts within the WebSphere Portal framework. There can be both advantages and disadvantages to this approach. When evaluating the integration scenarios, keep the following in mind:

• Existing knowledge base: Development teams might have existing knowledge in one of these frameworks and expect that they can leverage this knowledge by using an additional framework with WebSphere Portal. However, developers will still need to learn the portal API to write efficient portal applications.
• Write once - run anywhere: Customers may choose to write applications that have the advantage of running both within and outside of WebSphere Portal. Using a framework such as Jade or Struts can help to leverage that development effort in such a way that it can be reused in different environments. Developers must ensure that the application is written in a truly independent fashion and that the cost of development time does not outweigh using such code.
• Added complexity: Using an additional framework such as Jade or Struts will introduce additional complexity into your environment and more layers to the process. This could result in a higher learning curve for new developers and additional testing or debugging time.

Much information exists on all three of these frameworks, outlining features and benefits provided by each framework. While each framework might excel in specific areas, all of the frameworks are comparable in their approach. The following table compares the functionality of each of the frameworks.

A final thought on frameworks

While both Jade and Struts offer excellent functionality and benefit to developers, WebSphere Portal offers a robust framework that provides for fully functional application development. In some cases, using an additional framework on top of WebSphere Portal might be required because of a specific functional or customer requirement. However, be prepared to fully weigh the cost and benefit when evaluating such an approach.

While using Jade or Struts within your portal application might not be an appropriate approach for your project, there are other frameworks available through EAD4J. For example, Topaz has potential to be integrated within WebSphere Portal applications. Developers should also investigate this possibility.

Back to top

Returning to the earlier portlet design

Now you will complete the portlet design started in Part 1; this will help architects and developers understand how to use the portal framework to its fullest. Also following this design, beginning portlet developers and teams can have a common starting point on which they can build their own portlets.

Reviewing the UML design approach

While UML takes some time to get used to, it is an intuitive way to understand the design of a piece of functionality. The visual modeling of systems provides the following advantages:

• Users from different backgrounds can understand how the system works
• It shows how different pieces of the system interact with each other
• It illustrate the system from different viewpoints (multiple views), so that a complete design can be created

Using visual models in addition to other work products lets developers create an easy-to-understand design that they can use immediately. Keep in mind the distinction between UML and the Rational Unified Process (RUP). RUP is a software engineering process that makes use of UML. However, you can use UML independently with other processes or methodologies.

Understanding the doView()

The heart of any portlet is the doView() method. This method is inherited from abstractportlet along with several other mode type methods. Even though this article only discusses the doView() method, the techniques provided apply to any of the other doXXX methods. The following activity diagram describes what is happening in the doView() method.

In this case, the method completes the following:

1. Determines the next (target) JSP to display
2. Checks if the data bean (model) exists or creates one
3. Performs processing logic
4. Stores the bean in the session for further use by the portlet
5. Calls the target JSP for display

The download ZIP file below contains the code -- doView() method -- that implements this process. See Listing1.txt in the ZIP file.

If you want to store specific portlet information for a user, for example, credentials or private information, then you would implement the doEdit() in a similar fashion.

Mapping actions

Designers often struggle with how to determine the flow of interaction between the user and the portlet. To achieve this mapping of actions to the interface requires both technical and cognitive skills. Part 1 discussed the action handling sequence for one scenario: a search. Part 2 expands on the sequence to handle all actions within a portlet. Using a state chart diagram (see Figure 2) can help to determine the interface (JSP) transitions for the portlet. The arrows in the diagram illustrate the transition flow of the pages based on the user interaction.

The above diagram maps to seven JSPs within the portlet. This is a fairly simple example for this type of portlet. Most portlets will require this model to be extended based on the business logic implemented. You can use this diagram to directly code the action handling sequence of the portlet (see Listing2.txt in the download ZIP file below).

Building the model and utility class

Continuing with this design, you can place all of the business logic and transition mapping in a utility class for use by both our controller and JSPs. This approach lets you closely follow the MVC pattern, and limits the amount of business logic that is placed within our portlet controller. See Listing3.txt in the download ZIP file below.

This class also contains methods to handle the business logic for each element of functionality required. See Listing4.txt in the download ZIP file below.

Designing the user interface

This design does not provide branding (look and feel) information about the portlet. It is important to understand that designing a proper UI requires a very unique skill set with a proper understanding of the creative and cognitive issues related to building an effective user interface. The interface presented here and in the sample portlet is simply a mockup to illustrate the sample portlet.

You should design the UI fairly early in the process, soon after you have gathered the requirements. All of the portlets in an application should follow a similar UI design. Creating a set of wire frame templates aids in the design and development process, as well as making debugging and system changes easier over time.

Using the provided samples

The download ZIP file below provides a portlet template based on the design approach discussed here. This template is a working portlet without business logic included. It uses all aspects of the portlet plumbing including, logging, actions, exception handling, and portlet namespace conventions. The download specifically contains the following files:

• SampleCRUDPortlet: This WAR file is a fully functioning portlet that provides the interactions and interface as described by this article. You can use it as a template or modify it to use as your project template.
• Sample Rational Models: Sample models for the portlet are provided in Rational Rose format. You can quickly create new portlet models by using this as a template for your design.
• Sample Code Listings: Sample code listings that are discussed in this article. Use these for a quick review of the example rather then reviewing the entire portlet code.

The sample code is a good example of how to follow coding standards and documentation. As engagements get bigger and more complex, it becomes more important to adhere to standards within a team environment. Although with simple projects this might seem like overkill, it is well worth the effort when another developer needs to redesign or maintain the code.

Back to top

Conclusion

This design and the associated models discussed in Parts 1 and 2 provide a complete picture of portlet design. Using the provided template, you are well on your way to a full portal design. Most applications will require several different types of portlets, such as XSLT portlets that follow the View-Controller pattern, and portlet services that follow other patterns, such as the fasade pattern.

Back to top

Download

Name	Size	Download method
relatedfiles.zip	0.05 MB	FTP|HTTP

Information about download methods

Resources

• Modeling WebSphere Portal Portlets with UML -- Part 1
  
  
• The Jakarta Project - Struts
  
  
• Developing Enterprise Java Applications with J2EE and UML, by Khawar Zaman Ahmed and Cary E. Umrysh
  
  
• Applied Java Patterns, by Stephen Stelting and Olav Maasen
  
  

About the author

Anthony (Joey) Bernal is a Senior I/T Specialist with the e-Workplaces/Knowledge and Content Management Practice with IBM Global Services. You can reach Joey at abernal@us.ibm.com .

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Using a framework
• Returning to the earlier portlet design
• Conclusion
• Download
• Resources
• About the author
• Comments

Next steps from IBM

With the WebSphere Application Server you can benefit from the simplified EJB 3.0 development experience, new persistence model, and interceptors.

---

• Try: Download a free trial version of WebSphere Application Server Community Edition, the lightweight Java 5 application server with robust EJB 3.0 funtionality.
• Article: Learn how call patterns and components involved in making calls to EJB components deployed in the EJB container operate in WebSphere Application Server.
• Tutorial: This tutorials shows you how to create an enterprise J2EE application that implements both Plain Old Java Object (POJO) and EJB Web services endpoints.
• Buy: WebSphere Application Server

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers