Network Deployment (Distributed operating systems), v8.0 > New features > What has changed in this release

Transitioning notes for development topics

When you upgrade the application server to a newer version, be aware of the following settings that you might want to change.

• BLAManagement command group using wsadmin.sh

  In the WAS v7 Feature Pack for OSGi Applications and Java Persistence API 2.0, bundle changes to the asset are applied by restarting the business-level application. In v8, these changes are applied by updating the composition unit. The new approach in v8 means that many bundle changes can be applied in place, without restarting the running business-level application.

  To enable this new approach, the UpdateAppContentVersionsStep parameter has been replaced with the UpdateAppContentVersions parameter, and instead of restarting the business-level application you run the editCompUnit command with the CompUnitStatusStep parameter.

• Develop a dynamic client using JAX-WS APIs

  JAX-WS dynamic ports, which are those added using the service method addPort, might have additional memory requirements starting in WAS v8.0. In previous releases, a single instance of a dynamic port could be shared across multiple service instances. In version 8, dynamic ports are now scoped to the instance of the service that added them. If a JAX-WS client has multiple service instances which refer to a dynamic port of the same name, those instances are no longer shared. This can potentially increase the memory requirements for that client. The memory used by dynamic ports is released when the service instance goes out of scope. However, if you encounter issues related to increased memory usage, it is possible to revert the behavior so that dynamic ports are again shared across service instances.

  To do this, set the system property jaxws.share.dynamic.ports.enable to the value true. However, note that doing so can cause some other issues, such as having policy set attachments incorrectly applied across shared dynamic ports. If you set this flag to true and encounter some of these issues, then you should remove the flag setting.

  In previous releases, if a SOAP Action was not provided by the Dispatch client application, the correct SOAP Action was not sent on the outbound message. Instead, the SOAP action was set to an anonymous operation. Starting in WAS Version 8, if the SOAP Action is not provided by the Dispatch client application, the JAX-WS runtime environment parses the outgoing message. It determines the operation being invoked and uses that information to determine the appropriate value for the SOAP Action. The operation resolution of the outbound message is based on the SOAP Body and the message encoding, for example, Doc/Lit/Bare, Doc/Lit/Wrapped. Since this parsing can be expensive, a property can be set.

  To always disable the parsing, set the property at the System level.

  To disable parsing on a per-message basis, set the property on the JAX-WS Request Message Context. The property is defined as a constant org.apache.axis2.jaxws.Constants.DISPATCH_CLIENT_OUTBOUND_RESOLUTION with a String value of jaxws.dispatch.outbound.operation.resolution.enable. The default value of the property is null which is interpreted as the String true, which enables the outbound operation resolution. Setting the property to false disables the outbound operation resolution. If parsing is disabled, then the SOAP Action in the outbound message is set to an anonymous operation as in previous releases. If the client provides a SOAP Action through the JAX-WS javax.xml.ws.BindingProvider properties, SOAPACTION_USE_PROPERTY and SOAPACTION_URI_PROPERTY, then that SOAP Action is used. Therefore, parsing of the outbound message does not occur regardless of the setting of the property. Setting a SOAP Action explicitly by the client is considered a best practice, particularly for performance on the service-provider. This practice prevents the inbound message from being parsed, to be routed to the correct endpoint operation.

• EJB 3.0 and EJB 3.1 application bindings overview

  To specify user-defined bindings information for EJB 3.x modules, place the file ibm-ejb-jar-bnd.xml, in the META-INF directory for the EJB Java archive (JAR) file. The suffix on this file is XML, not XMI, as in prior versions of product.

• Enable DB2 Performance Expert Extended Insight

  The enableEndToEndMonitoringFeature custom property is deprecated in the WAS V7.0.0.1 environment, because PEEI feature is enabled by default. PEEI can be controlled by the disableEndToEndClientMonitoringFeature custom property, which has a default of false. If you use the enableEndToEndMonitoringFeature custom property, Application Server will issue an OBSOLETE_PROPERTY_SPECIFIED warning.

• Establishing security context for web services clients using SAML security tokens

  In WAS v7.0 Fix Pack 7 and later releases, the WS-Security runtime environment takes a SAML token Issuer name to represent the foreign security realm name. WS-Security takes the NameID element in the case of SAML 2.0 security tokens or the NameIdentifier element in the case of SAML 1.1 security tokens to represent user security name. Alternatively, you can explicitly specify which SAML token attribute to use to represent user security name. Moreover, you can also specify which SAML token attribute to use to represent user group membership. Read about SAML assertions across WAS security domains for a detailed discussion of the SAML token assertion trust model and binding configuration.

  v8 supports propagating select security context data in SAML tokens. We must set a tokenRequest custom property with an issueByWSCredential property value in the WS-Security binding configuration of the web services client. Read about propagating SAML tokens for a detailed description of this binding option. When the crossDomainIdAssertion property is set to true in v8, WS-Security checks whether a SAML token contains a SAML Attribute UniqueSecurityName with a NameFormat element with a value of com.ibm.websphere.security.cred.WSCredential. If found, WS-Security uses the NameQualifier attribute value of the NameID element or NameIdentifier element to represent the user security realm name. WS-Security also uses the UniqueSecurityName attribute value and the GroupIds attribute value to represent a unique user name and group membership. This default behavior is different between v7 and v8 of the product. We can add a CallbackHandler property, IssuerNameForRealm, and set its value to true to configure Version 8 to preserve the v7 behavior. Alternatively, you can add a CallbackHandler property, NameQualifierForRealm, and set its value to true to configure Version 8 to always use the NameQualifier attribute to represent the user security realm name.

• Implement web services applications with JAX-WS

  Starting with WAS v7.0 and later, Java EE 5 application modules (web application modules version 2.5 or above, or EJB modules version 3.0 or above) are scanned for annotations to identify JAX-WS services and clients. However, pre-Java EE 5 application modules (web application modules version 2.4 or before, or EJB modules version 2.1 or before) are not scanned for JAX-WS annotations, by default, for performance considerations. In the v6.1 Feature Pack for Web Services, the default behavior is to scan pre-Java EE 5 web application modules to identify JAX-WS services and to scan pre-Java EE 5 web application modules and EJB modules for service clients during application installation. Because the default behavior for WAS Version 7.0 and later is to not scan pre-Java EE 5 modules for annotations during application installation or server startup, to preserve backward compatability with the feature pack from previous releases, configure either the UseWSFEP61ScanPolicy property in the META-INF/MANIFEST.MF of a web application archive (WAR) file or EJB module or define the Java virtual machine custom property, com.ibm.websphere.webservices.UseWSFEP61ScanPolicy, on servers to request scanning during application installation and server startup.

  To learn more about annotations scanning, see the JAX-WS annotations information.

• JavaServer Faces migration

  The default JavaServer Faces implementation is now MyFaces 2.0, which provides full compliance with the updated JSF 2.0 specification.

• Migration of JPA applications and bean validation

  The Bean Validation API and implementation are included in the WAS v8. To deploy the feature pack applications on v8, be aware of the following changes in configuration and runtime behaviors:

  • In v7.0, the system property, com.ibm.websphere.validation.api.jar.path, is used to direct the feature pack run time to locate the Bean Validation API JAR file. In v8.0, the Bean Validation API JAR file is built into the product installation, therefore, this system property is ignored. However, the bean validation provider can still be overridden in V7 and V8 when packaged in application or shared libraries. The third bullet describes this usage scenario.
  • The bean validation implementation in WAS is automatically the effective default bean validation provider.

  • If standard bean validation features are used by the JPA application, the com.ibm.websphere.validation.api.jar.path system property, and user-supplied bean validation provider can be removed from application deployment.

  • If non-specification compliant or provider-specific features are used by an application, the bean validation provider that supports the required features must be packaged, configured, and deployed as a typical, third-party service provider in the user application, the application shared library, and the server associated shared library. Read more about shared library usage in applications for more information.

• Migration scenario for the getHeaderNames method

  To ensure the most successful migration, the return type of the StoredResponse getHeaderNames method was changed to com.ibm.websphere.servlet.response.CollectionEnumerationHybrid <String>. This type implements both Collection <String> and Enumeration.

• Runtime considerations for SIP application developers

  When a SIP application sends a request to a SIP URI over Transport Layer Security (TLS) in version 6.1, the request URI scheme changes from "sip" to "sips." In version 7.0, the scheme does not change. We can reverse the new behavior in version 7.0 by changing the application code. With a "sips" URI, the behavior remains the same after upgrading from version 6.1 to 7.0. See the information center topic Premigration considerations for more information.

• SCA programming model support in OSGi applications

  If the application previously used SDO version 1.0.0, change the Import-Package to:

  Import-Package: commonj.sdo;version="[2.0.0,3.0.0)"
  

• Secure downstream JAX-RS resources

  When using the LtpaAuthSecurityHandler class, ensure that you target resources using the https scheme for your URLs, and that the target application is SSL-enabled. It is highly recommended to use SSL connections when sending user credentials, including LTPA cookies. You may explicitly turn off the requirement for SSL in the LtpaAuthSecurityHandler class by invoking the setSSLRequired method on the security handler with the false value. The default value is true.

  yourLtpaAuthSecHandler.setSSLRequired(false);
  

• Secure JAX-RS applications within the web container

  When using the BasicAuthSecurityHandler class, ensure that you target resources using the https scheme for your URLs, and that the target application is SSL-enabled. It is highly recommended to use SSL connections when sending user credentials. You may explicitly turn off the requirement for SSL in the BasicAuthSecurityHandler class by invoking the setSSLRequired method on the security handler with the false value. By default, this value is true.

  secHandler.setSSLRequired(false);
  

• Secure web services using Security Markup Assertion Language (SAML)

  In WAS Version 7.0.0.7 and later, to use the SAML default policy sets, sample SAML general bindings, and JAAS login configuration settings for SAML, you were required to set up the SAML configuration, which is stored in a profile. In WAS v8.0, the SAML feature is available in all profiles by default.

• SOAP with Attachments API for Java interface

  Start in WAS v8, the SOAPMessage.getSOAPHeader and getSOAPBody methods now throw a SOAPException if there is no corresponding element in the message. A System property is provided to revert the behavior to return null rather than throw an exception. The property is defined in com.ibm.websphere.webservices.soap.IBMSOAPMessage.ENABLE_LEGACY_GETSOAP_BEHAVIOR as a String value of com.ibm.websphere.webservices.soap.enable.legacy.get.behavior. The default value of the property is null which is interpreted as false. To revert the behavior to returning a null, set the property to the String value true. The previous behavior of returning null is not compliant with the specification.

• Web services migration best practices

  Existing JAX-RPC applications wanting to use JAX-WS features must be rewritten using JAX-WS.

Reference topic    

---

+

Search Tips   |   Advanced Search