Architecting Portal Solutions: Applications Development

Chapter 1: Overview

Figure 1-1: Portal aspects

Figure 1-2: Horizontal portals infrastructure

Figure 1-3: Portal services

Figure 1-4: Portal layers

Figure 1-5: Product versus solution space

Figure 1-6: Iconic view of a custom design

Figure 1-7: Custom design with Self-Service, Information Aggregation, Access Integration, and Application Integration

Chapter 2: Portal Solutions

Figure 2-1: An example of a portal on a typical Web browser

Figure 2-2: Categories of portals and who uses them

Figure 2-3: Elements of a portal page

Figure 2-4: Depicts the context in which a portlet exists

Figure 2-5: The portal server extends an application server to support portal applications

Figure 2-6: Typical portal page request processing scenario

Figure 2-7: The most commonly reported IT priorities

Figure 2-8: Steps required to become an e-business on demand

Figure 2-9: The on demand enterprise

Chapter 3: A Recommended Approach to Architecting Portal Solutions

Figure 3-1: Work product dependencies

Figure 3-2: Portal composite pattern

Figure 3-3: Application patterns in the Portal composite pattern

Figure 3-4: e-Government characteristics and key initiatives

Figure 3-5: System Context Diagram for e-government

Figure 3-6: e-Government Use Case Model

Figure 3-7: Portal composite pattern generic use cases

Figure 3-8: Classifying delta use cases

Figure 3-9: The AOD (Subsystem) begins with a display of the major business functions

Figure 3-10: Architecture Overview Diagram (subsystem) after the Composite pattern is applied

Figure 3-11: The AOD (Subsystem) after Business patterns have been applied

Figure 3-12: AOD (Subsystem) after integration patterns have been applied

Figure 3-13: AOD (Subsystem) after the Composite pattern have been applied. Solid lines denote patterns which are not absorbed by the Composite pattern.

Figure 3-14: The AOD (Subsystem) after the chosen Composite pattern's Application patterns have been validated

Figure 3-15: Example of an AOD (Subsystem) that could be deceiving, leading you to select a Portal composite pattern instead of the Electronic Commerce composite pattern

Figure 3-16: AOD (Subsystem) after delta requirements have been highlighted

Figure 3-17: Illustration of the general problem addressed by the Extended Enterprise pattern

Figure 3-18: The five Extended Enterprise——Application patterns, highlighting the three that are applicable

Figure 3-19: Application patterns for delta requirements

Figure 3-20: The Portal composite pattern's Runtime pattern

Figure 3-21: The AOD (Logical Nodes) as seeded from the customized Portal composite pattern's Runtime pattern

Figure 3-22: Detail of the Exposed Business Services application pattern

Figure 3-23: Exposed Business Services application pattern—— Runtime pattern

Figure 3-24: AOD (logical nodes) after the Runtime patterns were updated for the delta "Assess Risk"

Figure 3-25: AOD (Logical Nodes) after all deltas have been addressed and the appropriate Runtime patterns incorporated

Figure 3-26: Mocked-up AOD (Logical Nodes) to be used in a technical walkthrough

Figure 3-27: e-government case study Component Model Relationship Diagram

Figure 3-28: e-government case study Component Interaction diagram—Scenario 1

Figure 3-29: e-government case study Component Interaction diagram—Scenario 2

Figure 3-30: e-government case study Component Interaction diagram—Scenario 3

Figure 3-31: e-government case study Component Interaction diagram—Scenario 4

Figure 3-32: Operational Model development process

Figure 3-33: AOD for the e-government case study

Figure 3-34: AOD for e-government case study with product mapping

Figure 3-35: e-government case study Operational Model

Figure 3-36: Operational Model with clustering

Figure 3-37: Where performance, scalability, and availability can be implemented

Figure 3-38: e-government case study Operational Model with high-availability NFR walkthrough

Chapter 4: Architecting on Demand Workplace Solutions

Figure 4-1: IFB system context diagram

Figure 4-2: IFB Use Case Model

Figure 4-3: Classifying IFB delta use cases

Figure 4-4: IFBs architecture overview diagram (subsystem)

Figure 4-5: AOD (subsystem) highlighting the coverage of the Portal composite pattern

Figure 4-6: Validating Application patterns for function subsystems included within the PCP

Figure 4-7: Business and Integration patterns for delta requirements

Figure 4-8: Application patterns shown in the AOD

Figure 4-9: AOD (logical nodes) seeded from the customized PCP runtime pattern

Figure 4-10: Adding Pervasive Device Access support

Figure 4-11: Adding integration server support

Figure 4-12: Final AOD (logical nodes) for IFB

Figure 4-13: Walkthrough for the Update Personnel Records use case

Figure 4-14: IFB component relationship diagram

Figure 4-15: IFB component interaction diagram—Update personnel information

Figure 4-16: IFB AOD with identified software services

Figure 4-17: IFB Operational Model

Figure 4-18: SSO walkthrough using Operational Model

Figure 4-19: ODW composite runtime pattern

Chapter 5: Galaxia and the on Demand Workplace

Figure 5-1: Vehicle development process

Figure 5-2: Change management processes

Figure 5-3: Typical IT infrastructure

Figure 5-4: Solution Overview Diagram

Figure 5-5: Apply business and integration patterns to the Solution Overview Diagram

Figure 5-6: Managed Process pattern

Figure 5-7: Customized Presentation to Host (U2B Topology 4)

Figure 5-8: Dynamic Workplace—Portal composite pattern variant

Figure 5-9: Galaxia solution—Runtime pattern

Figure 5-10: Galaxia product map

Figure 5-11: Scenario product mapping

Figure 5-12: Functional architecture

Figure 5-13: Dassault Systemes/IBM PLM architecture chart

Figure 5-14: Scenario overview

Figure 5-15: Scenario phases

Figure 5-16: Create an ECR

Figure 5-17: Change impact analysis—Engineering

Figure 5-18: Change impact analysis—Finance

Figure 5-19: Change impact analysis—Approval

Figure 5-20: EAI framework

Figure 5-21: Process templates for engineering

Figure 5-22: Work management template

Figure 5-23: Order Handling Process

Figure 5-24: Galaxia VPM Connector

Figure 5-25: ePCM architecture

Appendix A: E-Business on Demand

Figure A-1: A natural evolution

Figure A-2: Landmarks on the technology roadmap

Figure A-3: Open standards speed integration

Figure A-4: Comprehensive Linux support in IBM software

Figure A-5: Tivoli Identity Manager logical component architecture

Figure A-6: Tivoli Identity Manager Web User Interface subsystem

Figure A-7: Tivoli Identity Manager Application Interface module

Figure A-8: Tivoli Identity Manager Core Services subsystem

Figure A-9: Tivoli Identity Manager DSML connectivity

Figure A-10: Tivoli Identity Manager IBM Directory Integrator connectivity

Figure A-11: Weak Integration on the Application Web

Figure A-12: Improved integration on the service Web

Figure A-13: The new Web services economy

Figure A-14: How SOAP, WSDL, and UDDI are related

Figure A-15: The UDDI Business Registry Network

Figure A-16: WebSphere Studio desktop

Figure A-17: Web services for J2EE development flow

Figure A-18: Web services developer role

Figure A-19: Web services assembler role

Figure A-20: Web services deployer role

Figure A-21: Lifecycle of a servlet-based implementation bean

Figure A-22: Lifecycle of a session EJB

Figure A-23: Architecture of an IBM federated system

Figure A-24: Query planning for joins

Figure A-25: Compilation and runtime for non-relational sources

Figure A-26: Evolution of DBMS architecture

Figure A-27: Financial services scenario

Figure A-28: An information integration platform

Figure A-29: Components of self-managing systems

Figure A-30: The autonomic cycle

Figure A-31: The autonomic cycle

Figure A-32: Components of self-managing systems

Figure A-33: A typical process flow for incident management, problem management, and change management

Figure A-34: Structure of self-management technologies

Figure A-35: Self management within each level of the IT environment

Figure A-36: How an IT environment evolves towards a truly autonomic environment

Figure A-37: Five implementation levels for a self-configuring IT infrastructure

Figure A-38: Five implementation levels for self healing and availability management

Figure A-39: Five implementation levels for a self-optimizing IT infrastructure that can optimize workloads and transaction performance across multiple resources

Figure A-40: Five implementation levels for a self-protecting IT infrastructure

Appendix B: Using WebSphere Portal

Figure B-1: WebSphere Portal architecture

Figure B-2: A portal usage report from Web Site Analyzer

Figure B-3: The SAP portlet builder