IBM WebSphere Application Server architecture

milklivereddeepInternet and Web Development

Nov 13, 2013 (3 years and 6 months ago)


IBM WebSphere Application Server architecture
White paper
Building a complete Web application platform
This paper summarizes the capabilities of IBM

Application Server, describ-
ing 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 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
, 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.
Research Triangle Park, NC
• 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
• 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 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 communi-
cating with other ORBs (Object Request Brokers) and CORBA-compliant applications
• JavaMail
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
• 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 Application Server architecture
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 function 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
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
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
Figure 3: The big picture
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
Figure 4: Front-tier client architecture
• 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.
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
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.
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
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
• ORB-to-ORB communications via 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:
Figure 6: Back-tier connectivity activity
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 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 connec-
tion 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.
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

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.
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:
Figure 7: Dynamic access applications
• 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 application server is flexible
enough to openly support a variety of Java-based IDEs, and to allow for growth in applica-
tion 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 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:
© International Business Machines Corporation 1999
IBM Corporation
3039 Cornwallis
Research Triangle Park, NC
Produced in the United States of America
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.