Access Integration Pattern Using IBM WebSphere Portal Server

Transcription

1 Front cover Access Integration Pattern Using IBM WebSphere Portal Server Introducing the Access Integration pattern Guidelines for building a portal application Implementation examples Michele Galic Johan Edling Chris Hisler Paul Holm Wesley King Santosh K M Nathan Levis Remy Tiffon ibm.com/redbooks

2

3 International Technical Support Organization Access Integration Pattern Using IBM WebSphere Portal Server November 2001 SG

4 Take Note! Before using this information and the product it supports, be sure to read the general information in Special notices on page 341. First Edition (November 2001) This edition applies to WebSphere Portal Server Version1.2 for use with Windows NT. Comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. HZ8 Building 662 P.O. Box Research Triangle Park, NC When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. Copyright International Business Machines Corporation All rights reserved. Note to U.S Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

5 Contents Preface ix The team that wrote this redbook ix IBM trademarks xii Comments welcome xii Chapter 1. Introduction to Patterns for e-business How to use the Patterns for e-business Choosing a Business pattern Choosing an Application pattern Choosing a Runtime pattern Choosing a product mapping Applying the guidelines Chapter 2. Introduction to products The big picture Products used in this redbook WebSphere Portal Server WebSphere Personalization Server IBM WebSphere Application Server IBM WebSphere Studio IBM VisualAge for Java Other IBM products WebSphere Site Analyzer IBM WebSphere Translation Server IBM WebSphere Transcoding Publisher IBM WebSphere Voice Server IBM WebSphere Everyplace Suite Tivoli SecureWay Policy Director IBM WebSphere Edge Server IBM Content Manager IBM Enterprise Information Portal IBM offerings WebSphere Portal Family offerings WebSphere Everyplace Access offering WebSphere Translation offering Conclusion Part 1. Access Integration Pattern Copyright IBM Corp iii

6 Chapter 3. Introduction to Access Integration patterns Access Integration services Presentation Personalization Security and Administration Pervasive Device Support Chapter 4. Application patterns Application patterns for Access Integration Pervasive Device Access pattern Single Sign-On application pattern Web Single Sign-On application pattern Extended Single Sign-On application pattern Personalized Delivery application pattern Application patterns used in this book Chapter 5. Runtime patterns Runtime nodes Single sign-on runtime patterns Web Single Sign-On runtime patterns Extended Single Sign-On Runtime patterns Personalized Delivery runtime patterns Participatory personalization runtime Predictive personalization runtime Prescriptive pesonalization runtime Combining Access Integration services Combination Runtime pattern variation Combination Runtime pattern variation Combination Runtime pattern variation Part 2. Access Integration pattern: guidelines Chapter 6. Application design guidelines e-business application design Application elements Access Integration guidelines Application structure Model View Controller MVC and portal extended for multiple clients Extending Web applications to portal applications Personalization and portal guidelines Converting an existing application to a portal application WebSphere Portal Server guidelines Portal API iv Access Integration Pattern Using IBM WebSphere Portal Server

7 6.7 Single Sign-On with Portal Server Single Sign-On guidelines Other high-level design considerations Technical walkthrough example Conclusion Where to find more information Chapter 7. Application development guidelines Application development overview The development environment Development tools WebSphere Studio configuration for portlet development Portlet development with personalization configuration VisualAge for Java Configuration for portlet development WebSphere Portal development guidelines Performance guidelines Portal development Portlet development process Using PortletData for customizing portlets Using persistence capabilities with PortletData Single Sign-On with Portal Server Personalization development Rules, actions, and classifiers Personalizing portlets Chapter 8. System management guidelines Managing your Portal and Personalization Servers WebSphere Application Server WebSphere Personalization Resource Console WebSphere Portal Server Web site availability and content analysis Trace and log files WebSphere security WebSphere security with Portal install Where to find more information Part 3. Access Integration Pattern: scenario Chapter 9. yourco Toys Identifying the Patterns Portal composite pattern Selecting the Business pattern Choosing an Access Integration application pattern Selecting the Runtime pattern Contents v

8 9.2 How the example works Changing existing Webapp to Portal Creating a project Steps to create a new project Setting up the publishing server Changing the portal server look and feel Loading the preexisting archive Setting up for the look and feel project Changing look and feel files Sales Application example Products example Opening the existing archive file Opening the personalization archive Copying files from the personalization project Creating JSP pages for the portlets Creating the portlets Publishing projects in WebSphere Studio Domino example Access Application example Accessing user information Developing the code AccessApp example Chapter 10. Product installation instructions Development environment Development Server Verifying the development installation Development client Verifying the installation Production environment Machine C: Database server Machine D: Web server Machine F: LDAP server Machine E: Application server Post-installation for Portal Server in the production environment Machine G: Web Analytical Where to find more Information: Related publications IBM Redbooks Other resources vi Access Integration Pattern Using IBM WebSphere Portal Server

9 Referenced Web sites How to get IBM Redbooks IBM Redbooks collections Special notices Index Contents vii

10 viii Access Integration Pattern Using IBM WebSphere Portal Server

11 Preface The Patterns for e-business are a group of proven, reusable assets that can speed the process of developing applications. The Access Integration pattern is an emerging pattern that describes the services and components commonly required to provide users with consistent, seamless, device-independent access to relevant applications and information. This redbook provides an example and guidelines for the Access Integration pattern. It shows how the pattern works and documents the tasks required to build an example of it. Part 1 of the redbook guides you through the process of choosing an application and runtime pattern to deliver the desired functionality of the Access Integration pattern. Part 2 provides a set of guidelines for building your portal application and includes a discussion of application design, application development and systems management. Part 3 demonstrates how to portalize an existing application and develop personalized portlets. The sample uses LDAP for external authentication and WebSphere Security for authorization. The introduction to the Access Integration pattern in this redbook will be structured along the same format as the Self-Service pattern introduction found at the Patterns Web site: and will also provide the updates for this Web site. The team that wrote this redbook This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Raleigh Center. Michele Galic is a WebSphere Specialist at the International Technical Support Organization, Raleigh Center. Her focus is on the WebSphere family of products and Patterns for e-business. She has 13 years of experience in the IT field. She holds a degree in Information Systems. Before joining the ITSO, she was a Senior IT Specialist in IBM Global Services in the Northeast, specializing in the WebSphere field. Copyright IBM Corp ix

12 Johan Edling is an Advisory IT Specialist in Sweden. He has four years of experience in the Web application field. He holds a Masters degree in Electrical Engineering from Chalmers University of Technology in Gothenburg. His areas of expertise include Web application and Java development. He has written extensively about WebSphere Portal Server and WebSphere Personalization development. Chris Hisler is an IT Architect in the Architecture Center of Excellence National practice from the U.S. He has nine years of experience in high-volume systems design and development. He holds a degree in Information Systems from Virginia Tech. His areas of expertise include architecture evaluation, design and development, application servers, configuration management, and software design. Paul Holm is a Senior Technical Consultant for PlanetJ Corporation in San Diego, CA. He has over 12 years of experience in application development. Before starting his own business, PlanetJ, in 1999, he worked for IBM in Rochester, MN. for 10 years. He holds a degree in Computer Science from the University of Minnesota. His areas of expertise include Java, Object-Oriented Programming, VisualAge for Java, WebSphere and Internet development. He teaches IBM classes on AS/400, Java and WebSphere. Wesley King is a Java Consultant working for PlanetJ Corporation out of San Diego, CA. He obtained a degree in Computer Science from Saint Mary s University of Winona, Minnesota in His areas of expertise include Java, servlets, JSPs, JavaScript, HTML, AS/400, VisualAge for Java, and WebSphere. Santosh K M is an e-business analyst working for Ontrack Solutions Pvt Ltd in Mumbai (India). He has one and a half years of experience with WebSphere Application Server and WebSphere Commerce Suite. He received his Master s degree in Computer Software Applications from Bombay (India). His areas of expertise include Java servlets, EJB and JSP. He has also worked on an ERP system. Nathan Levis is a Java Consultant and VisualAge Specialist in San Diego, CA. He has three years of experience in the Java field. He holds a degree in Computer Science from Iowa State University. His areas of expertise include Java, VisualAge for Java and IBM WebSphere. Remy Tiffon is an IT Architect in Bordeaux, France. He has 16 years of experience in IBM with eight years in the field. He holds a Master s degree in Microelectronics from a Component Integration Laboratory in Bordeaux University. His areas of expertise include Web application architecture, design and development on IBM WebSphere Application Server, WebSphere Portal x Access Integration Pattern Using IBM WebSphere Portal Server

13 Server, Lotus Domino and Interwoven Teamsite. Before joining IBM Business Innovation Services, he was an IT specialist in IBM Microelectronics in Corbeil-Essonnes, France, specializing in chips test program development in C++. Thanks to the following people for their contributions to this project: Margaret Ticknor International Technical Support Organization, Raleigh Center Jeanne Tucker International Technical Support Organization, Raleigh Center Carla Sadtler International Technical Support Organization, Raleigh Center John Medicke IBM Raleigh Mike Ferro IBM Endicott Carol Jones IBM Raleigh Skyler Thomas IBM Raleigh Preface xi

14 IBM trademarks The following terms are trademarks of the International Business Machines Corporation in the United States and/or other countries: e (logo) IBM AS/400 BookMaster CICS DB2 DB2 Universal Database DirectTalk Everyplace Illustra ImagePlus IMS MQSeries OS/390 Perform Planet Tivoli Redbooks Redbooks Logo S/390 SecureWay SP ViaVoice VisualAge WebSphere Lotus Lotus Notes Notes Domino Comments welcome Your comments are important to us! We want our IBM Redbooks to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at: ibm.com/redbooks Send your comments in an Internet note to: redbook@us.ibm.com Mail your comments to the address on page ii. xii Access Integration Pattern Using IBM WebSphere Portal Server

15 1 Chapter 1. Introduction to Patterns for e-business The job of an IT architect is to evaluate business problems and to develop a solution. The architect begins by gathering input on the problem, the desired solution, and any special considerations or requirements that need to be factored in. The architect takes this input and designs a solution that includes one or more applications that provide the necessary functions. It is to our advantage to capture the experience of these IT architects in such a way that future engagements are made simpler. Taking this experience and crafting a repository that provides a way for architects to use this experience to build future solutions using proven scenarios saves time and money for everyone and helps ensure a solid solution that will stand the test of time. The IBM Patterns for e-business effort does just this. Its purpose is to capture e-business approaches that have been tested and proven. The information captured is thought to fit the majority of situations. By making these approaches available and classifying them into useful categories, we save the e-business planners, architects, and developers both time and money. Copyright IBM Corp

16 These approaches are further refined into useful, tangible guidelines. The patterns and their associated guidelines allow the architect to start with a problem and a vision, find a conceptual pattern that fits this vision, define the necessary functional pieces that the application will need to succeed, and then actually build the application using coding techniques outlined in the guidelines. The highest level of patterns defines the possible business interactions required in the solution. The business function will typically fall into one or more of these defined Business patterns. 1.1 How to use the Patterns for e-business The Patterns for e-business are structured in such a way that each level of detail builds on the last. At the highest level are Business patterns, which describe the entities involved in the e-business solution. A Business pattern describes the relationship between the users, the business organization or applications, and the data to be accessed. There are four primary Business patterns: Self-Service pattern, formerly known as the User-to-Business pattern, which describes situations where users are interacting with a business application to view or update data. Collaboration pattern, formerly known as the User-to-User pattern, which describes the interaction between users. This would included and workflow processes. Information Aggregation pattern, formerly known as the User-to-Data pattern, which describes situations where users access and manipulate large amounts of data collected from multiple sources. Extended Enterprise pattern, formerly known as the Business-to-Business pattern, which describes the programmatic interaction between two distinct businesses. It would be very convenient if all problems fit nicely into these four categories, but in reality things are often more complicated. The patterns assume that all problems, when broken down into their most basic components will fit one of these patterns. When a problem describes multiple objectives that fit into multiple business patterns, the Patterns for e-business provide the solution in the form of Integration patterns. 2 Access Integration Pattern Using IBM WebSphere Portal Server

17 Integration patterns allow us to tie together multiple Business patterns to solve a problem. The Integration patterns include: Access Integration pattern, which provides the front-end integration of multiple services and information through a common portal. It is responsible for handling multiple client device types, single sign-on and personalization, and for providing a common look and feel to the application interfaces. Application Integration pattern, which provides for the seamless back-end integration of multiple applications and data without direct access by the user. When the same combination of Business and Integration patterns has been identified in the marketplace, we refer to the combination as a Composite pattern. Several common uses of Business and Integration patterns have been identified and formalized into Composite patterns: Account Access Electronic Commerce Portal Buy-side Hub Sell-side Hub Trading Exchange The makeup of these patterns is variable in that there will be basic patterns present for each type, but the Composite pattern can easily be extended to meet additional criteria. Visually, we can view the patterns as shown in Figure 1-1. This figure can represent a custom design in a particular installation or a common Composite pattern. These patterns are discussed in more detail further on. Access Integration Self-Service C o lla b o ra tio n Inform ation Aggregation Extended Enterprise Application Integration Figure 1-1 Business and Integration patterns Chapter 1. Introduction to Patterns for e-business 3

18 Once the Business pattern is identified, the next step is to define the high-level logical components that make up the solution and how these components interact. This is known as the Application pattern. A Business pattern will usually have multiple Application patterns identified that describe the possible logical components and their interactions. For example, an Application pattern may have logical components that describe a presentation tier for interacting with users, a Web application tier, and a back-end application tier. The Application pattern is further refined and broken down into one or more Runtime patterns. Runtime patterns define functional nodes representing middleware functions that must be performed. The Application pattern exists as an abstract representation of high-level functions, whereas the Runtime pattern is a more concrete representation of the functions that must be performed, the network structure to be used, and the systems management features, such as load balancing and security. Once a Runtime pattern has been identified, the next logical step is to determine the actual product and platform to use for each node. The Patterns for e-business have Runtime Product mappings that correlate to Runtime patterns, describing actual products that have been used to build an e-business solution for this situation. Finally, guidelines assist you in creating the application using best practices that have been identified through experience. 4 Access Integration Pattern Using IBM WebSphere Portal Server

19 Composite Patterns Business & Integration Patterns Application Patterns Runtime Patterns Product Mappings Best Practice Guidelines Application Design Application Development Systems Management Technology Choices Performance Figure 1-2 Patterns for e-business components We will look at each of these steps in more detail Choosing a Business pattern When faced with the challenge of designing a solution for a business problem, the first step is to take a high-level view of the goals you are trying to achieve. A proposed business scenario should be described and each element should be matched to an appropriate Business pattern. You may find that the total solution will require one or more Business patterns. For example, suppose an insurance company wants to reduce the amount of time and money spent on call centers that handle customer inquiries. By allowing customers to view their policy information and to request changes online, the company will be able to cut back significantly on the resources spent handling this data by phone. The objective is to allow policy holders to view their policy information stored in legacy databases. Chapter 1. Introduction to Patterns for e-business 5

20 The Self-Service business pattern fits this scenario perfectly. It is meant to be used in situations where users need direct access to business applications and data Choosing an Application pattern Application patterns break the application down into the most basic conceptual components, identifying the goal of the application. In our example, the application falls into the Self-Service business pattern and the goal is to build a simple application that allows users to access back-end information. The Directly Integrated Single Channel application pattern shown in Figure 1-3 fulfills this requirement: Pres. Presentation synchronous App. Web Application synch/ asynch Back-end Application 2 Back-end Application 1 Read / Write data Application node containing new or modified components Application node containing existing components with no need for modification or which cannot be changed Figure 1-3 Self -Service Directly Integrated Single Channel application pattern The Application pattern consists of a presentation tier that handles the request/response to the user. The Web application tier represents the component that handles access to the back-end applications and data. The multiple application boxes on the right represent the back-end applications that contain the business data. The type of communication is specified as synchronous (one request/one response, then the next request/response) or asynchronous (multiple requests and responses intermixed). Suppose that the situation is a little more complicated than that. Let us say that the automobile policies and the homeowner s policies are kept in two separate and dissimilar databases. The user request would actually need data from multiple, disparate back-end systems. In this case, there is a need to break the request down into multiple requests (that is, to decompose the request) to be 6 Access Integration Pattern Using IBM WebSphere Portal Server

21 sent to the two different back-end databases, then to gather the information sent back from the requests and put it into the form of a response (recompose it). In this case, the following Decomposition application pattern would be more appropriate. Pres. Presentation synchronous Decomp/ Recomp synch/ asynch Back-end Application 2 Back-end Application 1 Application node containing new or modified components Transient data - Work in progress - Cached committed data - Staged data (data replication flow) Application node containing existing components with no need for modification or which cannot be changed Read / Write data Figure 1-4 Self-Service:Decomposition application pattern This Application pattern extends the idea of the application node that accesses the back-end data by adding decomposition and recomposition capabilities Choosing a Runtime pattern The Application pattern can be further defined into more explicit functions to be performed. Each function is associated with a runtime node. In reality, these functions, or nodes, can exist on separate physical machines or may co-exist on the same machine. In the Runtime pattern, this is not relevant. The focus is on the logical nodes required and their placement in the overall network structure. As an example, let us assume that our customer has determined that his/her solution fits into the Self-Service business pattern and that Application pattern 1 is the most descriptive of the situation. The next step is to determine the Runtime pattern that is most appropriate for his/her situation. The customer knows that he will have users on the Internet accessing his/her business data and will therefore require a measure of security. Security can be implemented at various layers of the application, but the first line of defense is almost always one or more firewalls that define who and what can cross the physical network boundaries into the company network. Chapter 1. Introduction to Patterns for e-business 7

22 The functional nodes required to implement the application and security measures must also be determined. The following Runtime pattern is one option. Outside world Demilitarized Zone (DMZ) Internal network Public Key Infrastructure Directory and Security Services Domain Name Server User I N T E R N E T Protocol Firewall Web Application Server Domain Firewall Database Application Pattern 1 Presentation Application Figure 1-5 Self-Service runtime pattern By overlaying the Application pattern on the Runtime pattern, you can see the roles that each functional node will fulfill in the application. The presentation and application tiers will be implemented with a Web application server, which combines the functions of an HTTP server and an application server. It handles both static and dynamic Web pages. Application security is handled by the Web application server through the use of a common central directory and security services node. A characteristic that makes this Runtime pattern different from others is the placement of the Web application server between the two firewalls. The following Runtime pattern is a variation on this. It splits the Web application server into two functional nodes by separating the HTTP server function from the application server. The HTTP server (Web server redirector) will serve static Web pages and redirect other requests to the application server. It moves the application server function behind the second firewall, adding further security. 8 Access Integration Pattern Using IBM WebSphere Portal Server

23 Outside world Demilitarized Zone (DMZ) Internal network Public Key Infrastructure Directory and Security Services Domain Name Server User I N T E R N E T Protocol Firewall Web Server Redirector Domain Firewall Application Server Database Application Pattern 1 Presentation Application Figure 1-6 Self-Service runtime pattern variation These are just two examples of the possible Runtime patterns available. Each Application pattern will have one or more Runtime patterns defined. These can be modified to suit the customers needs. For example, the customers may want to add a load balancing function Choosing a product mapping The last step in defining the network structure for the application is to correlate real products with one or more runtime nodes. The patterns Web site will show each Runtime pattern with products that have been tested in that capacity. The product mappings are oriented toward a particular platform, though more likely, the customer will have a variety of platforms involved in the network. In this case, it is simply a matter of mixing and matching. For example, the runtime variation above could be implemented using the product set depicted in Figure 1-7 on page 10. Chapter 1. Introduction to Patterns for e-business 9

24 Outside world Public Key Infrastructure Demilitarized Zone (DMZ) Windows NT 4.0 SecureWay Firewall 4.1 Internal network Directory and security services Domain Name Server User Node I N T E R N E T Protocol Firewall Web Application Server Domain Firewall Windows NT SP6a SecureWay Directory DB2 UDB 6.1 (Fixpack 4) Database Windows 2000 DB2 UDB fp1 Windows 2000 WebSphere App Serv 4.0 JDK DB2 UDB fp 2a IBM HTTP Server Figure 1-7 Product mapping Applying the guidelines The Application patterns, Runtime patterns, and Runtime Product mappings are intended to guide you in defining the application requirements and the network layout. The actual application development has not been addressed yet. The patterns Web site provides guidelines for each Application pattern that include techniques for developing, implementing, and managing the application. Design guidelines instruct you on tips and techniques for designing the applications. Development guidelines take you through the process of building the application, from the requirements phase all the way through the testing and rollout phases. System management guidelines address the day-to-day operational concerns, including security, backup and recovery, application management, etc. Performance guidelines give information on how to improve application and system performance. 10 Access Integration Pattern Using IBM WebSphere Portal Server

25 2 Chapter 2. Introduction to products The IBM WebSphere product family covers a wide set of products. We can find any solution to different IT demands within the WebSphere family products. This chapter introduces the products that we used in this redbook as well as products from the WebSphere product family that can be implemented to extend the solution that we illustrate. This chapter is broken down as follows: The big picture Products used in this redbook Other IBM products IBM offerings For more information about the WebSphere product family, please refer to the IBM Web site at Copyright IBM Corp

26 2.1 The big picture When implementing a personalized portal solution, it is important to understand what the relationship is to the content, personalization, content management systems, and portals, as shown in Figure 2-1. The products used to implement the solution should complement each other. Web Content Management is about Web-based contribution of Web content Preparing content for use with W eb applications Content Management is about storing and preparing content Gathering/Unifying/Federating content Managing the storage (HSM) Locating content for update and use Preparing content for use/repurposing access Portals are about access to information Content Dynamic content Applications and application output Personalization is about Targ eting content to individuals Figure 2-1 The big picture: personalization, portals and content management Content Without content, there is nothing to personalize. Content is the information on your Web site that makes it worthwhile to visit. The IBM WebSphere Portal and Personalization product retrieves content for a specific user or a group of users. Content also includes user profile information. The IBM SecureWay Directory product provides an industry-standard directory implementation using the Lightweight Directory Access Protocol (LDAP) to store user profile information. 12 Access Integration Pattern Using IBM WebSphere Portal Server

27 Personalization Personalization is about targeting Web content and applications to specific users. Personalization ensures that the most relevant information is delivered to the user, enabling a more productive interactive experience and encouraging user loyalty. Personalization can be extended by gathering and storing information about site visitors, analyzing the information, and, based on the analysis, delivering the right information to each visitor at the right time. Content management Content management products provide methods for preparing, storing and displaying content on the Web site. Some examples of content management products are Lotus Domino, IBM Content Manager, and Interwoven Teamsite. Portals Portals provide a secure single point of access to diverse information and applications, personalized to the needs of the users. How and where does WebSphere Portal and Personalization fit within a Web site or e-business solution? Figure 2-2 on page 14 displays how WebSphere Portal and Personalization fits within the IBM WebSphere software platform for e-business. Chapter 2. Introduction to products 13

28 Process Automation B2E B2B B2C e-markets WebSphere Commerce Suite Lotus Domino MQSeries Workflow WebSphere B2B Integrator WebSphere Homepage Builder VisualAge for Java VisualAge Application Rules WebSphere Studio WebSphere Business Components VisualAge Generator WebSphere Transcoding Publisher WebSphere Voice Server WebSphere Portal Server WebSphere Everyplace Suite WebSphere Personalization Web Content Management WebSphere Site Analyzer WebSphere Edge Server MQSeries Integrator Tivoli Policy Director WebSphere Host Integration WebSphere Application Servers MQSeries Figure 2-2 WebSphere software platform for e-business The WebSphere software platform for e-business helps enable WebSphere Portal and Personalization Server to provide an open and extensible framework to build enterprise, marketplace, consumer and workspace portals accessible from a wide variety of desktop and mobile devices. Having extended the new portal architecture with these features suddenly makes the architecture more powerful. We will discuss this new architecture in the following chapters. 14 Access Integration Pattern Using IBM WebSphere Portal Server

29 2.2 Products used in this redbook WebSphere Portal Server The IBM WebSphere Portal allows companies to build their own custom portal Web site to serve the needs of employees, business partners and customers. Users can sign on to the portal and receive personalized Web pages providing access to the information, people and applications they need. This personalized single point of access to all necessary resources reduces information overload, accelerates productivity, and increases Web site usage. WebSphere Portal Server allows you to: Build multiple types of portals on a single integrated infrastructure based on the WebSphere Portal Architecture. Provide a scalable, single point of access for data, people, and applications. Deliver an easy to use graphical interface suitable for both occasional and expert users. Crawl and categorize intranet and Internet repositories. Execute a federated search against all forms of data, structured and unstructured. Aggregate and summarize information content for users. Customize the look and content of home page displays by user. Build rules-based and collaborative filtering personalization. Integrate applications and workflow systems into the portal. Add collaborative services such as , shared places, and instant messaging. Add pervasive wireless device support for remote and mobile users. Provide multiple levels of security and authentication services. Leverage syndicated information from over 50,000 databases for news and research. Add modules from Independent Software Vendors or custom developed modules. Leverage Web site tools for JSP page building, performance monitoring, caching, etc. Build next generation Web sites with standards such as XML, SOAP, CORBA, and LDAP. Manage users as individuals or within groups. Access control at the portlet level. Access Lotus and Microsoft Office applications via portlets. Use WebSphere Personalization as an integrated component. Implement a distributed, heterogeneous search across disparate data sources. Use a flexible architecture that enables integration with your current directory, database, and security infrastructure. Chapter 2. Introduction to products 15

30 Figure 2-3 gives a high level overview of the WebSphere Portal Server architecture: Figure 2-3 WebSphere Portal Server architecture The demands for a consistent, seamless, device-independent access to relevant applications and information are increasing and the WebSphere Portal Server, with its open framework, allows other technologies to plug in to this framework. Overview The main purpose of a portal is to provide a user with a single point of access to multiple types of information. A portal aggregates information in a way preferred by the user, regardless of the location or format of that information. In addition, a portal can be made accessible from multiple types of devices, such as a Web browser on a personal computer, or a microbrowser on a mobile phone. To that end, the WebSphere Portal Server provides the following: A flexible framework and infrastructure Support for multiple data formats and different devices User enrollment, authentication, and authorization 16 Access Integration Pattern Using IBM WebSphere Portal Server

31 Portal page customization Personalization Support for portlet installation Samples, plug-ins, and common portal features such as a search feature The portal infrastructure helps create, integrate, manage, and personalize information and applications for specific portals that cater to the needs and interests of a particular user or group. WebSphere Portal runtime process flow After installation, the portal developer develops and deploys a portal to users. The developer alters the layout and appearance of the default portal page by selecting a theme or skins that WebSphere Portal Server provides, or by creating a page layout that matches a corporate standard. A portlet programmer writes and registers additional portlets by using the portlet API provided with WebSphere Portal Server. The portlet API provides services that the portlet can use to obtain content, access user-specific configuration information, and format and display the information. After the portal recognizes user data, a user can log on to the portal. If a user attempts a logon, the incoming request passes through an authentication layer that provides controlled access to the portal. If the logon is authenticated, a single sign-on component stores user information for later use by other programs that require authentication, and user information is placed in a data store, such as an LDAP directory or a relational database. Based on the user information, the portal framework retrieves the portal page layout and customization data from storage. WebSphere Portal Server processes the layout by generating markup for the portal page and rendering the portlets that are accessible to the user. We will examine this framework in more detail in the following section. The portal engine WebSphere Portal Server provides a pure Java portal engine, which runs on many hardware platforms. In Figure 2-4, the portal engine s main responsibility is to aggregate content from different sources and to serve the assembled content to multiple devices. Because each content area (or portlet) is developed and maintained as a discrete component, the task of supporting multiple devices is made much easier. In effect, the presentation details of the portlets are decoupled from those of the overall page. In front of the portal engine is an authentication component such as standard WebSphere security or a third-party authentication proxy server. Chapter 2. Introduction to products 17

32 1 Trust Association Interceptor Portlet Engine Access Control 3 Full Page 4 View Authentication Server Portal Servlet Aggregation Modules Portlets 2 Page Customizer Portal Registry Services User Bean LDAP Directory Relational Database Management System Figure 2-4 Portal engine The central component in the portal engine is the portal servlet. It examines the URL and header fields of each request and invokes the appropriate handler. The request is handled in two phases. In the first phase, the servlet generates portlet events and sends these events to one or more portlets. In the second phase, the appropriate aggregation module for the users s device renders multiple portlets in a single page. Access to portlets is controlled by checking access rights during page aggregation and page customization. Currently, WebSphere Portal Server has three aggregation modules, as can be seen in Figure 2-5. The HTML aggregation component produces pages for desktop computers and other devices with HTML browsers. The WML aggregation component produces WML content for WAP devices, which are typically mobile phones. The i-mode aggregation component produces chtml markup for mobile devices in the NTT DoCoMo network. 18 Access Integration Pattern Using IBM WebSphere Portal Server

33 Aggregation Modules Desktop Browser HTML PDA WML Portlets Content and Applications Mobile Phone chtml Access Control Figure 2-5 Page content aggregation In future releases, IBM will provide additional aggregation components, including a voice aggregation module for devices with Voice XML browsers and a PDA aggregation module for Personal Digital Assistant devices. Each user can customize a unique home page for each device, selecting the content and applications that are most useful on the device. When the home page is requested, page aggregation works by first detecting the type of device that is making the request, and then assembling the portlets, each of which renders its contents in the appropriate markup language. Constructing the home page The structure of the page and its navigation areas is defined in page template files, using Java Server Pages markup. The arrangement and the look of these areas can be changed easily, so it is possible to make the portal pages reflect your company s unique style or brand image. Cascading style sheets, images, and other visual elements are used to further define the look of the page. Using these techniques, the contents of the navigation areas are determined by the portal site developer. When building the body of the page where the portlets are displayed, WebSphere Portal Server uses page layout templates, which are also based on Java Server Pages. Chapter 2. Introduction to products 19

34 The process to aggregate a page works like this: When the aggregation module is invoked, it obtains the page layout information for the current page of the current user. The page layout information is parsed and generates a tree with nodes referencing rows, columns, portlet decoration elements, and finally the actual portlets. TopNav.jsp LeftNav.jsp control.jsp portlet column.jsp page.jsp control.jsp control.jsp portlet portlet column.jsp control.jsp portlet Figure 2-6 JSP-based aggregation As you can see in Figure 2-6, just as the page layout and navigation areas can be changed easily, so can the JSP row, column, and decoration templates. This makes it easy to change the look and feel of all aspects of the portal. Membership management WebSphere Portal Server provides Web pages that allow users to enroll at the portal and self-manage their own preferences and account information. Alternatively, enterprises can integrate the portal with existing user directories, and may choose to disable the self-enrollment pages. WebSphere Portal Server provides connectivity between the portal and information in various user directories. 20 Access Integration Pattern Using IBM WebSphere Portal Server

35 User-specific data: The user name, user ID, and password are stored in a lightweight directory access protocol (LDAP). The Java Naming and Directory Interface (JNDI) enables read/write interoperability between WebSphere Portal Server and the LDAP directory. By default, the LDAP directory stores user-specific data as entries that are associated with the inetorgperson schema. Portal-specific data: The home page settings and portlet settings are stored in a relational database management system (RDBMS). WebSphere Portal Server supports IBM DB2 and Oracle 8 i. WebSphere Portal Server provides a Java bean interface for accessing user information. The User bean acts as an interface to a stateless session EJB, which, in turn, acts as a consolidation interface to multiple back-end EJB classes, each responsible for retrieving a portion of the user data. Chapter 2. Introduction to products 21

36 1 User or User-Group Self-Care Enrollment Enrollment Pages Enrollment Pages Pages WebSphere Portal Server User Bean Enterprise JavaBean Read/Write Read/Write 2 3 LDAP Directory Relational Database Management System Figure 2-7 User profile Figure 2-7 on page 22 illustrates the following: The user and group self-care interface begins with the portal s enrollment pages. These pages can be modified to collect additional attributes or to allow the user to specify group membership information. The User bean class calls the backing EJB to store or retrieve the basic user information (such as name or city) in the LDAP directory. 22 Access Integration Pattern Using IBM WebSphere Portal Server

37 The bean also calls another EJB to store or retrieve the portal-specific settings for the user, such as the user s list of portlets and their settings. The EJB implementation classes can be exchanged transparently, so that third-party LDAP servers, alternate schemas, and other external data stores can be easily integrated into the portal s user management system. Each customer can replace the implementation classes to match where their data is stored. Many companies already have databases that contain user data; WebSphere Portal Server enables the federation of user data from multiple, existing repositories. In this scenario, you may access user data in a read-only LDAP directory and then store additional user data in relational database tables. Most intranet type applications will use this scenario, where users are already defined and there is no need to add users on a regular basis. Group management: The user bean class also gives access to group information. Users may be classified into one or more groups. Group membership information is stored in the LDAP, and the group names are defined using the LDAP directory s administration interface. Delegate administration of users is through the LDAP administration interface. Access control permissions are assigned through a policy specification portlet interface (or through the administration interface of a third party authorization server, if applicable). The portal server protects access to portlets, and the backing LDAP server protects access to users and groups. Portal security overview A portal will provide access to many different applications, often at many different sites. Access to these applications must be transparent and seamless without compromising security. Because portals must support access from both inside and outside the firewall, the usual set of security services are required: virtual private networks, intrusion detection, Secure Sockets Layer (SSL), Public Key Infrastructure (PKI), etc. A key portal requirement is single sign-on, in which a user logs on once to gain access to all portal resources. Another key portal requirement is access management that supports filtration of access based on user profiles and an organization's content access policies. Because many different applications are made accessible to many different users or user groups in an almost real-time manner, access management must be role-based and hierarchical. For example, a person who assumes a new managerial role must have instant access to a set of applications derived from updated profile information. Chapter 2. Introduction to products 23