This version contains many new and changed features for application
developers.
| Web services
|
This product has been a leader in advocating
support for Web services standards that allow more automated, less hand-coded
cross-platform computing. Standards support includes WS-Security, which authenticates
communications between web services, and WS-Transactions, which is designed
to assure that Web Services transactions are consistently delivered. Additionally,
the product supports the WS-I Basic Profile 1.1 for development of interoperable
Web services supporting the integration of Web services solutions.
See Task overview: Implementing Web services applications.
|
| WS-Transaction affinity, routing, and authorization
| New in V6.1! The implementation
in this product version removes 6.0 limitations to provide Web services the
same level of distributed transaction support as enterprise beans using CORBA:
- WS-AT contexts use virtual host names and can span firewalls
- Application requests with WS-AT contexts can place transactional affinity
constraints on client-side workload management.
- WS-AT protocol messages can be secured.
This product implements a standards-based solution to allow Web
services on disparate systems to take part in global transactions with ACID
properties. Transactions can span between JTA and J2EE and WS-AT/Web services
domains in a seamless manner, requiring no additional programming.
Web
services on disparate systems can take part in a compensation model in which
compensational scopes span J2EE components and WS-BA/Web services domains
in a seamless manner, requiring no additional programming. Applications distributed
between WebSphere Application Server and other vendor solutions, for example
Microsoft .NET, can take part in the same global transaction.
See Web Services Atomic Transaction support in WebSphere Application Server.
|
| WS-Notification support – “pub/sub for
Web services”
|
New in V6.1! The WS-Notification
v1.3 specifications have been added to the WebSphere programming model. Informally
described as ‘pub/sub for web services,’ this family of specifications define
web service message exchanges (such as an application interface) to enable
web service applications to utilize the ‘publish and subscribe’ messaging
pattern. Traditionally, publish and subscribe messaging is used in message
oriented middle ware scenarios to implement a one-to-many distribution pattern.
In
the publish and subscribe pattern a producing application inserts (publishes)
a message (event notification) into the messaging system, having marked it
with a topic that indicates the subject area of the message. Consuming applications
that have subscribed to the topic and have the appropriate authority, receive
an independent copy of the message that was published by the producing application.
WS-Notification
also allows interchange of event notification between WS-Notification applications
and other clients of the service integration bus. By exploiting other service
integration bus functionality, you can use this function to interchange messages
with other IBM publish and subscribe brokers such as Event Broker or Message
Broker.
For more information, refer to WS-Notification
- publish and subscribe messaging for Web services.
|
| WS-Addressing support -- "protocol independent
interoperability for Web services"
|
New in V6.1! The product
offers support and interoperability with the latest WS-Addressing specifications
from W3C, while maintaining interoperability with the pre-W3C specification.
This family of specifications provides transport-neutral mechanisms to address
Web services and to facilitate end-to-end addressing.
This product version
provides a programming interface to support referencing and targeting of Web
service endpoints that represent WS-Resource instances, as defined by the
WS-Resource Framework specification. Additionally, this version introduces
a programming interface to allow programmers to create, reason about and manipulate
WS-Addressing artifacts. Programmers can specify the WS-Addressing Message
Addressing Properties for outbound messages and also acquire WS-Addressing
Message Properties from the incoming message at the receiving endpoint.
See Web Services Addressing support.
|
| Enterprise beans can be invoked from a
Web services client using RMI-IIOP
|
WebSphere Application Server V6.0.x
supports directly accessing an enterprise JavaBean (EJB) as a Web service,
as an alternative to using HTTP or Java Message Service (JMS) to transport
requests between the server and the client.
Java API for XML-based Remote
Procedure Call (JAX-RPC) is the Java standard API for invoking Web services
through remote procedure calls. A transport is used by a programming language
to communicate over the Internet. You can invoke Web services using protocols
with the transport such as SOAP and RMI.
With
V6.0.x, you can use Remote Method Invocation over Internet Inter-ORB
Protocol (RMI-IIOP) with JAX-RPC to support non-SOAP bindings. Using RMI-IIOP
with JAX-RPC enables WebSphere Java clients to invoke enterprise beans using
a WSDL file and the JAX-RPC programming model instead of using the standard
J2EE programming model. When a Web service is implemented by an EJB, multiprotocol
JAX-RPC permits the Web service invocation path to be optimized for WebSphere
Java clients.
Using the RMI/IIOP protocol instead of a SOAP- based protocol
yields better performance and enables you to get support for client transactions,
which are not standard for Web services. Benefits include -- XML processing
is not required to send and receive messages; Java serialization is used instead.
The client JAX-RPC call can participate in a user transaction, which is not
the case when SOAP is used.
For more information, refer to Using WSDL EJB bindings to invoke an EJB from a Web services client .
|
| New extensions to the JSR-101 and JSR-109
programming models
| WebSphere Application Server V6.0.x
provides extensions to the Java Specification Request JSR-101 and JSR-109
client programming models. These extensions include the following:
- The REQUEST_TRANSPORT_PROPERTIES property and RESPONSE_TRANSPORT_PROPERTIES
property can be added to a Java API for XML-based RPC (JAX-RPC) client Stub
to enable a Web services client to send or retrieve HTTP transport headers.
- Implementation-specific support for javax.xml.rpc.ServiceFactory.loadService()
as described by the JSR-101 and JAX-RPC specifications. The loadService methods
create an instance of the generated service implementation class in an implementation-specific
manner. The loadService methods are new for JAX-RPC 1.1 and include three
public.javax.xml.rpc.Service loadService signatures.
For more information, refer to Implementing extensions to the JAX-RPC and Web Services for J2EE client
programming models.
|
| Updates to options used by the emitter
tools Java2WSDL and WSDL2Java
|
The Java2WSDL command maps a Java
class to a Web Services Description Language (WSDL) file by following the
Java API for XML-based remote procedure call (JAX-RPC) 1.1 specification.
The Java2WSDL command accepts a Java class as input and produces a WSDL file
that represents the input class. If a file exists at the output location,
it is overwritten. The WSDL file that is generated by the Java2WSDL command
contains WSDL and XML schema constructs that are automatically derived from
the input class. You can override these default values with command-line arguments.
The Java2WSDL command is protocol independent; when you run the Java2WSDL
command, you can specify command-line options that generate both SOAP and
non-SOAP protocol bindings in the WSDL file. For each binding that can be
generated, the Java2WSDL command has a binding generator to generate the WSDL
for that binding.
New option: Use the -bindingTypes option of
the Java2WSDL command to create a WSDL file that contains non-SOAP protocol
bindings. The -bindingTypes option specifies the binding types to be written
to the output of the WSDL document. Review the Java2WSDL article for more
information on using the -bindingTypes option.
The WSDL2Java command
is run against a Web Services Description Language (WSDL) file to create Java
APIs and deployment descriptor templates. A WSDL file describes a Web service.
The Java API for XML-based remote procedure call (JAX-RPC) 1.1 specification
defines a Java API mapping that interacts with the Web service. The Java Specification
Requirements (JSR) 109 1.1 specification defines deployment descriptors that
deploy a Web service in a Java 2 Platform Enterprise Edition (J2EE) environment.
The WSDL2Java command is run against the WSDL file to create Java APIs and
deployment descriptor templates according to these specifications.
For
more information, refer to Java2WSDL command for JAX-RPC applications and WSDL2Java command for JAX-RPC applications.
|
| Additional HTTP transport properties for
Web services applications
|
JVM custom properties are available to
manage the connection pool for Web services HTTP outbound connections. Establishing
a connection is an expensive operation. Connection pooling improves performance
by avoiding the overhead of creating and disconnecting connections. When an
application invokes a Web service over an HTTP transport, the HTTP outbound
connector for the Web service locates and uses an existing connection from
a pool of connections. When the response is received, the connector returns
the connection to the connection pool for reuse. The overhead to create and
disconnect the connection is avoided.
See Configuring additional HTTP transport properties using the JVM custom
property panel in the administrative console.
|
| J2EE 1.4 support
|
J2EE 1.4 specification support is the basis
of this product's programming model. It enables you to take advantage of the
latest Java technology, as described in J2EE specification.
|
| WebSphere extensions
|
Several more WebSphere extensions are now
available in this product edition. As a starting point for learning about
each extension, see Learn about WebSphere programming extensions.
See also the WebSphere extensions section in Learn about WebSphere applications: Overview and new features.
|
| Portlet application support (JSR 168)
|
New in V6.1! Developers can
write portlets, in addition to servlets. Administrators can configure, manage,
and run portlet applications. Users can access the portlets with URLs, as
they do servlets.
See Introduction: Portlet applications.
|
| Remote RequestDispatch calls are handled
the same as local calls
|
New in V6.1! Now you can
deploy portlets in web applications into separate application server instances
with their own virtual machines, but call the portlets with the request dispatcher,
just as you would call portlets in local Web applications. This supports application
isolation to keep one portlet from bringing down the entire portal server.
Complexity and differentiation between remote and local calls is minimized
for the administrator.
See Remote request dispatcher.
|
| Real time collaboration features in applications
(JSR 116)
|
New in V6.1! The application
programming model has been extended to include Session Initiation Protocol
(SIP) servlet applications. Developers can write SIP applications, which 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.
An IETF standard, the
SIP protocol (JSR 116) supports clients registration, presence management,
and media session negotiation. Media sessions can include such diverse media
as text chat, IP audio/video, application sharing, and electronic whiteboards.
Applications are growing rapidly, from telecoms and wireless providers, call
centers, pervasive computing, and Customer Relationship Management (CRM).
The SIP proxy can route SIP or HTTP with enterprise class availability.
See Introduction: SIP applications.
|
| Java 5 Software Development Kit (SDK)
|
New in V6.1! Developers can
use many new API libraries, including generics, auto boxing of primitives,
annotations, and enumerated types.
See Migrating to Java 2 Standard Edition (J2SE) 5.
|
| Reliable World Type and Devanagari font
availability
|
New in V6.1! The World Type
fonts and Devanagari font are available as an e-fix from the product Support
site. This is to help mitigate the variance in font coverage among Linux distributions,
especially the Asian language versions.
See Packaging for
more information about the fonts.
|
| Added serialVersionUID (SUID) to handle
imposing explicit version control for serialized classes
| Classes implementing the Serializable interface
have added serialVersionUID (SUID) to impose explicit version control for
Java serialization. A serialVersionUID identifies the unique original class
version for which a class is capable of writing streams and also from which
that class can be read.
 Best practice: bprac
As
you develop your applications, IBM recommends that your classes implementing
the Serializable interface use serialVersionUID (SUID) to impose explicit
version control for Java serialization.
|
| IBM JSF widget library for improved Web
pages
|
New in V6.1! IBM JSF Widget
Library (JWL) is provided as an optional library in WAS. Applications can
use the library when it is included in the Shared Library path. FacesClient
Framework enabled Web pages are able to sustain longer interactions with the
end user without requiring roundtrips back to the server. By creating what
effectively is an MVC (Model View Controller) model inside the page, a developer
is able to define a working set and a set of controls that dynamically bind
to that data. The user can then interact with the working data set, using
those controls, and until a roundtrip back to the server is really necessary
(for example, to submit data), the user benefits from response times and a
freedom to interact with the page that is uncommon in regular Web pages.
For
an enterprise that deploys FacesClient Framework enabled Web pages, in addition
to increased user satisfaction due to a more interactive and more responsive
application, it also benefits in other areas such as lower consumption of
server-side resources. Because of the lower amount of roundtrips, and smaller
page size relatively speaking, the enterprise is able to scale its server
infrastructure and bandwidth further, accommodating more users in the current
setup. Applications overall are simpler to develop and maintain. By enabling
an MVC-like model on the page, the FacesClient Framework enables a development
model based on standards such as JSF (Java Server Faces).
See JavaServer Faces widget library (JWL).
|
| Java Server Faces (JSF) 1.1 support
|
New in V6.1! V6.1
introduces the ability to use JSF 1.1 (JSR 127) in your Java-based Web applications
without including the JSF runtime libraries in your application, meaning you
can produce smaller applications. The JSF 1.1 DTD will be provided as part
of the application server runtime. The JSF specification provides migration
instructions and does not list any deprecations. Your JSF 1.0 applications
will continue to run without modification.
See JavaServer Faces.
|
| Functionality for implfactory.properties has
moved
|
The app_server_root/profiles/profile_name/properties/implfactory.properties file
in V5 of WebSphere Application Server has been eliminated in Version
6 and its functionality has moved to META-INF/impl-factory.xml in
the runtime.jar file. You now set the access permissions for this property
by using META-INF/impl-factory.xml.
|
| Service Data Objects (SDO)
|
As Introduction to Service Data Objects explains,
the SDO framework makes the J2EE data programming model simpler, so you can
focus on the business logic of your applications.
See Data access with Service DataObjects.
|
| Easier programming of disconnected data
objects
|
New in V6.1! An enhanced
EJB Service Data Object (SDO) Mediator simplifies the programming model. Current
techniques for implementing a disconnected data objects involve a combination
of copy helper objects, session beans and EJB access beans. Using the EJB
mediator reduces the amount of programming. Dynamic data objects provide flexibility
and eliminate the need to define copy helper type objects. Increased performance
can be achieved with optimized queries and having the EJB mediator read and
write directly to the data store, bypassing the need to activate EJB instances.
In addition, the EJB Mediator allows the EJB entity bean programming model
and the EJB query language to provide services that can send or receive SDOs.
See Enterprise JavaBeans Data Mediator Service.
|
| Cloudscape 10.1.x database support
| New in V6.1! WebSphere Application
Server supports Cloudscape v10.1.x as a test and development database. The
new Cloudscape is a pure Java database server. The code base, which the open
source community calls Derby, is a product of the Apache Software Foundation
(ASF) open source relational database project. Cloudscape 10.1.x highlights
include:
- com.ibm.db2j.* becomes org.apache.derby.*:
- org.apache.derby.drda contains the networkServerControl to manipulate
the NetworkServer process
- org.apache.derby.jdbc contains the JDBC classes
- org.apache.derby.tools contains the tools like ij and sysinfo dblook
- db2j.properties file becomes derby.properties
- db2j.system.home becomes derby.system.home
- db2j.drda.* becomes derby.drda.*
See the Cloudscape section of ibm.com: http://www.ibm.com/software/data/cloudscape/.
|
| Easier to configure access to WebSphere
MQ queues from the service integration bus
|
New in V6.1! The service
integration bus offers improved, easier to configure connectivity to WebSphere
MQ software. An application connected to the bus now can read messages directly
from any z/OS WMQ queue, reducing your need to repeat MQ configuration details.
Version
6.0 did not allow pulling messages directly from MQ queues, which could only
be configured as “foreign destinations.” In this version, a bus destination
can act as a proxy for a z/OS WMQ Queue. JMS applications (including those
using message driven beans) can access WMQ queues through such destinations.
Requests to both send and receive messages against a destination that is acting
as a proxy are delegated to the Queue Manager of the MQ queue, using MQ client
protocols including XA flows. This capability enables queue access to be
coordinated as part of a global transaction running in WebSphere Application Server.
As
a starting point, see Learn about WebSphere applications > Service integration in
the WebSphere Application Server information center
navigation.
|
| Flexibility in storage options
|
New in V6.1! Storage options
now include using the file system instead of a relational database. The message
store component of a service integration bus messaging engine can be configured
to use the file system for persistent storage as an alternative to using a
relational database. New messaging engines are configured with a file-system-based
message store by default. Options are provided in the console wizard and related
scripting commands to specify directories and storage file sizes. Options
also exist to select a relational-database-based message store.
As a
starting point, see Learn about WebSphere applications > Service integration in
the WebSphere Application Server information center
navigation.
|