Network Deployment (Distributed operating systems), v8.0 > New features > Overview and new features: Developing and deploying

What is new for developers

This version contains many new and changed features for application developers.

• Communications Enabled Applications concepts

  We can take advantage of integrated telephony and collaborative web services to extend the interactivity of Enterprise and web commerce applications. With the CEA capability, Enterprise solution architects and developers can use a single core application to enable multiple modes of communication. Enterprise developers do not need to have extensive knowledge of telephony or Session Initiation Protocol (SIP) to implement CEA. The CEA capability delivers call control, notifications, and interactivity and provides the platform for more complex communications.

• Contexts and Dependency Injection (CDI) integration with EJB container

  The EJB specification defines a programming model for application components that access transactional resources in a multi-user environment. Concerns, such as role-based security, transaction demarcation, concurrency, and scalability are specified declaratively using annotations and XML deployment descriptors that are enforced by the EJB container at run time. EJB components might be stateful, but are not by nature, contextual.

• Create timers using the EJB timer service for enterprise beans

  In support of the EJB 3.1 specification, you can now create non-persistent EJB timers. This product also supports the expanded TimerService API for programmatic timer creation. In addition, you can configure the EJB container to automatically create a timer when the application starts.

• Develop data access applications

  Generic work context implementation provides a mechanism for a resource adapter to control the contexts in which instances of work submitted by the resource adapter to WAS's work manager for execution are executed. By submitting a work instance that implements the WorkContextProvider interface, the resource adapter can propagate various types of context to the WAS. The application server then, if it supports the propagated context type, sets the provided context as the execution context of the work instance during its execution.

• Develop deployment descriptors for a JAX-WS client

  The <lookup-name> deployment descriptor element is new in Java EE 6, and is used to indirectly refer to an already-defined service reference. When the <lookup-name> element is used, only the <service-ref-name> element may also be specified, and no other child elements of <service-ref> may be defined.

  The following example shows a service-ref entry within a WEB-INF/web.xml file which defines a reference to a JAX-WS service, as well as a service-ref entry within the same web.xml file which defines an indirect reference to the first service-ref:

  <service-ref>
  <service-ref-name>service/ExampleService
  </service-ref-name>
  <service-interface>com.ibm.sample.ExampleService
  </service-interface>
  <service-ref-type>com.ibm.sample.ExampleServicePortType
  </service-ref-type>
  <wsdl-file>WEB-INF/wsdl/ExampleService.wsdl
  </wsdl-file>
  </service-ref>
  
  <service-ref>
  <service-ref-name>service/ExampleService2
  </service-ref>
  <lookup-name>java:comp/env/service/ExampleService
  </lookup-name>
  </service-ref> 

  Assuming the above service-refs are defined in the WEB-INF/web.xml file, the client application could perform a JNDI lookup using the name java:comp/env/service/ExampleService2, and the result would be a reference to the ExampleService service defined in the WSDL document WEB-INF/wsdl/ExampleService.wsdl, as defined in the first service-ref.

• Develop OSGi applications

  The OSGi Applications support in WAS helps you develop and deploy modular applications that use both Java EE and OSGi technologies. We can design and build applications and suites of applications from coherent, versioned, reusable OSGi modules that are accessed only through well-defined interfaces. This enables the same, or different, applications to use different versions of the same third party libraries without interference.

• Disable WebSphere MQ functionality in WAS

  When a WAS process or an application client process starts, and while this process is running, an amount of processing is performed to allow it to support WebSphere MQ-related functionality such as the WebSphere MQ messaging provider. By default this processing is performed regardless of whether any WebSphere MQ-related functionality is ever used. If you do not need to take advantage of any WebSphere MQ functionality, it is possible to disable all WebSphere MQ functionality in an application server or client process to give increased performance.

• EJB 3.0 and EJB 3.1 application bindings overview

  Bindings support in the EJB container has been expanded. The EJB container assigns default JNDI bindings for EJB 3.x business interfaces based on application name, module name, and component name. You do not have to explicitly define JNDI binding names for each of the interfaces or EJB homes within an EJB 3.x module or no-interface views within an EJB 3.1 module.

• EJB content in WAR modules

  All types of EJB 3.x beans are supported in WAR modules, and 2.x and 1.x session beans.

• External high availability frameworks and service integration

  To provide high availability for a WebSphere MQ queue manager connected to WAS, you can specify multiple connection names in your WAS definition for the WebSphere MQ link sender channel. If the active gateway queue manager fails, the service integration bus can use this information to reconnect to a standby gateway queue manager.

• Implement RESTful views of EJB applications using JAX-RS

  JAX-RS supports the use of enterprise beans that declare a local business interface and no-interface view enterprise beans.

• Install and uninstall the Pluggable Application Client for WAS

  The Pluggable Application Client for WAS is now installed by Installation Manager rather than by the programs based on InstallShield MultiPlatform (ISMP) that are used to install and uninstall previous versions.

• Install enterprise application files by adding properties files to a monitored directory

  We can deploy an EAR, JAR, WAR, or SAR file to an application server or cluster by dragging or copying an application properties file to a monitoredDeployableApps/deploymentProperties monitored directory. The product scans a monitored directory for new properties files no more frequently than every 5 seconds, by default. After finding a new properties file in a monitored directory, the product automatically runs the wsadmin applyConfigProperties command, installs the application or module on the application server or cluster, and starts the application or module.

• Install enterprise application files by adding them to a monitored directory

  We can deploy an EAR, JAR, WAR, or SAR file to an application server or cluster by dragging or copying the file to a monitored directory. For base (stand-alone) application servers, the monitored directory is the monitoredDeployableApps/servers/server_name directory of the application server profile. For dmgrs, the monitored directories are the monitoredDeployableApps/servers/server_name , monitoredDeployableApps/nodes/node_name/servers/server_name , and monitoredDeployableApps/clusters/cluster_name directories of the dmgr profile. The product scans a monitored directory for new applications no more frequently than every five seconds, by default. After finding a new EAR, JAR, WAR, or SAR file in a monitored directory, the product installs the file on the application server or cluster and starts the application or module.

• Interoperation using the WebSphere MQ messaging provider
  • WAS v8.0 provides first class support for connecting to multi-instance WebSphere MQ queue managers. We can provide host and port information in the form of a connection name list, which a connection factory or activation specification uses to connect to a multi-instance queue manager.
  • v8.0 exposes WebSphere MQ queue or topic destination properties allowing you to specify:
    • Whether an application processes the RFH version 2 header of a WebSphere MQ message as part of the JMS message body.
    • The format of the JMSReplyTo field.
    • Whether an application can read or write the values of MQMD fields from JMS messages that have been sent or received using the WebSphere MQ messaging provider.
    • Which message context options are specified when sending messages to a destination.

  • v8.0 exposes the following four WebSphere MQ connection properties that are used to configure the WebSphere MQ resource adapter used by the WebSphere MQ messaging provider. These properties affect the connection pool used by activation specifications:
    • maxConnections
    • connectionConcurrency
    • reconnectionRetryCount
    • reconnectionRetryInterval

• JavaServer Faces

  WAS supports JavaServer Faces 2.0 at a runtime level.

• Java Servlet 3.0 considerations
  • Java Servlet 3.0 has many, new powerful features. Some of these features are not fully documented in the Servlet 3.0 specification or they entail trade-offs. Consider the following topics to make best use of the new features.

• JAXB

  This version of the application server supports the JAXB 2.2 specification. JAX-WS 2.2 requires JAXB 2.2 for data binding. JAXB 2.2 provides minor enhancements to its annotations for improved schema generation and better integration with JAX-WS.

• JAX-WS

  Version 8.0 supports the JAX-WS v2.2 and Web Services for Java EE (JSR 109) v1.3 specifications.

  The JAX-WS 2.2 specification supersedes and includes functions within the JAX-WS 2.1 specification. JAX-WS 2.2 adds client-side support for using WebServiceFeature-related annotations such as @MTOM, @Addressing, and the @RespectBinding annotations. JAX-WS 2.1 had previously added support for these annotations on the server. There is also now the ability to enable and configure WS-Addressing support on a client or service by adding WS-Policy assertions into the WSDL document. In addition, the Web Services for Java EE 1.3 specification introduces support for these WebServiceFeature-related annotations, as well as support for using deployment descriptor elements to configure these features on both the client and server. JAX-WS 2.2 requires Java Architecture for XML Binding (JAXB) v2.2 for data binding.

• Job manager

  You can complete job manager actions and run jobs from a dmgr. The dmgr administrative console has Jobs navigation tree choices similar to those in the job manager administrative console.

• JSR 289 overview

  v8.0 includes support for SIP Servlet Specification 1.1, also referred to as Java Specification Request (JSR) 289.

• Lookup names support in deployment descriptors and thin clients

  Beginning in v8.0, EJB homes are bound under the name, java:global/appName/moduleName/beanName . Names of that form are not topology-based and are fully-qualified already. Similarly, all application resources that are bound with java:global, java:app, or java:module names need no additional qualification when the java:global, java:app, or java:module lookup name is specified. Application resources include, for example, EJB references, resource references, and environment entries.

• Overview of IBM JAX-RS

  JAX-RS is a collection of interfaces and Java annotations that simplifies development of server-side REST applications. By using JAX-RS technology, REST applications are simpler to develop, simpler to consume, and simpler to scale when compared to other types of distributed systems. This product supports a Java API for developing REST-based services. The IBM implementation of JAX-RS provides an implementation of the JAX-RS specification.

• Overview of XML support

  IBM WAS v8.0 delivers critical technology that provides application developers with support for the following key World Wide Web Consortium (W3C) XML standards:

  • Extensible Stylesheet Language Transformations (XSLT) 2.0
  • XML Path Language (XPath) 2.0
  • XML Query Language (XQuery) 1.0

  These new and updated W3C XML standards offer application developers numerous advanced capabilities for building XML applications. Specific benefits delivered in the XPath 2.0, XSLT 2.0, and XQuery 1.0 standards include the following:

  • Simpler XML application development and improved developer productivity
  • Improved ability to query large amounts of data stored in XML outside of a database with XQuery 1.0
  • Improved XML-application performance through new features introduced in the W3C specifications to address previous shortcomings
  • Improved XML-application reliability with new support for XML schema-aware processing and validation

• Request SAML bearer tokens from an external STS using WSS APIs and transport level protection

  We can request a SAML token with the bearer subject confirmation method from an external STS and then send the SAML token in web services request messages from a web services client using WSS APIs.

• Request SAML sender-vouches tokens from an external STS using WSS APIs and message level protection

  You can request a SAML token with the sender-vouches subject confirmation method from an external STS and then send the SAML token in web services request messages from a web services client using WSS APIs with message level protection.

• Request SAML sender-vouches tokens from an external STS using WSS APIs and transport level protection

  You can request a SAML token with the sender-vouches subject confirmation method from an external STS and then send the SAML token in web services request messages from a web services client using WSS APIs with transport level protection.

• Secure downstream JAX-RS resources

  When composing JAX-RS resources, a new LTPA JAX-RS security handler can be used to seamlessly authenticate on downstream resource invocations.

• Secure JAX-RS clients using SSL

  JAX-RS client programs can take advantage of transport security using Secure Socket Layer (SSL) in order to protect requests and responses from JAX-RS resources.

• Send self-issued SAML bearer tokens using WSS APIs

  We can build your web services client to use SAML tokens with the bearer subject confirmation method in SOAP request messages using the Web Services Security programming interfaces. Using the programming interfaces in a web services client to specify the use of SAML tokens with bearer subject confirmation is an alternative approach to using policy sets and binding configurations.

• Send self-issued SAML sender-vouches tokens using WSS APIs with message level protection

  We can protect SOAP request messages and SAML tokens by using the Web Services Security programming interface to satisfy the sender-vouches subject confirmation method validation requirements with message level protection. Using the programming interfaces in web services client is an alternative approach to using policy set and binding configuration.

• Send self-issued SAML sender-vouches tokens using WSS APIs with SSL transport protection

  We can build your web services client to use SAML tokens with the sender-vouches subject confirmation method in SOAP request messages using the Web Services Security programming interfaces. Using the programming interfaces in a web services client to specify the use of SAML tokens with sender-vouches subject confirmation using message protection at the transport level is an alternative approach to using policy sets and binding configurations.

• Servlet 3.0 programmatic configuration

  The new methods for Servlet 3.0 are part of the ServletContext interface. We can call these methods from either a ServletContainerInitializer or a ServletContextListener.

• Task overview: Implementing web services applications

  v8.0 includes support for singleton session enterprise beans as JAX-WS endpoints. Singleton session beans are useful in situations where a single instance of a web services endpoint implementation bean is needed to process all requests that are received for a particular web services endpoint. Perhaps, the single instance of the bean needs to share state information across requests. Typically, a new instance of a web services endpoint implementation bean is created to process each request.

• Transactional batch and compute-intensive batch programming models

  The Java EE applications that the application server hosts typically perform short, lightweight, transactional units of work. In most cases, an individual request can be completed with seconds of processor time and relatively little memory. Many applications, however, must complete batch work that is computational and resource intensive. The batch function extends the application server to accommodate applications that must perform batch work alongside transactional applications. Batch work might take hours or even days to finish and uses large amounts of memory or processing power while it runs.

• Use bean validation in the product

  The product provides support for the Bean Validation API in the Java EE environment by providing a bean validation service in multiple Java EE technologies including Java Servlets, Enterprise JavaBeans, Java Persistence API (JPA) 2.0, Java EE Connector API (JCA) 1.6 and Java ServerFaces (JSF) 2.0. Bean validation provides these technologies a way to maintain data integrity in an integrated and standard environment.

• Use Java contexts and dependency injection with JAX-RS

  Java Contexts and Dependency Injection (JCDI) is a new Java Platform, Enterprise Edition (Java EE) 6 feature. It can change the programming model to make applications easier to develop while increasing maintainability. JAX-RS developers can use JCDI features, such as @javax.inject.Inject support, in root resource and provider classes.

• Use WADL to generate service documentation

  WADL is a developing standard which helps describe the services available to users. WADL documents are written in XML. Using XSTL or XML parsers, developers can generate documentation for the service. In some cases, users may develop clients to dynamically understand the RESTful service by inspecting the WADL document.

  Use IBM JAX-RS, developers can generate a JAXB XML representation of a WADL document describing all of the resources available in the application. The JAXB representation can be returned from a JAX-RS resource method. Then, the WADL document resource is treated like any other JAX-RS resource and can be used by clients.

• Web container configuration for JSP static file access
  • Pre-fragment document roots is a new function in WAS v8.0.
  • META-INF/resources directories of fragments under the WEB-INF/Lib directory in the application WAR file is a new function in WAS v8.0.

• Web fragments

  Web module deployment descriptor fragments (web fragments) provide the same configuration metadata that a web.xml file provides, but they exist as a web-fragment.xml file that is packaged inside a JAR file in the WEB-INF/lib directory.

  Framework developers provide JAR files that are included in a web application which uses that specific framework. If that framework uses servlets, filters, or other web module configuration, web fragments provide the ability to simply drag the JAR file into an application without requiring changes to the existing web module configuration. Previously, web application developers were required to augment their configuration with additional metadata required by the framework. Another use case is the aforementioned need to use the same components across web modules. Also, the use of mock objects or stubs might be made easier with Web fragments.

• Web service clients and policy configuration to use the service provider policy

  In WAS v8.0, a service reference can be configured to use a different WSDL document to the WSDL configured for the client service. By default, service references inherit their policy set and WS-Policy configuration from their parent service, however, if desired, the policy set and WS-Policy configuration can be overwritten. See the Use WS-Policy to exchange policies in a standard format topic and its child topics for further details.

• Web Services Addressing support

  The following features were introduced in the JAX-WS 2.2 specification, which WAS v8 supports:

  • We can specify additional binding information within the metadata of an endpoint reference as part of the JAX-WS 2.2 specification. This functionality was added to WAS in version 7, however as it was not part of the JAX-WS 2.1 specification, you might have experienced incompatibility issues when interoperating with non- WAS servers which did not offer support for additional metadata in endpoint references. Now that JAX-WS 2.2 supports WSDL metadata in endpoint references, applications will be compatible with other implementations of this specification. See the "Web Services Addressing overview" topic for further information.
  • We can enable and configure WS-Addressing on a client or service by adding WS-Policy assertions into the WSDL document. WAS will now process WS-Addressing information held within the WS-Policy aspect of a WSDL document and use it in the configuration of that application. See the "Enabling Web Services Addressing support for JAX-WS applications using WS-Policy" topic for further information.
  • We can specify whether a synchronous or an asynchronous message exchange pattern is required by a web service application using the addressing annotation or the AddressingFeature. Use the new responses parameter on the addressing annotations or the AddressingFeature class in the code. See the "Enabling Web Services Addressing support for JAX-WS applications using addressing annotations" topic and the "Enabling Web Services Addressing support for JAX-WS applications using addressing features" topic for further information.
  • We can configure WS-Addressing using deployment descriptors. Add an <addressing> element and optional child elements to the deployment descriptor file for the application. See the "Enabling Web Services Addressing support for JAX-WS applications using deployment descriptors" topic for further information.
  • We can generate code from a WSDL document and WAS will now automatically insert @Action and @FaultAction annotations into the generated Java code. See the "Web Services Addressing annotations" topic for further information.

• What is new for securing web services

  The Security Assertion Markup Language (SAML) is an XML-based OASIS standard for exchanging user identity and security attributes information. Using SAML, a client can communicate assertions regarding the identity, attributes, and entitlements of a SOAP message. Using the SAML function in WAS, you can apply policy sets to JAX-WS applications to use SAML assertions in web services messages and in web services usage scenarios. Use SAML assertions to represent user identity and user security attributes, and optionally, to sign and to encrypt SOAP message elements.

• WS-Policy

  The following features were introduced in the JAX-WS 2.2 specification, which WAS v8 supports:

  • We can specify transport level security on client WSDL acquisition. We can now attach a system policy set to either an HTTP GET request or a WS-MetadataExchange request when obtaining provider policy. See the "Configuring the client.policy to use a service provider policy" topic for further information.
  • We can specify a policy set and binding for a service reference that is different from the policy set attachment for the service. By default, service references inherit their policy set and WS-Policy configuration from their parent service, however, if desired, the policy set and WS-Policy configuration can be overwritten. See the "Using WS-Policy to exchange policies in a standard format" topic and its child topics for further details.
  • We can enable and configure WS-Addressing support on a client or service provider by adding WS-Policy assertions into the WSDL document. WAS will now process WS-Addressing information held within the WS-Policy aspect of an application's WSDL document and use it in the configuration of that application. See the "Enabling Web Services Addressing support for JAX-WS applications using WS-Policy" topic for further information.
  • We can publish policy configuration relating to WS-Addressing based on JSR109 deployment descriptors or JAX-WS 2.2 features or annotations, as well as information based on policy sets. This ensures that the policy information published matches the run time behavior of the service. See the "Web service providers and policy configuration sharing" topic for further information.

+

Search Tips   |   Advanced Search