WebSphere applications features
Overview
WAS ND v7.0 has the following aspects...
- Java specifications and other open standards for developing applications
- WebSphere programming model extensions to enhance application functionality
- Containers in the appserver, used by deployed applications, and which sometimes can be extended
Single appserver installation
See also: Product architecture.
Java EE application components
Web apps run in the Web container and are comprised of one or more related servlets, JSP and HTML files managed as a unit.
Each appserver runtime has one logical Web container, which can be modified, but not created or removed.
Each Web container provides the following.
- Web container transport chains
Requests are directed to the Web container using the Web container inbound transport chain. The chain consists of...
- Servlet processing
When handling servlets, the Web container creates a request object and a response object, then invokes the servlet service method. The Web container invokes the servlet's destroy method when appropriate and unloads the servlet, after which the JVM performs garbage collection.
Servlets can perform such tasks as...
- supporting dynamic Web page content
- providing database access
- serving multiple clients at one time
- filtering data
- HTML and other static content processing
Requests for HTML and other static content that are directed to the Web container are served by the Web container inbound chain. However, in most cases, using an external Web server and Web server plug-in as a front end to the Web container is more appropriate for a production environment.
- Session management
Support is provided for the interface...
javax.servlet.http.HttpSession
An HTTP session is a series of requests to a servlet, originating from the same user at the same browser, allowing applications running in a Web container to keep track of individual users.
For example, many Web apps allow users to dynamically collect data as they move through the site, based on a series of selections on pages they visit. Where the user goes next, or what the site displays next, might depend on what the user has chosen previously from the site. To maintain this data, the application stores it in a "session."
- SIP applications and their container
SIP applications are Java programs that use at least one Session Initiation Protocol (SIP) servlet. SIP is used to establish, modify, and terminate multimedia IP sessions including IP telephony, presence, and instant messaging.
- Portlet applications and their container
Portlet applications are special reusable Java servlets that appear as defined regions on portal pages. Portlets provide access to many different applications, services, and Web content.
EJB applications run in the EJB container, which provides all of the runtime services needed to deploy and manage enterprise beans. It is a server process that handles requests for both session and entity beans.
Enterprise beans are Java components that typically implement the business logic of Java EE applications, as well as accessing data. The enterprise beans, packaged in EJB modules, installed in an appserver do not communicate directly with the server. Instead, the EJB container is an interface between EJB components and the appserver. Together, the container and the server provide the enterprise bean runtime environment.
The container provides many low-level services, including threading and transaction support. From an admin perspective, the container handles data access for the contained beans. A single container can host more than one EJB JAR file.
Client applications and other types of clients
In a client-server environment, clients communicate with applications running on the server. Client applications or application clients generally refers to clients implemented according to a particular set of Java specifications, and which run in the client container of a Java EE-compliant appserver.
Other clients in the WAS environment...
Web clients Web apps Web services clients Clients of Web services programs Administrative clients Clients of WAS ND systems administration
- Client applications and their container
The client container is installed separately from the appserver, on the client machine. It enables the client to run applications in an EJB-compatible Java EE environment. The diagram shows a Java client running in the client container.
WAS ND V7.0 provides a convenient launchClient tool for starting the application client, along with its client container runtime.
Depending on the source of technical information, client applications sometimes are called application clients. In this documentation, the two terms are synonymous.
- Web clients, known also as web browser clients
The diagram shows a Web browser client, which can be known simply as a Web client, making a request to the Web container of the appserver. A Web client or Web browser client runs in a Web browser, and typically is a Web app.
- Web services clients
Web services clients are yet another kind of client that might exist in the application serving environment. The diagram does not depict a Web services client. The Web services information includes information about this type of client.
- Administrative clients
The diagram shows two kinds of admin clients: a scripting client and the admin console that is the GUI (GUI) for administering this product. Both are accessing parts of the systems administration infrastructure. In the sense that they are basically the same for whatever kind of applications we are deploying on the server, admin clients are part of WAS architecture. However, because many of these clients are programs you create, they are discussed as part of the model for completeness.
Web services
The diagram shows the Web services engine, part of the Web services support in the appserver runtime. Web services are self-contained, modular applications that can be described, published, located, and invoked over a network. They implement a service-oriented architecture (SOA), which supports the connecting or sharing of resources and data in a flexible and standardized manner. Services are described and organized to support their dynamic, automated discovery and reuse.
WAS ND v7.0 acts as both a Web services provider and as a requestor. As a provider, it hosts Web services that are published for use by clients. As a requester, it hosts applications that invoke Web services from other locations. The diagram shows the Web services engine in this capacity, contacting a Web services provider or gateway.
Data access, messaging, and Java EE resources
- Data access resources
Connection management for access to enterprise information systems (EIS) in the appserver is based on the Java EE Connector Architecture (JCA) specification.
The diagram shows JCA services helping an application to access a database in which the application retrieves and persists data.
The connection between the enterprise application and the EIS is done through the use of EIS-provided resource adapters, which are plugged into the appserver. The architecture specifies the connection management, transaction management, and security contracts between the appserver and EIS.
The Connection Manager (not shown) in the appserver pools and manages connections. It is capable of managing connections obtained through both resource adapters defined by the JCA spec and data sources defined by the JDBC 2.0 Extensions specification.
JDBC resources (JDBC providers and data sources) are a type of Java EE resource used by applications to access data. Although data access is a broader subject than that of JDBC resources, this information often groups data access under the heading of Java EE resources for simplicity.
JCA resource adapters are another type of Java EE resource used by applications. The JCA defines the standard architecture for connecting the Java EE platform to heterogeneous EIS. Imagine an ERP, mainframe transaction processing, database systems, and legacy applications not written in the Java programming language.
The JCA resource adapter is a system-level software driver supplied by EIS vendors or other third-party vendors. It provides the connectivity between Java EE appservers or clients and an EIS. To use a resource adapter, install the resource adapter code and create configurations that use that adapter. WAS ND v7.0 provides a predefined relational resource adapter for the use.
- Messaging resources and messaging engines
JMS support enables applications to exchange messages asynchronously with other JMS clients by using JMS destinations (queues or topics). Applications can use message-driven beans automatically retrieve messages from JMS destinations and JCA endpoints without explicitly polling for messages.
For inbound non-JMS requests, message-driven beans use a Java EE Connector Architecture (JCA) 1.5 resource adapter written for that purpose. For JMS messaging, message-driven beans can use a JCA-based messaging provider such as the default messaging provider that is part of WAS ND.
The messaging engine supports the following types of message providers.
- Default messaging provider (service integration bus)
The default messaging provider uses the service integration bus (SIB) for transport.
Provides point-to-point functions, as well as publish and subscribe functions. Within this provider, you define JMS connection factories and destinations that correspond to SIB destinations.
- WebSphere MQ provider
External JMS provider. The appserver provides the JMS client classes and administration interface, while WebSphere MQ provides the queue-based messaging system.
- Generic JMS provider
Use another messaging provider as long as it implements the ASF component of the JMS 1.0.2 specification. JMS resources for this provider cannot be configured using the admin console.
For transitioning users: V6 replaces the V5 concept of a JMS server with a messaging engine built into the appserver, offering the various kinds of providers mentioned previously. The V5 messaging provider is offered for configuring resources for use with V5 embedded messaging. We also can use the V5 default messaging provider with a SIB.
EJB 2.1 introduces an ActivationSpec for connecting message-driven beans to destinations. For compatibility with V5, you still can configure JMS message-driven beans (EJB 2.0) against a listener port. For those message-driven beans, the message listener service provides a listener manager that controls and monitors one or more JMS listeners, each of which monitors a JMS destination on behalf of a deployed message-driven bean.
- Default messaging provider (service integration bus)
- Service integration bus (SIB)
The SIB is a JMS provider that provides reliable message transport and uses intermediary logic to adapt message flow intelligently into the network. The SIB supports the attachment of Web services requestors and providers.
The SIB is often referred to as just a bus. When used to host JMS applications, it is often referred to as a messaging bus. It consists of the following parts (not shown at this level of detail in the diagram).
- Bus members
Application servers added to the bus.
- Messaging engine
Manages bus resources, providing a connection point for clients to produce or from where to consume messages.
- Destinations
The place within the bus to which applications attach to exchange messages.
Destinations can represent...
- Web services endpoints
- messaging point-to-point queues
- messaging publish and subscribe topics
Destinations are created on a bus and hosted on a messaging engine.
- Message store
Each messaging engine uses a set of tables in a supported data store (such as a JDBC database) to hold information such as messages, subscription information, and transaction states.
Through the SIB Web services enablement, we can:
- Make an internal service that is already available at a service destination available as a Web service.
- Make an external Web service available at a service destination.
- Use the Web Services Gateway to map an existing service, either an internal service or an external Web service, to a new Web service that appears to be provided by the gateway.
- Bus members
- Mail, URLs, and other Java EE resources
The following kinds of Java EE resources are used by applications deployed on a J2EE-compliant appserver.
- JDBC resources and other technology for data access (previously discussed)
- JCA resource adapters (previously discussed)
- JMS resources and other messaging support (previously discussed)
- Java Mail support, for applications to send Internet mail
The Java Mail APIs provide a platform and protocol-independent framework for building Java -based mail client applications. The APIs require service providers, known as protocol providers, to interact with mail servers that run on the appropriate protocols.
A mail provider encapsulates a collection of protocol providers, including...
- Simple Mail Transfer Protocol (SMTP) for sending mail
- Post Office Protocol (POP) for receiving mail
- Internet Message Access Protocol (IMAP) as an option for receiving mail
To use another protocol, install the appropriate service provider for the protocol.
Java Mail requires not only service providers, but also the Java BeansActivation Framework (JAF), as the underlying framework to handle complex data types that are not plain text, such as MIME, URL pages, and file attachments.
- URLs, for describing logical locations
URL providers implement the functionality for a particular URL protocol, such as HTTP, enabling communication between the application and a URL resource that is served by a particular protocol.
A default URL provider is included for use by any URL resource with protocols based on the supported Java SE specification, such as HTTP, FTP, or File. We also can plug in our own URL providers that implement additional protocols.
- Resource environment entries, for mapping logical names to physical names
The name space environment...
java:comp/env
...allows lookup of both JNDI name space objects and local application environment objects
The Java EE spec also provides a mechanism for defining customer environment entries by defining entries in the standard deployment descriptor of an application, using the following methods to separate the definition of the resource environment entry from the application.
- Requiring the appserver to provide a mechanism for defining separate administrative objects that encapsulate a resource environment entry. The administrative objects are accessible using JNDI in the appserver local name space...
java:comp/env
- Specifying the admin object's JNDI lookup name and expected returned object type. This spec is performed in the aforementioned resource environment entry in the deployment descriptor.
WAS ND v7.0 supports the use of resource environment entries with the following admin concepts.
- A resource environment entry defines the binding target (JNDI name), factory class, and return object type (via the link to a referenceable) of the resource environment entry.
- A referenceable defines the class name of the factory that returns object instances implementing a Java interface.
- A resource environment provider groups together the referenceable, resource environment entries and any required custom properties.
- Requiring the appserver to provide a mechanism for defining separate administrative objects that encapsulate a resource environment entry. The administrative objects are accessible using JNDI in the appserver local name space...
Security
- Security model and infrastructure
WAS ND v7.0 provides security infrastructure and mechanisms to protect sensitive Java EE resources and admin resources and to address enterprise end-to-end security requirements on authentication, resource access control, data integrity, confidentiality, privacy, and secure interoperability.
Security infrastructure and mechanisms protect Java EE resources and admin resources, addressing the enterprise security requirements. In turn, the security infrastructure of this product works with the existing security infrastructure of the multiple-tier enterprise computing framework. Based on open architecture, WAS provides many plug-in points to integrate with enterprise software components to provide end-to-end security.
The security infrastructure involves both a model and elements of WAS architecture that are independent of the application type.
Additional services for use by applications
- Naming and directory
Each appserver provides a naming service that in turn provides a JNDI name space. The service is used to register resources hosted on the appserver. The JNDI implementation is built on top of a CORBA naming service (CosNaming).
JNDI provides the client-side access to naming and presents the model used by application developers. CosNaming provides the server-side implementation and is where its name space is actually stored. JNDI essentially provides a client-side wrapper of the name space stored in CosNaming, and interacts with the CosNaming server on behalf of the client.
Clients of the appserver use the naming architecture to obtain references to objects related to those applications. The objects are bound into a mostly hierarchical structure called the name space. It consists of a set of name bindings, each one of which is a name relative to a specific context and the object bound with that name. The name space can be accessed and manipulated through a name server.
WAS ND v7.0 provides the following naming and directory features.
- Distributed name space, for additional scalability
- Transient and persistent partitions, for binding at various scopes
- Federated name space structure across multiple servers
- Configured bindings for defining bindings bound by the system at server startup
- Support for CORBA Interoperable Naming Service (INS) object URLs
See also...
Note that with the addition of virtual member manager to provide federated repository support for product security, WAS now offers more extensive and sophisticated identity management capabilities than ever before, especially in combination with other WebSphere and Tivoli products.
- Object Request Broker (ORB)
WAS ND v7.0 uses an ORB to manage interaction between client applications and server applications, as well as among product components. An ORB uses IIOP to enable clients to make requests and receive requests from servers in a network distributed environment.
The ORB provides a framework for clients to locate objects in the network and call operations on those objects as though the remote objects were located in the same running process as the client, providing location transparency.
Although not shown in the diagram, one place in which the ORB comes into play is where the client container is contacting the EJB container on behalf of a Java client.
- Transactions
WAS ND v7.0 provides the transaction service to...
- Coordinate multiple updates to resources as atomic units (indivisible units of work) such that all or none of the updates are made permanent,
- Integrate software assets such as ActivitySessions.
Applications running on the server can use transactions to coordinate multiple updates to resources as one unit of work such that all or none of the updates are made permanent. Transactions are started and ended by applications or the container in which the applications are deployed.
The appserver is a transaction manager that supports coordination of resource managers and participates in distributed global transactions with other compliant transaction managers.
The server can be configured to interact with databases, JMS queues, and JCA connectors through their local transaction support when distributed transaction support is not required. How applications use transactions depends on the type of application...
- A session bean either can manage its transactions itself, or delegate the management of transactions to the container.
- Entity beans use container-managed transactions.
- Web components, such as servlets, use bean-managed transactions.
WAS ND v7.0 handles transactions with the following components.
- A transaction manager supports the enlistment of recoverable XAResources and ensures each resource is driven to a consistent outcome, either at the end of a transaction, or after a failure and restart of the appserver.
- A container manages the enlistment of XAResources on behalf of deployed applications when it performs updates to transactional resource managers such as databases. Optionally, the container can control the demarcation of transactions for EJB applications that have enterprise beans configured for container-managed transactions.
- An API handles bean-managed enterprise beans and servlets, allowing such application components to control the demarcation of their own transactions.
WebSphere extensions
WebSphere programming model extensions are the model benefits you gain by purchasing this product. They represent leading edge technology to enhance application capability and performance, and make programming and deployment faster and more productive.
In addition, the applications can use the Eclipse extension framework. Your applications are extensible as soon as you define an extension point and provide the extension processing code for the extensible area of the application. We can also plug an application into another extensible application by defining an extension that adheres to the target extension point requirements.
The extension point can find the newly added extension dynamically and the new function is seamlessly integrated in the existing application. It works on a cross Java EE module basis. The application extension registry uses the Eclipse plug-in descriptor format and APIs as the standard extensibility mechanism for WebSphere applications. Developers who build WebSphere application modules can use WAS extensions to implement Eclipse tools and to provide plug-in modules to contribute functionality such as actions, tasks, menu items, and links at predefined extension points in the WebSphere application.
The various WebSphere programming model extensions, and the corresponding application services that support them in the appserver runtime, can be considered in three groups...
- Business Object Model extensions
- Business Process Model extensions
- Next Generation Applications extensions
Extensions pertaining to the Business Object Model
Business object model extensions operate with business objects, such as EJB applications.
- Application profiling
Dynamically control concurrency, prefetch, and read-ahead.
Application profiling and access intent fine-tune application performance for enterprise beans without impacting source code. Different enterprise beans, and even different methods in one enterprise bean, can have their own intent to access resources. Profiling the components based on their access intent increases performance in the appserver runtime.
- Dynamic query
Dynamically build and submit queries that select, sort, join, and perform calculations on application data at runtime.
Pass in and process EJB query language queries at runtime, eliminating the need to hard-code required queries into deployment descriptors during application development.
Dynamic query improves enterprise beans by enabling the client to run custom queries on EJB components during runtime. Until now, EJB lookups and field mappings were implemented at development time and required further development or reassembly in order to be changed.
- Dynamic cache
Cache the output of servlets, commands, and JSPs. Intercept calls to cacheable objects and...
- Store the output of the object
- Serve the content of the object from the dynamic cache
Because Java EE applications have high read-write ratios and can tolerate small degrees of latency in the currency of their data, the dynamic cache can create opportunity for significant gains in server response time, throughput, and scalability.
Features include...
- Cache replication among clusters
- Cache disk offload
- Edge side include caching
- External caching - Control caches outside of the appserver, such as that of the Web server.
Extensions pertaining to the Business Process Model
Business process model extensions provide process, workflow functionality, and services for the appserver. Use them in conjunction with business integration capabilities.
- ActivitySessions
Reduce the complexity of dealing with limitations associated with one-phase commit resources by grouping multiple local transactions, allowing commits based on deployment criteria.
- Web services
Connect resources and data in a flexible and standardized manner.
Extensions for creating next generation applications
WebSphere programming extensions......
- Asynchronous beans
Enable performance enhancements for resource-intensive tasks by allowing single tasks to run as multiple tasks.
Asynchronous scheduling facilities can also be used to process parallel processing requests in "batch mode" at a designated time. WAS ND v7.0 provides full support for asynchronous execution and invocation of threads and components within the appserver. The appserver provides execution and security context for the components, making them an integral part of the application.
- Startup beans
Enable the automatic execution of business logic when the appserver starts or stops.
For example, startup beans might be used to pre-fill application-specific caches, initialize application-level connection pools, or perform other application-specific initialization and termination procedures.
- Object pools
Used to improve application performance at runtime, by allowing multiple instances of objects to be reused. This reuse reduces the overhead associated with instantiating, initializing, and garbage-collecting the objects. Creating an object pool allows an application to obtain an instance of a Java object and return the instance to the pool when it has finished using it.
- Internationalization
Automatically recognize the time zone and location information of the calling client, so that the application can act appropriately. Deliver each user, around the world, the right date and time information, the appropriate currencies and languages, and the correct date and decimal formats.
- Scheduler
Start actions at specific times or intervals. Helps minimize IT costs and increase application responsiveness by maximizing utilization of existing computing resources. The scheduler service provides the ability to...
- process workloads using parallel processing
- set specific transactions as high priority
- schedule less time-sensitive tasks to process during low traffic off-hours
- Work areas
Similar to "global variables." Used for passing contextual information between application components.
For example, adding profile information to a work area makes it available throughout the application and for all the customers, eliminating the need to hand-code a solution or to read or write information to a database.
Subtopics
Specifications and API documentationWeb apps
Learn about Web apps
Introduction: Web apps
Introduction: Portlet applications
Learn about portlet applications
Introduction: SIP applications
Learn about SIP applications
EJB applications
Introduction: EJB applications
Learn about EJB applications
Client modules
Introduction: Client applications
Learn about client applications
Web services
Introduction: Web services
Learn about Web services
Data access resources
Introduction: Data access resources
Learn about data access resources
Messaging resources
Introduction: Messaging resources
Messaging: Links
Mail, URLs, and other J2EE resources
Introduction: Mail, URLs, and other Java EE resources
Learn about mail, URLs, and other Java EE resources
Security
Introduction: Security
Introduction: Naming and directory
Learn about naming and directory
Learn about Object Request Brokers (ORB)
Introduction: Object Request Broker
Introduction: Transactions
Learn about transactions
Related concepts
Object Request BrokersLearn about WebSphere programming extensions