Introduction: Application servers
An appserver is a JVM that runs user applications. The appserver collaborates with the Web server to return a dynamic, customized response to a client request. The client request can consist of servlets, JSPs, and enterprise beans, and their supporting classes.
For example, a user at a Web browser visits a company Web site:
- The user requests access to data in a database.
- The user request flows to the Web server.
- The Web server determines that the request involves an application containing resources not handled directly by the Web server (such as servlets). It forwards the request to one of its appservers on which the application is running.
- The invoked application then processes the user request. For example:
- An application servlet prepares the user request for processing by an enterprise bean that performs the database access.
- The application produces a dynamic Web page containing the results of the user query.
- The appserver collaborates with the Web server to return the results to the user at the Web browser.
When you install WAS ND, a default appserver, named server1, is automatically created. Use the admin console to manage this server.
Use the admin console or wsadmin commands to create additional application servers that can either be separately configured processes or nearly identical clones. As with server1, we can use the admin console to mange these additional servers.
New feature: We can improve system performance if we configure some of the appservers, such that each of their components are dynamically started as they are needed, instead of letting all of these components automatically start when the server starts. Selecting this option can improve server startup time, and reduce the memory footprint.
Starting components as they are needed is most effective if all of the applications that are deployed on the appserver are of the same type. For example, using this option works better if all of the applications are Web apps that use servlets, and JSP. This option works less effectively if the applications use servlets, JSPs and EJB
We can also perform the following tasks to enhance the operation of an appserver:
- Set transport chains to provide networking services to such functions as the service integration bus component of IBM service integration technologies, WebSphere Secure Caching Proxy, and the high availability manager core group bridge service.
- Add an interface to an appserver to define a hook point that runs when the server starts and shuts down.
- Define command-line information that passes to a server when it starts or initializes.
- Tune the appserver.
- Enhance the performance of the appserver JVM.
- Set an ORB for RMI/IIOP communication.
Asynchronous messaging
WAS ND v7.0 supports asynchronous messaging based on the JMS of a JMS provider that conforms to the JMS spec V1.1.
The JMS functions of the default message service that is provided with WAS are served by one or more messaging engines (in a service integration bus) that runs within appservers.
Version 5.1 nodes can exist in a dmgr cell. If a V5.1 node does exist in a deployment manager cell, and is configured to use V5.1 default messaging, only one JMS server can reside on that node.
Generic Servers
A generic server is a server that is managed in the WebSphere admin domain, although it is not a server that is supplied by WAS ND. The generic server can be any server or process that is necessary to support WAS environment.
Related concepts
Introduction: Application servers
Related tasks
Create generic servers
Programming to use JMS and messaging directly
Administer appservers
Set transport chains
Create custom services
Set the JVM
Tuning appservers
Manage Object Request Brokers