Overview

This document discusses the various ways in which an iSeries customer might web-enable its 5250 applications. It is assumed that the initial requirement is for an Intranet solution, but we also discuss some possibilities related to Extranet or other externally accessed Web applications. First we will discuss Logicalis’ structured approach to Web application requirements, which aims to ensure that the right questions are asked when infrastructure and architecture solutions are being defined. We will then cover some proposed infrastructure and architecture solutions. Finally we will confirm how these proposals cover the various elements of the Logicalis structured approach.

Structured approach

Logicalis’ approach to defining a solution for any Web application requirement centres around six Web application elements, taking availability, performance, security and compliance into account throughout.

The diagram shows these application elements in green.

Client represents the browser interface, and any limitations (browser dependencies) that are being assumed;

Networking represents the path of the application through the Internet, and any network traffic and firewall security issues that may arise;

Web server represents the static HTTP server in use;

Web application server represents the software component(s) that may be present to handle any server-side processing that may be required by pages served by the HTTP server;

Connectors are the software components used to link the application server intelligently with production server(s) and their hosted applications and databases. This would assume the presence of established militarised and demilitarised zones (MZ and DMZ, shown in grey on the diagram), if (as in this case) this application is to be deployed to clients outside the organisation;

Database and application programs are the relevant back-end application systems and databases.

Network infrastructure components: the diagram also shows (in yellow) the network infrastructure components that allow the Web application to be supported securely through the establishment of militarised and demilitarised zones.

Availability: appropriate levels of redundancy (with clustering or failover as appropriate) need to be carefully considered for each component. It is also essential to allow for back-end overnight windows and other downtime (planned or unplanned).

Performance: the Web application needs to meet its response time objectives without unacceptably impacting system or network performance for existing users. Note that we must take into account the impact, especially on network performance, of any additional HA provision that may be required to meet the Web application’s availability objectives.

Security: the Web application must make use of best practice for both network and application security (note that the planned integration with credit card processing will almost certainly involve some level of security auditing by the relevant bank).

Compliance: we clearly need to take FSA, Data Protection and any other relevant compliance requirements into account.

Possible infrastructure and architecture

We would propose a structure as shown in the above diagram. Details of the relevant products are given in the next section.

For Intranet (e.g. call centre) application purposes the customer would need to deploy the Militarised Zone aspects only. An Intranet Web server and a Web application server will be required to serve up Web enabled applications accessed internally. These could reside on a dedicated iSeries or as an additional workload in an existing production iSeries, or could be deployed to another platform such as an xSeries running Windows or Linux.

If and when the customer wished to provide Extranet or other external access to its Web applications, an additional Web server would be required in the DMZ. This could be configured to communicate with the Web application server in the MZ.

The level of network traffic between the Web server(s) and the Web application server must be able to be controlled, as must the level of network traffic between the Web application server and the back end.

If high or unpredictable volumes of external traffic are expected, the performance impact of Web transactions on internal users must be kept under control. This is most easily achieved by keeping the Web application server outside the production iSeries partition. Operational issues, such as differing PTF level requirements, may also affect the choice of location for the Web application server.

Possible application elements

Client

Typical Web applications are written to work with the following browsers:

• Internet Explorer 5.0 and above
• Netscape Navigator 4.5 and above

Clients will typically need to be configured to accept session cookies to access the application. This is the default setting for the browsers above.

Networking

This document assumes a potential need for Intranet, Extranet and other external access to Web-enabled applications. Note that, should encryption (SSL or HTTPS) be required by an Extranet or other external access application, the HTTP server would be configured to handle this requirement, and the relevant firewalling would need to permit HTTPS as well as HTTP traffic to pass to the appropriate server(s).

Web Server and Web Application Server

The IBM HTTP Server (which is a packaging of, and is normally referred to as, Apache) will fulfil the function of Web server. It can run on any platform, including iSeries. It will use very little resource.

Note that, if the Web server were to be implemented on an iSeries platform, it would need to reside in a separate LPAR with no virtual LAN connectivity, to maintain an appropriate level of DMZ separation.

There are effectively four options for the Web application server:

• Apache Tomcat – free of charge, shipped with the iSeries HTTP Server licensed program (5722-DG1). Tomcat is the ‘reference implementation’ of the open J2EE standard. It would serve very well for a proof of concept. It is not as resilient, scalable, secure or easy to manage as any of the flavours of WebSphere, but it is free of charge and requires less hardware resources.
• WebSphere Application Server 6, Express edition, shipped free of charge with OS/400 V5R3. In WAS 6, unlike previous releases, the Express edition of WebSphere Application Server has support for Enterprise Java Beans.
• WebSphere Application Server 6, Base edition. The Base edition of WebSphere Application Server is more expensive and more complex to manage than the Express edition. An upgrade from Express to Base is available. There appears little benefit in deploying Base rather than Express on iSeries.
• Should clustering of WebSphere instances be required at any time, whether for high availability or for high traffic, the Network Deployment edition of WebSphere would be required. This involves multiple instances of the Base edition, with an additional Network Deployment server being deployed to manage them in a cluster. Again this can be reached via an upgrade.

Both Tomcat and all editions of WAS 6 fully support the J2EE standard for the deployment, running and management of Web applications using Java servlets, Java Server Pages and Web services. All editions of WAS 6 additionally support Enterprise Java Beans.

The Apache Web server communicates with WebSphere Application Server via a plugin shipped with WAS. The network impact of these connections is controlled by configurable concurrency limits within the plugin. The use of the pugin is shown in the following diagram:

Click here for information about connectors, database, application programs and integration options

Notes on availability and scalability

ISP connectivity, network security and DMZ infrastructure

To minimise the risk of downtime it is advisable to use two different ISPs.

It should be noted that changes to DNS entries can take up to 48 hours to be notified through the Internet. Effective failover from one site to another could be achieved, therefore, only if this were taken into account.

Web server and Web application server

For scalability and availability, load balancing and WebSphere clustering capability should be allowed for in the application architecture.

Load balancers, even if configured for ‘sticky sessions’, cannot be trusted to ensure that a client remains connected to a single Web application server throughout his/her session. This is because several ISPs, notably AOL and Wanadoo, use proxy mechanisms that can give the client a new IP address between one IP connection and the next. This is particularly troublesome where a mixture of HTTP and HTTPS is in use. The only effective solution to this is to use WebSphere clustering (involving deployment of the Network Deployment edition to cluster multiple Base edition instances).

Click here for reference examples