This version contains many new and changed features for application developers.
The biggest improvement in development is support for the J2EE 1.4 specification, enabling you to take advantage of the latest Java technology, as described in Java 2 Platform, Enterprise Edition (J2EE) specification . All editions, including WebSphere Application Server Express, are J2EE 1.4 compliant.
Another big change is the inclusion of several WebSphere programming model extensions in all WebSphere Application Server editions that were formerly available only in certain editions. As a starting point for learning about the available extensions, see Learn about WebSphere programming extensions .
In addition, deploying applications has never been easier -- particularly redeploying updated applications or modules. For what is new with deployment, see What is new for administrators .
Deprecated and removed features describes features that are being replaced or removed in this or future releases.
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. |
Enterprise beans can be invoked from a Web services client using RMI-IIOP | WebSphere Application Server Version 6.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 Remote Method Invocation (RMI). With Version 6.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 Version 6.0.x
provides extensions to the Java Specification Request JSR-101 and JSR-109
client programming models. These extensions include the following:
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. |
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 Java 2 Platform, Enterprise Edition (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 . |
64-bit support can affect applications using JNI | WebSphere Application Server supports 64-bit environments. For most J2EE applications, support for 64-bit environments is not a concern. However, it is a concern for applications that use Java Native Interface (JNI) code. An application that uses JNI code might not start after deployment. The JNI allows Java code running in a virtual machine to operate with applications and libraries written in other languages, such as C, C++, and assembly. If your J2EE application uses JNI in a 32-bit environment, you must recompile your code in a 64-bit environment. The JNI calls might be different after the compilation because JNI specifications can change from version to version. |
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.
![]() |
Functionality for implfactory.properties has moved | The app_server_root/profiles/profile_name/properties/implfactory.properties file in Version 5 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. |
Easier deployment | Deploying applications has never been easier -- particularly redeploying updated applications or modules. For what is new with deployment, see What is new for administrators . |
Updates to Application Server Toolkit | Application Server Toolkit has the following capability:
See Assembly tools . |