Level: Intermediate Anthony Bernal (abernal@us.ibm.com), Senior I/T Specialist , IBM
27 Nov 2002 Part 2 provides an in-depth discussion of modeling portal applications, and introduces the additional topics of modeling portlet services, EJBs, and other coalesced objects within a portal application design.
© 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.
 |
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.
|
Framework Feature Comparison
| | Feature | WebSphere Portal | Jade | Struts | Additional Remarks | | Proven in production | Yes | Yes | Yes | All three frameworks have been used successfully
by organizations. | | MVC Architecture | Yes | Yes | Yes | | | JSP Tag Libraries | Yes | Yes | Yes | | | Internationalization Support | Yes | Yes | Yes | | | Action Handling | Yes | Yes | Yes | | | Web Services | Yes | Yes | No | | | Logging Support | Yes | Yes | No | | | Exception Handling | Yes | Yes | No | | | Persistence Model | Yes | Yes | No | WebSphere Portlet persistence is available
via a published API. An object persistence model is available
for Jade via another package (Topaz). | | Source Code Provided | No | Yes | Yes | Jade source is available to IBM customers
at cost. | | Documentation | Yes | Yes | Some | Struts documentation is limited to the
open source community and users who offer support. | | Support/Training | Yes | Yes | No | WebSphere Portal and Jade support and training
are available through IBM. |
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.
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.
Figure 1. The doView() activity diagram
In this case, the method completes the following:
- Determines the next (target) JSP to display
- Checks if the data bean (model) exists or creates one
- Performs processing logic
- Stores the bean in the session for further use by the portlet
- 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.
Figure 2. The action handler state chart diagram
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.
Figure 3. User interface
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.
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.
Download | Name | Size | Download method |
|---|
| relatedfiles.zip | 0.05 MB | FTP |HTTP |
Resources
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
.
|
Rate this page
| 
