The question "Why should I run WebSphere Application Server on my iSeries?" often comes up. This is an understandable question, but it's far more complex than it appears to be. It is really several questions. Why should I use WAS? Why should I use the iSeries? Even if I want to use WAS and the iSeries, why do I want to use them together? This gets even more complicated when you consider the different versions of WAS, the different iSeries models, and the different bundles of hardware and software. Many great white papers, Redbooks, and presentations answer parts of those questions.
In this article, I will give you a first look at why WAS makes good business and technical sense running on the iSeries. I'll give you an overview of WAS 5.0 and discuss the following topics:
- WebSphere Application Server (WAS) technologies
- WebSphere Application Server (WAS) on iSeries differences
- The business case for WebSphere Application Server (WAS) on iSeries
WebSphere Application Server (WAS) 5.0 Overview
WAS is IBM's offering based on the J2EE standard for application servers. Three versions of WAS are available on the iSeries platform. The first is WAS Express, a low-cost, entry-level version of WAS. The second, WAS Base, is a fully J2EE 1.3-compliant application server that includes Enterprise Java Beans (EJBs) and Java Messaging Service (JMS). The third, WAS Network Deploy, is a superset of Base functions. The major addition to the Base function is the Deployment Manager, which allows customers to run their applications in a scalable environment, potentially consisting of multiple servers and multiple physical nodes. These three products cover the range of partners on iSeries from small to large, and there is a wealth of great information on these products available on the Web. For information gathering, start here:
- WebSphere Application Server for iSeries: Related Resources
- WebSphere for the IBM eServer iSeries Server: Buying and Selling Guide (Redpaper)
WebSphere Application Server (WAS) Technologies
WAS incorporates many technologies. Below is a sample of these technologies, with a short description. J2EE encompasses most of these technologies. As newer versions of the J2EE standard are created, WAS will be enhanced to support these standards.
J2EE 1.3 EJB 2.0 Local Interfaces
In the EJB 2.0, standard local interfaces were introduced. This mechanism, defined in the EJB 2.0 specification, enables components in the same container to bypass Remote Method Invocation (RMI) and call each other's methods directly. In general, local interface calls are faster than traditional remote (RMI) calls. The use of local interfaces does limit the code because the Bean and client must run in the same container. EJB 2.0 offers both local and remote interfaces, but the choice is not transparent to the client and will be reflected in the client code.
J2EE 1.3 EJB 2.0 Container Managed Persistence (CMP)
In EJB 1.1, persistence data was defined by the Bean's instance variables. In EJB 2.0, it is up to the container to implement the concrete persistence model. The developer of the Bean need only define the accessor abstract method. With the new CMP, the underlying persistence store and the CMP Beans are independent of each other.
J2EE 1.3 Web Components
The two major components of J2EE Web Components are servlet 2.3 and JSP 1.2. New features available with servlet 2.3 include servlet filtering, application lifecycle listeners and events, enhanced internationalization support, and API changes. One of the major additions was servlet filters. All filters implement javax.filter.filter. Filters can be used to intercept a request before it reaches a servlet, modify the response after the servlet has processed the request and before the client receives the response, or send the response directly without sending to the next filter or the servlet. One major negative of using filters is that if any filter fails, the request is not completed. JSP 1.2's new and enhanced features include new classes for tag library validation, new tag support for iteration, tag library support for application lifecycle events, and tag library lifecycle enhancements. The most important change for the JSP1.2 spec is the ability to encode the JSP in pure XML format, so every tool that is capable of editing XML can now be used with JSPs.
J2EE 1.3 Message-Driven Beans (MDBs)
MDBs are a standard way to create a message receiver that is managed by the container. This allows the MDB writer to concentrate on processing and parsing the message. MDBs make it easier to separate message and business logic, allowing some other EJB to implement the business logic.
WAS 5.0 Java Message Service (JMS) Administration
WAS 4.0 JMS support requires the separate installation of a messaging product such as MQSeries. WAS 5.0 Base and Network Deploy ship with an embedded and integrated JMS provider.
Java Management Extensions (JMX)
JMX is a framework that provides a standard way of exposing Java resources to a systems management infrastructure. There are three main layers of JMX. The first, the instrumentation layer, defines how resources can be wrappered in Management Beans, a special type of JavaBean. The second is the agent layer, which implements event notification and monitoring. The third is the distributed services layer. It defines how external management applications can interact with the underlying layers.
Workload Management (WLM)
Workload management optimizes the distribution of client processing requests across multiple instances of WAS Network Deploy. WLM also provides failover when servers are not available. With WAS Network Deploy, WLM can be combined with clusters of application servers to provide a balanced high availability workload environment.
The many different levels of security in WAS--including Web components, WebSphere security, Java security, and platform security (OS/400)--have been enhanced in V5. New features in WAS 5.0 include J2EE 1.3 security compliance, Java 2 platform security, Java Authentication and Authorization Service (JAAS) programming model support (which provides a means for restricting the running of code based on authentication of the user), and support for CSLv2 security protocol (which provides interoperability between different solution providers' application servers). WebSphere Security Administration now supports multiple security roles and naming security with all security configuration handled by the administration console Security Center.
Enhanced performance was a major consideration in the development of the entire line of WAS 5.0. Two of the technical specifications that brought the most performance benefit are JDK 1.3.1 and EJB 2.0. Other enhancements for performance include dynamic cache improvements, new Performance Monitoring Infrastructure (PMI) features, and Tivoli Performance Viewer (not available in WAS Express). The release of WAS Express 5.0 tuned and priced for the small-to-medium business (SMB) market showed that WebSphere can scale down as well as up.
WebSphere Application Server on iSeries Differences
Before I discuss how WAS is different on iSeries, you should know that, in some ways, WAS on iSeries behaves just like WAS on all other platforms. Applications will function the same and are 100% portable, assuming that you do not have platform-specific code in your application. However, there are also some important distinctions. The following is just a subset of the differences between distributed-platform WAS and WAS for iSeries. Most of these differences are due to integration with OS/400.
Supported HTTP Servers
WAS 5.0 for iSeries supports two HTTP servers: IBM HTTP server for iSeries (Apache-based on 2.0.43) and Lotus Domino Web Server (V5 or higher, V6.0.2 or higher). The IBM HTTP server for iSeries is integrated into OS/400. You can access it by typing STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN) on your green-screen or by starting the job through iSeries Navigator and then going to http://:2001. As of October 2003, support for limited administration of Base instances will be added to the IBM HTTP Server administrative pages. It will have the same type of support as is offered for WAS Express today.
The iSeries offers iSeries-specific scripts for use with WAS based on the version. These can be accessed in the IFS through Qshell in the bin directory of the application server. Here are just a few of these scripts:
- Checkprereqs--The check prerequisites tool is used to validate that WAS for iSeries prereqs are met (available in group PTF for 5.0.2 and higher).
- Crtwasinst--The create WAS instance is roughly equivalent to wsinstance on distributed platforms.
- Dspwasinst--This script displays information about an instance, such as the ports used by the instance, type of instance, applications installed, state of server (started/stopped), etc.
Because of different install directories, WAS for iSeries can coexist with other editions and versions of WAS. Version 5.0 can coexist with all previous versions of WAS. Version 5.0 Base, Network Deploy, and Express can all coexist. This is accomplished by changing the ports used by the different application server. This topic is covered in the initial installation and configuration documentation.
There are several differences with the Java Virtual Machine (JVM) on the iSeries. First is the fact that the iSeries has its own JVM that was developed by the iSeries team. It is integrated into the low levels of OS/400, has enhanced garbage collection, and is based on Sun reference implementation. On the iSeries, Java code can be transformed from Java byte code to native executables called "Java executables" or "JVAPGM" objects. When transformed, an optimization level is specified. The values are 10, 20, 30, and 40 where 40 is the most optimized. Just In Time (JIT) can also be used. As Java matures, JIT performance is approaching that of Java executables. Like other platforms, WAS 5.0 requires JDK 1.3.1. The native start/stop code enforces this and will exit if the correct level is not installed.
For problem determination and debug, tracing has remained unchanged from the previous version. WebSphere Development Studio Client (WDSc) for iSeries debugger and tooling can be used with WAS for iSeries as can iSeries native debugger.
On the iSeries, WAS has unique software pricing. iSeries machines that are multiprocessor can take advantage of subcapacity pricing. Subcapacity pricing allows these products that are priced on a per-processor basis to be priced at less than the full capacity of the iSeries machine when logical partitioning (LPAR) is used.
IBM Telephone Directory Version 5.1 for iSeries ships with WAS Express Version 5.0 for iSeries. It is similar to IBM's internal Blue Pages application, which IBM employees use every day. This application is provided at no cost for up to 1,000 employee records as part of the effort to give out-of-the-box value for WAS Express Version 5.0
iSeries WAS Development
A final and very important difference for the iSeries version of WebSphere is WebSphere Development Studio Client for iSeries (WDSc). It is an enhanced development environment with additional functions and wizards just for the iSeries. There are two versions of this tool. The first is based off of WebSphere Studio Site Developer, and the more advanced version is based off of WebSphere Development Studio Application Developer.
Why WebSphere Application Server (WAS) Makes Good Sense on iSeries
I am sure you have heard the "Why iSeries?" argument before and the "Why WebSphere?" speech at least a few times. So why run WebSphere on iSeries? For the benefits of both, of course. The iSeries--unlike other systems--comes with fully integrated security at the object level and DB2 built into the operating system. It is part of OS/400, and its security meets U.S. Department of Defense C2 specifications. Here is something that cannot be said enough: No iSeries has ever been infected with a virus. iSeries hardware starts in the SMB market and can grow as big as your business needs require. Integration, security, reliability, and scalability are the combined reasons for WebSphere on iSeries.
WAS and iSeries are both points of current and future focus for IBM. They both fit into the SMB space that is so important to the industry today. The iSeries has been rebuilt and enhanced with new technologies as they emerge, producing an extremely reliable integrated platform that is a perfect fit for one of the latest technologies, WebSphere. Together, they can deliver for your business.
Michael Sandberg is a member of the IBM eServer Solutions Enablement team located in Rochester, Minnesota, and works to help IBM solution developers integrate new iSeries technologies into their programming environments. These technologies include WebSphere Application Server, WebSphere Portal, WebSphere Development Studio Client, Host Access Transformation Services, iSeries Access for Web, and IBM WebFacing Tool.