Overview
With this stand-alone topology, requests from the Internet must first pass through a firewall to get into the internal network. In this case the firewall provides the basic protection of the internal network against intrusion and therefore acts as both a protocol and domain firewall.
The presentation logic of the application is provided by a single Web application server node. The business logic is implemented on the Web application server. User information, needed for authentication and authorization, is stored in the directory and security services node, also located behind the firewall in the internal network.
Stand-Alone Single Channel::Product mapping=z/OS
Design Last Updated: 2-25-2004
(Click a node to get a detailed explanation.)
By using a Web server redirector node, we can place the majority of the business logic in the internal network, placing it behind two firewalls. The redirector is implemented using the IBM HTTP Server and WebSphere Application Server Web server plug-in. The redirector serves static HTML pages and forwards requests for dynamic content to a WebSphere application server using the HTTP protocol.
With this Product mapping, you only need one logical partition on a z/OS server. Both presentation and business logic are executed on that system image. In this Product mapping, the system image is implemented with z/OS 1.4.
Since we are using a single system image, all nodes reside in the internal network. A single firewall is used to perform both the protocol and domain firewall functions. There is no DMZ represented. Since z/OS provides very effective program and hardware isolation, it is feasible to use the z/OS Firewall Technologies that come with z/OS either on the same system image, or on a separate system image.
The Web application server is required to provide both the Web server node functions and the application server node functions. The Web application server is implemented using IBM WebSphere Application Server for z/OS V5.0 and is configured with the HTTP Transport Handler.
The HTTP Transport Handler is lightweight HTTP management code that provides a significant performance advantage. The Transport Handler runs in the control region of the WebSphere application server instance, dispatching requests to the EJB containers that provide the Web application business logic. The performance comes at a price, however. Much of the traditional support found in Web servers (for instance, the ability to recognize different browsers) does not exist in the Transport Handler. This is because enterprises are relegating the traditional Web request handling to servers closer to the edge of the enterprise. Because the handler can expect that the customer request has been filtered by some other server, it does not need the extra code. In this case, the protocol firewall filters the requests to block malformed requests from reaching the Transport Handler.
Authentication and authorization in the z/OS environment are handled using Resource Access Control Facility (RACF®) or a combination of RACF and LDAP. For smaller environments, RACF alone is sufficient but with a large number of users, the combination of RACF and LDAP are recommended. At the application level, authorization is done using the J2EE security model (role mapping). WebSphere uses the WebSphere Trust Associator Interceptor (TAI) for policy definition and to perform lookups on the RACF.
In this Runtime pattern, scalability can be extended with the use of a sysplex configuration. Horizontal scalability can be achieved by using multiple application servers instances on up to 32 system images.
What's Next
Next, Review guidelines and related links or review another product mapping:
- Mappings featuring WebSphere Application Server V5.0
- Mappings featuring WebSphere Application Server V6.0
