WAS 7.0 - Overview and New Features
WAS 7.0 - Overview and New Features
WAS 7.0 - Overview and New Features
Use the Learn about WebSphere applications section as a starting point to study the programing model, encompassing the
many parts used in and by various application types supported by the application server.
The programming model for applications deployed on this product has the following aspects.
Java™ specifications and other open standards for developing applications
WebSphere® programming model extensions to enhance application functionality
Containers and services in the application server, used by deployed applications, and which sometimes can be
extended
The diagram shows a single application server installation. The parts pertaining to the programming model are discussed here.
Other parts comprise the product architecture, independent of the various application types outlined by the programming model.
See WebSphere Application Server product architecture.
Java EE application components
The product supports application components that conform to Java Platform, Enterprise Edition (Java EE) specifications.
Web applications run in the Web container
The Web container is the part of the application server in which Web application components run. Web applications are
comprised of one or more related servlets, JavaServer Pages technology (JSP files), and Hyper Text Markup Language
(HTML) files that you can manage as a unit. Combined, they perform a business logic function.
The Web container processes servlets, JSP files, and other types of server-side includes. Each application server
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 a
TCP inbound channel that provides the connection to the network, an HTTP inbound channel that serves HTTP
requests, and a Web container channel over which requests for servlets and JSP files are sent to the Web container for
processing.
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, and filtering data.
JSP files enable the separation of the HTML code from the business logic in Web pages. IBM® extensions to the JSP
specification make it easy for HTML authors to add the power of Java technology to Web pages, without being experts
in Java programming.
An HTTP session is a series of requests to a servlet, originating from the same user at the same browser. Sessions
allow applications running in a Web container to keep track of individual users. For example, many Web applications
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 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 are special reusable Java servlets that appear as defined regions on portal pages. Portlets provide
access to many different applications, services, and Web content.
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 application server do not communicate
directly with the server. Instead, the EJB container is an interface between EJB components and the application server.
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 administrative
perspective, the container handles data access for the contained beans. A single container can host more than one
EJB Java archive (JAR) file.
This product 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 services
Web services
The diagram shows the Web services engine, part of the Web services support in the application server 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.
The product 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.
The connection between the enterprise application and the EIS is done through the use of EIS-provided resource
adapters, which are plugged into the application server. The architecture specifies the connection management,
transaction management, and security contracts between the application server and EIS.
The Connection Manager (not shown) in the application server pools and manages connections. It is capable of
managing connections obtained through both resource adapters defined by the JCA specification 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 application servers or clients and an EIS. To use a resource adapter, install
the resource adapter code and create configurations that use that adapter. The product provides a predefined relational
resource adapter for your use.
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 the product.
For transitioning users: Version 6 replaces the Version 5 concept of a JMS server with a messaging
engine built into the application server, offering the various kinds of providers mentioned previously. The
Version 5 messaging provider is offered for configuring resources for use with Version 5 embedded
messaging. You also can use the Version 5 default messaging provider with a service integration bus.
EJB 2.1 introduces an ActivationSpec for connecting message-driven beans to destinations. For compatibility
with Version 5, 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.
The service integration bus provides a unified communication infrastructure for messaging and service-oriented
applications. The service integration bus is a JMS provider that provides reliable message transport and uses
intermediary logic to adapt message flow intelligently into the network. It supports the attachment of Web services
requestors and providers. Its capabilities are fully integrated into product architecture, including the security, system
administration, monitoring, and problem determination subsystems.
The service integration bus 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
The component that manages bus resources. It provides 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, or 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 service integration bus Web services enablement, you 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.
Mail, URLs, and other Java EE resources
The following kinds of Java EE resources are used by applications deployed on a J2EE-compliant application server.
JDBC resources and other technology for data access (previously discussed)
JCA resource adapters (previously discussed)
JMS resources and other messaging support (previously discussed)
JavaMail support, for applications to send Internet mail
The JavaMail 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; and Internet Message Access Protocol (IMAP)
as another option for receiving mail. To use another protocol, you must install the appropriate service provider
for the protocol.
JavaMail requires not only service providers, but also the JavaBeans™ Activation Framework (JAF), as the
underlying framework to handle complex data types that are not plain text, such as Multipurpose Internet Mail
Extensions (MIME), URL pages, and file attachments.
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 Platform,
Standard Edition (Java SE) specification, such as HTTP, FTP, or File. You also can plug in your own URL
providers that implement additional protocols.
The java:comp/env environment provides a single mechanism by which both the JNDI name space objects and
local application environment objects can be looked up. The product provides numerous local environment
entries by default.
The Java EE specification also provides a mechanism for defining customer environment entries by defining
entries in the standard deployment descriptor of an application. The Java EE specification uses the following
methods to separate the definition of the resource environment entry from the application.
o Requiring the application server to provide a mechanism for defining separate administrative objects
that encapsulate a resource environment entry. The administrative objects are accessible using JNDI
in the application server local name space (java:comp/env).
o Specifying the administrative object's JNDI lookup name and expected returned object type. This
specification is performed in the aforementioned resource environment entry in the deployment
descriptor.
The product supports the use of resource environment entries with the following administrative concepts.
o 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.
o A referenceable defines the class name of the factory that returns object instances implementing a
Java interface.
o A resource environment provider groups together the referenceable, resource environment entries and
any required custom properties.
Look at the main tasks and more overviews
Dig deeper into the main concepts
Security
Security programming model and infrastructure
The product provides security infrastructure and mechanisms to protect sensitive Java EE resources and administrative
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 Platform, Enterprise Edition (Java EE) resources and
administrative resources, addressing your enterprise security requirements. In turn, the security infrastructure of this
product works with the existing security infrastructure of your multiple-tier enterprise computing framework. Based on
open architecture, the product provides many plug-in points to integrate with enterprise software components to provide
end-to-end security.
The security infrastructure involves both a programming model and elements of the product architecture that are
independent of the application type.
JNDI provides the client-side access to naming and presents the programming 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 application server 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.
Note that with the addition of virtual member manager to provide federated repository support for product security, the
product now offers more extensive and sophisticated identity management capabilities than ever before, especially in
combination with other WebSphere and Tivoli® products.
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.
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 application server 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, for example:
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.
The product 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 application
server.
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.
Look at the main tasks and more overviews
Dig deeper into the main concepts
WebSphere extensions
WebSphere programming model extensions are the programming 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, your 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. You 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 Platform, Enterprise Edition (Java
EE) module basis. The application extension registry uses the Eclipse plug-in
descriptor format and application programming interfaces (APIs) as the standard
extensibility mechanism for WebSphere applications. Developers who build
WebSphere application modules can use WebSphere Application Server 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. For more information about this feature, see Application
extension registry.
Business object model extensions operate with business objects, such as enterprise
bean (EJB) applications.
Application profiling
Application profiling is a WebSphere extension for defining strategies to dynamically control concurrency, prefetch, and
read-ahead.
Application profiling and access intent provide a flexible method to 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 application server runtime.
Dynamic query
Dynamic query is a WebSphere programming extension for unprecedented application flexibility. It lets you dynamically
build and submit queries that select, sort, join, and perform calculations on application data at runtime. Dynamic Query
service provides the ability to 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
The dynamic cache service improves performance by caching the output of servlets, commands, and JSP files. This
service within the application server intercepts calls to cacheable objects and either stores the output of the object or
serves 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, and external caching
- the ability to control caches outside of the application server, such as that of your Web server.
ActivitySessions provide the ability to extend the scope of multiple local transactions, and to group them. This enables
them to be committed based on deployment criteria or through explicit program logic.
Web services
Web services are self-contained, modular applications that can be described, published, located, and invoked over a
network. They implement a services oriented architecture (SOA), which supports the connecting or sharing of
resources and data in a very flexible and standardized manner. Services are described and organized to support their
dynamic, automated discovery and reuse.
Look at the main tasks and more overviews
Dig deeper into the main concepts
Work areas enable efficient sharing of information across a distributed application. For example, you might want to add
profile information as each customer enters your application. By placing this information in a work area, it will be
available throughout your application, eliminating the need to hand-code a solution or to read and write information to a
database.
Subtopics
Specifications and API documentation
Web applications
Learn about Web applications
Introduction: Web applications
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: Resources for learning
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 Brokers
Learn about WebSphere programming extensions
Concept topic