IBM WebSphere Application Server architecture
Building a complete Web application platform
This paper summarizes the capabilities of IBM® WebSphere™ Application Server,
describ-ing the supported configurations, protocols, and application programmdescrib-ing interfaces. This paper is provided for technical support personnel, architects, and those who need to understand these supported application deployment environments. To understand the rich function within WebSphere Application Server, it is necessary to go beyond existing brochures and presentations on WebSphere Application Server, for a concise architecture-level description of capabilities.
The IBM WebSphere Application Server is an integral part of the WebSphere extended family of products. The Server provides a robust and portable application deployment environment as well as application execution management. The server is supported on many popular operating system platforms, including Windows NT™, Sun Solaris, IBM
AIX/6000®, Linux, OS/390®, OS/400® and OS/2® Warp. It has close affinity to IBM integrated
tool sets, such as IBM WebSphere Studio and IBM VisualAge® for Java™ Enterprise Edition
to facilitate rapid application development and deployment. WebSphere Application Server also works with WebSphere Performance Pack to deliver highly-scalable and reliable Web-based information serving. The WebSphere software extended product line provides one of the most complete Web application platforms on the market today for development, deployment, and management of Web applications.
IBM WebSphere products are based on, and support, key open-industry standards such as HTTP (HyperText Transfer Protocol), HTML (HyperText Markup Language), XML (Extensible Markup Language), SSL (Secure Sockets Layer), Java, JavaBeans, CORBA (Common Object Request Broker Architecture), LDAP (Lightweight Directory Access Protocol), and most importantly the Enterprise Java APIs:
WebSphere Application Server architecture
This IBM WebSphere Application Server white paper was written by: Jeff Reser, WebSphere Product Manager and David Backman, Software IT Architect.
• Enterprise JavaBeans (EJB) technology, reusable Java componentry for connectivity and transactions
• Java Server Pages (JSP), in-line Java code scripted within Web pages
• Java Servlets, used in building and deploying server-side Java applications
• Java Interface Definition Language (JIDL), for connecting to CORBA objects and applications
• Java DataBase Connectivity (JDBC), for connections to relational databases. WebSphere supports JDBC within its Connection Manager (described later) and within EJBs, for distributed database interactions and transactions
• Java Messaging Service (JMS), to be supported via MQSeries for asynchronous messag-ing and queuemessag-ing and for providmessag-ing an interface between an MQSeries queue manager and back-tier MQ-enabled servers and applications
• Java Transaction Service (JTS) and Java Transaction API (JTA), low-level APIs for interacting with transaction processing systems and relational databases, respectively. WebSphere uses these within EJBs for supporting distributed transactions
• Java Naming and Directory Interface (JNDI), for communicating with directories and naming systems and used in WebSphere Application Server to look up existing EJBs and interact with directories
• Java Remote Method Invocation over Internet Inter-ORB Protocol (RMI/IIOP), for communi-cating with other ORBs (Object Request Brokers) and CORBA-compliant applications
Transacting business with WebSphere Application Server
There are basic e-business strategies for developing the right componentry and applica-tions, deploying them within an execution environment with a rich set of services, and for managing applications, servers, and systems easily. WebSphere Application Server is the product implementation and foundation for e-business, and defines one of the most complete, Java-based Web application platform on the market today for developing, deploying, and managing e-business. The WebSphere strategy is defined by the following principles:
• Build on what you have while integrating your business systems with the Web
• Leverage existing skills and existing information technology (IT) systems
• Utilize open standards for portability and productivity
• Deploy secure, scalable, and manageable applications for dynamic content access and generation
The core of a Web application platform is the deployment environment. WebSphere Application Server manages deployment of Java-based applications, dynamic content access and generation, and enables powerful interactions and transactions involving remote and existing systems and servers. The Enterprise JavaBeans Server (EJS) implemented within the WebSphere Application Server, Advanced Edition follows the leading e-business premise of integrating with and protecting existing investments while enabling Web access to transactional systems. As shown in Figure 1, networks continue to deal with many types of clients accessing a logical middle-tier environment where EJB components are deployed independent of these clients.
Universal access is then provided to data, information, and services within data centers and across all types of networks. The server-side Enterprise Java technologies and APIs provide greater security and protection of assets, greater control, increased scalability, and better performance for access to enterprise-wide data and information in a multitiered architectural environment. The Enterprise JavaBeans server was built to meet the following key principles:
• Provide a deployment environment for session beans (client-specific data) and entity beans (transaction system data) based on a server and container component model
• Provide container management and persistence support for distributed transactions via server-side JavaBeans that conforms to the Enterprise JavaBeans specification
• Support transactions within server-side EJB business logic via Java Transaction Service (JTS) or through other Enterprise Java APIs where applicable
Figure 1: Clients to services
WebSphere configurations: the big picture
Figure 2 shows a typical—albeit simplified—Web application flow through a Web applica-tion server. Here, we have four basic steps:
The client sends a request to the HTTP Web server, which could be a database query for information. The Web server identifies the request as addressing a Java servlet and utilizes its configuration data to pass the request on to the servlet runtime engine code. The appropriate servlet is invoked via HTTP.
Next, the servlet understands which method or call it needs to make to obtain the informa-tion to satisfy the client request. The servlet calls funcinforma-tion routines written as JavaBeans, or in this example, more transactional Enterprise JavaBeans to conduct the query while connecting to a remote database.
Figure 2: Web application flow
1.
The third step involves business logic written as part of the Enterprise JavaBean, which connects to the back-tier database and performs the transaction. Because we are using an EJB, the database transaction is persistent and stored in a local relational database to provide dynamic direct mapping—via Entity Beans—to the remote database system that we need to access.
When the query results are sent back to the WebSphere middle-tier environment, the Java servlet regains control and manages the response page generation which needs to be served back to the client making the original request. To do that, an appropriate Java Server Page can be selected to help generate the dynamic content. The computed Web page with the results of the query is then served back to the Web client via the HTTP server.
Now, let’s look at what is happening in these scenarios within the Web application server and in a typical scenario. The big picture is shown Figure 3. Subsequent descriptions of this configuration show this picture as clients within the front “tier,” applications within the middle “tier,” and connected systems and servers within the back “tier.” We will cover the major capabilities of WebSphere Application Server, including the protocols and APIs supported and used, and use Figure 3 as a road map. The IBM WebSphere Performance Pack (shown in Figure 3) provides workload balancing across multiple Web servers. An in-depth discussion of WebSphere Performance Pack is beyond the scope of this paper. More information is available from the WebSphere Performance Pack Web site at
www.ibm.com/software/webservers/perfpack
Figure 3: The big picture
3.
Front tier: clients
The WebSphere Application Server supports a wide variety of client interfaces using industry standards. The IBM Application Framework for e-business focuses on “thin” clients that perform most or all functions using a Web browser, with a minimum of application code on the client. Figure 4 illustrates the types of thin clients supported:
• Web browsers with HTML (up to HTML 4) and JavaScript. The Web browsers communicate using standard HTTP and HTTPS (SSL) protocols with a Web server such as Apache, IBM HTTP Server (Apache-based), Netscape Enterprise, or Microsoft IIS, which delegates requests to WebSphere Application Server as appropriate. WebSphere also supports cookies, which are commonly used to place persistent information on clients with Web browsers. WebSphere provides an API cookie for creating, updating, and accessing cookies.
• Clients running XML-aware Java applications. XML interfaces can be generated either by translating XML to HTML on an application server or through the use of an XML-aware Java applet to convert XML to HTML on the client. WebSphere Application Server provides an XML4J parser and generator that conforms to XML standards, such as DOM and SAX APIs; XML, XPointer, and Namespace core standards. With the availability of XML-aware Web browsers such as Netscape Communicator 5.0 and Microsoft Internet Explorer 5.0, XML can be sent directly to Web browsers over the HTTP protocol.
• Clients running Java applets and applications. Java applets can communicate with WebSphere either through the HTTP protocol used by the Web browser, using the Web server as an intermediary, or can use IIOP to communicate directly to Java servlets and Enterprise JavaBeans (EJBs) running within WebSphere Application Server. WebSphere provides a CORBA-compliant Java-based ORB which supports IIOP.
• In addition, WebSphere can support “fat” clients that use IIOP or IP sockets protocols. Clients, like Visual Basic applications that are based on the Microsoft COM model, are also supported.
Middle tier: configurations
Within the middle tier, placement of Web servers, firewalls, and Web application servers is often integral to optimizing security and performance of e-business applications. This section defines basic, supported configurations for the middle-tier, prior to the discussion of supported components and protocols.
A common misconception about WebSphere Application Server is that it is a Web server or an HTTP server (that directly receives requests from Web clients over the HTTP protocol). Actually, WebSphere is a Web application server and works in close cooperation with Web servers to handle requests from Web clients. WebSphere Application Server supports all popular HTTP servers: Apache, IBM HTTP Server, Domino, Domino Go Webserver, Netscape Enterprise Server, and Microsoft Internet Information Server. WebSphere Application Server includes a copy of IBM HTTP Server, which is an en-hanced version of the Apache Web server. The IBM HTTP Server can be installed auto-matically as part of the WebSphere installation process for customers who do not already have a Web server. WebSphere can be configured to run within the same process as the Web server or run in a separate process. Running WebSphere “out-of-process” is preferred and supported for highest availability, because the Web server will remain running even if the WebSphere Application Server or Web server should crash.
Configuration for these three elements: Web server, Web application server, and firewall is measured by performance, scale, and security. These configurations can be described in four basic configurations:
One machine, one Web server, one Web application server, no firewall
This configuration, which executes all Java servlets and Java Server Pages in one single process that encompasses the Web server and the Web application server, provides the best overall performance for straight servlets and JSPs. Scalability, however, is limited to vertical scaling within the single machine.
One machine, n Web servers, n Web application servers, no firewall
This configuration provides decent servlet and JSP performance, and allows you to advantage of an n-way multiprocessor machine. There are multiple application server engines deploying several instances of Java applications, all managed within a logical server group. This configuration and configuration 1 above are both ideal for horizontal scaling, where IBM WebSphere Performance Pack could balance workloads across several machines. Each machine is configured as a Web server and Web application server group.
N machines, n Web servers, n Web application servers, TCP/IP firewall
In this configuration, the primary Web server is outside the firewall; with application server engines allowed to be separated outside and inside the firewall. Workload balancing via Performance Pack still occurs across the Web servers. HTTP tunneling is used to securely communicate with the Web application server behind the firewall.
N machines, n Web servers, n Web application servers, IIOP firewall
This configuration—although complex—allows maximum flexibility in application deployment. The primary Web servers are outside the firewall, with the Web application server process (the “master” logical EJB server) communicating with multiple server engines running behind the IIOP firewall. Because the firewall helps filter IIOP as well as TCP/IP, workload management can be achieved across EJB servers inside the firewall. Workload management can still be implemented across multiple Web servers outside the firewall.
1.
2.
3.
Middle tier: application architecture
The middle-tier portion of the big picture architecture (figure 5) describes the engine and application-to-application communications.
Figure 5: Middle-tier application architecture
The WebSphere Application Server deployment environment can be separated into two distinct engines with associated services.
• Java server
Focuses on deploying and managing Java servlets, Java Server Pages, and JavaBeans.
• Enterprise JavaBeans server
Focuses on deploying and managing Enterprise JavaBeans components into containers (either session beans or entity beans).
Java server and services
WebSphere Application Server has implemented the Java Servlet API, plus extensions of and additions to the API. Java servlets are standard, server-side Java programs that extend the capabilities of a Web server. Servlets are analogous to Java applets, except that applets run on client machines and servlets run on application servers. Also, servlets can process requests from Web servers.
Servlets are secure, portable, high-performance alternatives to CGI (Common Gateway Interface) scripts. Servlets are secure because their code runs safely behind firewalls. They run within the servlet engine process; no servlet can run with access rights beyond those of that process. WebSphere Application Server provides a security framework based on ACLs (Access Control Lists) for servlets. Servlets can also use native security features, such as x.509 Digital Certificate credentials. Because servlets are written in Java, they are extremely portable. And, they perform better than CGI scripts because they are multi-threaded, maintaining sessions across HTTP requests. Servlets can be preloaded and remain in memory as needed.
WebSphere includes a servlet engine for running and managing Java servlets. WebSphere has been tested with and supports Java Developer’s Kit Version 1.1.6. The servlets that are run and managed by WebSphere can be plain servlets, or they can be defined as JavaBeans. WebSphere also handles servlets that are generated from Java Server Pages (JSPs). JSPs are files that include both HTML content and Java code (or more likely, references to Java code). JSPs separate presentation logic (for example, the HTML code that defines Web site structure and appearance) from business logic (for example, the Java code that accesses a database for information to display on the Web site). Therefore, JSPs facilitate the development of dynamic Web pages by allowing page designers to concentrate on the page content and layout, while programmers focus on the dynamic elements. For flexibility, JSP files can include any combination of in-line Java, <SERVLET> tags, HTML tags and JavaBeans.
Servlets communicate in the same fashion as other Java programs, through method calls. Servlets can interact with C and C++ programs via JNI, or Java Native Interface. Servlets can communicate with each other across different WebSphere instances through Java Remote Method Invocation (RMI). WebSphere also supports servlet communication across WebSphere instances via RMI over CORBA IIOP. RMI over IIOP is used for object-to-object communications where those objects are CORBA-compliant. This method is then used for communications to other enterprise Java servers and other ORBs.
The WebSphere Application Server deployment manager provides a Java-based console for servlet management. With this tool, administrators can assign short names and aliases
Enterprise JavaBeans server and services
WebSphere Application Server also includes support for and management and deploy-ment of EJBs (Enterprise JavaBeans). EJBs are server-side components written in Java. EJBs are distinguished from JavaBeans by their quality of service. EJBs, unlike JavaBeans, manage their own persistence (entity beans), are fully transactional, and have built-in security. WebSphere includes the ability to run and manage applications coded to the Sun EJB Specification. WebSphere, unlike other EJB servers, provides intelligent “containers” for running EJBs. Because WebSphere manages these containers, developers need not concern themselves with the distributed object “plumbing” issues that can consume more than 70 percent of a large-scale application development project.
With integrated development environments such as IBM VisualAge for Java Enterprise Edition, developers can easily create session and entity EJBs with the help of wizards. VisualAge for Java also provides an EJB testing environment, including a graphical client test harness generator and a runtime EJB container. When EJBs are ready for deployment in WebSphere, VisualAge for Java exports the EJB files into a deployment staging directory. The WebSphere administrator then uses the WebSphere deployment manager to config-ure the EJB containers and deploy the EJBs in WebSphere. The deployment manager is also used to monitor and manage the runtime EJB environment within WebSphere. Each type of EJB, session beans and entity beans, run in a separate EJB container within WebSphere.
EJBs communicate with each other using standard CORBA IIOP. WebSphere includes a CORBA-compliant ORB (Object Request Broker) to support EJBs. Clients locate EJB homes using the naming service provided by WebSphere. Currently, this service is based on JNDI (Java Naming and Directory Interface). Other JNDI-compliant naming services and LDAP-enabled directories, such as IBM SecureWay® Directory, are supported as well.
Because EJBs currently have no built-in security, it is best to leverage Web server and WebSphere security when deploying them. For example, EJBs can be called by servlets, which in turn are invoked due to requests coming from a Web server. EJB security is being added to revisions of the EJB specification and will subsequently be included within WebSphere.
EJBs running within WebSphere can communicate with EJBs running in other non-WebSphere containers. Currently, this EJB interoperability has been tested with the Visigenics VisiBroker ORB, IONA ORB, and the BEA WebLogic Application Server. Other CORBA-compliant ORBs might also work but should be tested due to slight differences in CORBA implementations by ORB vendors.
EJBs come in two types: session beans, which can be either stateless or stateful, and entity beans, which can persist indefinitely. Stateless beans are created and pooled by the Web application server, while stateful beans are created by and dedicated to clients. WebSphere supports EJB persistence using both EJB container-managed persistence and EJB bean-managed persistence. Container-managed persistence is easier to use because WebSphere manages the persistence for you. Container-managed persistence has been tested using DB2® Universal Database™. Bean-managed, or self-managed
persistence is more flexible because the developer has full control over the persistence logic; the trade-off is greater development effort for the EJB.
EJBs, being Java components, can also communicate with C and C++ programs using the JNI (Java Native Interface).
To summarize the application interactions supported here, we have the following:
• Servlet-to-servlet communications via Java RMI
• Java-to-C++ application communications via JNI
• Beans-to-beans and EJB-to-EJB interactions via RMI over IIOP
Back tier: connectivity architecture
The WebSphere Application Server supports inclusion of a variety of different connec-tors, gateways, and application adapters to access back-tier servers and systems. Connectivity can be distinguished in two ways: gateway and adapter. Gateway connec-tivity refers to Java-based applications that convert HTML requests into sets of param-eters. These parameters are then passed to an associated client that executes in the same process as the gateway and communicates with the back-tier application server via native or Java-based APIs. Adapter connectivity establishes direct mapping to data and information contained within back-tier systems and servers, and encompasses the transactional nature of connections across dissimilar and remote systems. Enterprise JavaBeans components are examples of adapter connectivity. Both types of connectivity are used to help extend the enterprise systems to the Web and to the Web application server environments. Adapter connectivity, due to its transactional nature, can dynami-cally change to accommodate changes within the back-tier systems. Greater
interoperability exists with those systems and powerful interactions and transactions are invoked via WebSphere Application Server. Gateway connectivity is certainly not as scalable in nature as EJB adapters but provide a simple-to-use and easy-to-develop alternative which can also be called from servlets. Figure 6 shows possible connections and the supported APIs:
For relational database access, WebSphere Application Server supports the standard JDBC drivers for database access from servlets. WebSphere Application Server allows updates to multiple database managers through multiple connections. In addition, WebSphere Application Server supports extensions to JDBC to make database program-ming easier and improve database query performance via data access beans and the connection manager.
Data access beans provide a higher level API for database access through JDBC. Using the IBM WebSphere Studio database access-servlet wizard or the VisualAge for Java Select Beans, a developer can visually create data access beans and use those beans to read and update relational databases such as DB2 Universal Database. Data access beans address several shortcomings of the current JDBC standard. For example, JDBC supports only forward scrolling of a result set, while data access beans allow bidirectional scrolling. Also, data access beans support inserting and updating with a single message and allow parameters to be named within queries.
The connection manager feature allows many servlets to share “pools” of long-lived JDBC database connections, improving scalability and performance by eliminating the
overhead required to open a new connection for each request. These database connec-tion pools are defined in the WebSphere Applicaconnec-tion Server deployment manager. For each pool, the WebSphere administrator can specify parameters such as the minimum and maximum number of connections, the connection time-out (how long a connection can be held by a requester), and the maximum age of a connection (how long a connec-tion should remain idle before being reclaimed). Using the connecconnec-tion pool monitor in the deployment manager, the administrator can determine if additional connections are needed and allocate more connections dynamically. The connection manager has an API that servlet programmers use to retrieve, use, and release database connections from the connections pool.
In addition to the database access support for servlets, WebSphere supports the entity type of Enterprise JavaBeans. Through entity beans, persistence can be managed in databases through container-managed persistence and bean-managed persistence strategies. WebSphere Application Server supports all databases that conform to the JDBC access standard via a JDBC-ODBC bridge. However, for best performance, use native database drivers. The WebSphere Application Server includes a copy of DB2 Universal Database Server, which can be used to persist and manage information related to the use of WebSphere and EJBs.
Connectivity management is handled in two ways: through connection manager, as described above, WebSphere can manage and maintain a pool of relational database
Gateway connectivity
Gateway connectivity is the most prolific method of communication available today for building into e-business applications. Some examples are shown in Figure 6. Specifically, gateway connectors are available today for:
• Lotus® Domino™
Using the Java Notes interface that comes with Domino, you can connect to Domino applications from a servlet or a bean.
• Relational databases
Using JDBC connectivity and products such as Net.Data®, beans and macros can be
called from servlets to communicate with any database that supports JDBC, including IBM DB2 Universal Database, Oracle, Sybase, Informix, and others.
• Transaction processing systems
Using products such as CICS® Internet Gateway, MQSeries® Internet Gateway, or DCE
Encina Lightweight Gateway, you can interact with the respective transaction processing systems on the back tier. The MQSeries Internet Gateway provides a Java-based Queue Manager, which executes within the middle tier and manages asynchronous messaging to MQ-enabled applications and systems on the back-tier. The CICS Internet Gateway provides conversion of transaction requests from HTML to parameters, which the Gateway passes to a native CICS client for Java.
• Hierarchical databases
Other databases such as IMS use connectors like IMS Web, which includes several components to help the communications. ITOC (Java TCP/IP Open Connectivity) is installed on the OS/390 side to accept requests coming from the middle-tier environment.
• SanFrancisco™-based applications
Applications that are written in Java and used within the SanFrancisco framework as Common Business Objects can be connected to via servlets using Java RMI. These servlets are distributed as part of the SanFrancisco framework.
• CORBA applications
Adapter connectivity
Adapter connectivity encompasses the enterprise Java APIs, which are built into Enter-prise JavaBeans generated by IDEs (Integrated Development Environments) such as VisualAge for Java Enterprise. These interfaces are defined within the EJB specifications and are listed earlier in this paper. Enterprise JavaBeans technology is core to the specification, which can be mapped directly to CORBA and CORBA services. EJBs, as explained earlier, are either session beans (containing information associated with client sessions) or entity beans (mapping directly into back-tier application servers and systems). In this context, application adapters are beginning to take the form of Enterprise JavaBeans, dealing with a wide range of applications, application servers, relational and hierarchical databases, transaction processing systems, and information systems. These EJBs are in turn deployed and managed within the Enterprise JavaBeans Server in WebSphere Application Server.
In summary
To summarize the WebSphere Application Server architecture, applications can be generated and deployed to provide dynamic access to a variety of different information and data sources in several different ways. The architecture is separated into three distinct areas of function and protocols:
• Front tier: clients
This tier involves user services and support for clients such as Web browsers, XML-aware applications, and Java applications on any type of client from desktop workstations to wireless devices. In Figure 7, user services include fast access to large, remote databases, where the clients initiate the queries.
• Middle tier: Web application servers
This involves a Web server with a pluggable Java application engine. The Java servlets and JavaBeans involved in the middle-tier application server in the example in Figure 8 help enable access to the back-tier databases (in this example, Oracle databases on Sun Solaris systems). These Java applications could possibly be built by Java integrated development environments such as IBM VisualAge for Java, then staged over to the WebSphere Applica-tion Server deployment environment, again as shown. The applicaApplica-tion server is flexible enough to openly support a variety of Java-based IDEs, and to allow for growth in applica-tion funcapplica-tion as well as cross-platform facilities. Because of the Java portability attributes, development and deployment cycle time is essentially reduced and customer service is ultimately improved.
• Back tier: servers and systems
The overriding principle behind Web application servers is to preserve existing investments in skills, hardware and software. IBM extends the enterprise systems and databases to the Web by providing gateway and adapter connectivity to these existing systems and servers. New services can be added quickly within the middle-tier environment without significantly affecting the back-tier applications. Ultimately, response time to these systems from Web browsers is significantly improved with scaling and workload balancing among the applica-tions being deployed within the middle-tier environments.
Hence, the architecture described in this paper provides the foundation for a complete, secure, reliable, and scalable Web application platform for developing, deploying, and managing new-wave e-business applications.
For more information
For more information on the WebSphere software product line, visit us at: www.ibm.com/software/WebSphere
© International Business Machines Corporation 1999 IBM Corporation
3039 Cornwallis Research Triangle Park, NC
Produced in the United States of America 7-99
All Rights Reserved
AIX, AIX/6000, DB2 Universal Database, IBM, MQSeries, Net.Data, OS/2, OS/390, OS/400, SanFrancisco, SecureWay, the e-business logo, VisualAge and WebSphere are trademarks of International Business Machines Corporation in the United States, other countries, or both.
Domino and Lotus are trademarks of Lotus Development Corporation in the United States, other countries, or both.
Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Microsoft, Windows and Windows NT are trademarks of Microsoft Corporation in the United States, other countries, or both.
Other company, product, and service names may be trademarks or service marks of others.
