White paper. IBM WebSphere Application Server architecture

White paper IBM WebSphere Application Server architecture

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. Research Triangle Park, NC Building a complete Web application platform This paper summarizes the capabilities of IBM WebSphere Application Server, describing the supported configurations, protocols, and application programming 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 architecturelevel 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: 1

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 messaging and queueing and for providing 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 communicating with other ORBs (Object Request Brokers) and CORBA-compliant applications JavaMail 2

Transacting business with WebSphere Application Server There are basic e-business strategies for developing the right componentry and applications, 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. 3

WebSphere Application Server architecture 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: Figure 1: Clients to services 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 4

1. WebSphere configurations: the big picture Figure 2 shows a typical albeit simplified Web application flow through a Web application 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. Figure 2: Web application flow 2. Next, the servlet understands which method or call it needs to make to obtain the information to satisfy the client request. The servlet calls function routines written as JavaBeans, or in this example, more transactional Enterprise JavaBeans to conduct the query while connecting to a remote database. 5

3. 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. 4. 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 indepth 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 6

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. Figure 4: Front-tier client architecture 7

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 enhanced version of the Apache Web server. The IBM HTTP Server can be installed automatically 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. 8

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: 1. 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. 2. 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. 3. 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. 4. 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. 9

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). 10

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 objectto-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 to servlets; identify servlets to be loaded manually or at server start-up; configure options for session management; set up servlet aliases, chaining, and filtering; and monitor running servlets. 11

Enterprise JavaBeans server and services WebSphere Application Server also includes support for and management and deployment 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 configure 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. 12

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 ORB-to-ORB communications via IIOP 13

Back tier: connectivity architecture The WebSphere Application Server supports inclusion of a variety of different connectors, gateways, and application adapters to access back-tier servers and systems. Connectivity can be distinguished in two ways: gateway and adapter. Gateway connectivity refers to Java-based applications that convert HTML requests into sets of parameters. 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 dynamically 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: Figure 6: Back-tier connectivity activity 14

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 programming 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 connection pools are defined in the WebSphere Application 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 connection should remain idle before being reclaimed). Using the connection 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 connections; and using the WebSphere Enterprise JavaBeans Server, you can create an EJB instance and manage a pool of transactional EJBs to various databases and transaction processing systems. 15

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 You can connect CORBA-compliant ORBs and other EJB servers via IIOP. 16

Adapter connectivity Adapter connectivity encompasses the enterprise Java APIs, which are built into Enterprise 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: Figure 7: Dynamic access applications 17

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 Application Server deployment environment, again as shown. The application server is flexible enough to openly support a variety of Java-based IDEs, and to allow for growth in application function 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 applications 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 18

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. 19