This topic highlights what is new or changed, for users who are going to customize, administer, monitor, and tune production server environments. It also addresses those who are going to deploy and operate applications.
In this release, the procedure to create or modify a cluster bus member is simplified. In the administrative console, you can use a wizard to create a cluster bus member, so that there is guidance through the steps, the correct components are created, and some components are created automatically.
When you create or modify a cluster bus member, you can use messaging engine policy assistance, which provides guidance about creating and configuring messaging engines in a cluster to provide the behavior you require. You can select from one of three predefined messaging engine policy types, which support cluster configurations that require high availability, scalability, or both. For more advanced requirements, you can use messaging engine policy assistance to create a custom configuration, and some associated components are created automatically.
In this release, when you are adding a server to a messaging bus you can, if required, tune performance by changing the settings for the starting and maximum Java™ Virtual Machine (JVM) heap sizes. Tuning the heap sizes helps to ensure that application servers hosting one or more messaging engines are provided with an appropriate amount of memory for the message throughput you require.
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.
In a flexible management environment, the job manager enables you to asynchronously submit and administer jobs for large numbers of stand-alone application servers and deployment managers over a geographically dispersed area. Many of the management tasks that you can perform with the job manager are tasks that you can already perform with the product, such as application management, server management, and node management. However, with the job manager, you can aggregate the tasks and perform the tasks across multiple application servers or deployment managers.
The administrative agent provides a single interface to administer multiple unfederated (stand-alone) application server nodes in, for example, development, unit test, or server farm environments. By using a single interface to administer your application servers, you reduce the overhead of running administrative services in every application server.
You can apply properties files that have portable resource identifiers to another environment.
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.
The ability to configure a bootstrap member policy for a bus is new in this release. Use this policy to nominate cell members to service requests to bootstrap into the bus.
In this release, the procedure to configure a connection to a non-default bootstrap server is enhanced by the introduction of the Provider Endpoints property for activation specifications. The Provider Endpoints property allows a message-driven bean to consume messages from a queue that is in another cell. This property is added to the JMS activation specification [Settings] administrative console panel and to the createSIBJMSActivationSpec and modifySIBJMSActivationSpec commands.
If you have defined security domains in the application server, you can click Browse... to select an authentication alias for the resource that you are configuring. Security domains allow you to isolate authentication aliases between servers. The tree view is useful in determining the security domain to which an alias belongs, and the tree view can help you determine the servers that will be able to access each authentication alias. The tree view is tailored for each resource, so domains and aliases are hidden when you cannot use them.
Client reroute for DB2® allows you to provide an alternate server location, in case the connection to the database server fails. If you decide to use client reroute with the persistence option, the alternate server information will persist across Java Virtual Machines (JVMs). In the event of an application server crash, the alternate server information will not be lost when the application server is restored and attempts to connect to the database.
In this release, the procedure to configure a service integration bus to connect to other messaging networks and exchange messages with those networks is simplified. In the administrative console, you can use a wizard to configure a foreign bus connection, including the objects required to enable message flow between the bus and another service integration bus, or the bus and a WebSphere® MQ queue manager. You can configure the foreign bus connection to support point-to-point messaging, publish/subscribe messaging, or an indirect connection through one or more intermediate buses. For a direct connection, the appropriate physical link (a service integration bus link or a WebSphere MQ link) is created automatically.
You can isolate a mail provider to allow different versions of the same provider to be loaded in the same Java Virtual Machine (JVM). For example, you might want to deploy multiple applications on a single server, but each application requires different versions or implementations of the mail provider. You can now isolate each version or implementation of the provider, and the provider will be loaded in its own class loader and will not interfere with other implementations. There are some general considerations for isolating any type of resource provider; refer to the topic on considerations for isolated resource providers for more information.
Using the Oracle JDBC driver, you can configure failover support, load balancing, or both, in an Oracle RAC environment.
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.
In this release, there are two types of WS-Notification service, depending on whether your WS-Notification application uses JAX-RPC or JAX-WS. This release also supports WS-Notification Version 1.3, and you can filter WS-Notification messages by using XPath selectors.
You can use a tunnel proxy peer access point when the core groups cannot directly communicate with each other because of a firewall. Typically, when a firewall exists between two core groups, the core groups cannot communicate with each other. However if a DMZ Secure Proxy Server for IBM® WebSphere Application Server resides in the demilitarized zone (DMZ) outside of the firewall, you can create a tunnel access point group that enables you to establish a core group bridge tunnel between the core groups that are running on servers inside of the firewall, and the core groups that are running on the DMZ Secure Proxy Server for IBM WebSphere Application Server.
You can use an alternate protocol provider instead of the default Discovery Protocol and Failure Detection Protocol to monitor and manage communication between core group members. In general, alternate protocol providers, such as the z/OS® Cross-system Coupling Facility (XCF)-based provider, uses less system resources than the default Discovery Protocol and Failure Detection Protocol, especially during times when the core group members are idle. An alternate protocol provider generally use less system resources because it does not perform the member-to-member TCP/IP pinging that the default protocol providers use to determine if a core group member is still active.
Using the PropertiesBasedConfiguration command group for the AdminTask object, you can use properties files to create, modify, and delete configuration objects from your environment.
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 or cluster, 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.
In previous releases of the product, extracted properties only contained the most important properties of each object type. You now can extract all the properties of any WCCM object, modify the properties, and then validate and apply the modified properties to a system configuration.
In previous versions of WebSphere Application Server, you can connect to a queue manager by using the WebSphere MQ classes for JMS that are in an external WebSphere MQ installation (a WebSphere MQ installation that is on a different machine from WebSphere Application Server). You achieve this configuration by setting the MQ_INSTALL_ROOT variable.
In WebSphere Application Server Version 7.0, the MQ_INSTALL_ROOT variable is only used to locate native libraries, and is overridden by any native library path configured on the Resource Adapter.
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.
You can improve system performance if you configure some of your application servers, such that each of their components are dynamically started as they are needed, instead of letting all of these components automatically start when the server starts. Selecting this option can improve server startup time, and reduce the memory footprint. Starting components as they are needed is most effective if all of the applications that are deployed on the application server are of the same type. For example, using this option works better if all of your applications are Web applications that use servlets, and JavaServer Pages (JSP). This option works less effectively if your applications use servlets, JSPs and Enterprise JavaBeans™ (EJB).
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.
You can extract the properties that are required to run a command using the createPropertiesFileTemplates command.
Only the total transaction lifetime timeout and the maximum transaction timeout have grace periods. You can disable the grace periods using the DISABLE_TRANSACTION_TIMEOUT_GRACE_PERIOD custom property.
An isolated shared library enables one instance of the library classes to be shared only among associated applications and Web modules. An isolated shared library enables multiple applications or Web modules to share a common set of classes across a subset of the applications. Further, an isolated shared library supports versioning and loads the minimum number of library copies. The class loader created for an isolated shared library does not reload and, like a server class loader, exists for the lifetime of a server. For shared native libraries, you can use an isolated shared library to avoid errors resulting from reloading of native libraries.
In this release, the length of time that a security group will be cached is now configured independently for each service integration bus, rather than being based on the expiry time taken from the LTPA timeout token, as in the previous release.
Set the value of the group cache timeout set using the Group cache timeout field in the Security for bus bus_name [Settings] window, or by using the -securityGroupCacheTimeout parameter of the createSIBus or modifySIBus commands. This allows a group cache timeout for the user to be tuned to the optimum setting, balancing the need for responsiveness with the registry load.
This release includes the new command migrateServerMEtoCluster. You can use this command to migrate the messaging engine in a server to the scope of a cluster when a server that is a member of a bus is converted to a cluster. This command makes the new cluster a member of the bus and ensures that the messaging engine continues to work with previously configured destinations.
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.
IBM Support Assistant version 4.0 enhancements include:
Resource Adapter for JMS with WebSphere Application Server provides supported third-party application servers with full connectivity to service integration resources running inside WebSphere Application Server.
The Thin Client for JMS with WebSphere Application Server allows Java SE applications to interoperate with default messaging provider messaging engines in WebSphere Application Server.
In this release the client ships with WebSphere Application Server, rather than being available for separate download and installation, as for earlier releases ( WebSphere Application Server Version 6.0.2 onwards). The client continues to offer a low footprint and connectivity from Java SE and in this release provides the additional benefits of Eclipse Rich Client Platform (RCP) support.
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.
The Jython script library provides a set of procedures to automate the most common application server administration functions. For example, you can use the script library to easily configure servers, applications, mail settings, resources, nodes, business-level applications, clusters, authorization groups, and more. You can run each script procedure individually, or combine several procedures to quickly develop new scripts.
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.
This release provides you with finer control over sending messages to a service integration bus queue with multiple queue points, hosted on a multi-messaging engine cluster bus member. This control includes the ability to create an affinity between sets of messages and a single queue point, the ability to balance the workload of messages across queue points in a wider range of topologies, and the ability to scope individual messages and reply messages to specific queue points of a clustered queue. These abilities allow clustered queues to be used in many more messaging topologies than in previous releases, enabling better scaling solutions to be applied.
This release also allows a service integration bus queue with multiple queue points to be seen by a message consumer as a single collection of messages, rather than a set of discrete collections. This new feature allows a single consuming application to have all messages on any of the queue points available to it from anywhere in the bus, removing the need for a consumer to carefully check each queue point individually for messages.
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.