IBM's WebSphere product employs all the latest technologies to allow you to easily build and manage host-based Internet applications. This article describes those technologies and details how you can use WebSphere in your e-commerce strategy.
Editor’s Note: This article was previously published in the February/ issue of AS/400 NetJava Expert.
Applications designed for the Web have generated a whole new set of technologies. Servlets, JavaServer Pages (JSP), and Enterprise JavaBeans (EJB) are at the heart of WebSphere, which is IBM’s solution for Web-based applications. In this article, I will explain the technologies used in Web-based applications and how WebSphere supports them.
What Is an Application Server?
Everywhere you look, application servers are cropping up. Numerous products with various functionality are using the application server label. So, what is an application server? Unfortunately, it is not yet well-defined, but, as the application server market matures, a set of expected features will emerge.
An application server manages the second tier of a three-tiered model. In this model, the first tier is the client device or user interface presentation (usually a PC with a browser), the second tier contains the business logic, and the third tier is the data stores (usually a database). The purpose of the application server is to make the development, deployment, and management of the tier-two elements easier.
Application servers are especially useful in more complex environments with requirements such as transactions and distributed computing. They provide services such as component management, messaging, and transaction services, and will be often used in heterogeneous settings where legacy and Web applications must coexist. These various functions are often called middleware. Scalability and performance must be assumed.
Today’s application servers generally (or soon will) support one of two competing architectures: EJB from Sun Microsystems or Component Object Model (COM) from
Microsoft. Products that have used CORBA (Common Object Request Broker Architecture) from the Object Management Group (OMG) will generally move to include support for EJB. Obviously, Microsoft Transaction Server uses COM. The new application servers will use new technologies to help to bring robust, mission-critical applications that require transactions and distributed capabilities to small and midsize servers. Application servers for mainframes will use the facilities that have existed for some time (such as IBM’s TXSeries and Component Broker).
What Is WebSphere?
WebSphere is a brand name for a set of IBM software products that enables the building, deploying, and managing of Web applications (Internet or intranet). These products help implement IBM’s Network Computing Framework (NCF) for e-business. (NCF is an architecture, or a description of APIs, protocols, services, and conventions, that defines a powerful standards-based environment for distributed or Web applications. If you are not familiar with NCF, see the references list at www.midrangecomputing. com/anje/99/01 for sources of further information.) WebSphere is or will be available for NT, AIX, Solaris, OS/400, OS/390, and OS/2. WebSphere is built on open industry standards and technologies (e.g., HTTP and IIOP [Internet Inter-ORB Protocol]). WebSphere consists of many pieces, each of which is a pluggable component. This means users can choose to use IBM’s functions or plug in another product. (Generally, plug-in components must have some special plug-in code to integrate with WebSphere, so the number of actual choices for plug-ins at this time is limited. The interfaces between the components are defined by NCF.) WebSphere is the successor of ServletExpress, a servlet engine. This section will explain WebSphere in general terms; WebSphere for AS/400 differences are highlighted in the next section.
Figure 1 provides a look at WebSphere’s three main parts:
1. WebSphere Studio is a set of PC-based tools for building Web applications targeting WebSphere Application Server. WebSphere Studio simplifies the job of building applications that integrate various technologies such as HTML, EJB, JSP, and servlets. The tools aid in development, testing, versioning, and team dynamics. WebSphere Studio includes VisualAge for Java (Professional Edition), NetObjects Fusion, NetObjects BeanBuilder, NetObjects ScriptBuilder, and various wizards.
2. WebSphere Performance Pack is a set of tools for resource monitoring, filtering, load management, caching, and replication. WebSphere Performance Pack increases performance and availability via tools for configuration and runtime monitoring. WebSphere Performance Pack includes WebTraffic Express, NetDispatcher, Nagano caching and Andrew File System (AFS). WebTraffic Express supplies proxy caching. NetDispatcher is a front-end tool that distributes HTTP requests among HTTP servers. Nagano caching provides dynamic caching. AFS, a distributed file system, is also included.
3. WebSphere Application Server is the heart of WebSphere; this is where applications are run. Think of the application server as sitting between the HTTP server and the data stores (usually a database). The HTTP server handles simple requests and routes complex requests requiring more processing to the application server. The application server handles these requests, which generally involves some processing by the server itself as well as running some Java code provided by developers. During this processing, the back-end data stores may be accessed to retrieve or update data. The result is sent back to the HTTP server (in the form of HTML), which is then displayed to the browser client.
Eventually, there will be three levels of the application server—Standard, Advanced, and Enterprise. In the first release of WebSphere, only a single edition was available, which corresponded most closely with WebSphere Standard. Now, with the release of Version 2, both Standard and Advanced are available. The Advanced edition adds EJB support and increases scalability. Eventually, it will also add hooks to various back-end systems. The Enterprise edition will integrate with TXSeries and Component
Broker. Not all editions will be available on all platforms—each platform will offer the editions that fit best with the platform’s strengths, capabilities, and customer expectations.
The WebSphere Application Server is the application runtime environment. It contains a support for servlets, JSP, EJB, CORBA, IIOP, and XML (Extensible Markup Language). EJB is supported at the 1.0 specification level; it includes containers and deployment of both session and entity Beans. CORBA support includes code generators, CORBA naming service, object creation and factories, and a CORBA 2.0 compliant object server. WebSphere Application Server can handle both HTTP and IIOP communications. It also provides session tracking and state management. This support allows several HTTP requests to be considered a single session, enabling state information to be used across several HTTP requests (Web pages). How long a session will be maintained before being discarded is configurable. Session support can be used in a clustered environment, where several Web servers may process pieces of a single session. WebSphere also has the capability to save information about a particular Web user. This information is persistent, so it will last not only across HTTP requests and sessions, but also across Web server instances and different applications. Personalization support allows you to add news flashes to Web pages on a page-by-page basis or to add support for person-to-person messages on Web pages. There is also a connection manager that caches and reuses Java Database Connectivity (JDBC) connections to improve performance and throughput. The application server contains a browser-based administration tool called the Application Server Manager. This can be used for configuration and monitoring of the server.
In addition to the three main WebSphere components, there are two complementary elements shipped with the application server: an HTTP server and a set of connectors. The HTTP server is a pluggable component, which means that any HTTP server for which a WebSphere plug-in exists can be used. There are currently plug-ins available for several popular HTTP servers. The set of connectors is used to access data or applications outside the server, such as those in Customer Information Control System (CICS), Information Management System (IMS), MQSeries, Domino, and Encina.
To date, there have been three releases of WebSphere, each with increasing capabilities. See Figure 2 for an overview of the functions in each release.
Eventually, both Net.Commerce and SanFrancisco will evolve to use EJB. This means they will require an EJB server such as WebSphere. When they do, they will adopt the WebSphere branding. WebSphere will also become more integrated with other server products, such as Tivoli, TXSeries, Component Broker, OS/390, and OS/400.
What Is WebSphere for AS/400?
WebSphere first appeared on the AS/400 in V4R3 as a set of PTFs (see Figure 2). The first set of PTFs, which became available in September of 1998, contained WebSphere Version 1.0. In December of 1998, a new set of PTFs became available that upgraded WebSphere to Version 1.1. The 1.0 support is English only. Version 1.1 supports other languages. WebSphere is part of the HTTP Server for AS/400 product (5769DG1).
WebSphere has since shipped a Version 2.0 (in December of 1998), but this is not available for the AS/400. Since 2.0 was the first release that contained EJB support, the AS/400 does not currently have EJB capability via WebSphere. (BEA WebLogic [Tengah] can be used for EJB on the AS/400 today.)
WebSphere for AS/400 differs from the general description in the previous section in several respects:
1. The Apache Web server, which is assumed in the WebSphere documentation, is not available on AS/400. This does not affect the application server functionality because the HTTP server is a pluggable component and the HTTP Server for AS/400 functions just as well as (or better than) Apache. Currently, the HTTP Server for AS/400 is the only supported HTTP server for WebSphere for AS/400.
2. The performance pack does not run on OS/400. Parts of the performance pack
(e.g., NetDispatcher) can be run on other platforms to support AS/400 servers.
3. On AS/400, the WebSphere Application Server is free.
4. Only those connectors that connect to products that are available on the AS/400 are supported.
5. WebSphere Studio does not run on the AS/400. (It runs only on Win32.) It can be used for development, and the resulting components can then be deployed on an AS/400.
Since WebSphere for AS/400 is currently at the 1.1 level, it is roughly equivalent to the Standard edition. It stands to reason that in the future WebSphere Advanced will be the edition for the AS/400 because WebSphere Standard does not match the expectations of the AS/400 market and WebSphere Enterprise is based on products that are not used on the AS/400.
More New Web Technologies
It is no secret the Web is changing drastically. Most of the Web is used to share static information. For the Web to be most useful, however, content has to become more interactive and dynamic. This content change is the driving factor for many of the new technologies that WebSphere (and NCF) champion.
First, there was static HTML. The first wave of dynamic content was provided through Common Gateway Interface (CGI). Disadvantages of CGI programs are that they are not portable and they are generally slower since they usually are run in a new process. (Note that some HTTP servers work around the latter, including the HTTP server for AS/400.) Advantages of CGI are that it is robust (since it is run in a separate process, it cannot disrupt the Web server) and it is widely available. (Note that IBM’s Net.Data product, which provides a popular and powerful way to easily embed live data into Web pages, uses CGI capabilities.)
Server-side scripting and applets were the next technologies used. Several different scripting solutions emerged, none of which were universally accepted. Scripting requires learning a scripting language that is generally not portable. Applets provide portability since they are written in Java. However, applet performance can be a problem since code is downloaded from the server to the client. Also, because the applet code is running on the client, the client must have sufficient capabilities (such as the required level of browser/Java Virtual Machine [JVM]). If communication with server elements is needed, proprietary protocols may be used. Unfortunately, this limits portability and may be problematic if firewalls are used.
All of these technologies also suffer from the problem that HTTP servers are inherently stateless. This means that each request is a single unit—no state information is saved from one (page) request to the next. Tricks, such as hidden fields and cookies, are used to work around this limitation. Persistent CGI capability in some HTTP servers (including HTTP Server for AS/400) can help solve this problem. Although WebSphere supports all of these technologies, it recommends the use of servlets, JSP, and EJB for most new applications.
A sidebar to this article, “WebSphere for AS/400 Setup,” provides a tutorial on how to install Websphere. With WebSphere installed and a general knowledge of servlets, you’re ready to absorb “AS/400 Servlets 101.” Both “WebSphere for AS/400 Setup” and “AS/400 Servlets 101” can be found on MC’s Web site at www.midrangecomputing.com/anje/99/02.
This article continues by introducing you to servlets.
An Introduction to Servlets
A servlet is a chunk of Java code that runs on the server. Servlet interfaces are defined by a standard Java extension. Servlets are a CGI alternative, over which they have two main advantages. First, the code is portable since it is written in Java. Second, servlets are often faster since they are run in an existing server process rather than a new, separate process. A servlet instance is loaded the first time it is used, and that same instance is then used for subsequent requests. This boosts performance but requires that a servlet be able to
handle multiple concurrent requests and multithreading. (Note that, on the AS/400, servlet and CGI performance is comparable because of the CGI capabilities of the HTTP server for AS/400.)
Servlets are also used as a replacement for applets. The main difference between applets and servlets is that servlets run on the server and applets run on the client. A servlet solution results in less communication traffic; only the results of the servlet (the HTML) are sent from the server to the client, whereas, with an applet, the Java byte codes must be sent over the wire. Also, since an applet runs on the client, the client must have a certain level of software (JVM or browser). The client requirements are compounded by the different support in various software products and versions and by the lag time between the release of new Java features and when client software supports them (and then when users install these versions). This is not a problem with servlets because the server environment can be controlled.
The servlet API provides session objects that support state across HTTP requests. Maintaining state is one of the benefits of servlets. Before servlets, HTTP-based Internet applications were stateless; each user request from an HTML form was serviced as a completely new request. Servlets save user state of an application in a session object, which is then used by servlets servicing subsequent requests.
Servlets can be called in many ways. Besides the browser client simply using a URL that points to a servlet class, WebSphere offers configuration options to give the servlet a name or a URL alias. When a servlet is called directly, the result of the servlet is displayed to the browser user. Servlets can also be called from within HTML forms (using the ACTION attribute). Server-side HTML (SHTML) files, also called Java Server-side Includes (JSSIs), can call servlets using the SERVLET tag. In this case, the servlet output replaces the SERVLET tag in the HTML shown to the user. Servlets can also be used in conjunction with JSP. Lastly, servlets can be called as a result of servlet filtering or chaining. Chaining means some servlets are executed before others. Filtering means some servlets process the output of other servlets.
JSP is a new technology for creating dynamic Web content. JSP separates the presentation and data content. The presentation (user interface) is coded using HTML. Data is encapsulated into JavaBeans using Java code. The (dynamic) data content is pulled into the presentation by simple Bean access, which can be accomplished via JSP tags. The JSP specification is under development; as of the writing of this paper, it was at level 0.92.
JSP has three elements: components, scripting, and a compiled object. JavaBeans are used for the components, Java is the scripting language, and servlets are used for the compiled object. In the future, other options may be available for each of these elements.
JSP provides dynamic content generation through a combination of scripting and servlet technology, all of which is processed on the server. A JSP file contains a mixture of HTML, NCSA, servlet tags, and JSP. NCSA allow JSSIs (requests for the HTTP server to do some predefined action). It is most commonly used to embed common information such as copyrights or time of day. JSP tags are used to access data content. Java code can also be included in JSP tags, although this is not the primary intended purpose of JSP. When the server processes a JSP file, it creates a servlet. This servlet then generates the dynamic content. The servlet is automatically built the first time the JSP is processed and will be reused thereafter. The server will automatically detect if the JSP has changed and rebuild the corresponding servlet only if needed.
There are two main ways to use JSP to develop dynamic Web pages (see Figure 3). Using the first scenario, the Web user calls a JSP page directly (i.e., points the browser to a file with a .jsp extension). The JSP file contains JSP tags that are used to generate dynamic content. The second option is for the Web user to call a servlet (either directly or indirectly through a Web page that invokes a servlet). The servlet will gather data, store it
in a JavaBean, and then call a JSP page. The JSP page generates the presentation content using data from the Bean.
The separation of presentation and data generation is the main value of JSP. Without JSP, dynamic data content can be achieved in two ways. First, dynamic data generation can be embedded in HTML via scripting options. This can quickly lead to HTML source that is difficult to read and understand. Dynamic content can also be achieved through servlets. If the entire Web page is generated by the servlet, this can lead to a lot of print statements in the servlet code to generate the HTML, and the servlet contains both data logic and presentation logic. Servlets can be used to only generate the dynamic portion of the HTML, but the servlet is still responsible for the formatting of the data used for presentation. JSP allows the complete separation of data and presentation. This separation allows different developers (with different skills) to focus on data and presentation development and, of course, isolates each portion from changes in the other.
The use of JavaBeans to encapsulate dynamic data is another advantage of using JSP. JSP includes support for session tracking via the use of Beans. Since the language used in JSP scripting is Java, it is portable and results in skills reuse.
EJB is a specification from Sun Microsystems that brings a component model to server-side Java and makes building robust business applications easy. It includes support for transactions and distributed, persistent components. Version 1.0 of the specification has been out for almost a year, and several products have announced support. EJB makes use of many other enterprise APIs, such as JNDI (Java Naming and Directory Interface). Over time, EJB will become more integrated with other enterprise Java APIs, such as JMS (Java Message Service).
The advantage of EJB is its inherent support for difficult enterprise problems like transactions and distributed components. An EJB server (container) will handle these functions, saving the application developer much time and resulting in more reliable solutions.
EJB support in WebSphere is still in its infancy; it should mature over the next couple of releases. WebSphere currently advocates the use of EJB from within servlets in order to access back-end data. Until WebSphere EJB support is available on the AS/400, BEA WebLogic (Tengah) can be used.
How Does It All Fit Together?
By using of a mix of technologies, you can structure an application that closely resembles the powerful model-view-controller architecture. JSP handles the presentation (user interface), containing the information content and formatting of the data. JavaBeans or EJB contain the application logic and data access. Servlets (either raw or via JSP) coordinate the other two elements.
Figure 1: WebSphere consists of many pieces.
5769DG1 V4R3 PTFs
Legacy Data and Services
Servlet Engine JavaServerPages Connection Manager Database Access Beans CORBA ORB
Studio XMI Parser Connectors
EJB 1.0 Entity and Session Beans Managed Transactions Persistence to DB/2 Deployment Tool
WebSphere for AS/400
Figure 2: Each version of WebSphere has extended its capabilities.
5769DG1 V4R3 PTFs
JSP Called via a Servlet
Figure 3: JSP can be called directly from the Web client or from a servlet.
JSP Called Directly