Welcome to Applications

The following items comprise the application programming model, including numerous services available to support deployed applications.

 

Web modules

Use Web components such as servlets and JSP files to develop dynamic Web sites. Product extensions to the open source servlet and JSP APIs enhance standard features, and provide additional functionality.

Web modules consist of the following application components, each performing a different function:

  • HTML and JSP pages provide the user interface and program logic

  • Servlets coordinate work between other components of the application

  • BSF enables users to implement JavaScript code in JSP applications

HTTP sessions are a key area of product support for Web modules. By managing HTTP sessions for your Webapps, you can personalize a Web site for individual customers. A session is a series of requests to a servlet, originating from the same user at the same browser. Managing HTTP sessions allows servlets running in a Web container to keep track of individual users. For example, a servlet might use sessions to provide "shopping carts" to on-line shoppers. Suppose the servlet is designed to record the items each shopper indicates he or she will purchase from the Web site. It is important that the servlet be able to associate incoming requests with particular shoppers. Otherwise, the servlet might mistakenly add choices of Shopper 1 to the cart of Shopper 2.

 

EJB modules

IBM WAS provides broad support for enterprise beans, including the EJBs 2.0 specification. The EJB 2.0 specification introduces a container-managed persistence 2.0 component model, which provides a number of improvements to aid developer productivity and application performance. In addition, this product continues to fully support enterprise beans written to the CMP 1.1 programming model and deployed in previous versions of this product; applications can use CMP 1.1 beans, CMP 2.0 beans, or a mixture of both. CMP 1.1 beans can be directly carried forward in an EJB 1.1 ejb-jar module or may be repackaged and combined with CMP 2.0 beans in an EJB 2.0 module.

For EJB 2.0 modules, a feature introduced in Version 5 of this product, called access intent policies, eases the management of interactions between CMP beans and their underlying datastores. Each policy sets such data access characteristics such as access type (read or update) and transaction isolation that affect the locking of resources, letting you choose the level of data integrity and performance for your application.

Several excellent trade books that cover EJB 2.0 and the CMP 2.0 persistence model are already available. A good way to locate some of these is to visit your favorite online bookstore and search on the term EJBs. For a more basic orientation, see Enterprise beans: Links.

Your application development might include asynchronous messaging, which the product supports as a method of communication based on the Java Message Service programming interface.

The base JMS support enables IBM WAS applications to exchange messages asynchronously with other JMS clients by using JMS destination queues and topics. An application can explicitly poll for messages on a destination.

WAS also provides a message listener service that applications can use to automatically retrieve messages from JMS destinations for processing by message-driven beans, without the application having to explicitly poll JMS destinations.

Referto:

 

Client modules

The Imaginary Buffer Line product provides a CD-ROM and installation program for installing application clients without installing the entire appserver. This smaller footprint is useful if you want to run client applications on multiple client machines. For more information, see Installing application clients.

Application clients follow several programming models with unique requirements and suitability for different types of applications. Most of these models are only available when you install the product. Models include:

 

ActiveX application client

Supported Windows platforms only; Client only

 

Applet client

Supported Windows platforms only; Client only

 

J2EE application client

All supported server platforms; All supported client platforms

 

Pluggable application client

Supported Windows platforms only, Sun JRE 1.3.1_03 or later (but not 1.4); Thin application client programming model only (no J2EE programming model); Client only

 

Thin application client

All supported client platforms

 

Web services

The Web services components included with this product version build upon the Apache Simple Object Access Protocol (SOAP) 2.3-based capabilities delivered with Version 4.0.x of the product.

Version 5.0 introduced an open source implementation for a Web Services Invocation Framework (WSIF).

An additional Web services component, "IBM WebSphere Web Services for J2EE Technology Preview" is available for use with Version 5. It is available as a separate download from: http://www7b.boulder.ibm.com/wsdd/downloads/techpreviews.html.

The Web Services Technology Preview supports emerging Java Web services standards like JAX-RPC and Web services for J2EE. It is recommended that new development efforts use the Web Services Technology Preview and follow these standards.

Additional features, such as UDDI Registry, and Web Services Gateway are described in Welcome to Servers.

WAS supports Web services security functionality that is based on standards included in the Web services security (WS-Security) specification.

 

Application services

IBM WAS 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.

  • Class loading

    The WAS product provides several class-loading modes, policies, and features to enable you to deploy and run your applications successfully. An appserver 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 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 WAS 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, also provide a xalan.jar file within your application.

  • Shared library

    Version 5.0 of WAS 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 appserver (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 file for easier version management and space efficiency.

  • Internationalization support

    If your application component must support multiple locales, the localizable-text API can help both developers and administrators through central management of displayed strings. The developer separates strings into a message catalog, which is then translated into the other languages required. All message catalogs are then deployed with the application component. From then on, the administrator can add or update message catalogs centrally as required. See Internationalizing applications.

  • Transactions

    IBM WAS 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:

    WAS 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 appservers). 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 2-phase coordination (by offering an XAResource interface) and those that support only 1-phase coordination (for example through a LocalTransaction interface). The IBM WAS transaction support provides coordination, within a transaction, for any number of 2-phase capable resource managers. It also enables a single 1-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 1-phase commit (1PC) capable resource with any number of 2-phase commit (2PC) capable resources in the same global transaction. At transaction commit, the 2-phase commit resources are prepared first using the 2-phase commit protocol, and if this is successful the 1-phase commit-resource is then called to commit(one_phase). The 2-phase commit resources are then committed or rolled back depending on the response of the 1-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 1-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.

  • Naming

    Naming clients use Naming Services primarily to access objects, such as EJB homes, associated with applications installed on IBM WAS. 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 WAS 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.

  • Dynamic cache

    Dynamic cache improves application performance by caching outputs and contents of outputs of Servlets, 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:

     

    Servlet/JSP files caching

    This caches output of dynamic servlets and JSP files by working with Java Virtual Machine of the appserver by intercepting calls to service methods and serving Web pages from the cache. This improves server response time, throughput and scalability.

     

    Command caching

    Commands that are written to the Command Architecture encapsulate business logic tasks and provide a standard way to invoke the business logic request. Command objects need to implement CacheableCommand interface instead of TargetableCommand interface to cache. Like in servlets and JSP caching, requests to execute business logic in the command is intercepted by the cache. If a command with the same request attributes are available in cache, output properties are copied from the cached instance to the requested instance and returned without executing the business logic again.

     

    Web Services caching

    Web service responses can be cached just like servlet and JSP results. These requests are intercepted and cache ID computed based on how the cache ID rules are specified in the cache policy. Hash of the whole SOAPEnvelope can be used as a cache ID or it can be parsed and service, operation and parameters to these operations used as cache ID. If a cache entry is not found for the computed cache id, the request is forwarded to the SOAP engine and the result is cached.

     

    Edge Side Include caching

    This provides the ability to cache, assemble and deliver dynamic web pages at the edge of the enterprise network. Edge Side Includes (ESI) is a simple markup language which enables dynamic web pages (which by themselves are not so cache efficient) to be broken down into cacheable fragments. These fragments are then cached on the edge of the network and assembled into a single page upon user requests.

     

    Distributed caching

    Cache contents can be shared and replicated among servers by Dynamic Caching using an underlying JMS based message broker system, DRS (Data Replication Service). Sharing characteristics of individual cache entry is configured using the cache policy specification.

  • User profiles

    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.

 

Assembly tools

The Application Assembly Tool and a command line deployment tool are provided for packaging your application code components into the needed modules for deployment onto the server.

See Assembling applications.

EAR files are comprised of the following archives:

The standard file extension of an Enterprise application file is .ear.

For a discussion of archives and Web components supported by the Application Assembly Tool in Version 5, see Archive support in Version 5.0.

See the Assembling or packaging topic for more information.

For the Windows and Linux Intel operating systems, the Assembly Toolkit replaces the Application Assembly Tool (AAT). http://www-3.ibm.com/software/webservers/appserv/was/support/ to download the Assembly Toolkit, which offers the Assembly Toolkit and other products. The Assembly Toolkit consists of the J2EE Perspective of the WebSphere Studio Application Developer product, without the code generation capabilities.

 

Deployment

Tools, such as the WebSphere Administrative Console, are provided for installing your modules onto the appserver, then managing the installed modules in their respective containers.


 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.