1.3 Integrating Domino applications into portlets and workplaces

 < Day Day Up > 



1.3 Integrating Domino applications into portlets and workplaces

In this section we look at the methodology with which Domino applications can be portalized, that is, transformed and embedded into a portal.

To better understand this we need to first introduce the concepts of portlets and places.

1.3.1 Introduction to portlets

Portlets are the heart of a portal. The term portlet refers to a small portal application, usually depicted as a small box on the Web page. Figure 1-5 shows a sample Web page that contains six portlets.

click to expand
Figure 1-5: Portal page with several portlets displaying weather, news, and so forth

Portlets are reusable components that provide access to applications, Web-based content, and other resources. Web pages, Web services, applications, and syndicated content feeds can be accessed through portlets.

Portlet modes

Portlet modes allow a portlet to display a different user interface, depending on the task required of the portlet. A portlet has several modes of display, which can be invoked by icons on the portlet title bar: configure, edit, and help. The portlet shown in Figure 1-6 is currently displayed in view mode.

click to expand
Figure 1-6: Portlet modes example

  • A portlet is initially displayed in its view mode. As the user interacts with the portlet, it may display a sequence of view states, such as forms and responses, error messages, and other application-specific states.

  • Help mode is used to provide user assistance about the portlet.

  • Edit mode provides a page for users to change the portlet settings. For example, a weather portlet might provide an edit page for users to specify their location. Users must be logged into the portal to access edit mode.

  • If Configure mode is supported by a portlet, it provides a page for portal administrators to configure portlet settings that are shared by all users.

Each portlet mode can be displayed in normal, maximized, or minimized state. When a portlet is maximized, it is displayed in the entire body of the portal page, replacing the view of other portlets. When a portlet is minimized, only the portlet title bar is displayed on the portal page.

1.3.2 Portlet applications

Portlets are more than simple views of existing Web content. A portlet is a complete application having multiple states and view modes, plus event and messaging capabilities.

Portlets run inside the portlet container of a portal server, similar to a servlet running on an application server. The portlet container provides a runtime environment in which portlets are instantiated, used, and finally destroyed. Portlets rely on the portal infrastructure to access user profile information, participate in window and action events, communicate with other portlets, access remote content, look up credentials, and to store persistent data.

Generally, portlets are administered more dynamically than servlets. For example, portlet applications consisting of several portlets can be installed or removed while the server is running, and administrators can change the settings and access rights of a portlet while the portal is running, even in a production environment.

1.3.3 Introduction to places

The flexible design of WebSphere Portal allows users to initiate diverse places organized around specific projects, issues, or groups. It provides access to a wide range of tools, such as instant messaging, discussion databases, people awareness, and other collaborative tools that support teams. Best of all, users can create and modify these places to best meet their needs, without involvement from IT personnel. The result? Greater efficiency and faster results from any team effort.

Portal content is organized on pages that can be grouped. A page group becomes a virtual place when a user organizes content selectively and grants permission for other portal users to use the place. Within portal places, people can find other people and the right information quickly, building better teams and stronger ties to each other.

Places:

  • Provide a new way to view, organize, and use portal resources, and are designed to improve communication, workflow, content management, and teamwork

  • Present people and information in context with organizational or community needs

  • Show links to individuals within places and portlets (people awareness)

  • Have portlets that launch collaborative applications (for example instant messaging, Lotus Notes)

In addition, portlets have the ability to interact with each other. This functionality allows you to present information in a new context, which can greatly improve the user experience.

Let's look at this functionality in more detail.

Portlet cooperation

The portal server provides a mechanism for portlets to communicate with each other, exchanging data or other messages. In a production portal, portlet communication could be used to copy common data between portlets. This saves redundant typing by the user and makes the portal easier to use. For example, one portlet might display information about accounts while a second portlet displays information about transactions that have occurred for one of the accounts over the last 30 days. To do this, the transactions portlet needs to obtain the corresponding account information when it displays the transaction details. This is accomplished by communication between the two portlets, using portlet actions and portlet messages. In this example, the account portlet creates a portlet action and encodes it into the URL that is rendered for displaying transactions. When the link is clicked, the action listener is called, which then sends a portlet message to send the necessary data.

Programmatic messaging helps unify portlet applications that access different back-end applications. However, this is relatively static, and requires planning and design work in advance. The portlets exchanging messages must already know about each other in order to make the interchange work. Next we discuss more flexible means of portlet cooperation.

Brokered cooperation

Brokered cooperation allows independently developed portlets to exchange information. Portlets register their intent to cooperate with a broker, which facilitates the exchanges at runtime. The broker works by matching data types between the sources in one portlet and the actions of another portlet. When the types match, an exchange is possible. Portlets that exchange data in response to a user action are called "Click to Action" portlets.

The objective of the Click to Action portlets is to increase the productivity of portal users working with multiple portlets by enabling them to send information easily from one portlet to another. For example, users can click on information that is displayed in one portlet and transfer that information to another portlet. The portlet receiving the information processes it and updates its display.

Click to Action automatically matches the portlet information sources and possible actions based on their data type compatibility. Click to Action does not rely on drag and drop or other non-standard browser features. A unique advantage of Click to Action is that is it designed to work in different browsers, making it more accessible to users.

In WebSphere Portal 4.2, Click to Action is limited to Portlets that reside on the same page.

Example of a place with portlet cooperation

Figure 1-7 is an example of a place that incorporates portlet cooperation.

click to expand
Figure 1-7: Example of a workplace with portlet cooperation

The example shows an HR workplace. In the upper left corner we have placed an employee directory. The other portlets show employee details (top right), skills (bottom left) and the projects (bottom right) the employee is currently working on. The skills and project information are coming from separate Domino databases. In previous times they were all developed and used separately. Now that we are moving to a workplace interface, we want to use the Portlet cooperation features to present the information in a new context.

If we search for an employee in the employee directory and click on the person entry we are looking for, we can have the other portlets react to our selection. The employee's detail information and skills, as well as the projects he is currently working on, will be shown in the other portlets. All this is triggered by a simple click on the employee link.

This example illustrates why portlet cooperation is a great concept that helps us to build new kind of applications, just by exposing old Domino applications inside the portal.

1.3.4 The portalizing process

Before we talk about portalizing, we first need to establish a common understanding of what this means.

Figure 1-8 presents a high-level outline of the overall portalizing process.

click to expand
Figure 1-8: From Domino applications to portlets and workplaces

On the left is a list of typical Domino applications. They need to be portalized into portlets, which can then be made available for different workplaces.

A Domino application can be represented by a single portlet, but there is usually not a one-to-one relationship between applications and portlets. Most cases exhibit a one-to-many relationship. Portal applications are usually made up of multiple portlets that use portlet cooperation. This way, application functionality exposed in portlets can be combined in many different ways, sometimes allowing the user to put information in a context that not even the developer of the individual portlet has thought about.

It is also important to understand that the same portlet can be used in different workplace contexts with different user roles.

1.3.5 The portalizing challenge

Looking at the portalizing process raises the following questions:

  • What portlet development techniques are available?

  • What is the effort required for portlet development?

  • What functionalities can be implemented within a portal?

  • How can scalability and performance be ensured?

In the following discussion we address these questions and describe the factors and dependencies of the portalization process.

Figure 1-9 illustrates the relevant factors.

click to expand
Figure 1-9: Factors and dependencies

As with any development project, there are multiple factors and dependencies that influence a portalizing project. The important parameters for a Domino portlet project are:

  • Domino application: the characteristics of the Domino application.

  • Integration techniques: knowledge of all the different options.

  • Domino portlet pattern: defines the portal integration depth and user interface requirements for the portlet. This is discussed in greater detail later in this chapter.

  • Considerations: overall project parameters like resources, skills, and so forth.

You need to develop a good understanding of the different factors and their dependencies to be able to successful portalize a Domino application into portlets. Therefore, in the following sections we drill down deeper into the various factors and dependencies.

1.3.6 Domino applications

The most important piece in the portalizing process is the Domino application itself.

You need to consider the following parameters to characterize the application:

  • Number of documents

  • Number of users, number of maximum users

  • Usage pattern, number of concurrent users

  • Application complexity

  • Single or multiple database application

  • Web-enabled or Notes client-based

Figure 1-10 on page 17 can help to characterize a given Domino application.

click to expand
Figure 1-10: Domino application types

It shows several Domino applications, with their database usage on the horizontal axis and the number of users on the vertical axis. The size of each bubble represents the database size, and the bar in the middle indicates the application complexity.

Placing a given Domino application into this grid can help to develop a better understanding of the usage scenario for a Domino portlet.

This then allows us to estimate the workload on the portal and Domino servers.

Another important consideration is that the portal introduces new usage scenarios for your applications. With a Notes Client a user usually accesses Domino applications sequentially, meaning one at a time. On a workplace there are multiple portlets active, which will concurrently access your applications. This increases the server load significantly. In addition, the portal will broaden the user community for your applications because they are more visible now.

All this can have severe implications on your Domino backend and performance.

Performance considerations

From our experience, we know that portlet performance is the most important factor in a Domino portlet development project.

Let's imagine the following example. We are going to build an employee directory. The portlet is specified to look like this:

click to expand
Figure 1-11: Example portlet "Employee Directory"

It has the following requirements:

  • Employee directory with 100,000 entries

    Initially the portlet shows the first 10 Employees of the A-name category. Users can page through the Employees like in a paper phone book, or search for an Employee by Name or Employee Number.

  • Portal user community of 40,000 users

    We assume a concurrency of 5% of the total portal user number for the workplace the portlet is placed on. That means we have approximately 2,000 concurrent users for the portlet.

Let's assume the following scenario:

The portlet is available on the portal home page for all users. Monday morning at 8 AM all employees are going to log on to the portal.

The interesting question now is: What is going to happen to the overall portal performance and server load?

Let's analyze: We are going to have 2,000 concurrent requests to display the initial view of the portlet. Creating 2,000 concurrent sessions to the Domino backend and rendering the first page for each user does not seem feasible.

If we planned for this scenario, we probably would have thought about caching strategies and overall session management for this use case. If not, this portlet can significantly decrease the overall portal performance and put a very high load on the Domino backend. Later in the book, we discuss caching strategies and session management in detail.

Note 

Portlet performance and scalability is often underestimated in Domino portlet development projects. It is good best practice to do performance testing right from the start of the project. Performance is not only dependant on your coding or the Domino backend, but also on the overall portal/Domino infrastructure.

1.3.7 Portlet patterns

Portlets can be as simple as data display windows into existing applications, or as advanced as a replacement for complex workflow applications. They also can have a different level of integration with the portal.

Portlet patterns will help you to classify what type of integration level you are looking for; this information is relevant when deciding what integration technique to use.

In this section we describe the following patterns:

  • Link

  • Display

  • Integrated

  • Migrated

As for any development project, it is best practice to establish use cases for the portlet usage. We need to ask:

  • What is the use case from a user's perspective?

  • Does the use case vary with the role of the user?

With this information we can then decide what portlet pattern our application falls into.

Link

The Link type is the easiest of all integration types. It provides the user with a link that launches into the native application. This can be either a Notes-based or a browser-based application. Depending on the setup of the authentication system, the user may need to log on to the specific application. The Notes client will challenge you for your password if you have not configured it to use your operating system login. If the application is browser-based and you did enable single sign-on (SSO), the re-authentication is not necessary.

A link type integration can be achieved by using, for example, the Bookmark Portlet or Quicklinks Portlet that ship with WebSphere Portal.

click to expand
Figure 1-12: Link type example

Display

In the display category are portlets that only display information from Domino. If the user needs to interact with the application functionality, they must launch either into the Notes Client or a Browser interface. This can be a good option if an application is already Web-enabled. In the portal we can give the user an overview of, for instance, all the expense reports that he needs to approve, and then for the approval process launch the expense report application in a new browser window. Depending on the implementation, it would be possible to launch immediately into the expense report that the user wants to approve.


Figure 1-13: Display type example

This example illustrates that it is not necessary to portalize the whole application to the portal. Sometimes a small view into the application might be enough.

Integrated

An integrated scenario lets the user perform tasks in other applications inside the portlet, rather than having to launch the other application.

In the previous scenario we could provide the user with a list of expense reports to approve, but to perform the approval task we had to launch into a different application. Launching into a separate application might not be a problem, but being able to perform the task inside of the portlet context enhances the user experience and the usability of the portlet.

In our example, we want to allow the user to approve or deny an expense report. In the denial case he should also be able to provide a reason.

For a different user role, we also want to allow the creation of new expense reports from within the portal. In these two use cases we have exposed only some of the functionality of the expense report application to the portal. Other workflow processing of the expenses and back-end integration with an HR system will remain untouched in the native Domino application.

This example shows the advantages of the coexistence of portlets and Domino Applications. Only the information and logic needed for certain use cases will be transferred into the portlet.

click to expand
Figure 1-14: Integrated type example

Migrated

A migrated portlet is one that is used to replace an application and transform entire business processes into portlets. Usually an approach like this would involve a redesign of the application.

1.3.8 Considerations for the portlet design

In this section we outline a few design issues that are important to consider the requirement gathering process for the two portlet patterns.

We want to try to reuse as much of the Domino application functionality and code as possible. The reusability will greatly depend on the architecture of the original Domino application. If it is a Web-enabled application the chances for reuse are much higher.

What can be reused?

Usually you can reuse:

  • Views

  • Agents

  • Forms

  • Field validations

The options for application reuse vary with the chosen integration technique, and are discussed in detail in the corresponding chapters.

Figure 1-15 shows a portlet user interface that we are using to illustrate some common requirements for a Domino Portlet.

click to expand
Figure 1-15: Elements of a Portlet

Layout and functional aspects

Key elements of the illustrated portlet are numbered, and have the following meanings:

  1. Layout definition for views and forms

  2. Retrieving and aggregating documents from multiple databases

    Let's imagine that we have a product manager. He works with lots of departments; for instance, Marketing, Sales, Research and Development. Over time all these different departments have built there own policy databases. To find a particular policy, our product manager has to look into every single database. In the portlet context we now want to consolidate all the different policy databases into one portlet.

  3. Edit-Mode: Implementing user personalization

    This can have two different aspects. Since a workplace is tailored for a specific user role, we want to deliver only the subset of information that is relevant for a particular user to do his or her work. In addition, we want to allow the user to set a filter to further refine the information that is delivered to them.

  4. Sametime integration

  5. Advanced layout (buttons, alternating line colors, and so forth)

  6. Search functionality

  7. Pagination

Additional functionalities that may be needed in your portlet include:

  • Categorization of data

  • Write access to enable editing of existing data or creation of new documents

  • Transactional handling, for example, calling Agents

  • Search - full text or field level

  • Rich Text Support for display and editing

  • Page flow between different input screens/workflow

  • Portlet cooperation

Considerations in choosing a portalizing type

Portlets can have view and form-like display, page flows (workflow), page navigation, read and write access, transactions (for example, using agents), and portlet cooperation.

Several levels of integration are possible. Each has a different degree of integration with the portal.

To decide on the portalizing type for a particular portlet, the answers to the following questions can be helpful:

  • What functionality do you want to include/expose?

  • What functionality do you need in the portlet?

  • Do users perform transactions?

  • Do you need simple write access to single fields or have complex forms with field validation?

  • Do you have a page flow within the application?

  • Is the portlet a replacement for a Domino application?

  • Is your Domino application Web-enabled?

  • Will the portlet be used to Web-enable an application?

  • Are you going to have one complex portlet or many task-oriented portlets?

It is a good practice to develop a clear understanding of the purpose and use case for a portlet before starting the development. Portlets are true applications, and therefore it is important to a have detailed requirements for the development. Using portlet patterns can help in the requirement gathering process, and to develop a common understanding with the business users.

Portlet patterns can be characterized as requirement definitions for portlets.

Portlet pattern examples

In this section we look at a few more examples for portlet patterns. We are going to start with simple ones and move forward to more complex portlets.

Display example: News portlet


Figure 1-16: News portlet

Portlet description:

  • The portlet displays news from a high-volume news database.

Portlet functionalities:

  • Displays data from one underlying Domino database.

  • Opens the content document in a new browser window.

Value for users:

  • The portlet will be a mass channel for combining internal news. As an enhancement, users can personalize which news categories they want to see.

Integrated example: New Documents

click to expand
Figure 1-17: New Documents portlet

Portlet description:

  • The portlet consolidates several enterprise knowledge databases based on Standard Document Library, Domino Doc, or Teamrooms. This is the key differentiation from the previous portlet. It adds the ability to select the view and a search option. Additionally, users have People awareness to get in touch with the author of the document.

Portlet functionalities:

  • Combines data from several Domino databases

    All databases have a different database structure, are not Web-enabled (only standard-view functionality is supported) and have high data volumes.

    Tools for merging the different Domino databases into one consolidated database are available, including the Lotus Enterprise Integrator® (LEI).

  • Searches inside of the consolidated database

  • Content is opened in a form-like layout embedded in the portlet

  • Form display also includes Rich Text fields

    Displaying Rich Text inside of a portlet requires special attention. This is covered in detail in a later chapter.

  • Allows the creation of new documents

  • Has integrated people awareness

Value:

  • Users never miss published documents again. All relevant information and documents will be available in one portlet.

Integrated example: Policies portlet with write access and transactions

click to expand
Figure 1-18: Portlet with personalization and form display

Portlet description:

  • The portlet displays the company's consolidated policy databases. Users have the option to select the policy categories they are interested in. The portlet also has a built-in search function. The individual policies are opened in a form-like display and are embedded inside of the portlet. Additionally, users have People awareness to get in touch with subject matter experts.

  • The HR staff can create and modify policies from within the portlet. The HR manager who is responsible to approve policies can perform the approval process from within the portlet.

Portlet functionalities:

  • The portlet has the same functionality as the previous example, plus:

    • Content creation and modification from within the Portlet

    • Integrated approval workflow for policies

Value:

  • Users never miss new or updated policies. Through personalization they only see the policies that are relevant to them.

  • For the HR staff it is very convenient to update and create new policies. The integrated approval workflow expedites policy publishing.

Summary

These are just a few examples that should help you to develop a general understanding of portlet patterns and how they can help in the requirements gathering process.

1.3.9 Considerations

There are a number of factors that have great influence on a project. Some of these are:

  • Time frame for the project and milestones

  • Available people and resources

  • Available or set products and versions

  • Target platform, such as AIX®, Win 2000, and so forth

  • Scalability and performance requirements

  • Experience and development skills

  • Portal/Domino infrastructure

Most conditions for a Domino integration project are not any different than for other software development projects. Therefore, you should apply the same project management and development methodology to a portalization project that you would use for other development project.

The Portal/Domino infrastructure

The Portal/Domino infrastructure is one condition that needs our special attention. It can have tremendous impact in a transformation project.

There are two aspects that are relevant in this context:

  • Server infrastructure

    Figure 1-19 shows the three portal/Domino infrastructure options that are used most often:

    • Single server configuration

      In this scenario the portal and Domino Server run on one machine. Databases from remote servers get replicated onto the local Domino server. This configuration is typical for the WebSphere Portal Express offering, as well as for Proof of Concept scenarios.

    • Domino hub configuration

      In this configuration the Domino and Portal servers are separate; a dedicated hub server is used for integration with the portal.

    • Distributed Domino configuration

      In this configuration all Domino servers hosting Domino applications are accessed directly from the portal.

    click to expand
    Figure 1-19: Portal/Domino Infrastructure options - D1, D2 and D3 represent Domino servers

    Looking at the different infrastructure scenarios can help us to identify and avoid bottlenecks in the infrastructure.

    Here are a few checkpoints from a Domino portlet point of view:

    • Local Domino access is faster than remote access, but limits the scalability to one physical server

    • Having a dedicated server to host the Domino applications for the portal makes the performance more predictable and scalable, but introducing a Domino cluster makes the programming more difficult. You then need to handle failover and load-balancing yourself. It is important to ensure a fast network connection between the Portal and Domino hub server.

    • Accessing multiple Domino servers helps with balancing the load, but you need to check whether the Domino servers can handle the extra load from the portlet. Depending on the access method you choose, you might have to load the HTTP and/or DIIOP task on the Domino server. Bandwidth constraints can also be problematic for portlet performance.

  • Single sign-on

    The portal server provides comprehensive single sign-on (SSO) support. Users want to be able to log on only once, and be known to the different parts of the portal server with the same consistent user credentials. Users should not be asked to do multiple logons simply because they access different portal applications.

    The portal server supports single sign-on realms using WebSphere Application Server as well as authentication proxies. This means that the user needs to log on only once to gain access to all enterprise applications that are installed within the single sign-on realm.

    With Domino there are two single sign-on options that you can use:

    • LTPA Token authentication

      This option requires that the WebSphere and Domino server are configured to share an LTPA session cookie. Using this method has the least impact on your portlet coding since the sign-on process is handled transparently for you.

      For configuration information refer to the Portal InfoCenter.

    • Active and passive credential vault

      In the case that, for example, the portal server and the Domino server use different directories or are in different DNS domains, it is necessary to handle authentication manually. You need to get the user credentials either out of the current portal session or out of a slot in the credential vault, and then use these user credentials for the authentication with the Domino server.

      For further information refer to the Portal InfoCenter.



 < Day Day Up > 



Portalizing Domino Applications for Websphere Portal
Portalizing Domino Applications for Websphere Portal
ISBN: 0738499811
EAN: 2147483647
Year: 2003
Pages: 103
Authors: IBM Redbooks

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net