Preparation of Papers for IEEE TRANSACTIONS (Revised May 2003) s1
AUTHOR: TITLE odd page 3
Portal Technology Feasibility Study
Jonathan J. Ferry, Christopher Helmeset, Gregory J. McGraw and Jonathan M. Peffer
Abstract — The goal of this paper is to provide an overview of the RIT / Excellus Senior Design Project: Portal Technology Feasibility Study. This project aims to address key areas of concern for a proposed Portal-based presentation layer in Excellus’s anticipated new information system, jTIGRESS.
Index Terms— Distributed/Internet based software engineering tools and techniques, Maintainability, Software engineering for Internet projects, Software process models
—————————— u ——————————
1 Introduction
Ferry, Helmeset, McGraw, Peffer: Portal Technology Feasibility Study odd page 4
E
XCELLUS BlueCross BlueShield, headquartered in Rochester, NY, is part of a $4 billion family of companies that finance and deliver health care services across upstate New York and long-term care insurance nationwide.
Currently, Excellus employs over 450 customer service representatives who are responsible for handling approximately 30,000 thousand calls a day from some of its 2.1 million subscribers. All representatives operate on computers equipped with TIGRESS, a Visual Basic 6 (VB6) application developed by Excellus, to retrieve customer information and manage subscriber transactions. The current application has adequate functionality and excellent performance, however with their growing customer base and increasingly distributed centers of operation, the limitations of the technology in terms of maintainability, extensibility and reusability are becoming apparent. The proposed plan for replacing TIGRESS is an architecture based on JAVA/J2EE technology, with an expressed interest in an IBM WebSphere Portal-based solution. This new application, jTIGRESS, could be used internally for claims processing, membership and billing functions, customer service, and externally via the Web for self-service to Excellus subscribers.
The goal of the RIT and Excellus senior design partnership is to research and provide answers to a group of questions regarding the capabilities and limitations of IBM WebSphere Portal technology. This research will influence the design of jTIGRESS.
2 Project Objectives
The objective of our project was to explore specific aspects of the technology that were of particular interest and concern to Excellus. Our requirements, which were more in the nature of objectives, were to research the following areas of Portal-based technology and assess their suitability for meeting Excellus needs: Interface design, Application Design, Portlet Families, and general WebSphere capabilities and limitations. Each objective is prioritized and explained in further detail below:
1. The design that Excellus has in mind for jTIGRESS includes extensive use of communicating Portlets for dynamically updating views in other Portlets whenever users perform operations. Hence our first and most critical objective was to determine the feasibility of inter-Portlet communication, particularly two-way communication rather than merely a control hierarchy. The objective also included understanding the different schemes available for communication and limitations, if any.
2. Excellus customer service representatives use multiple systems to retrieve customer data, and must sign on to each separately. To alleviate this, we researched the Enterprise-Wide authentication capabilities of WebSphere Portal, particularly its Single Sign-On (SSO) features and interoperability with Lightweight Directory Access Protocol (LDAP) authentication.
3. Excellus has multiple departments with distinct but overlapping needs, including customer service, billing, and claims processing. Since they require customized views of the same data, our research on the design of families of Portlets concerned the ability of a Portal-based solution to leverage interface and logic reuse, including the constraints / limitations, capabilities, and effort to develop. The Excellus concern in this area is to avoid redundant logic among different application areas.
4. Interface design explores the extent to which Portal interfaces can emulate the look and feel of popular PC interfaces, to minimize the user training required. In addition there was a focus on the capabilities and limitations of customization and personalization. Excellus would like to generate different user interfaces based on the roles and characteristics of the specific users.
In addition to the research conducted in these general areas, there was significant concern regarding possible performance issues that may arise from a web-based solution. However, given the differences between our environment and the Excellus operational environment and the limited resources available, it was mutually agreed that this was out of scope for our project. We were given a broad charter to look out for any additional issues that might impact Excellus’ use of the technology, or other capabilities that they might possibly find to be useful.
3 Research and Development Process
The process for the RIT Excellus Portal Technology Feasibility Study consisted of two ten week phases using an Agile approach. The following is a high level description of the process.
3.1 Phase 1 (Winter Quarter)
The goal of phase one was to familiarize ourselves with WebSphere technology and discover the basic feasibility of Portlet inter-communication. The activities during these ten weeks included obtaining and setting up the WebSphere development environment, understanding Portlet technology and demonstrating the feasibility of inter-Portlet communication. Research consisted of two concurrent threads: Portal research focused on acquiring a comprehensive understanding of the JAVA Portal JSR168 standard, while IBM WebSphere research related to the server and development environments that were used in prototyping. This initial research resulted in the development of documentation for each subject, which guided the design of the initial prototype. This prototype was a proof-of-concept of Portlets using IBM WebSphere Portal technology and of the feasibility of inter-Portlet communication.
During this phase, we met with our faculty mentor and the customer liaison periodically, to provide progress updates and obtain feedback. Regular weekly reports were also produced to keep the customers informed of directions, progress and any issues encountered. The most important metric during phase one was the time required to ramp-up on Portal technology. This data will be useful to Excellus in their project planning. Our overall project effort and cycle-time were also tracked.
Fig. 3.1.1. Phase 1 Process
3.2 Phase 2 (Spring Quarter)
Phase two of the process involved a heavily feedback driven Agile process based on the prototyping lifecycle model. An initial set of objectives (requirements) provided by the customer were used to guide the design of the prototype which was followed by implementation. After the prototype was implemented, it was then reviewed against the objectives (success criteria) and delivered to Excellus for further review and feedback along with documentation on our findings (both high level and technical) through the iteration. The feedback from Excellus on the prototype and documentation was used to revise (mostly augment) the objectives for the next iteration. This process continued throughout the 10 weeks of phase two until the initial project objectives were met, giving Excellus answers to their questions on Portal technology. All deliverables were inspected by the team, and document deliverables were also reviewed by our faculty mentor.
Measurements for phase two included time taken to research each objective and lines of code per Portlet application. These metrics will be used by Excellus when planning their Portal based jTIGRESS solution and the resources required for development.
Fig. 3.2.1. Phase 2 Process
4 Planning
The initial plan for phase one consisted of three major task milestones: software/hardware installation and configuration, research, and prototype development. Unfortunately, software/hardware installation and configuration activities ran behind the initially scheduled time due to technical difficulties. This latency did not affect research activities, as the team was able to begin such tasks while concurrently troubleshooting software/hardware installations and configurations. Key deliverables for phase one include the preliminary technology feasibility report and initial proof-of-concept prototype (including source code). These were simultaneously delivered on time on February 15, 2004.
The initial plan for phase two was to have three bi-weekly iteration milestones. During the first week it became apparent that the lengthy elicitation process caused the first iteration to be pushed back a week, thus pushing back all other iterations. After the plan was rescheduled, the new milestones were completed on schedule. Phase two deliverables include the finalized technology feasibility report, which is an expanded version of the preliminary technology feasibility report, the final prototype (including source code), and a findings workshop for the Excellus engineers and architects. These are on schedule and to be delivered May 20, 2004.
5 Research Results
Given the aforementioned objectives, we were able to guide our research towards the following aspects of Portlet and WebSphere technology: Inter-Portlet communication, Single Sign-On (SSO), Customization and Personalization, and Lightweight Directory Access Protocol (LDAP) support within WebSphere.
5.1 Inter-Portlet Communication
Essentially, there are four different types of Portlets:
· Portlets that do not communicate with other Portlets
· source Portlets - Portlets that only send information to other Portlets (explicitly or by broadcast)
· target Portlets – Portlets that only receive information and update themselves based on other Portlets
· source and target Portlets – Portlets that both send and receive data
Implementing a combination of source and target Portlets in a Portlet application provides data transfer capabilities between Portlets. Thus, clients interact with the Portlets via a web browser, which sends information to the server. The server then passes messages between the Portlets, which updates the client’s browser. One important caveat that we found was message passing is only supported within pages. To keep persistent data across multiple pages, data must be stored in a data object, and when the user switches between pages, the Portlets on the new page must read information from the data object. Portal provides a set of predefined data objects with different lifetimes for data persistence. These data objects exist on the server-side, hence the client must retrieve the data from the server when switching between pages. While this may not be a significant limitation, it is a constraint to be considered when designing Portlet based applications.
WebSphere provides further Inter-Portlet communication methods through WebSphere Click-to-Action (C2A) Portlets, and extensions such as People Service. C2A Portlets, also referred to as Cooperative Portlets, provide communication between Portlets based on a set of defined rules. People Service provides predefined capabilities such as awareness of users who are logged into the system. Our exploration of these technologies was limited, but they appear interesting enough to warrant further exploration.
5.2 Single Sign-On (SSO)
SSO technology provides the capability for a user to authenticate only once while gaining access to multiple secure applications. WebSphere provides two models of authentication, Web SSO and Extended SSO.
With Web SSO the user logs in to one application, which then generates authentication tokens for the other applications with the aid of some LTPA authentication proxy. This follows the centralized authentication model (once authenticated to the first application you are authenticated to all). Unfortunately, this requires modifying all the other applications so that they are capable of accepting these authentication tokens. Further, this scheme is only applicable to homogenous environments where all applications are in the same security domain and accept identical authentication tokens.
Extended SSO is where the credentials for users to access different systems are stored in a credential vault. Once the user is logged into the Portlet, the Portlet can then retrieve credentials from the vault that are necessary to access the back end application. The credential vault can store credentials that are secret at the individual Portlet level, shared among different Portlets for a single user, or shared across all users. The sharing of credentials across all users is system level authentication, rather than user level authentication. The credential vault facilitates storage and retrieval of credentials, however establishing and managing the credentials must still be done by the system administrator for each user and each application, hence this model does not reduce administrative overhead. On the contrary, setting up this model is an added complex task that involves possibly modifying the applications which require SSO access.
Fig. 5.2.1. Credential Vault
Extended SSO is most likely the preferable solution for Excellus as they possess a heterogeneous system. Also it is our understanding that the applications to be accessed may be running in different cities and may reside in different security domains.
If desired, the system-level authentication capabilities can be designed to eliminate managing separate credentials for the different users. However, this may result in the loss of the ability to track access patterns by individual users. Further, if some of the data returned by the back end application is to be restricted only to particular roles or users, others must be restricted from accessing those specific Portlets.
Fig. 5.2.2. Extended SSO Central Authentication Service
The functionality of SSO technology was found to be best suited for environments that permit secure access through a defined mechanism, such as, but not limited to, HTTP Authentication. Environments that require the manual entry of authenticating credentials, although supported, must be implemented by developers according to the SSO specification, rather than being able to take advantage of the support provided by WebSphere SSO setup wizards.
5.3 Customization and Personalization
WebSphere’s Customization and Personalization features are capable of handling both the Interface Design and Family of Portlets objectives. Customization provides the capability of supporting multiple user configurations, such as Internet Explorer and Netscape, as well as supporting localization. Interface design to provide any desired look-and-feel is accomplished by configuring Themes and Skins for Pages and Portlets, respectively.
Themes allow a Website designer to provide an overall visual consistency and navigational structure, banner, colors and fonts, Portlet skins, and other visual elements. This is accomplished by creating JSP files, style sheets, and images. Every theme must define a default skin to associate with the Portlets displayed. Through the use of Themes, we feel that Excellus will be able to provide external and internal users with any desired look and feel, including that of typical Windows applications.