What is new for developers

What is new for developers

This topic highlights what is new or changed in v6.x for users who are going to develop and assemble WebSphere applications.
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 J2EE specification.
In addition, deploying applications has never been easier -- particularly redeploying updated applications or modules. For what is new with deployment, see New: Application deployment improvements.
The remainder of this topic describes smaller but significant changes in the development and assembly infrastructure, and for various types of WebSphere applications.

WebSphere Application Server supports 64-bit environments WebSphere Application Server now 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, 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.

WebSphere extensions
Several more WebSphere extensions are now available in this product edition, with new features relative to their recent inclusion in the WebSphere Business Integration Server Foundation, V5.1 release. As a starting point for learning about each extension, see WebSphere programming extensions. See also the WebSphere extensions section in WebSphere applications: Overview and new features.

Service Data Objects (SDO)
As Introduction to Service Data Objects explains, the SDO framework makes the J2EE data programming model simpler, so one can focus on the business logic of your applications.
For information about using SDO with your WAS v6.x applications, see Data access with Service DataObjects.

Web services
WebSphere Application Server has been a leader in advocating support for Web services standards that allow more automated, less hand-coded cross-platform computing. New 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 WebSphere Application Server v6.x supports the WS-I Basic Profile 1.1 for development of interoperable Web services supporting the integration of Web services solutions. WAS also supports 30 operating system platforms, the most in the industry.
More detail about Web services support is provided in the following items.

Enterprise beans can be invoked from a Web services client using RMI-IIOP
WebSphere Application Server v6.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. We can invoke Web services using protocols with the transport such as SOAP and RMI.
With v6.x, one 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.
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.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 Extensions to the JAX-RPC and Web Services for J2EE 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. We can override these default values with command-line arguments. The Java2WSDL command is protocol independent; when you run the Java2WSDL command, one 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: 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 and WSDL2Java command.

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.

Related Information

What is new in this release

WebSphere Application Server supports 64-bit environments	WebSphere Application Server now 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, 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.

WebSphere extensions	Several more WebSphere extensions are now available in this product edition, with new features relative to their recent inclusion in the WebSphere Business Integration Server Foundation, V5.1 release. As a starting point for learning about each extension, see WebSphere programming extensions. See also the WebSphere extensions section in WebSphere applications: Overview and new features.

Service Data Objects (SDO)	As Introduction to Service Data Objects explains, the SDO framework makes the J2EE data programming model simpler, so one can focus on the business logic of your applications. For information about using SDO with your WAS v6.x applications, see Data access with Service DataObjects.

Web services	WebSphere Application Server has been a leader in advocating support for Web services standards that allow more automated, less hand-coded cross-platform computing. New 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 WebSphere Application Server v6.x supports the WS-I Basic Profile 1.1 for development of interoperable Web services supporting the integration of Web services solutions. WAS also supports 30 operating system platforms, the most in the industry. More detail about Web services support is provided in the following items.

Enterprise beans can be invoked from a Web services client using RMI-IIOP	WebSphere Application Server v6.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. We can invoke Web services using protocols with the transport such as SOAP and RMI. With v6.x, one 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. 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.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 Extensions to the JAX-RPC and Web Services for J2EE 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. We can override these default values with command-line arguments. The Java2WSDL command is protocol independent; when you run the Java2WSDL command, one 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: 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 and WSDL2Java command.

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.