This version contains many new and changed features for application developers.
You 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.
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.
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.
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 WebSphere® Application Server'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 WebSphere Application Server. 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.
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.
The OSGi Applications support in WebSphere Application Server helps you develop and deploy modular applications that use both Java EE and OSGi technologies. You 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.
When a WebSphere Application Server 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.
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.
All types of EJB 3.x beans are supported in WAR modules, and 2.x and 1.x session beans.
JAX-RS supports the use of enterprise beans that declare a local business interface and no-interface view enterprise beans.
WebSphere Application Server supports JavaServer Faces 2.0 at a runtime level.
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.
Version 8.0 supports the JAX-WS Version 2.2 and Web Services for Java EE (JSR 109) Version 1.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) Version 2.2 for data binding.
Version 8.0 includes support for SIP Servlet Specification 1.1, also referred to as Java Specification Request (JSR) 289.
Beginning in Version 8.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.
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.
You 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.
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.
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.
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.
You 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.
You 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.
You 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.
The new methods for Servlet 3.0 are part of the ServletContext interface. You can call these methods from either a ServletContainerInitializer or a ServletContextListener.
Version 8.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.
The Java Platform, Enterprise Edition (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.
The product provides support for the Bean Validation API in the Java Platform, Enterprise Edition (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.
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.
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.
Using 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 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.
In WebSphere Application Server Version 8.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 Using WS-Policy to exchange policies in a standard format topic and its child topics for further details.
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 WebSphere Application Server, 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.