designing websphere portal applications

© 2006 Wellesley Information Services. All rights reserved.

Designing WebSphere Portal Applications

John KiddKidd & Associates

2

What We’ll Cover …

• Understanding portal development• Integrating your applications into the portal• Selecting a development method• Designing your portal application• Developing your portal application

3

Understanding Roles and Responsibilities

• There are three distinct activities in building a portalDeveloping portlets (developers)Creating themes and skins (designers)Creating page definitions (administrators)

• Everyone can work independentlyChanges in portlets don’t affect themes or page layoutsChanges in themes don’t affect portlets or page layoutsChanges in page definitions don’t affect themes or portlets

• Critical supporting activities for building a portal:Designing, building, and monitoring the WebSphere Application Server (WAS) infrastructure (administrators)

Note

4

Reviewing Development Skills

• How is development done today? In-house? Offshore?• How many developers do you have?• What are their skills?

Usability ArchitectureDesignDevelopmentTesting

• What technologies and tools are they familiar with?

5



6

Integrating Applications Into WebSphere Portal

• To integrate an application into WebSphere Portal, we use a process called “portalizing” the application

Involves separating the application functionality into re-usable user interface components called portlets

• Applications are typically implemented with multiple portlets which cooperate to provide all functionality

A single portlet represents one aspect of an application • Integrating applications presents an opportunity to

redesign application functionality as components Portlets, which are designed to cooperate, can be placed on pages with other portlets to create new applications

7

Understanding Portlet Applications

Seeing Cooperative

Portlets

8

Portalizing Existing Applications

• The first step in portalizing is to characterize the application using the following parameters:

Size of the databases/number of recordsNumber of users, maximum number of usersUsage pattern, number of concurrent usersApplication complexityIntegration of single or multiple back-end systemsAlready Web-enabled or rich-client-based?Notes client-based?

9

Understanding Application Usage Characteristics

10

Example Scenario

• Employee directory with 100,000 entriesInitial portlet display is the first 10 people in the A-namesUsers can browse the directory pages or search by nameTotal of 40,000 portal users, 5% of which have concurrent access to the page where the portlet lives

Assuming that all users have access to the portlet• Result: 2,000 concurrent requests to the portlet

2,000 portal sessions (for state navigation of directory pages)2,000 concurrent accesses to the back-end system

11

Understanding the Impact to the Portal

• Memory for 2,000 sessions at a lean 50 KBs per session means an instance usage of 100 MBs

Could cause a portal severe performance issues on systems with limited availability of memory

• If the back-end system can’t open 2,000 sessions concurrently, portal response times are reduced

Whatever the cause of the performance issue, end users perceive the portal as being “broken”

• By analyzing the impact of portalizing your existing J2EE applications, you can mitigate potential risks

Implement a caching strategy (portlet output, data, etc.)Increase the amount of memory in advance

12

Using a Phased Approach to Application Integration

Just Connect to Legacy

Applications

80/20Rule

Build or Migrate Portlet

Applications

Very little functionality built into portal. Most work is in connecting to existing systems.

Rebuild the most useful 20% of existing application functionality in the portal.

Link to the other 80%.

Migrate legacy applications or extend those applications to leverage portal capabilities

The Sweet Spot

13

Phase 1: Get the Application into the Portal Quickly

• LinkUser is given a link which launches the applicationApplication launches in a separate windowUser may be required to authenticate with the applicationCan be done with the Bookmarks and QuickLinks portlets

• DisplayPortlet displays information from the back-end system

Useful for display-only type applicationsUser must launch the application to interact with it

14

Phase 2: Portalize the Most Useful Functionality

• IntegratedPortlets provide an interactive interface to the applicationGreat approach where only parts of the application need to be available through the portal interface

For example, approval of travel or expense reportsThe workflow and back-end integration used by the existing application can remain as is

Peaceful co-existence and minimal impacton the overall performance of the portal

15

Phase 3: Portalize the Entire Application

• MigratedThe portlet application replaces the existing applicationTypically requires the application to be redesigned

With the exception of Web applications, most existing applications have a user interface paradigm that will need to be completely redesigned for use in a portal

Web-based applications map quite well to the portalLike Web apps, portlet apps are packaged in WAR filesPortlet applications have another deployment descriptor(portlet.xml) which describes the portlet application

16

Prioritizing Your Applications

• What applications will be integrated into the portal?• What is the most likely integration approach?

LinkDisplayIntegratedMigrated

• What will be the likely initial (short-term) and the strategic (long-term) integration approach?

• How is authentication performed with applications?

17



18

Understanding the Rational Unified Process (RUP)

19

Using RUP on Portal Projects

• A 3-3-2-3 iteration approach is typical for the first project• Inception phase iterations (3-3-2-3)

Inception 1: Visual design and portlet sourcingUse state diagrams to describe what portlets do asthey transition between portlet states (view, edit, configure, help)

Inception 2: Infrastructure designCapture using deployment architecture diagrams

Inception 3: Content/information architecture designStatic class models are great for designing content models

20

Using RUP on Portal Projects (cont.)

• Elaboration phase iterations (3-3-2-3)Elaboration 1: Prototype connectivity and portlet interfacesElaboration 2: Load testingElaboration 3: Prototype connectivity and portlet interfaces

Unit tests for portlet services are critical• Construction phase iterations (3-3-2-3)

Construction 1: Heavy stress-testingConstruction 2: Finish portlet service and portlet development

Content model must be finalized during this phaseFunctional testing should be continuous

21

Using RUP on Portal Projects (cont.)

• Transition phase iterations (3-3-2-3)Transition 1: Operations trainingTransition 2: Load testingTransition 3: Rollout

• For later portal projects you can use a 1-1-3-3 approachVisual design, portlet sourcing, and content design (inception)Prototyping and load testing (elaboration)Build and test functional groups of portlets (construction)Train operations, load test, and rollout (transition)

22

Using Extreme Programming on Portal Projects

• Portal challenges to extreme programmingMainly infrastructure in the beginningRequirementsToo many outside actorsRepositories (not specific to portal)

• Portal benefits to extreme programmingPortal components lead to small XP mini projectsPortlets are small enough to make good user storiesLess modeling required – braindead object modelsPortlets make rapid real releases more possibleCross-training is critical to solving the portal knowledge gap

23

Portlet Development Method Best Practices

• Use short, iterative development cycles to deliver value Define functionality that can be developed in 4-6 weeksBe flexible, what you learn during one development cycle may change existing functionality and planned development cycles

• Use Agile methodologies like XP with careNot recommended for the first portal projectFirst, gain experience with portal and portlet developmentPortal and its portlets provide a much more natural way to divide up teams, and can work well with an Agile approach

24



25

Starting your Project

• A process that works …Have an architecture and design sessionDescribe your portalDecide on a default interface model and exceptions criteriaGet any screen mock-ups or wire framesDefine the content source for portlets (portlet sourcing) Build a state model to describe portlet state transitionsMock up the portlet user interfaceUse a top-down approach to describe user roles and page transitionsBuild, test, and debug portlets with portal tooling

26

Gathering Portal Requirements

• Most customers follow a requirements process that is inadequate to satisfy the needs of the portal

This does not mean you should throw away your processConsider adding portlet sourcing to your process

It can save you an average of two months• Portlet sourcing is a key activity for a successful project

The primary basis for accurate project sizing Great way to communicate your needs effectivelyThe primary source of portlet requirements for developers

27

Sourcing the Portal Content

• To bring content into the portal, we must identify:The content source (where the content is and who owns it)How we’re going to get the content into the portalWhat service level agreements exist with the content owner

• Consider portlet sourcing to be an iterative processIt’s okay to use placeholders for portal pages and portletsGet as much information as you know out, and refine later

• Each portlet “sourcing” document should be:The base for the portlet requirementsUpdated as decisions are made

28

Start With a Simple Whiteboarding Session

Page One

CEO’s Message Quicklinks

Newsflash Stock Ticker

SametimeBuddies

Alerts

29

Sample Portlet Sourcing Questions

• Who can view, edit, and configure this portlet?• Is this a wizard (multi-state) or cooperative portlet?• Who owns the data? Is the format likely to change?• Are there multiple items displayed? How many?

In what order?• Is the content personalized?• What (spoken) languages need to be supported? • What mark-up languages?• Is this a JSR-168 portlet? Web Services for Remote

Portlets (WSRP)?• Do you need to be able to print the portlet view?• Is the content of the portlet cacheable?

30

Portal Sourcing – Wire Frame to Worksheet

Use wire frames to refine your

understanding of the requirements

Document portlet design decisions in the portlet sourcing

worksheet

31

Portlet Interface Model Design Considerations

• You need to decide on a default user-interface metaphorWill portlets behave like a wizard or Windows Explorer?

• A wizard interface implies many portlet view states We call this interface the wizard modelThis is well suited to Struts and JavaServer Faces (JSF)

• A Windows Explorer like model implies portletcooperation

We call this interface the Cooperative modelThis is well suited to Click-2-Action (IBM Portlet API only)

32

CreditAppl

{update DB}EditLineItem

OK

[ Quantity < 1 ]

Successful

BadQuantity

(request: LineItem item)(session: CustProfile prof) Order

Details

[ total > credit ]

NeedMoreCredit

ErrorInfo

MiddlewareError

[ error occured ]

Result Name Condition

Unit of Work

Event Name

Transient Data

Detailed Design of Portlet States

33



34

Comparing Web Applications to Portlet Applications

• Similarities – Development standards and best practicesPortlet applications use the Model View Control (MVC) pattern to separate user request handling from business logic and results display

Portlet code JavaBeans JSPs• Differences – Developer no longer has complete control

Developer controls the functionality and display of the portletThe portal administrator controls:

The navigational structure for portal pagesLook and feel of the page (theme) and the portlet (skin)Which portal page(s) your portlets are placed onWhich other portlets are placed on that page

Note

35

Understanding JSR-168

• The JSR-168 defines a portlet container standard that provides portability across portal products

The IBM Portlet API pre-dates JSR-168 by several yearsWebSphere V5 supports both IBM and JSR-168 APIs

• The JSR-168 API is IBM’s strategic direction for portlet development with WebSphere Portal

The IBM Portlet API still has some more features than the JSR-168 API, but that feature gap is getting much smallerIBM is creating JSR-168 extensions to fill the feature gap

• In WebSphere Portal 6, the IBM Portlet API is deprecatedBut it will continue to be supported by IBM for several years

Note

36

Understanding MVC Frameworks

• Portlets that require wizard-like interfaces have some special requirements beyond simple MVC

Ability to display and navigate sequences of screensAbility to maintain state with the user

• Frameworks provide a flexible solution for implementing portlets with such requirements

Struts and JavaServer Faces (JSF) provide for thisBoth are supported by WebSphere Portal and tools

• Struts is a proven framework for portlet applications, but strategically JSF (when proven) will replace Struts

37

Understanding Portal Navigation

• The biggest difference between developing Web applications and portlet applications is navigation

Web applications control the entire Web page and have complete control and notification of all user actionsPortlet applications reside on a portal page with other portlets which they may, or may not, be aware of

• When users click on links inside portlets, the portlet is notified, and can process the action

User actions can be shared by multiple portlets to create a complete application experience

38

Understanding the Portal Navigation Challenge

• So far so good, but here’s where it gets trickyThe portal page also provides the user with navigation controls which allow users to move to other portal pagesWhen a user navigates to a new page, the portlets on the current page are given no chance to process that action

• So what?This is a serious design consideration for portlet applications that conduct transactions with users

If a user navigates to a new portal page during a transaction, the user state can be lost and the transaction left incomplete if the portlet does notsave state changes

39

Managing the Navigation Challenge

• To manage the navigation challenge:Use multiple portlets (if necessary) to handle the complete application flow on a single portal pageUse wizard and co-operative portlet interface models

Remember, you can combine these two models• The layout of portlets on a page is chosen by the

administrator (or other user with sufficient rights)Unlike Web applications, portal applications cannot predetermine or dynamically control the layout of the portlets on the page

Tip

40

User Interface Design Best Practices

• Customizing the WebSphere Portal themes to match some exotic Web site can be very time consuming

• Educate your UI design team on portal capabilitiesDesigners who understand the functional capabilities of the portal are much more likely to design the interface toleverage those capabilities rather than work around them

• Select an existing theme and modify it to your needsGet users interacting with the site as quickly as possibleFocus on refining the themes as the last step

41

Navigation Best Practices

• Avoid using more than three or four levelsCreate a clear and distinct hierarchy between the levelsCreate a clear and distinct relationship between the levels

• Location and orientationStick with industry standardsPrimary navigation top horizontal or left vertical

• StyleAvoid using drop-down menus for site navigationUse tabs for horizontal navigations onlyUse tree-like mechanisms for vertical navigations

42

• Portal themes use style sheets to ensure consistency with visual items like fonts and colors

• Styles.css contains the majority of the stylesThe portal theme and skins are totally dependent upon the styles that are defined in the Styles.css style sheetYou can modify the styles, but never delete any of them

• HelpStyles.css contains styles for portlet HelpJSPs associated with portlet help mode use these styles

Caution

Understanding the Importance of Portal Style Sheets

43

Load Testing Your Portal Application

• You must do load testing, it is not a negotiable itemThe best portal application can fail in production if you do not do adequate stress testing before going into productionTest to failure, then identify and fix problems

• Load test as part of the iterative development processSimplifies the process of problem isolation

44

Reviewing Development Standards

• Do you have portlet development skills?IBM Portlet API, JSR-168 API, or both?

• Are you presently using an MVC framework like Struts?• What are your standards for load-testing Web

applications?• What are your needs for parallel development?

Present and next version of the portal applicationMultiple versionsMultiple applications on the same production system?

45

Resources

• WebSphere Portal family product pagewww.software.ibm.com/websphere/portal

• WebSphere Developers Domain Portal Zonewww7b.software.ibm.com/wsdd/zones/portal

• DeveloperWorkswww-106.ibm.com/developerworks

• WebSphere Portal Patterns Sitewww-106.ibm.com/developerworks

• IBM Software Services for Lotuswww-142.ibm.com/software/sw lotus/services/cweeducation.nsf/wdocs/serviceshomepage

46

7 Key Points to Take Home

• Focus on the “sweet spot”Integrate high-value functionality quickly into the portal

• Use an incremental, iterative, approach to developmentBe conservative initially, then transition into an XP model

• Use a phased approach to migrating Web appsFollow the 80/20 rule, link, display, integrate then migrate

• Augment requirements with Portlet Sourcing• Leverage Unified Modeling Language (UML) artifacts to

capture portlet designCollaboration and sequence diagrams

• Leverage the existing best practices documentation• Integrate load testing activities with development

47

Your Turn!

Questions?

How to Contact Me:John Kidd

[email protected]

designing websphere portal applications

Technology