What is new for developers

What is new for developers

+
Search Tips | Advanced Search

WAS v6.1 contains many new and changed features for application developers.
Deprecated and removed features describes features that are being replaced or removed in this or future releases.

Web services

Web services
WAS 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.
WS-Transaction affinity, routing, and authorization The implementation in WAS 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.

WAS 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 WAS and other vendor solutions, for example Microsoft .NET, can take part in the same global transaction.
WS-Notification support – “pub/sub for Web services”
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"
WAS 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.
WAS 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
WAS V6.0.x supports directly accessing an enterprise JavaBean (EJB) as a Web service, as an alternative to using HTTP or 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.
Use 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 Use WSDL EJB bindings to invoke an EJB from a Web services client .
New extensions to the JSR-101 and JSR-109 programming models WAS V6.0.x provides extensions to the Java Specification Request JSR-101 and JSR-109 client programming models. These extensions include...

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 J2EE (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 Configure additional HTTP transport properties using the JVM custom property panel in the console.

Changes to the programming model

J2EE 1.4 support
J2EE 1.4 specification support is the basis of WAS'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 WAS 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)
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
Now you can deploy portlets in web applications into separate appserver 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)
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)
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
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.
64-bit support can affect applications using JNI WAS 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.
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, it is recommended 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
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
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 appserver 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 WAS 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.

Data access resources

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
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 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/.

Messaging resources

Easier to configure access to WebSphere MQ queues from the service integration bus
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 WAS.
As a starting point, see Learn about WebSphere applications > Service integration in the WAS information center navigation.
Flexibility in storage options
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 WAS information center navigation.

Improved development and assembly tools

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:

The server editor has an option to optimize a WAS v6.x server for testing and developing. This option can reduce the startup time of the server. For details on the Optimize server for testing and developing check box, see Reducing the startup time for WebSphere Application Server v6 in the online help.

For EJB 2.x container managed persistence (CMP) entity beans, you can use a partial operation to specify how you want to update the persistent attributes of the CMP bean to the database. Use the UPDATE_ONLY option for the partial operation to limit updates to the database to only persistent attributes of the CMP bean modified. You can specify the partial operation as a persistent option at the bean-level in the access intent policy configured for the bean. For details on how to use the Partial Operation check box, see Partial operation for container managed persistence in the online help.

You can specify Derby v10 as a valid database vendor backend ID when generating EJB deployment code. See The ejbdeploy command in the online help.

You can specify the -dbvendor option for a mapped JAR file. In releases previous to v6.0.2, if the -dbvendor option is specified for mapped JAR files, the database vendor specification is ignored. Specifying the database vendor in the ejbdeploy command is used for generating new top-down maps. If omitted, then the ejbdeploy command uses a default value: DB2UDB_V81. For 2.x CMP beans, multiple mappings to different database vendors are supported. 1.1 CMP beans can only be mapped once. For details on the -dbvendor option, see the online help.

See Assembly tools.

Related information
What is new in this release

Web services	WAS 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.
WS-Transaction affinity, routing, and authorization	The implementation in WAS 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. WAS 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 WAS and other vendor solutions, for example Microsoft .NET, can take part in the same global transaction.
WS-Notification support – “pub/sub for Web services”	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"	WAS 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. WAS 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	WAS V6.0.x supports directly accessing an enterprise JavaBean (EJB) as a Web service, as an alternative to using HTTP or 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. Use 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 Use WSDL EJB bindings to invoke an EJB from a Web services client .
New extensions to the JSR-101 and JSR-109 programming models	WAS V6.0.x provides extensions to the Java Specification Request JSR-101 and JSR-109 client programming models. These extensions include... 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 J2EE (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 Configure additional HTTP transport properties using the JVM custom property panel in the console.

J2EE 1.4 support	J2EE 1.4 specification support is the basis of WAS'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 WAS 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)	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	Now you can deploy portlets in web applications into separate appserver 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)	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)	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	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.
64-bit support can affect applications using JNI	WAS 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.
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, it is recommended 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	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	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 appserver 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 WAS 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.