This version contains many new and changed features for application developers.
Support for the WS-ReliableMessaging standard was first introduced as part of the IBM WebSphere Application Server Version 6.1 Feature Pack for Web Services. At that time, the Reliable Asynchronous Messaging Profile (RAMP) Version 1.0 specification used WS-ReliableMessaging to ensure the reliable delivery of messages, and the Feature Pack for Web Services in WebSphere Application Server Version 6.1 included default policy sets that support this specification. You can migrate WebSphere Application Server Version 6.1 WS-ReliableMessaging configurations that use RAMP-based policy sets to the current version of the product.
Following on from the RAMP Version 1.0 specification, the Web Services Interoperability organization (WS-I) Reliable Secure Profile working group has developed Version 1.0 of an interoperability profile dealing with secure, reliable messaging capabilities for Web services. This profile is similar to RAMP Version 1.0, except that it is updated to use WS-ReliableMessaging Version 1.1 with the OASIS WS-SecureConversation Version 1.3 specification. The WS-I RSP default policy sets provided in this version of WebSphere Application Server are an implementation of the Reliable Secure Profile Version 1.0 specification.
If you create JAX-WS based WS-Notification services, you can apply WS-ReliableMessaging policies to them to make your WS-Notification services reliable. For more information, see Configuring WS-Notification for reliable notification.
The WS-Policy implementation in WebSphere Application Server supports Web Services Reliable Messaging Policy Assertion Version 1.0 and Web Services Reliable Messaging Policy Assertion Version 1.1. For more information, see WS-Policy.
This release introduces resource commit ordering, where you control the order in which transactional resources are processed during two-phase commit processing. Resource commit ordering can increase the occurrence of one-phase commits and therefore improve performance, and reduce problems caused by transaction isolation.
A business-level application is an administration model that provides the entire definition of an application as it makes sense to the business. It is a WebSphere® configuration artifact, similar to a server, that is stored in the product configuration repository. A business-level application can contain artifacts such as Java Platform, Enterprise Edition (Java EE) applications or modules, shared libraries, data files, and other business-level applications. You might use a business-level application to group related artifacts or to add capability to an existing application. For example, suppose you want to add capability provided in a Java archive (JAR) to a Java EE application already deployed on a product server. You can add that capability by creating a new business-level application and adding the JAR file and the deployed Java EE application to the business-level application. In some cases, you do not even need to change the deployed Java EE application configuration to add the capability.
DB2 Performance Expert Extended Insight (PEEI) allows you to monitor, identify, and resolve performance issues for your entire stack and not just the database layer. These features provide results with a granularity to accurately pinpoint the cause and the culprit of the issue, allowing you to quickly resolve the problem and minimize downtime for your environment.
This release introduces a new way to enable WS-Addressing. You can now use JAX-WS 2.1 annotations and feature classes to enable WS-Addressing from either the server or the client. You also have more control over the behavior of WS-Addressing when using policy sets; you can specify whether WS-Addressing is enabled and whether to use synchronous, asynchronous, or both messaging patterns.
"S1000"=;1062=com.ibm.websphere.ce.cm.DuplicateKeyException;"08004"= com.ibm.websphere.ce.cm.StaleConnectionExceptionuserDefinedErrorMap can be located in the administrative console by selecting the data source and configuring the custom properties.
"S1000"=;1062=com.ibm.websphere.ce.cm.DuplicateKeyException;"08004"= com.ibm.websphere.ce.cm.StaleConnectionExceptionuserDefinedErrorMap can be located in the administrative console by selecting the data source and configuring the custom properties.
In this release, the relationship between the available JMS messaging providers is explored in some detail in Choosing a messaging provider and (for messaging environments that involve both WebSphere MQ and WebSphere Application Server) Choosing messaging providers for a mixed environment.
In this release, the procedure to create a new WebSphere MQ link is simplified. Instead of configuring each resource separately, you use the foreign bus connection wizard to connect a bus and a WebSphere MQ network. You configure the connection for either point-to-point messaging or publish-subscribe messaging. As part of this process, the WebSphere MQ link is created and configured.
Similarly, in this release you use a wizard to remove a foreign bus connection between a service integration bus and a WebSphere MQ network. As part of this process, the associated WebSphere MQ link is deleted, along with any publish/subscribe broker profiles and topic mappings.
WebSphere Application Server Version 7.0 supports the JAXB 2.1 specification. JAX-WS 2.1 requires JAXB 2.1 for data binding. JAXB 2.1 provides enhancements such as improved compilation support and support for the @XMLSeeAlso annotation. With JAXB 2.1, you can configure the xjc schema compiler so that it does not automatically generate new classes for a particular schema. Similarly, you can configure the schemagen schema generator to not automatically generate a new schema. This enhancement is useful when you are using a common schema and you do not want a new schema generated. JAXB 2.1 also introduces the @XMLSeeAlso annotation that enables JAXB to bind additional Java classes. This annotation enables JAXB to know about all classes that are potentially involved in marshalling or unmarshalling as it is not always possible or practical to list all of the subclasses of a given Java class. JAX-WS 2.1 also supports the use of the @XMLSeeAlso annotation on a service endpoint interface (SEI) or on a service implementation bean to ensure all of the classes referenced by the annotation are passed to JAXB for processing.
WebSphere Application Server Version 7.0 supports the JAX-WS 2.1 specification. JAX-WS 2.1 extends the functionality of JAX-WS 2.0 to provide support for the WS-Addressing in a standardized API. Using this function, you can create, transmit and use endpoint references to target a Web service endpoint. You can use this API to specify the action uniform resource identifiers (URIs) that are associated with the Web Services Description Language (WSDL) operations of your Web service. JAX-WS 2.1 introduces the concept of features as a way to programmatically control specific functions and behaviors. There are three standard features: the AddressingFeature for WS-Addressing, the MTOMFeature when optimizing the transmission of binary attachments, and the RespectBindingFeature for wsdl:binding extensions. JAX-WS 2.1 requires Java Architecture for XML Binding (JAXB) Version 2.1 for data binding.
This release features additional Java Transaction API (JTA) support. JTA 1.1 is supported through the introduction of the TransactionSynchronizationRegistry interface. System-level application components, such as persistence managers, resource adapters, enterprise beans, and Web application components, can use the TransactionSynchronizationRegistry interface to register with a JTA transaction. Also, the UOWSynchronizationRegistry interface and the UOWManager interface are introduced so that all types of units of work (UOWs) that the product supports can register with a JTA transaction and can be manipulated.
In this release, when you work with policy sets, you can configure the WS-Transaction policy type for the WS-AtomicTransaction (WS-AT) and the WS-BusinessActivity (WS-BA) protocols. You can configure the way in which a Java API for XML Web Services (JAX-WS) client handles WS-AT or WS-BA context. You can specify that the client must send context, can send context if it is available, or must not send context.
In this release, a local transaction containment (LTC) is shareable, that is, a single LTC can span multiple application components, including Web application components and enterprise beans that use container-managed transactions, so that those components can share connections without using a global transaction. Sharing a single resource manager between application components improves performance, increases scalability, and reduces lock contention for resources.
If your application contains EJB 3.0 or Web 2.5 modules, you can select to lock the deployment descriptor of one or more of the EJB 3.0 or Web 2.5 modules on the Metadata for modules page. If you set the metadata-complete attribute to true and lock deployment descriptors, the product writes the complete module deployment descriptor, including deployment information from annotations, to XML format.
WebSphere Application Server Version 7.0 introduces support for an emerging industry standard SOAP over JMS protocol. The SOAP over JMS specification provides a standard set of interoperability guidelines for using a JMS-compliant transport with SOAP messages to enable interoperability between the implementations of different vendors. Using this standard, a mixture of client and server components from different vendors can interoperate when exchanging SOAP request and response messages over the JMS transport for both Java API for XML Web Services (JAX-WS) and Java API for XML-based RPC (JAX-RPC) Web services. By using the JMS transport, your enterprise beans based Web service clients and servers can communicate through JMS queues and topics instead of through HTTP connections.
This release provides support for the Java API for XML-Based Web Services (JAX-WS) 2.1 API, which you can use to create portable applications that use WS-Addressing. Existing JAX-WS applications will work as before.
WebSphere Application Server supports the WS-Transaction 1.0, WS-Transaction 1.1 and WS-Transaction 1.2 specifications. In practice, version 1.2 of the WS-Transaction standard is functionally equivalent to version 1.1, so within WebSphere Application Server, wherever WS-Transaction 1.1 is supported, WS-Transaction 1.2 is also. You can configure the default WS-Transaction specification level to use for outbound requests if the specification level that the server requires cannot be determined from the provider policy. This applies to outbound requests that include a Web Services Atomic Transaction (WS-AT) or Web Services Business Activity (WS-BA) coordination context.
WebSphere Application Server supports the WS-Transaction 1.0, WS-Transaction 1.1 and WS-Transaction 1.2 specifications. In practice, version 1.2 of the WS-Transaction standard is functionally equivalent to version 1.1, so within WebSphere Application Server, wherever WS-Transaction 1.1 is supported, WS-Transaction 1.2 is also. You can configure the default WS-Transaction specification level to use for outbound requests if the specification level that the server requires cannot be determined from the provider policy. This applies to outbound requests that include a Web Services Atomic Transaction (WS-AT) or Web Services Business Activity (WS-BA) coordination context.
The pass message payload by reference properties, which can provide performance improvements for JMS messaging, are new in this release.
WebSphere Application Server supports the WS-Transaction 1.0, WS-Transaction 1.1 and WS-Transaction 1.2 specifications. In practice, version 1.2 of the WS-Transaction standard is functionally equivalent to version 1.1, so within WebSphere Application Server, wherever WS-Transaction 1.1 is supported, WS-Transaction 1.2 is also.