Websphere Portal on Z/OS

1.6 Our architecture

During this redbook project we set up two architectures. Our initial architecture was simple to enable the installation efforts. Later we switched on other components to get closer to real customer environments.

1.6.1 Our initial architecture

For this redbook, we started by keeping things simple and used the two-tier architecture with a single WebSphere Application Server Control Region (CR) and one Portal Server Region (SR). We also felt that, in the early stages of deployment and test, this would be the most common option for implementation by IBM customers. The architecture shown in Figure 1-8 on page 11 does not explicitly address scalability, but during the WebSphere Portal installation there is a parameter that controls the number of Server Regions to create. We left that parameter to unlimited, giving WLM the ability to generate Server Regions if the need arose. Therefore, the second SR and WebSphere Portal server are shown in the figure but are not highlighted in bold.

Figure 1-8: Our initial WebSphere Portal architecture

Installation summary

WebSphere Portal Server was installed by creating another J2EE server on WebSphere Application Server on z/OS or OS/390. Then the administrative portlets were installed. After verifying that portal server was up and running the additional portal components, namely WebSphere Transcoding Publisher (WTP), WebSphere Portal Content Publishing (WPCP) Publisher runtime, and Personalization, were added. The Personalization component actually gets installed as part of WPCP.

Figure 1-9 on page 12 gives you a glimpse inside WebSphere Portal Server. Therefore, whenever we show or discuss the WebSphere Portal Server it implies that it also contains WTP, WPCP, and the administrative portlets.

Figure 1-9: Inside WebSphere Portal on z/OS and OS/390

1.6.2 Our preferred architecture

In the architecture as shown in Figure 1-8 on page 11 the incoming HTTP request is handled by the HTTP Transport Handler (HTH) via port 8082. This is one of the ways of testing browser access into WebSphere. We do not recommend this in a production environment, because you are directly allowing access to a port in WebSphere Application Server's Control Region.

The preferred way to handle portal access is by having an IBM HTTP Server on the z/OS and OS/390 machine that is accessible to clients via port 80. The IBM HTTP Server HTTP plug-in then sends the request across to the HTTP Transport Handler that is listening on port 8082. We set this up and tested the portal functionality for our environment. Figure 1-10 on page 13 shows the recommended architecture.

Figure 1-10: Our preferred architecture

1.6.3 Our overall environment

Table 1-1 lists the major software products and release levels that we used. You will find a detailed description of all the software components that were used in Chapter 2, "Portal installation" on page 19.

Our test environment was set up in this manner:

• On the zSeries system, running z/OS V1.3, we installed the main portal components - WebSphere Portal server, WebSphere Portal Content Publishing Runtime Server, WebSphere Transcoding Publisher, and Administrative portlets. Note, our system already had a DB2 database server, native LDAP server, and WebSphere Application Server. For portal purposes we created another instance of the LDAP server which is shown as two LDAP boxes in Figure 1-11 on page 15.

  Figure 1-11: Our WebSphere Portal environment

• On a PC, running Windows 2000 SP2®, we installed a Web browser and the Authortime component of WebSphere Portal Content Publishing.

• On another PC, running Windows 2000 SP2, the development tooling was installed, that is, WebSphere Studio Application Developer V4.1 with plug-ins for the Portal Toolkit and WPCP wizards.

For detailed information on our installation and setup refer to Chapter 2, "Portal installation" on page 19 and Chapter 3, "Development environment installation" on page 93.

The Portal environment on zSeries lends itself well to best practices or application patterns that make up the Portal Composite Pattern. These Application Patterns are:

• Access Integration::Web Single Sign-On Application Pattern

• Access Integration::Pervasive Device Access Application Pattern

• Access Integration::Personalized Delivery Application Pattern

• Self Service::Directly Integrated Single Channel Application Pattern

These and other patterns are detailed in the redbook A Portal Composite Pattern Using WebSphere V4.1, SG24-6869.