Application services
IBM WebSphere Application Server provides essential services to ease the building of dynamic and flexible e-business applications. These services support and extend the open standards of J2EE and Web services, with a focus on application reuse and integration.
The Enterprise Extensions product takes application services to the next level, providing a broad range of dynamic API extensions that address functional gaps in the J2EE programming model.
The WebSphere Application Server product provides several class-loading modes, policies, and features to enable you to deploy and run your applications successfully. An application server provides an Application class-loader policy that enables you to control the isolation of applications in a server. If you want applications to share classes, choose the SINGLE policy; otherwise choose the MULTIPLE policy, which isolates the class loaders for each application.
Similarly, at the application level, you can choose a WAR class-loader policy that configures the isolation of Web modules within an application. If you choose the policy APPLICATION, then each Web module in your application can see the classes of other Web modules. A policy of MODULE creates a separate class loader for each Web module, resulting in isolation for each of the classes of each Web module.
The class-loader mode setting, which you can configure at the server, application, or Web module level depending on your class-loader policy, enables you to control whether application class loaders override classes contained in base run-time class loaders. By default, the WebSphere Application Server class loaders have a class-loader mode of PARENT_FIRST, which is the standard JDK mode and does not allow the application class loader to override classes. You must take care when using the PARENT_LAST class-loader mode to make all dependent classes available within the application or you might get LinkageErrors or other class-loader exceptions. For example, if you provide a newer version of the Xerces.jar file and your application is using XSLT, you must also provide a xalan.jar file within your application.
Version 5.0 of WebSphere Application Server introduces the concept of a Managing shared libraries. A shared library is a CLASSPATH and a symbolic name for that CLASSPATH. You define shared libraries at the cell, node, or server level and then associate the shared libraries either with an application server (making the classes available to all applications in the server) or with individual applications (making the classes available only to the referencing application). This mechanism provides a convenient way to make libraries of classes available to your applications outside of a standard J2EE enterprise application (EAR) file for easier version management and space efficiency.
The EJB query language is used to specify a query over container-managed entity beans. WebSphere's EJB query language is compliant with the EJB QL defined in Sun's EJB 2.0 specification, but adds additional support as described in the topic Comparison of EJB 2.0 specification and WebSphere query language .
EJB query can be used to define a finder or select method of an EJB entity bean. Finder and select queries are specified in the bean deployment descriptor using the <ejb-ql> tag. Queries specified in the deployment descriptor are compiled into SQL during deployment. For more information about EJB query, see Using EJB query.
The Enterprise Extensions product includes the dynamic query service, an additional API that enables you to dynamically specify a query in your application by adding the executeQuery() method. For more information about the dynamic query service, see Using the dynamic query service.
The internationalization service manages the distribution of locale and time zone information, or internationalization context, in applications that run on WebSphere Application Server Enterprise installations. The internationalization service solves the problem of mismatched locales and time zones by systematically managing the distribution of internationalization context across the various components of EJB applications.
The internalization service transparently propagates
internationalization context over requests that originate from J2EE-compliant
Web service clients. The service creates a SOAP header block that contains
the invocation context scoped to the current thread; this SOAP representation
is then inserted into the outgoing Web services request. For incoming requests,
the service scopes the propagated internationalization context, referred to
as caller context, to the invocation of the stateless session bean
that is enabled as a Web service. The service also scopes an invocation
context as prescribed by the internationalization context management policies
that were assigned to the enterprise bean's methods during application assembly.
For more information about the internationalization service, see Using the internationalization service.
The WorkArea service enables application developers to implicitly propagate information beyond the information passed in remote calls. Applications can create a work area, insert information into it, and make remote invocations. The work area is propagated with each remote method invocation, eliminating the need to explicitly include an appropriate argument in the definition of each method. The methods on the server side can use or ignore the information in the work area as appropriate. For more information about the WorkArea service, see Using shared work areas.
Application profiling enables you to configure multiple access intent policies on the same method of an entity bean, and to configure multiple access intent policies for dynamic query on the same entity bean.
To use application profiling, application developers identify named units of work, or tasks. A task typically corresponds to the execution of a concrete and high-level job within the application. The IBM WebSphere Application Server run-time environment queries the task at the invocation of any entity bean, and establishes the appropriate access intent policy under which the bean should execute. An application profile is the set of access intent or query intent policies that should be selectively applied, as well as the list of tasks for which the policies should be applied. For more information about application profiling, see Application profiling.
The scheduler service enables J2EE work to be executed at a requested time or interval. The scheduler API supports different implementations of the TaskInfo interface, each of which can be used to schedule a particular type of work; for example, you can develop a task that calls a session bean or a task that sends a JMS message. You can set a notification sink on a task in order to receive the notification events that are generated by a scheduler when it performs an operation on the task. For more information about the scheduler service, see Using the scheduler service.
An asynchronous bean is a Java object or enterprise bean that can be executed asynchronously by a J2EE application, using the J2EE context of the bean's creator. These beans also can run with copies of other J2EE contexts. For example:
Asynchronous beans enable the construction of stateful, "active" J2EE applications. These applications address a segment of the application space that J2EE has not previously addressed (that is, advanced applications that require application threading, active agents within a server application, or distributed monitoring capabilities). For more information about synchronous beans, see Using asynchronous beans.
Objects are frequently pooled by Java applications in order to avoid the cost of creating new Java objects and the associated garbage collection delays that result when these objects are reclaimed after use. An object pool keeps a number of pre-allocated objects on behalf of its users. Applications can get an object from the pool, use it, and later return it to the pool. This allows the individual object instances to be reused and effectively limits the amount of garbage generated by the application. For more information about object pools, see Using object pools.
Startup beans are stateful session beans that enable J2EE applications to execute business logic when an application starts or stops. The startup bean is loaded when the application starts. The start() method is then invoked on the bean's remote interface. This method can execute any business logic needed by the application at start time. Similarly, the bean's stop() method is called on the instance when the application is stopped and can execute any business logic needed by the application at stop time. For more information about startup beans, see Using startup beans.
Startup beans are especially useful when used in combination with asynchronous beans to develop an active J2EE server application.
Business Rule Beans are used to separate business rules from an application's core behavior, allowing the application code to remain intact and untouched even as business practices change. Each business rule is represented by an entity bean that persistently stores information related to that rule. Each business rule is assigned an appropriate rule name and stored in a rule folder. The application developer identifies "points of variability" within an application and codes trigger points at these locations. These trigger points invoke one or more business rules. For more information about business rule beans, see Using Business Rule Beans
IBM WebSphere Application Server applications can use transactions to coordinate multiple updates to resources as atomic units (as indivisible units of work) such that all or none of the updates are made permanent. The way that applications use transactions depends on the type of application component, as follows:
The product is a transaction manager that supports the coordination of resource managers through their XAResource interface and participates in distributed global transactions with other OTS 1.2 compliant transaction managers (for example, J2EE 1.3 application servers). Applications can also be configured to interact with databases, JMS queues, and JCA connectors through their local transaction support when distributed transaction coordination is not required.
Resource managers that offer transaction support can be categorized into those that support two-phase coordination (by offering an XAResource interface) and those that support only one-phase coordination (for example through a LocalTransaction interface). The IBM WebSphere Application Server transaction support provides coordination, within a transaction, for any number of two-phase capable resource managers. It also enables a single one-phase capable resource manager to be used within a transaction in the absence of any other resource managers, although a WebSphere transaction is not necessary in this case. With the Last Participant Support of Enterprise Extensions, you can coordinate the use of a single one-phase commit (1PC) capable resource with any number of two-phase commit (2PC) capable resources in the same global transaction. At transaction commit, the two-phase commit resources are prepared first using the two-phase commit protocol, and if this is successful the one-phase commit-resource is then called to commit(one_phase). The two-phase commit resources are then committed or rolled back depending on the response of the one-phase commit resource.
The ActivitySession service of Enterprise Extensions provides an alternative unit-of-work (UOW) scope to that provided by global transaction contexts. It is a distributed context that can be used to coordinate multiple one-phase resource managers. The product EJB container and deployment tooling support ActivitySessions as an extension to the J2EE programming model. Enterprise beans can be deployed with lifecycles that are influenced by ActivitySession context, as an alternative to transaction context. An application can then interact with a resource manager through its LocalTransaction interface for the period of a client-scoped ActivitySession rather than just the duration of an EJB method.
For more information about the transaction service and related topics, see Using the transaction service.
Naming clients use Naming Services primarily to access objects, such as EJB homes, associated with applications installed on IBM WebSphere Application Server. Objects are made available to clients by being bound into a name space. A name space is under the control of a name server. In this product, there are potentially many name servers, and the name spaces controlled by the various name servers are federated together to form the view of a single name space. Each name server presents the same logical view of the federated name spaces.
Name servers provided by this product are a CORBA CosNaming implementation. IBM WebSphere Application Server provides a CosNaming JNDI plug-in which enables clients to access the name servers through the JNDI interface. Clients to EJB applications typically use JNDI to perform Naming operations. Clients may access the name servers directly through the CORBA programming model. The CosNaming interface is part of the CORBA programming model. CORBA clients which need to access EJB homes or some other objects bound to the name space would typically use the CORBA CosNaming interface to perform Naming operations.
For more information about the naming service, see Using naming.
Dynamic cache improves application performance by caching outputs and contents of outputs of servlets, JavaServer Pages (JSP) files, Web services, and commands. On subsequent client requests to the same applications, dynamic cache intercepts these calls and responds by serving the output or the contents of output from the cache.
Dynamic cache in this product version includes:
For more information about caching, see Configuring the dynamic cache service to improve performance.
Managing user profiles allows a company to maintain database tables containing fields for demographic data of individual customers or other users on the company system. For example, when a user repeatedly logs onto a Web site that supports user profiles, the Web site can display headlines and advertising tailored to the shopping preferences of that user. The site can address the user by his or her logon name. User profile API is deprecated in the current release.
For more information about user profiles, see Using user profiles.