Services created with LEIF are hosted in servlets instantiated by the LEIF server. The LEIF server is an executable servlet container that manages connections, receives and parses requests, transmits responses, manages security, and maintains state.
The LEIF server has three distinct aspects:
the container itself
one or more network connectors
one or more contexts that contain services (which could be LEIF Web services or just servlets), filters, listeners, or named objects
This section introduces these three components and how they work. For more detailed information on the LEIF server and these components, see Chapter 2, "LEIF Server and Servlet Concepts," in the Servlet Development Guide. For more information on how the container manages security and maintains state, see Chapter 11, "Security," in the Web Services Development Guide.
The LEIF server container is the intermediary between the Web server and the services inside it. It loads, initializes, and executes the services.
A container can hold any number of active services, named objects, filters, or listeners. Both the LEIF server and the objects in it are multithreaded. Therefore, each object within a container must be threadsafe.
The LEIF server receives requests through a network connector and includes network connectors for two different protocols:
The AJP13 protocol is widely used for communication between Web servers and servlet containers. The container includes ready-built AJP13 plug-ins for the Apache and IIS Web servers. For production use, we recommend the AJP13 protocol.
Web servers and clients communicate using HTTP. The container includes a miniature HTTP server for development and testing purposes.
A running container may use any number of these connectors, in any combination. The LEIF server configuration determines which connectors it uses. See Section 13.7.1for instructions on configuring connectors.
The LEIF server uses a context to group all the components for a given application. The LEIF server loads the objects within a context as a group, and objects within the same context can easily share data. Therefore, each context usually corresponds to a distinct Web application.
When you deploy your applications, LEIF creates a separate directory inside your installdir\webapps directory to define each application's context. The name of the context directory is the name of the context and determines the path to the servlets within the context. Each context directory contains a WEB-INF directory, and other files related to the application. Each WEB-INF directory contains a web.xml file. The web.xml file, or service descriptor, describes the configuration of the context and the servlets, filters, and listeners that occupy the context. (To use the web.xml file to customize your service configuration, see Section 13.6, "Configuring the Servlet Used by the Service.")
For example, if you have built and deployed both the shipped examples DayofWeek and WeatherSummary, your webapps directory should contain the following two contexts and associated directory structure:
webapps
\dayofweek
DayOfWeek.wsdl
handlers.xml
transports.xml
\WEB-INF
web.xml
objects.xml
\weather
handlers.xml
transports.xml
WeatherSummary.wsdl
\WEB-INF
web.xml
objects.xml
Note the configuration files handlers.xml, transports.xml, and objects.xml. These are server-side configuration files used by a Web service. The file handlers.xml supports server-side handler configuration and chaining, transports.xml defines available transports for the service, and objects.xml includes all server-side named objects required by this service, so they will be registered and created when the container is started.
These configuration files are discussed in more detail in Section 4.3.12, "Customizing the Service Configuration Files," in the Web Services Development Guide.
©2003-2005 Copyright Quovadx, Inc. All Rights Reserved.
Rogue Wave is a registered trademark of Quovadx, Inc. in the United States and other countries. All other trademarks are the property of their respective owners.
Contact Rogue Wave about documentation or support issues.