Websphere Portal on Z/OS

1.5 Physical architectures

Since the different components required in a portal installation can exist separately or be co-located, there are various physical architectures that can be implemented. The driving factors would be cost, and Quality of Service (QoS). Quality of Service is further defined by availability, security, maintainability, reliability, and service levels.

WebSphere Portal Server requires WebSphere Application Server and is configured like any other J2EE Server on zSeries with a Control Region and one or more Server Regions. Personalization server, WebSphere Portal Transcoding Publisher, and WebSphere Portal Content Publishing Runtime are the other software components that get added to the WebSphere Portal server J2EE application.

1.5.1 Two-tier physical architecture

With portal server acting as the presentation layer, the two-tier architecture is rather easy to set up. Figure 1-5 shows the architecture containing one Control Region (CR) and a Server Region (SR). Client portal requests arrive at the HTTP Transport Handler (HTH) and are passed on to WebSphere Portal server. If needed the backend application tier is accessed and the results returned to the Web browser.

Figure 1-5: Basic two-tier configuration

We do not recommend that you use the LDAP server instance that is used by WebSphere Application Server. Instead, create another instance of the base LDAP server for the Portal server, because of potential issues with access contention. Even though the LDAP server can exist anywhere on the z/OS and OS/390 system, we recommend that it reside on the same image as the WebSphere Portal server.

For a description of the rest of the usual z/OS and OS/390 components, refer to e-business Cookbook for z/OS: Technology Introduction, SG24-5664.

The z/OS and OS/390 platforms come with Workload Manager (WLM) giving you inherent workload distribution and load balancing. Figure 1-6 on page 9 shows how WLM could start up Server Regions either via a parameter during setup or on its own based on system load. This architecture starts to address scalability but not high availability.

Figure 1-6: Two-tier architecture with scalability

Chapter 2, "Portal installation" on page 19 discusses how multiple Server Regions were created with the same Control Region in our test environment. In our simple test the WLM facility was able to serve 100 plus concurrent users with a good response characteristics using a WebSphere Workload Simulator. Certainly this small test did not replicate any production customer scenario.

1.5.2 Three-tier physical architecture

In many cases, the a WebSphere J2EE application is used to access existing data on a production z/OS system. The middle-tier could have WebSphere Application Server on a z/OS or non-z/OS system. If a z/OS system is used for both the middle tier and the back-end tier, and they are both in the same parallel sysplex, then the benefits include better security and higher Quality of Service. A sample three-tier architecture is shown in Figure 1-7 on page 10.

Figure 1-7: Sample three-tier architecture

As far as WebSphere Portal is concerned there is really not much difference between the two-tier and three-tier architectures, because everything required by WebSphere Portal is found on tier one and tier two. WebSphere Application Server repository has to exist on the same system. Only production-related database and other back-ends would be in the third-tier. Custom portlets accessing those third-tier back-end systems would be used within WebSphere Portal server to get information to the portal user.