CXF Transports - 6.3

Talend ESB Service Developer Guide

EnrichVersion
6.3
EnrichProdName
Talend Data Fabric
Talend Data Services Platform
Talend ESB
Talend MDM Platform
Talend Open Studio for ESB
Talend Real-Time Big Data Platform
task
Design and Development
Installation and Upgrade
EnrichPlatform
Talend ESB

HTTP Transport

HTTP transport support via servlet-based environments is described below (embedded Jetty and OSGi deployment is also available in CXF).

Client HTTP Transport (including SSL support)

Configuring SSL Support

To configure your client to use SSL, you'll need to add an <http:conduit> definition to your XML configuration file. If you are already using Spring, this can be added to your existing beans definitions.

A wsdl_first_https sample can be found in the CXF distribution with more detail. Also, if desired, you can encrypt any temporary files created by CXF during large data stream caching -- see the CXF documentation for more details.

Here is a sample of what your conduit definition might look like:

<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:sec="http://cxf.apache.org/configuration/security"
   xmlns:http="http://cxf.apache.org/transports/http/configuration"
   xmlns:jaxws="http://java.sun.com/xml/ns/jaxws"
   xsi:schemaLocation="
      http://cxf.apache.org/configuration/security
      http://cxf.apache.org/schemas/configuration/security.xsd
      http://cxf.apache.org/transports/http/configuration
      http://cxf.apache.org/schemas/configuration/http-conf.xsd
      http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">

   <http:conduit
      name="{http://apache.org/hello_world}HelloWorld.http-conduit">

      <http:tlsClientParameters>
         <sec:keyManagers keyPassword="password">
            <sec:keyStore type="JKS" password="password"
               file="my/file/dir/Morpit.jks"/>
         </sec:keyManagers>
         <sec:trustManagers>
            <sec:keyStore type="JKS" password="password"
               file="my/file/dir/Truststore.jks"/>
         </sec:trustManagers>
         <sec:cipherSuitesFilter>
            <!-- these filters ensure that a ciphersuite with
               export-suitable or null encryption is used,
               but exclude anonymous Diffie-Hellman key change as
               this is vulnerable to man-in-the-middle attacks -->
            <sec:include>.*_EXPORT_.*</sec:include>
            <sec:include>.*_EXPORT1024_.*</sec:include>
            <sec:include>.*_WITH_DES_.*</sec:include>
            <sec:include>.*_WITH_AES_.*</sec:include>
            <sec:include>.*_WITH_AES_.*</sec:include>
        <sec:include>.*_WITH_NULL_.*</sec:include>
            <sec:exclude>.*_DH_anon_.*</sec:exclude>
         </sec:cipherSuitesFilter>
      </http:tlsClientParameters>
      <http:authorization>
         <sec:UserName>Betty</sec:UserName>
         <sec:Password>password</sec:Password>
      </http:authorization>
      <http:client AutoRedirect="true" Connection="Keep-Alive"/>

   </http:conduit>

</beans>

The first thing to notice is the "name" attribute on <http:conduit>. This allows CXF to associate this HTTP Conduit configuration with a particular WSDL Port. The name includes the service's namespace, the WSDL port name (as found in the wsdl:service section of the WSDL), and ".http-conduit". It follows this template: "{WSDL Namespace}portName.http-conduit". Note: it's the PORT name, not the service name. Thus, it's likely something like "MyServicePort", not "MyService". If you are having trouble getting the template to work, another (temporary) option for the name value is simply "*.http-conduit".

Another option for the name attribute is a reg-ex expression (e.g., "http://localhost:*") for the ORIGINAL URL of the endpoint. The configuration is matched at conduit creation so the address used in the WSDL or used for the JAX-WS Service.create(...) call can be used for the name. For example, you can do:

<http:conduit name="http://localhost:8080/.*">
   ...
</http:conduit>

to configure a conduit for all interactions on localhost:8080. If you have multiple clients interacting with different services on the same server, this is probably the easiest way to configure it.

If your service endpoint uses an SSL WSDL location (i.e., "https://xxx?wsdl"), you can configure the http conduit to pick up the SSL configuration by using a hardcoded http conduit name of "{http://cxf.apache.org/}TransportURIResolver.http-conduit". The specific HTTP conduit name or a reg-ex expression can still be used.

Keystores (as identified by the sec:keyStore element above) can be identified via any one of three ways: via a file, resource, or url attribute. File locations are either an absolute path or relative to the working directory, the resource attribute is relative to the classpath, and URLs must be a valid URL such as "http://..." "file:///...", etc. Only one attribute of "url", "file", or "resource" is allowed.

Advanced Configuration

HTTP client endpoints can specify a number of HTTP connection attributes including whether the endpoint automatically accepts redirect responses, whether the endpoint can use chunking, whether the endpoint will request a keep-alive, and how the endpoint interacts with proxies.

A client endpoint can be configured using three mechanisms:

  • Configuration

  • WSDL

  • Java code

Using Configuration
Namespace

The elements used to configure an HTTP client are defined in the namespace http://cxf.apache.org/transports/http/configuration" . It is commonly referred to using the prefix http-conf . In order to use the HTTP configuration elements you will need to add the lines shown below to the beans element of your endpoint's configuration file. In addition, you will need to add the configuration elements' namespace to the xsi:schemaLocation attribute.

Example 21. HTTP Consumer Configuration Namespace

<beans ...
   xmlns:http-conf=
      "http://cxf.apache.org/transports/http/configuration
      ...
      xsi:schemaLocation="...
          http://cxf.apache.org/transports/http/configuration
          http://cxf.apache.org/schemas/configuration/http-conf.xsd
          ...">

The conduit element

You configure an HTTP client using the http-conf:conduit element and its children. The http-conf:conduit element takes a single attribute, name , that specifies the WSDL port element that corresponds to the endpoint. The value for the name attribute takes the form portQName .http-conduit . For example, the code below shows the http-conf:conduit element that would be used to add configuration for an endpoint that was specified by the WSDL fragment <port binding="widgetSOAPBinding" name="widgetSOAPPort> if the endpoint's target namespace was http://widgets.widgetvendor.net". Alternatively, the name attribute can be a regular expression to match a URL. This allows configuration of conduits that are not used for purposes of WSDL based endpoints such as JAX-RS and for WSDL retrieval.

Example 22. http-conf:conduit Element examples

<http-conf:conduit name=
   "{http://widgets/widgetvendor.net}widgetSOAPPort.http-conduit">
   ...
</http-conf:conduit>

<http-conf:conduit name="*.http-conduit">
<!-- you can also using a wild card specify the http-conduit 
   that you want to configure -->
   ...
</http-conf:conduit>
  
<http-conf:conduit name="http://localhost:8080/.">
<!-- you can also use the reg-ex URL to match for 
   the http-conduit that you want to configure -->
   ...
</http-conf:conduit>

<http-conf:conduit name="http://localhost:8080/.*">
<!-- you can also using the reg-ex URL matching for 
     the http-conduit that you want to configure -->
  ...
</http-conf:conduit>
...

The http-conf:conduit element has a number of child elements that specify configuration information. They are described below. See also Sun's JSSE Guide for more information on configuring SSL.

Element

Description

http-conf:client

Specifies the HTTP connection properties such as timeouts, keep-alive requests, content types, etc.

http-conf:authorization

Specifies the the parameters for configuring the basic authentication method that the endpoint uses preemptively.

http-conf:proxyAuthorization

Specifies the parameters for configuring basic authentication against outgoing HTTP proxy servers.

http-conf:tlsClientParameters

Specifies the parameters used to configure SSL/TLS.

http-conf:authSupplier

Specifies the bean reference or class name of the object that supplies the authentication information used by the endpoint both preemptively or in response to a 401 HTTP challenge.

http-conf:trustDecider

Specifies the bean reference or class name of the object that checks the HTTP(S) URLConnection object in order to establish trust for a connection with an HTTPS service provider before any information is transmitted.

The client element

The http-conf:client element is used to configure the non-security properties of a client's HTTP connection. Its attributes, described below, specify the connection's properties.

Attribute

Description

ConnectionTimeout

Specifies the amount of time, in milliseconds, that the client will attempt to establish a connection before it times out. The default is 30000 (30 seconds). 0 specifies that the client will continue to attempt to open a connection indefinitely.

ReceiveTimeout

Specifies the amount of time, in milliseconds, that the client will wait for a response before it times out. The default is 60000. 0 specifies that the client will wait indefinitely.

AutoRedirect

Specifies if the client will automatically follow a server issued redirection. The default is false.

MaxRetransmits

Specifies the maximum number of times a client will retransmit a request to satisfy a redirect. The default is -1 which specifies that unlimited retransmissions are allowed.

AllowChunking

Specifies whether the client will send requests using chunking. The default is true which specifies that the client will use chunking when sending requests. Chunking cannot be used used if either of the following are true:

  • http-conf:basicAuthSupplier is configured to provide credentials preemptively.

  • AutoRedirect is set to true. In both cases the value of AllowChunking is ignored and chunking is disallowed. See note about chunking below.

ChunkingThreshold

Specifies the threshold at which CXF will switch from non-chunking to chunking. By default, messages less than 4K are buffered and sent non-chunked. Once this threshold is reached, the message is chunked.

Accept

Specifies what media types the client is prepared to handle. The value is used as the value of the HTTP Accept property. The value of the attribute is specified using as multipurpose internet mail extensions (MIME) types. See note about chunking below.

AcceptLanguage

Specifies what language (for example, American English) the client prefers for the purposes of receiving a response. The value is used as the value of the HTTP AcceptLanguage property. Language tags are regulated by the International Organization for Standards (ISO) and are typically formed by combining a language code, determined by the ISO-639 standard, and country code, determined by the ISO-3166 standard, separated by a hyphen. For example, en-US represents American English.

AcceptEncoding

Specifies what content encodings the client is prepared to handle. Content encoding labels are regulated by the Internet Assigned Numbers Authority (IANA). The value is used as the value of the HTTP AcceptEncoding property.

ContentType

Specifies the media type of the data being sent in the body of a message. Media types are specified using multipurpose internet mail extensions (MIME) types. The value is used as the value of the HTTP ContentType property. The default is text/xml . Tip: For web services, this should be set to text/xml . If the client is sending HTML form data to a CGI script, this should be set to application/x-www-form-urlencoded. If the HTTP POST request is bound to a fixed payload format (as opposed to SOAP), the content type is typically set to application/octet-stream.

Host

Specifies the Internet host and port number of the resource on which the request is being invoked. The value is used as the value of the HTTP Host property. Tip: This attribute is typically not required. It is only required by certain DNS scenarios or application designs. For example, it indicates what host the client prefers for clusters (that is, for virtual servers mapping to the same Internet protocol (IP) address).

Connection

Specifies whether a particular connection is to be kept open or closed after each request/response dialog. There are two valid values:

  • Keep-Alive (default) specifies that the client wants to keep its connection open after the initial request/response sequence. If the server honors it, the connection is kept open until the consumer closes it.

  • close specifies that the connection to the server is closed after each request/response sequence.

CacheControl

Specifies directives about the behavior that must be adhered to by caches involved in the chain comprising a request from a client to a server.

Cookie

Specifies a static cookie to be sent with all requests.

BrowserType

Specifies information about the browser from which the request originates. In the HTTP specification from the World Wide Web consortium (W3C) this is also known as the user-agent . Some servers optimize based upon the client that is sending the request.

Referer

Specifies the URL of the resource that directed the consumer to make requests on a particular service. The value is used as the value of the HTTP Referer property. Note: This HTTP property is used when a request is the result of a browser user clicking on a hyperlink rather than typing a URL. This can allow the server to optimize processing based upon previous task flow, and to generate lists of back-links to resources for the purposes of logging, optimized caching, tracing of obsolete or mistyped links, and so on. However, it is typically not used in web services applications. Important: If the AutoRedirect attribute is set to true and the request is redirected, any value specified in the Refererattribute is overridden. The value of the HTTP Referer property will be set to the URL of the service who redirected the consumer's original request.

DecoupledEndpoint

Specifies the URL of a decoupled endpoint for the receipt of responses over a separate server->client connection. Warning: You must configure both the client and server to use WS-Addressing for the decoupled endpoint to work.

ProxyServer

Specifies the URL of the proxy server through which requests are routed.

ProxyServerPort

Specifies the port number of the proxy server through which requests are routed.

NonProxyHosts

Specifies a list of hosts that should be directly routed. This value is a list of patterns separated by '|', where each pattern may start or end with a '*' for wildcard matching.

ProxyServerType

Specifies the type of proxy server used to route requests. Valid values are:

  • HTTP(default)

  • SOCKS

Example using the Client Element

The example below shows a the configuration for an HTTP client that wants to keep its connection to the server open between requests, will only retransmit requests once per invocation, and cannot use chunking streams.

Example 23. HTTP Consumer Endpoint Configuration

<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"
   xsi:schemaLocation="
      http://cxf.apache.org/transports/http/configuration
      http://cxf.apache.org/schemas/configuration/http-conf.xsd
      http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans.xsd">

   <http-conf:conduit name=
      "{http://apache.org/hello_world_soap_http}SoapPort.http-conduit">
      <http-conf:client Connection="Keep-Alive"
         MaxRetransmits="1"
         AllowChunking="false" />
   </http-conf:conduit>
</beans>

Again, see the Configuration page for information on how to get CXF to detect your configuration file.

The tlsClientParameters element

Please see TLS Configuration page for more information.

Using WSDL
Namespace

The WSDL extension elements used to configure an HTTP client are defined in the namespace http://cxf.apache.org/transports/http/configuration . It is commonly referred to using the prefix http-conf . In order to use the HTTP configuration elements you will need to add the line shown below to the definitions element of your endpoint's WSDL document.

Example 24. HTTP Consumer WSDL Element's Namespace

<definitions ...
   xmlns:http-conf="http://cxf.apache.org/transports/http/configuration

The client element

The http-conf:client element is used to specify the connection properties of an HTTP client in a WSDL document. The http-conf:client element is a child of the WSDL port element. It has the same attributes as the client element used in the configuration file.

Example

The example below shows a WSDL fragment that configures an HTTP client to specify that it will not interact with caches.

Example 25. WSDL to Configure an HTTP Consumer Endpoint

<service ...>
   <port ...>
      <soap:address ... />
      <http-conf:client CacheControl="no-cache" />
   </port>
</service>

Using java code
How to configure the HTTPConduit for the SOAP Client?

First you need get the HTTPConduit from the Proxy object or Client, then you can set the HTTPClientPolicy , AuthorizationPolicy, ProxyAuthorizationPolicy, TLSClientParameters , and/or HttpBasicAuthSupplier .

import org.apache.cxf.endpoint.Client;
import org.apache.cxf.frontend.ClientProxy;
import org.apache.cxf.transport.http.HTTPConduit;
import org.apache.cxf.transports.http.configuration.HTTPClientPolicy;
...

URL wsdl = getClass().getResource("wsdl/greeting.wsdl");
SOAPService service = new SOAPService(wsdl, serviceName);
Greeter greeter = service.getPort(portName, Greeter.class);

// Okay, are you sick of configuration files ?
// This will show you how to configure the http conduit dynamically
Client client = ClientProxy.getClient(greeter);
HTTPConduit http = (HTTPConduit) client.getConduit();

HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();

httpClientPolicy.setConnectionTimeout(36000);
httpClientPolicy.setAllowChunking(false);
httpClientPolicy.setReceiveTimeout(32000);

http.setClient(httpClientPolicy);

...
greeter.sayHi("Hello");
How to override the service address ?

If you are using JAXWS API to create the proxy obejct, here is an example which is complete JAX-WS compliant code

URL wsdlURL = MyService.class.getClassLoader.getResource ("myService.wsdl");
QName serviceName = new QName("urn:myService", "MyService");
MyService service = new MyService(wsdlURL, serviceName);
ServicePort client = service.getServicePort();
BindingProvider provider = (BindingProvider)client;
// You can set the address per request here
provider.getRequestContext().put(
   BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
   "http://my/new/url/to/the/service");

If you are using CXF ProxyFactoryBean to create the proxy object , you can do like this

JaxWsProxyFactoryBean proxyFactory = new JaxWsProxyFactoryBean();
proxyFactory.setServiceClass(ServicePort.class);
// you could set the service address with this method
proxyFactory.setAddress("theUrlyouwant");
ServicePort client = (ServicePort) proxyFactory.create();

Here is another way which takes advantage of JAXWS's Service.addPort() API

URL wsdlURL = MyService.class.getClassLoader.getResource(
   "service2.wsdl");
QName serviceName = new QName("urn:service2", "MyService");
QName portName = new QName("urn:service2", "ServicePort");
MyService service = new MyService(wsdlURL, serviceName);
// You can add whatever address as you want
service.addPort(portName, "http://schemas.xmlsoap.org/soap/", 
   "http://the/new/url/myService");
// Passing the SEI class that is generated by wsdl2java      
ServicePort proxy = service.getPort(portName, SEI.class);
Client Cache Control Directives

The following table lists the cache control directives supported by an HTTP client.

Directive

Behavior

no-cache

Caches cannot use a particular response to satisfy subsequent requests without first revalidating that response with the server. If specific response header fields are specified with this value, the restriction applies only to those header fields within the response. If no response header fields are specified, the restriction applies to the entire response.

no-store

Caches must not store any part of a response or any part of the request that invoked it.

max-age

The consumer can accept a response whose age is no greater than the specified time in seconds.

max-stale

The consumer can accept a response that has exceeded its expiration time. If a value is assigned to max-stale, it represents the number of seconds beyond the expiration time of a response up to which the consumer can still accept that response. If no value is assigned, it means the consumer can accept a stale response of any age.

min-fresh

The consumer wants a response that will be still be fresh for at least the specified number of seconds indicated.

no-transform

Caches must not modify media type or location of the content in a response between a provider and a consumer.

only-if-cached

Caches should return only responses that are currently stored in the cache, and not responses that need to be reloaded or revalidated.

cache-extension

Specifies additional extensions to the other cache directives. Extensions might be informational or behavioral. An extended directive is specified in the context of a standard directive, so that applications not understanding the extended directive can at least adhere to the behavior mandated by the standard directive.

A Note About Chunking

There are two ways of putting a body into an HTTP stream:

  • The "standard" way used by most browsers is to specify a Content-Length header in the HTTP headers. This allows the receiver to know how much data is coming and when to stop reading. The problem with this approach is that the length needs to be pre-determined. The data cannot be streamed as generated as the length needs to be calculated upfront. Thus, if chunking is turned off, we need to buffer the data in a byte buffer (or temp file if too large) so that the Content-Length can be calculated.

  • Chunked - with this mode, the data is sent to the receiver in chunks. Each chunk is preceded by a hexidecimal chunk size. When a chunk size is 0, the receiver knows all the data has been received. This mode allows better streaming as we just need to buffer a small amount, up to 8K by default, and when the buffer fills, write out the chunk.

In general, Chunked will perform better as the streaming can take place directly. HOWEVER, there are some problems with chunking:

  • Many proxy servers don't understand it, especially older proxy servers. Many proxy servers want the Content-Length up front so they can allocate a buffer to store the request before passing it onto the real server.

  • Some of the older WebServices stacks also have problems with Chunking. Specifically, older versions of .NET.

If you are getting strange errors (generally not SOAP faults, but other HTTP type errors) when trying to interact with a service, try turning off chunking to see if that helps.

When to set custom headers

If you use a custom CXF interceptor to set one or more outbound HTTP headers then it is recommended to get this interceptor running at a stage preceding the WRITE stage, before the outbound body is written out.

Otherwise the custom headers may get lost. The headers may get retained in some cases even if they are added after the body is written out, example, when a chunking threshold value (4K by default) has not been reached, but relying on it for the headers not to be lost is brittle and should be avoided.

Asynchronous HTTP Conduit

Please see Asynchronous HTTP Conduit page for more information.

Authentication

Basic Authentication sample:

<conduit name="{http://example.com/}HelloWorldServicePort.http-conduit" 
   xmlns:sec="http://cxf.apache.org/configuration/security"
   xmlns="http://cxf.apache.org/transports/http/configuration">
   <authorization>
      <sec:UserName>myuser</sec:UserName>
      <sec:Password>mypasswd</sec:Password>
      <sec:AuthorizationType>Basic</sec:AuthorizationType>
   </authorization>
</conduit>

For Digest Authentication, use the same as above but with AuthorizationType value of Digest. (Note the AuthorizationType element can be omitted if you're using Basic authentication, as above.)

Authorization can also be supplied dynamically, by implementing the org.apache.cxf.transport.http.auth.HttpAuthSupplier interface or another interface which extends it. The main method this interface provides is:

public String getAuthorization(AuthorizationPolicy authPolicy, 
   URL currentURL, Message message, String fullHeader);

With this method you'll need to supply the HttpAuthPolicy, the service URL, the CXF message and the full Authorization header (what the server sent in its last response). With the latter value multi-phase authentications can be implemented. For a simple implementation check the org.apache.cxf.transport.http.auth.DefaultBasicAuthSupplier class. On the conduit above, declare your implementation class in an AuthSupplier element for CXF to use it.

Spnego Authentication (Kerberos)

CXF supports Spnego authentication using the standard AuthPolicy mechanism. Spnego is activated by setting the AuthPolicy.authorizationType to 'Negotiate'. If userName is left blank then single sign on is used with the TGT from e.g. Windows Login. If userName is set then a new LoginContext is established and the ticket is created out of this. By default the SpnegoAuthSupplier uses the OID for Spnego. Some servers require the OID for Kerberos. This can be activated by setting the contextual property auth.spnego.useKerberosOid to 'true'.

Kerberos Config: Make sure that krb5.conf/krb5.ini is configured correctly for the Kerberos realm you want to authenticate against and supply it to your application by setting the java.security.krb5.conf system property

Login Config: Create a file login.conf and supply it to CXF using the System property java.security.auth.login.config. The file should contain:

CXFClient {
com.sun.security.auth.module.Krb5LoginModule    //
   required client=TRUE useTicketCache=true;
};

Sample config: Make sure the Authorization element contains the same name as the Section in the login.conf (here: CXFClient).

<!-- HTTP conduit configuration for spnego with single sign on -->
<conduit name="{http://example.com/}HelloWorldServicePort.http-conduit" 
   xmlns="http://cxf.apache.org/transports/http/configuration">
   <authorization>
      <AuthorizationType>Negotiate</AuthorizationType>
      <Authorization>CXFClient</Authorization>
   </authorization>
</conduit>

You can use UserName and Password in the above xml config if you want to log in explicitly. If you want to use the cached Ticket Granting Ticket then do not supply them. On Windows you will also have to make sure you allow the TGT to be used in Java. See: http://www.javaactivedirectory.com/?page_id=93 for more information.

<!-- Switching to Kerberos OID instead of Spnego -->
<jaxws:client>
   <jaxws:properties>
      <entry key="auth.spnego.useKerberosOid" value="true"/>
   </jaxws:properties>
</jaxws:client>
NTLM Authentication

On Java 6, NTLM authentication is built into the Java runtime and you don't need to do anything special.

Next, you need to configure jcifs to use the correct domains, wins servers, etc... Notice that the bit which sets the username/password to use for NTLM is commented out. If credentials are missing jcifs will use the underlying NT credentials.

//Set the jcifs properties
jcifs.Config.setProperty("jcifs.smb.client.domain", "ben.com");
jcifs.Config.setProperty("jcifs.netbios.wins", "xxx.xxx.xxx.xxx");
jcifs.Config.setProperty("jcifs.smb.client.soTimeout", 
   "300000"); //5 minutes
jcifs.Config.setProperty("jcifs.netbios.cachePolicy", 
   "1200"); //20 minutes
//jcifs.Config.setProperty("jcifs.smb.client.username", "myNTLogin");
//jcifs.Config.setProperty("jcifs.smb.client.password", "secret");

//Register the jcifs URL handler to enable NTLM
jcifs.Config.registerSmbURLHandler();

Finally, you need to setup the CXF client to turn off chunking. The reason is that the NTLM authentication requires a 3 part handshake which breaks the streaming.

//Turn off chunking so that NTLM can occur
Client client = ClientProxy.getClient(port);
HTTPConduit http = (HTTPConduit) client.getConduit();
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
httpClientPolicy.setConnectionTimeout(36000);
httpClientPolicy.setAllowChunking(false);
http.setClient(httpClientPolicy);

Please also see Asynchronous Client HTTP Transport for more information on NTLM.

Server HTTP Transport

HTTP server endpoints can specify a number of HTTP connection attributes including if it will honor keep alive requests, how it interacts with caches, and how tolerant it is of errors in communicating with a consumer.

A server endpoint can be configured using two mechanisms:

  • Configuration

  • WSDL

Using Configuration
Namespace

The elements used to configure an HTTP provider endpoint are defined in the namespace http://cxf.apache.org/transports/http/configuration. It is commonly referred to using the prefix http-conf . In order to use the HTTP configuration elements you will need to add the lines shown below to the beans element of your endpoint's configuration file. In addition, you will need to add the configuration elements' namespace to the xsi:schemaLocation attribute.

Example 26. Adding the Configuration Namespace

<beans ...
   xmlns:http-conf="http://cxf.apache.org/transports/http/configuration
   ...
   xsi:schemaLocation="...
      http://cxf.apache.org/transports/http/configuration
      http://cxf.apache.org/schemas/configuration/http-conf.xsd
   ...">

The destination element

You configure an HTTP server endpoint using the http-conf:destination element and its children. The http-conf:destination element takes a single attribute, name , the specifies the WSDL port element that corresponds to the endpoint. The value for the name attribute takes the form portQName .http-destination . The example below shows the http-conf:destination element that would be used to add configuration for an endpoint that was specified by the WSDL fragment <port binding="widgetSOAPBinding" name="widgetSOAPPort> if the endpoint's target namespace was http://widgets.widgetvendor.net .

Example 27. http-conf:destination Element

<http-conf:destination name=
   "{http://widgets/widgetvendor.net}widgetSOAPPort.http-destination">
   ...
</http-conf:destination>

The http-conf:destination element has a number of child elements that specify configuration information. They are described below.

Element

Description

http-conf:server

Specifies the HTTP connection properties.

http-conf:contextMatchStrategy

Specifies the parameters that configure the context match strategy for processing HTTP requests.

http-conf:fixedParameterOrder

Specifies whether the parameter order of an HTTP request handled by this destination is fixed.

The server element

The http-conf:server element is used to configure the properties of a server's HTTP connection. Its attributes, described below, specify the connection's properties.

Attribute

Description

ReceiveTimeout

Sets the length of time, in milliseconds, the server tries to receive a request before the connection times out. The default is 30000. The specify that the server will not timeout use 0.

SuppressClient-SendErrors

Specifies whether exceptions are to be thrown when an error is encountered on receiving a request. The default is false ; exceptions are thrown on encountering errors.

SuppressClient-ReceiveErrors

Specifies whether exceptions are to be thrown when an error is encountered on sending a response to a client. The default is false ; exceptions are thrown on encountering errors.

HonorKeepAlive

Specifies whether the server honors requests for a connection to remain open after a response has been sent. The default is true ; keep-alive requests are honored.

RedirectURL

Specifies the URL to which the client request should be redirected if the URL specified in the client request is no longer appropriate for the requested resource. In this case, if a status code is not automatically set in the first line of the server response, the status code is set to 302 and the status description is set to Object Moved. The value is used as the value of the HTTP RedirectURL property.

CacheControl

Specifies directives about the behavior that must be adhered to by caches involved in the chain comprising a response from a server to a client.

ContentLocation

Sets the URL where the resource being sent in a response is located.

ContentType

Specifies the media type of the information being sent in a response. Media types are specified using multipurpose internet mail extensions (MIME) types. The value is used as the value of the HTTP ContentType location.

ContentEncoding

Specifies any additional content encodings that have been applied to the information being sent by the service provider. Content encoding labels are regulated by the Internet Assigned Numbers Authority (IANA). Possible content encoding values include zip, gzip, compress, deflate, and identity. This value is used as the value of the HTTP ContentEncoding property.

ServerType

Specifies what type of server is sending the response. Values take the form program-name/version. For example, Apache/1.2.5.

Example

The example below shows a the configuration for an HTTP service provider endpoint that honors keep alive requests and suppresses all communication errors.

Example 28. HTTP Service Provider Endpoint Configuration

<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:http-conf=
      "http://cxf.apache.org/transports/http/configuration"
   xsi:schemaLocation="
      http://cxf.apache.org/transports/http/configuration
      http://cxf.apache.org/schemas/configuration/http-conf.xsd
      http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans.xsd">
   
   <http-conf:destination name=
      "{http://apache.org/hello_soap_http}SoapPort.http-destination">
      <http-conf:server SuppressClientSendErrors="true"
         SuppressClientReceiveErrors="true"
         HonorKeepAlive="true" />
   </http-conf:destination>
</beans>

Using WSDL
Namespace

The WSDL extension elements used to configure an HTTP server endpoint are defined in the namespace http://cxf.apache.org/transports/http/configuration . It is commonly refered to using the prefix http-conf . In order to use the HTTP configuration elements you will need to add the line shown below to the definitions element of your endpoint's WSDL document.

Example 29. HTTP Provider WSDL Element's Namespace

<definitions ...
   xmlns:http-conf="http://cxf.apache.org/transports/http/configuration

The server element

The http-conf:server element is used to specify the connection properties of an HTTP server in a WSDL document. The http-conf:server element is a child of the WSDL port element. It has the same attributes as the server element used in the configuration file.

Example

The example below shows a WSDL fragment that configures an HTTP server endpoint to specify that it will not interact with caches.

Example 30. WSDL to Configure an HTTP Service Provider Endpoint

<service ...>
   <port ...>
      <soap:address ... />
      <http-conf:server CacheControl="no-cache" />
   </port>
</service>

Server Cache Control Directives

The table below lists the cache control directives supported by an HTTP server.

Directive

Behavior

no-cache

Caches cannot use a particular response to satisfy subsequent requests without first revalidating that response with the server. If specific response header fields are specified with this value, the restriction applies only to those header fields within the response. If no response header fields are specified, the restriction applies to the entire response.

public

Any cache can store the response.

private

Public (shared) caches cannot store the response because the response is intended for a single user. If specific response header fields are specified with this value, the restriction applies only to those header fields within the response. If no response header fields are specified, the restriction applies to the entire response.

no-store

Caches must not store any part of response or any part of the request that invoked it.

no-transform

Caches must not modify the media type or location of the content in a response between a server and a client.

must-revalidate

Caches must revaildate expired entries that relate to a response before that entry can be used in a subsequent response.

proxy-revalidate

Means the same as must-revalidate, except that it can only be enforced on shared caches and is ignored by private unshared caches. If using this directive, the public cache directive must also be used.

max-age

Clients can accept a response whose age is no greater that the specified number of seconds.

s-max-age

Means the same as max-age, except that it can only be enforced on shared caches and is ignored by private unshared caches. The age specified by s-max-age overrides the age specified by max-age. If using this directive, the proxy-revalidate directive must also be used.

cache-extension

Specifies additional extensions to the other cache directives. Extensions might be informational or behavioral. An extended directive is specified in the context of a standard directive, so that applications not understanding the extended directive can at least adhere to the behavior mandated by the standard directive.

Servlet Transport

To create services that use this transport you can either use the CXF APIs (for example, see JAX-WS ) or create an XML file which registers services for you.

Publishing an endpoint from XML

CXF uses Spring to provide XML configuration of services. This means that first we'll want to load Spring via a Servlet listener and tell it where our XML configuration file is:

Next, you'll need to add CXFServlet to your web.xml:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
    "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
   <context-param>
      <param-name>contextConfigLocation</param-name>
      <param-value>
         classpath:com/acme/ws/services.xml
      </param-value>
   </context-param>

   <listener>
      <listener-class>
         org.springframework.web.context.ContextLoaderListener
      </listener-class>
   </listener>

   <servlet>
      <servlet-name>CXFServlet</servlet-name>
      <display-name>CXF Servlet</display-name>
      <servlet-class>
         org.apache.cxf.transport.servlet.CXFServlet
      </servlet-class>
      <load-on-startup>1</load-on-startup>     
   </servlet>

   <servlet-mapping>
      <servlet-name>CXFServlet</servlet-name>
      <url-pattern>/services/*</url-pattern>
   </servlet-mapping>
</web-app>

The next step is to actually write the configuration file:

<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:jaxws="http://cxf.apache.org/jaxws"
   xmlns:jaxrs="http://cxf.apache.org/jaxrs"
   xsi:schemaLocation="
      http://www.springframework.org/schema/beans 
      http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
      http://cxf.apache.org/jaxws 
      http://cxf.apache.org/schemas/jaxws.xsd
      http://cxf.apache.org/jaxrs 
      http://cxf.apache.org/schemas/jaxrs.xsd">

   <import resource="classpath:META-INF/cxf/cxf.xml"/>
   <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml"/>
   <import resource=
      "classpath:META-INF/cxf/cxf-extension-jaxrs-binding.xml"/>
   <import resource="classpath:META-INF/cxf/cxf-servlet.xml"/>

   <jaxws:endpoint id="greeter"
      implementor="org.apache.hello_soap_http.GreeterImpl"
      address="/Greeter1"/>

   <jaxrs:server id="greeterRest"
      serviceClass="org.apache.hello_soap_http.GreeterImpl"
      address="/GreeterRest"/> 

</beans>

Here we're creating a JAX-WS endpoint based on our implementation class, GreeterImpl.

NOTE: We're publishing endpoints "http://localhost/mycontext/services/Greeter1" and "http://localhost/mycontext/services/GreeterRest", but we set jaxws:endpoint/@address and jaxrs:server/@address to relative values such as "/Greeter1" "/GreeterRest".

Support for Asynchronous Requests

Enable an 'async-supported' servlet property if you work with Servlet3 API containers and need to support asynchronous requests:

<servlet>
    <servlet-name>CXFServlet</servlet-name>
    <display-name>CXF Servlet</display-name>
    <servlet-class>
       org.apache.cxf.transport.servlet.CXFServlet
    </servlet-class>

    <!-- Enable asynchronous requests -->

    <async-supported>true</async-supported>

    <load-on-startup>1</load-on-startup>
</servlet>
Redirecting requests and serving the static content

It is possible to configure CXFServlet to redirect current requests to other servlets or serve the static resources.

"redirects-list" init parameter can be used to provide a space separated list of URI patterns; if a given request URI matches one of the patterns then CXFServlet will try to find a RequestDispatcher using the pathInfo of the current HTTP request and will redirect the request to it.

"redirect-servlet-path" can be used to affect a RequestDispatcher lookup, if specified then it will concatenated with the pathInfo of the current request.

"redirect-servlet-name" init parameter can be used to enable a named RequestDispatcher look-up, after one of the URI patterns in the "redirects-list" has matched the current request URI.

"static-resources-list" init parameter can be used to provide a space separated list of static resource such as html, css, or pdf files which CXFServlet will serve directly.

One can have requests redirected to other servlets or JSP pages.

CXFServlets serving both JAXWS and JAXRS based endpoints can avail of this feature.

For example, please see this web.xml .

The http://localhost:9080/the/bookstore1/books/html/123 request URI will initially be matched by the CXFServlet given that it has a more specific URI pattern than the RedirectCXFServlet. After a current URI has reached a jaxrs:server endpoint, the response will be redirected by the JAXRS RequestDispatcherProvider to a "/book.html" address, see "dispatchProvider1" bean here .

Next, the request URI "/book.html" will be handled by RedirectCXFServlet. Note that a uri pattern can be a regular expression. This servlet redirects the request further to a RequestDispatcher capable of handling a "/static/book.html".

Finally, DefaultCXFServlet serves a requested book.html.

Serving welcome pages

Starting from CXF 2.5.5 and 2.6.2 it is possible to configure CXFServlet to serve welcome pages in a number of ways.

For example, lets assume we have a web application called "webapp" which has a root resource called "index.html". For CXFServlet to support both "/webapp" and "/webapp/index.html" requests returning "index.html", while letting all other requests to proceed to the actual endpoints, the following can be done.

Option1. Delegating to Default Servlet

<servlet>
    <servlet-name>CXFServlet</servlet-name>
    <display-name>CXF Servlet</display-name>
    <servlet-class>
      org.apache.cxf.transport.servlet.CXFServlet
    </servlet-class>
    <init-param>
        <param-name>redirects-list</param-name>
        <param-value>
           /
           /index.html
        </param-value>
    </init-param>
    <init-param>
        <param-name>redirect-attributes</param-name>
        <param-value>
          javax.servlet.include.request_uri
        </param-value>
    </init-param>
    <init-param>
        <param-name>redirect-servlet-name</param-name>
        <param-value>default</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>CXFServlet</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>

<welcome-file-list>
    <welcome-file>index.html</welcome-file>
</welcome-file-list>

Note that the redirects-list parameter has two space separated values, "/" and "index.html". The request attribute 'javax.servlet.include.request_uri' might need to be set for the underlying container like Jetty to successfully read "index.html".

Option2. Using CXFServlet itself to read index.html

<servlet>
    <servlet-name>CXFServlet</servlet-name>
    <display-name>CXF Servlet</display-name>
    <servlet-class>
       org.apache.cxf.transport.servlet.CXFServlet
    </servlet-class>
    <init-param>
        <param-name>static-welcome-file</param-name>
        <param-value>/index.html</param-value>
    </init-param>
    <init-param>
        <param-name>static-resources-list</param-name>
        <param-value>/index.html</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>CXFServlet</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>
Publishing an endpoint with the API

Once your Servlet is registered in your web.xml, you should set the default bus with CXFServlet's bus to make sure that CXF uses it as its HTTP Transport. Simply publish with the related path "Greeter" and your service should appear at the address you specify:

import javax.xml.ws.Endpoint;
import org.apache.cxf.Bus;
import org.apache.cxf.BusFactory;
import org.apache.cxf.transport.servlet.CXFServlet;
.....
// cxf is the instance of the CXFServlet, you could also get
// this instance by extending the CXFServlet
Bus bus = cxf.getBus();
BusFactory.setDefaultBus(bus); 
Endpoint.publish("/Greeter", new GreeterImpl());

The one thing you must ensure is that your CXFServlet is set up to listen on that path. Otherwise the CXFServlet will never receive the requests.

NOTE:

Endpoint.publish(...) is a JAX-WS API for publishing JAX-WS endpoints. Thus, it would require the JAX-WS module and APIs to be present. If you are not using JAX-WS or want more control over the published endpoint properties, you should replace that call with the proper calls to the appropriate ServerFactory.

Since CXFServlet know nothing about the web container listening port and the application context path, you need to specify the relative path instead of the full http address.

Using the servlet transport without Spring

A user who doesn't want to use the Spring libraries can alternatively publish the endpoint with CXF servlet transport. To do this, extend the CXFNonSpringServlet and then override the method loadBus, e.g.:

@Override
public void loadBus(ServletConfig servletConfig) 
   throws ServletException {
   super.loadBus(servletConfig);        
        
   // You could add the endpoint publish codes here
   Bus bus = cxf.getBus();
   BusFactory.setDefaultBus(bus); 
   Endpoint.publish("/Greeter", new GreeterImpl());
        
   // You can als use the simple frontend API to do this
   ServerFactoryBean factroy = new ServerFactoryBean();
   factory.setBus(bus);
   factory.setServiceClass(GreeterImpl.class);
   factory.setAddress("/Greeter");
   factory.create();              
}

If you are using Jetty as the embedded servlet engine, the endpoint can be published as follows:

// Set up the system properties to use 
// the CXFBusFactory not the SpringBusFactory
String busFactory = 
System.getProperty(BusFactory.BUS_FACTORY_PROPERTY_NAME);
System.setProperty(BusFactory.BUS_FACTORY_PROPERTY_NAME, 
   "org.apache.cxf.bus.CXFBusFactory");
try {
   // Start up the jetty embedded server
   httpServer = new Server(9000);
   ContextHandlerCollection contexts 
      = new ContextHandlerCollection();
   httpServer.setHandler(contexts);
            
   Context root = new Context(contexts, "/", Context.SESSIONS);
            
   CXFNonSpringServlet cxf = new CXFNonSpringServlet();
   ServletHolder servlet = new ServletHolder(cxf);
   servlet.setName("soap");
   servlet.setForcedPath("soap");
   root.addServlet(servlet, "/soap/*");
            
   httpServer.start();
           
   Bus bus = cxf.getBus();
   setBus(bus);
   BusFactory.setDefaultBus(bus);
   GreeterImpl impl = new GreeterImpl();
   Endpoint.publish("/Greeter", impl);
} catch (Exception e) {
   throw new RuntimeException(e);
} finally {
   // clean up the system properties
   if (busFactory != null) {
      System.setProperty(BusFactory.BUS_FACTORY_PROPERTY_NAME, 
      busFactory);
   } else {
      System.clearProperty(BusFactory.BUS_FACTORY_PROPERTY_NAME);
   }
}
Accessing the MessageContext and/or HTTP Request and Response

Sometimes you'll want to access more specific message details in your service implementation. One example might be accessing the actual request or response object itself. This can be done using the WebServiceContext object.

First, declare a private field for the WebServiceContext in your service implementation, and annotate it as a resource:

@Resource
private WebServiceContext context;

Then, within your implementing methods, you can access the MessageContext, HttpServletRequest, and HttpServletResponse as follows:

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.xml.ws.handler.MessageContext;
import org.apache.cxf.transport.http.AbstractHTTPDestination;
...

MessageContext ctx = context.getMessageContext();
HttpServletRequest request = (HttpServletRequest) 
   ctx.get(AbstractHTTPDestination.HTTP_REQUEST);
HttpServletResponse response = (HttpServletResponse) 
   ctx.get(AbstractHTTPDestination.HTTP_RESPONSE);

Of course, it is always a good idea to program defensively if using transport-specific entities like the HttpServletRequest and HttpServletResponse. If the transport were changed (for instance to the JMS transport), then these values would likely be null.

Asynchronous Client HTTP Transport

By default, CXF uses a transport based on the in-JDK HttpURLConnection object to perform HTTP requests. The HttpURLConnection object uses a blocking model for all IO operations which requires a per-thread execution model. From a pure performance standpoint, this model generally performs very well, but it does have problems scaling when many requests need to be executed simultaneously.

Also, the JAX-WS specification allows for generation of asynchronous methods on generated proxies as well as using asynchronous methods on the Dispatch objects. These methods can take an AsyncHandler object and return a polling Future object so applications do not have to wait for the response. With the HttpURLConnection based transport, CXF was forced to consume a background thread for each outstanding request.

CXF also has an HTTP client transport that is based on the Apache HTTP Components HttpAsyncClient library. Its Maven artifactId is cxf-rt-transports-http-hc. The HttpAsyncClient library uses a non-blocking IO model. This allows many more requests to be outstanding without consuming extra background threads. It also allows greater control over things like Keep-Alive handling which is very difficult or impossible with the HttpURLConnection based transport. However, the non-blocking model does not perform quite as well as the blocking model for pure synchronous request/response transactions.

By default, if the cxf-rt-transports-http-hc module is found on the classpath, CXF will use the HttpAsyncClient based implementation for any Async calls, but will continue to use the HttpURLConnection based transport for synchronous calls. This allows a good balance of performance for the common synchronous cases with scalability for the asynchronous cases. However, using a contextual property of "use.async.http.conduit" and set to true/false, you can control whether the async or blocking version is used. If "true", the HttpAsyncClient will be used even for synchronous calls, if "false", asynchronous calls will rely on the traditional method of using HTTPURLConnection along with a work queue to mimic the asynchronocity.

Another reason to use the asynchronous transport is to use HTTP methods that HttpURLConnection does not support. For example, the github.com REST API specifies the use of PATCH for some cases, but HttpURLConnection rejects PATCH.

Using the HTTP Components Transport from Java Code

To force global use of the HTTP Components transport, you can set a bus-level property:

Bus bus = BusFactory.getDefaultBus();
// insist on the async connector to use PATCH.
bus.setProperty(AsyncHTTPConduit.USE_ASYNC, Boolean.TRUE);
Setting Credentials

The "normal" CXF/JAX-WS method of setting user credentials via the BindingProvider.USERNAME_PROPERTY/PASSWORD_PROPERTY will work with the Async transport as well. However, the HttpAsyncClient library does have some additional capabilities around NTLM that can be leveraged. In order to use that, you need to:

  • Turn on the AutoRedirect and turn off the Chunking for the Conduit. This will allow CXF to cache the response in a manner that will allow the transport to keep resending the request during the authentication negotiation.

  • Force the use of the Async transport even for synchronous calls

    bp.getRequestContext().put("use.async.http.conduit", Boolean.TRUE);
  • Set the property "org.apache.http.auth.Credentials" to an instance of the Credentials. For example:

    Credentials creds = new NTCredentials("username", "pswd", null, "domain");
    bp.getRequestContext().put(Credentials.class.getName(), creds);
Configuration

The Asynchronous HTTP Transport has several options that can set using Bus properties or via the OSGi configuration services to control various aspects of the underlying Apache HTTP Components HttpAsyncClient objects.

Settings related to the underlying TCP socket (see the java.net.Socket JavaDoc for a definition of these values):

Option

org.apache.cxf.transport.http.async.TCP_NODELAY (Default true)

org.apache.cxf.transport.http.async.SO_KEEPALIVE

org.apache.cxf.transport.http.async.SO_LINGER

org.apache.cxf.transport.http.async.SO_TIMEOUT

Settings related to Keep-Alive connection management:

Option

Description

org.apache.cxf. transport.http.async. CONNECTION_TTL

Maximum time a connection is held open in ms. Default is 60000.

org.apache.cxf. transport.http.async. MAX_CONNECTIONS

Maximum number of connections opened per host. Default is 1000.

org.apache.cxf. transport.http.async. MAX_PER_HOST_CONNECTIONS

Maximum number of connections opened in total. Default is 5000.

Settings related to Apache HttpAsyncClient threads and selectors:

Option

Description

org.apache.cxf. transport.http.async. ioThreadCount

Number of threads HttpAsyncClient uses to process IO events. Default is "-1" which means one thread per CPU core.

org.apache.cxf. transport.http.async. interestOpQueued

true/false for whether the interest ops are queues or process directly.

org.apache.cxf. transport.http.async. selectInterval

Default 1000 ms. How often the selector thread wakes up if there are no events to process additional things like queue expirations.

Settings to control which conduit is used:

Option

Values

Description

org.apache.cxf. transport.http.async. usePolicy

ALWAYS, ASYNC_ONLY, NEVER

Similar in meaning to the "use.async.http.conduit" context property described above. Whether to use the HttpAsyncClient: ALWAYS for both synchronous and asynchronous calls, ASYNC_ONLY (default) for asynchronous calls only, NEVER will use HTTPURLConnection for both types of calls.

JMS Transport

CXF provides a transport plug-in that enables endpoints to use Java Message Service (JMS) queues and topics. CXF's JMS transport plug-in uses the Java Naming and Directory Interface (JNDI) to locate and obtain references to the JMS provider that brokers for the JMS destinations. Once CXF has established a connection to a JMS provider, CXF supports the passing of messages packaged as either a JMS ObjectMessage or a JMS TextMessage. The JMS transport also supports the SOAP over JMS specification, see SOAP over JMS 1.0 support.

Standard JMS transport configuration in CXF is done by defining a JMSConduit or JMSDestination, discussed below. There is however an alternative configuration option more conformant to Spring dependency injection, see Using the JMSConfigFeature.

JMS Namespaces

WSDL Namespace

The WSDL extensions for defining a JMS endpoint are defined in the namespace http://cxf.apache.org/transports/jms . In order to use the JMS extensions you will need to add the namespace definition shown below to the definitions element of your contract.

Example 31. JMS Extension Namespace

xmlns:jms="http://cxf.apache.org/transports/jms"

Configuration Namespaces

In order to use the JMS configuration properties you will need to add the line shown below to the beans element of your configuration.

Example 32. JMS Configuration Namespaces

xmlns:jms="http://cxf.apache.org/transports/jms"

Basic Endpoint Configuration

JMS endpoints need to know certain basic information about how to establish a connection to the proper destination. This information can be provided in one of two places: WSDL or XML configuration. The following configuration elements which are described can be used in both the client side Conduits and the server side Destinations.

Using WSDL

The JMS destination information is provided using the jms:address element and its child, the jms:JMSNamingProperties element. The jms:address element's attributes specify the information needed to identify the JMS broker and the destination. The jms:JMSNamingProperties element specifies the Java properties used to connect to the JNDI service.

The address element

The basic configuration for a JMS endpoint is done by using a jms:address element as the child of your service's port element. The jms:address element uses the attributes described below to configure the connection to the JMS broker.

Attribute

Description

destinationStyle

Specifies if the JMS destination is a JMS queue or a JMS topic.

jndiConnectionFactoryName

Specifies the JNDI name bound to the JMS connection factory to use when connecting to the JMS destination.

jndiDestinationName

Specifies the JNDI name bound to the JMS destination to which requests are sent.

jndiReplyDestinationName

Specifies the JNDI name bound to the JMS destinations where replies are sent. This attribute allows you to use a user defined destination for replies.

connectionUserName

Specifies the username to use when connecting to a JMS broker.

connectionPassword

Specifies the password to use when connecting to a JMS broker.

The JMSNamingProperties element

To increase interoperability with JMS and JNDI providers, the jms:address element has a child element, jms:JMSNamingProperties , that allows you to specify the values used to populate the properties used when connecting to the JNDI provider. The jms:JMSNamingProperties element has two attributes: name and value . The name attribute specifies the name of the property to set. The value attribute specifies the value for the specified property. The jms:JMSNamingProperties element can also be used for specification of provider specific properties. The following is a list of common JNDI properties that can be set:

  • java.naming.factory.initial

  • java.naming.provider.url

  • java.naming.factory.object

  • java.naming.factory.state

  • java.naming.factory.url.pkgs

  • java.naming.dns.url

  • java.naming.authoritative

  • java.naming.batchsize

  • java.naming.referral

  • java.naming.security.protocol

  • java.naming.security.authentication

  • java.naming.security.principal

  • java.naming.security.credentials

  • java.naming.language

  • java.naming.applet

For more details on what information to use in these attributes, check your JNDI provider's documentation and consult the Java API reference material.

Using a named reply destination

By default, CXF endpoints using JMS create a temporary queue for sending replies back and forth. You can change this behavior by setting the jndiReplyDestinationName attribute in the endpoint's contract. A client endpoint will listen for replies on the specified destination and it will specify the value of the attribute in the ReplyTo field of all outgoing requests. A service endpoint will use the value of the jndiReplyDestinationName attribute as the location for placing replies if there is no destination specified in the request's ReplyTo field.

A static reply queue can not be shared by several instances of the service client. Please use a dynamic reply queue or different queue names per instance instead.

The following example shows an example of a JMS WSDL port specification.

Example 33. JMS WSDL Port Specification

<service name="JMSService">
   <port binding="tns:Greeter_SOAPBinding" name="SoapPort">
      <jms:address jndiConnectionFactoryName="ConnectionFactory"
         jndiDestinationName="dynamicQueues/test.cxf.jmstransport">
         <jms:JMSNamingProperty name="java.naming.factory.initial"
            value="org.apache.activemq.jndi.ActiveMQInitialContextFactory"/>
         <jms:JMSNamingProperty name="java.naming.provider.url"
            value="tcp://localhost:61616" />
      </jms:address>
   </port>
</service>

Using Configuration

In addition to using the WSDL file to specify the connection information for a JMS endpoint, you can also supply it in the endpoint's XML configuration. The information in the configuration file will override the information in the endpoint's WSDL file.

Configuration elements

You configure a JMS endpoint using one of the following configuration elements:

  • jms:conduit : The jms:conduit element contains the configuration for a consumer endpoint. It has one attribute, name , whose value takes the form

    {WSDLNamespace}WSDLPortName.jms-conduit
  • jms:destination : The jms:destination element contains the configuration for a provider endpoint. It has one attribute, name , whose value takes the form

    {WSDLNamespace}WSDLPortName.jms-destination

    .

The address element

JMS connection information is specified by adding a jms:address child to the base configuration element. The jms:address element used in the configuration file is identical to the one used in the WSDL file. Its attributes are listed in the address element's attribute table . Like the jms:address element in the WSDL file, the jms:address configuration element also has a jms:JMSNamingProperties child element that is used to specify additional information used to connect to a JNDI provider.

Example 34. Addressing Information in a Configuration File

<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:ct="http://cxf.apache.org/configuration/types"
   xmlns:jms="http://cxf.apache.org/transports/jms"
   xsi:schemaLocation="
      http://www.springframework.org/schema/beans 
      http://www.springframework.org/schema/beans/spring-beans.xsd
      http://cxf.apache.org/jaxws 
      http://cxf.apache.org/schemas/jaxws.xsd
      http://cxf.apache.org/transports/jms 
      http://cxf.apache.org/schemas/configuration/jms.xsd">
   <jms:conduit 
      name="{http://cxf.apache.org/jms_endpt}HelloJMSPort.jms-conduit">
      <jms:address destinationStyle="queue"
         jndiConnectionFactoryName="myConnectionFactory"
         jndiDestinationName="myDestination"
         jndiReplyDestinationName="myReplyDestination"
         connectionUserName="testUser"
         connectionPassword="testPassword">
         <jms:JMSNamingProperty name="java.naming.factory.initial"
            value="org.apache.cxf.transport.jms.MyInitialContextFactory"/>
         <jms:JMSNamingProperty name="java.naming.provider.url"
            value="tcp://localhost:61616"/>
      </jms:address>
   </jms:conduit>
</beans>

Consumer Endpoint Configuration

JMS consumer endpoints specify the type of messages they use. JMS consumer endpoint can use either a JMS ObjectMessage or a JMS TextMessage . When using an ObjectMessage the consumer endpoint uses a byte[] as the method for storing data into and retrieving data from the JMS message body. When messages are sent, the message data, including any formating information, is packaged into a byte[] and placed into the JMS message body before it is placed on the wire. When messages are received, the consumer endpoint will attempt to unmarshall the data stored in the JMS body as if it were packed in a byte[] .

When using a TextMessage , the consumer endpoint uses a string as the method for storing and retrieving data from the JMS message body. When messages are sent, the message information, including any format-specific information, is converted into a string and placed into the JMS message body. When messages are received the consumer endpoint will attempt to unmashall the data stored in the JMS message body as if it were packed into a string.

When native JMS applications interact with CXF consumers, the JMS application is responsible for interpreting the message and the formatting information. For example, if the CXF contract specifies that the binding used for a JMS endpoint is SOAP, and the messages are packaged as TextMessage , the receiving JMS application will get a text message containing all of the SOAP envelope information.

Consumer endpoint can be configured by both XML configuration and via WSDL.

Using Configuration
Specifying the message type

You can specify the message type supported by the consumer endpoint using a jms:runtimePolicy element that has a single attribute:

  • messageType - Specifies how the message data will be packaged as a JMS message. text specifies that the data will be packaged as a TextMessage . binary specifies that the data will be packaged as an ObjectMessage .

The following example shows a configuration entry for configuring a JMS consumer endpoint.

Example 35. Configuration for a JMS Consumer Endpoint

<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:ct="http://cxf.apache.org/configuration/types"
   xmlns:jms="http://cxf.apache.org/transports/jms"
   xsi:schemaLocation="
      http://www.springframework.org/schema/beans 
      http://www.springframework.org/schema/beans/spring-beans.xsd"
      http://cxf.apache.org/jaxws 
      http://cxf.apache.org/schemas/jaxws.xsd
      http://cxf.apache.org/transports/jms 
      http://cxf.apache.org/schemas/configuration/jms.xsd">
...
   <jms:conduit 
      name="{http://cxf.apache.org/jms_endpt}HelloJMSPort.jms-conduit">
      <jms:address ... >
         ...
      </jms:address>
      <jms:runtimePolicy messageType="binary"/>
      ...
   </jms:conduit>
...
</beans>

The id on the jms:conduit is in the form of { WSDLNamespace}WSDLPortName.jms-conduit . This provides CXF with the information so that it can associate the configuration with your service's endpoint.

Using WSDL

The type of messages accepted by a JMS consumer endpoint is configured using the optional jms:client element. The jms:client element is a child of the WSDL port element and has one attribute:

  • messageType - Specifies how the message data will be packaged as a JMS message. text specifies that the data will be packaged as a TextMessage . binary specifies that the data will be packaged as an ObjectMessage.

Service Endpoint Configuration

JMS service endpoints have a number of behaviors that are configurable in the contract. These include:

  • how messages are correlated

  • the use of durable subscriptions

  • if the service uses local JMS transactions

  • the message selectors used by the endpoint

Service endpoints can be configure in one of two ways:

  • Configuration

  • WSDL

Using Configuration
Specifying configuration data

Using the jms:destination elements you can configure your service's endpoint. You can specify the service endpoint's behaviors using the jms:runtimePolicy element that has a the following attributes:

Attribute

Description

useMessageIDAsCorrelationID

Specifies whether the JMS broker will use the message ID to correlate messages. The default is false .

durableSubscriberName

Specifies the name used to register a durable subscription.

messageSelector

Specifies the string value of a message selector to use. For more information on the syntax used to specify message selectors, see the JMS 1.1 specification.

transactional

Specifies whether the local JMS broker will create transactions around message processing. The default is false .

The following example shows a CXF configuration entry for configuring a JMS service endpoint.

Example 36. Configuration for a JMS Service Endpoint

<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:ct="http://cxf.apache.org/configuration/types"
   xmlns:jms="http://cxf.apache.org/transports/jms"
   xsi:schemaLocation="
      http://www.springframework.org/schema/beans 
      http://www.springframework.org/schema/beans/spring-beans.xsd"
      http://cxf.apache.org/jaxws 
      http://cxf.apache.org/schemas/jaxws.xsd
      http://cxf.apache.org/transports/jms 
      http://cxf.apache.org/schemas/configuration/jms.xsd">
...
   <jms:destination 
      name="{http://cxf.apache.org/jms_endpt}HelloJMSPort.jms-destination">
      <jms:address ... >
         ...
      </jms:address>
         ...
      <jms:runtimePolicy messageSelector="cxf_message_selector"
         useMessageIDAsCorrelationID="true"
         transactional="true"
         durableSubscriberName="cxf_subscriber" />
      ...
   </jms:destination>
...
</beans>

Using WSDL

Service endpoint behaviors are configured using the optional jms:server element. The jms:server element is a child of the WSDL port element and has the following attributes:

Attribute

Description

useMessageIDAsCorrelationID

Specifies whether JMS will use the message ID to correlate messages. The default is false .

durableSubscriberName

Specifies the name used to register a durable subscription.

messageSelector

Specifies the string value of a message selector to use. For more information on the syntax used to specify message selectors, see the JMS 1.1 specification.

transactional

Specifies whether the local JMS broker will create transactions around message processing. The default is false . Currently, this is not supported by the runtime.

JMS Runtime Configuration

In addition to configuring the externally visible aspects of your JMS endpoint, you can also configure aspects of its internal runtime behavior. There are three types of runtime configuration:

  • Session pool configuration (common to both services and consumers)

  • Consumer specific configuration

  • Service specific configuration

Session Pool Configuration

You configure an endpoint's JMS session pool using the jms:sessionPoolConfig element. This property allows you to set a high and low water mark for the number of JMS sessions an endpoint will keep pooled. The endpoint is guaranteed to maintain a pool of sessions equal to the low water mark and to never pool more sessions than specified by the high water mark. The jms:sessionPool element's attributes, listed below, specify the high and low water marks for the endpoint's JMS session pool.

Attribute

Description

lowWaterMark

Specifies the minimum number of JMS sessions pooled by the endpoint. The default is 20.

highWaterMark

Specifies the maximum number of JMS sessions pooled by the endpoint. The default is 500.

The following example shows an example of configuring the session pool for a CXF JMS service endpoint.

Example 37. JMS Session Pool Configuration

<jms:destination 
name="{http://cxf.apache.org/jms_endpit}HelloJMSPort.jms-destination">
   ...
   <jms:sessionPool lowWaterMark="10" highWaterMark="5000" />
</jms:destination>

The jms:sessionPool element can also be used within a jms:conduit .

Consumer Specific Runtime Configuration

The JMS consumer configuration allows you to specify two runtime behaviors:

  • the number of milliseconds the consumer will wait for a response.

  • the number of milliseconds a request will exist before the JMS broker can remove it.

You use the jms:clientConfig element to set JMS consumer runtime behavior. This element's attributes, listed in the following table, specify the configuration values for consumer runtime behavior.

Attribute

Description

clientReceiveTimeout

Specifies the amount of time, in milliseconds, that the endpoint will wait for a response before it times out and issues an exception. The default value is 2000.

messageTimeToLive

Specifies the amount of time, in milliseconds, that a request can remain unrecieved before the JMS broker can delete it. The default value is 0 which specifies that the message can never be deleted.

The following example shows a configuration fragment that sets the consumer endpoint's request lifetime to 500 milliseconds and its timeout value to 500 milliseconds.

Example 38. JMS Consumer Endpoint Runtime Configuration

<jms:conduit 
name="{http://cxf.apache.org/jms_endpt}HelloJMSPort.jms-conduit">
   ...
   <jms:clientConfig clientReceiveTimeout="500"
      messageTimeToLive="500" />
</jms:conduit>

Service Specific Runtime Configuration

The JMS service configuration allows you to specify to runtime behaviors:

  • the amount of time a response message can remain unreceived before the JMS broker can delete it.

  • the client identifier used when creating and accessing durable subscriptions.

The jms:serverConfig element is used to specify the service runtime configuration. This element's attributes, listed below, specify the configuration values that control the service's runtime behavior.

Attribute

Description

messageTimeToLive

Specifies the amount of time, in milliseconds, that a response can remain unread before the JMS broker is allowed to delete it. The default is 0 which specifies that the message can live forever.

durableSubscriptionClientId

Specifies the client identifier the endpoint uses to create and access durable subscriptions.

The following example shows a configuration fragment that sets the service endpoint's response lifetime to 500 milliseconds and its durable subscription client identifier to jms-test-id .

Example 39. JMS Service Endpoint Runtime Configuration

<jms:destination 
   id="{http://cxf.apache.org/jms_endpt}HelloJMSPort.jms-destination">
   <jms:address ... >
      ...
   </jms:address>
   <jms:serverConfig messageTimeToLive="500"
      durableSubscriptionClientId="jms-test-id" />
</jms:destination>

SOAP over JMS 1.0 support

The [JMS Transport] offers an alternative messaging mechanism to SOAP over HTTP. SOAP over JMS offers more reliable and scalable messaging support than SOAP over HTTP. The SOAP over JMS specification is aimed at a set of standards for the transport of SOAP messages over JMS. Its main purpose is to ensure interoperability between the implementations of different Web services vendors. CXF supports and is compliant with this specification.

SOAP over JMS Namespace
JMS URI

JMS endpoints need to know the address information for establishing connections to the proper destination. SOAP over JMS implements the URI Scheme for Java Message Service 1.0 .

JMS URI Scheme

jms:<variant>:<destination name>?param1=value1&param2=value2

Variants

Prefix

Description

jndi

Destination name is a jndi queue name

jndi-topic

Destination name is a jndi topic name

queue

Destination is a queue name resolved using JMS

topic

Destination is a topic name resolved using JMS

Further parameters can be added as query parameters in the URI.

For example:

jms:jndi:SomeJndiNameForDestination?jndiInitialContextFactory=   //
   org.apache.activemq.jndi.ActiveMQInitialContextFactory&   //
   jndiURL=tcp://localhost:61616&priority=3&   //
   jms:queue:ExampleQueueName?timeToLive=1000
JMS parameters

Query Parameter

From Version

DefaultValue

Description

conduitIdSelectorPrefix

3.0.0

If set then this string will be the prefix for all correlation ids the conduit creates and also be used in the selector for listening to replies

deliveryMode

PERSISTENT

NON_PERSISTENT messages will kept only in memory

PERSISTENT messages will be saved to disk

durableSubscriptionClientId

3.0.1

Optional Client identifier for the connection. The purpose is to associate a connection with a state maintained on behalf of the client by a provider. The only such state identified by the JMS API is that required to support durable subscriptions.

durableSubscriptionName

3.0.0

jndiConnectionFactoryName

ConnectionFactory

Specifies the JNDI name bound to the JMS connection factory to use when connecting to the JMS destination.

jndiInitialContextFactory

Specifies the fully qualified Java class name of the "InitialContextFactory" implementation class to use.

jndiTransactionManagerName

3.0.0

Name of the JTA TransactionManager. Will be searched in spring, blueprint and jndi.

If a transaction manager is found then JTA transactions will be enabled. See details below.

jndiURL

Specifies the JNDI provider URL

jndi-*

Additional parameters for a JNDI provider

messageType

3.0.0

byte

JMS message type used by CXF (byte, text or binary)

password

3.0.0

Password for creating the connection. Using this in the URI is discouraged

priority

3.0.0

4

Priority for the messages. See your JMS provider documentation for details. Values range from 0 to 9 where 0 is lowest priority

replyToName

Specifies the JNDI name bound to the JMS destinations where replies are sent

receiveTimeout

3.0.0

60000

Timeout in milliseconds the client waits for a reply in case of request / repy exchanges

reconnectOnException

deprecated in 3.0.0

true

Should the transport reconnect in case of exceptions. From version 3.0.0 on the transport will always reconnect in case of exceptions

sessionTransacted

3.0.0

false

Set to true for resource local transactions. Do not set if you use JTA

timeToLive

0

Time (in ms) after which the message will be discarded by the jms provider

topicReplyToName

Reply to messages on a topic with this name. Depending on the variant this is either a jndi or jms name.

useConduitIdSelector

3.0.0

true

Each conduit is assigned with a UUID. If set to true this conduit id will be the prefix for all correlation ids. This allows several endpoints to share a JMS queue or topic

username

3.0.0

Username for creating the connection

Some of these attributes are specified in the JMS URI specification.

WSDL Extension

The WSDL extensions for defining a JMS endpoint use a special namespace. In order to use the JMS WSDL extensions you will need to add the namespace definition shown below to the definitions element of your contract.

Various JMS properties may be set in three places in the WSDL — the binding, the service, and the port. Values specified at the service will propagate to all ports. Values specified at the binding will propagate to all ports using that binding. For example, if the jndiInitialContextFactory is indicated for a service, it will be used for all of the port elements it contains.

JMS Properties. For details refer to the URI query parameters with the same name:

Name

deliveryMode

jndiConnectionFactoryName

jndiInitialContextFactory

jndiURL

replyToName

priority

timeToLive

jndiContextParameter

Here is an example:

Example 40. Ways to define a Service with JMS transport

<wsdl11:binding name="exampleBinding">
    <soapjms:jndiContextParameter name="name" value="value"/>
    <soapjms:jndiConnectionFactoryName>
       ConnectionFactory
    </soapjms:jndiConnectionFactoryName>
    <soapjms:jndiInitialContextFactory>
    org.apache.activemq.jndi.ActiveMQInitialContextFactory
    </soapjms:jndiInitialContextFactory>
    <soapjms:jndiURL>tcp://localhost:61616</soapjms:jndiURL>
    <soapjms:deliveryMode>PERSISTENT</soapjms:deliveryMode>
    <soapjms:priority>5</soapjms:priority>
    <soapjms:timeToLive>200</soapjms:timeToLive>
</wsdl11:binding>

<wsdl11:service name="exampleService">
    <soapjms:jndiInitialContextFactory>
       com.example.jndi.InitialContextFactory
    </soapjms:jndiInitialContextFactory>
    <soapjms:timeTolive>100</soapjms:timeToLive>
    <wsdl11:port name="quickPort" binding="tns:exampleBinding">
      <soapjms:timeToLive>10</soapjms:timeToLive>
    </wsdl11:port>
    <wsdl11:port name="slowPort" binding="tns:exampleBinding">
      ...
    </wsdl11:port>
</wsdl11:service>

If a property is specified at multiple levels, the setting at the most granular level takes precedence (port first, then service, then binding). In the above example, notice the timeToLive property — for the quickPort port, the value will be 10ms (specified at the port level). For the slowPort port, the value will be 100ms (specified at the service level). In this example, the setting in the binding will always be overridden.

WSDL Usage

For this example:

Example 41. Greeter Service with JMS transaport

<wsdl:definitions name="JMSGreeterService"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
  xmlns:tns="http://cxf.apache.org/jms_greeter" 
  xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
  xmlns:x1="http://cxf.apache.org/jms_greeter/types" 
  xmlns:soapjms="http://www.w3.org/2010/soapjms/" 
  name="JMSGreeterService"
  targetNamespace="http://cxf.apache.org/jms_greeter">
    ...
   <wsdl:binding name="JMSGreeterPortBinding" 
      type="tns:JMSGreeterPortType">
      <soap:binding style="document"
         transport="http://www.w3.org/2010/soapjms/" />
      <soapjms:jndiContextParameter name="name"
         value="value" />
      <soapjms:jndiConnectionFactoryName>
         ConnectionFactory
      </soapjms:jndiConnectionFactoryName>
      <soapjms:jndiInitialContextFactory>
         org.apache.activemq.jndi.ActiveMQInitialContextFactory
      </soapjms:jndiInitialContextFactory>
      <soapjms:jndiURL>tcp://localhost:61616</soapjms:jndiURL>
      <soapjms:deliveryMode>PERSISTENT</soapjms:deliveryMode>
      <soapjms:priority>5</soapjms:priority>
      <soapjms:timeToLive>1000</soapjms:timeToLive>
      <wsdl:operation name="greetMe">
         <soap:operation soapAction="test" style="document" />
         <wsdl:input name="greetMeRequest">
            <soap:body use="literal" />
         </wsdl:input>
         <wsdl:output name="greetMeResponse">
            <soap:body use="literal" />
         </wsdl:output>
      </wsdl:operation>
   </wsdl:binding>
   <wsdl:service name="JMSGreeterService">
      <soapjms:jndiConnectionFactoryName>
         ConnectionFactory
      </soapjms:jndiConnectionFactoryName>
      <soapjms:jndiInitialContextFactory>
         org.apache.activemq.jndi.ActiveMQInitialContextFactory
      </soapjms:jndiInitialContextFactory>
      <wsdl:port binding="tns:JMSGreeterPortBinding" name="GreeterPort">
         <soap:address location=
            "jms:jndi:dynamicQueues/test.cxf.jmstransport.queue"/>
      </wsdl:port>
   </wsdl:service>
</wsdl:definitions>

  • The transport URI (http://www.w3.org/2010/soapjms/) is defined in the <soap:binding>.

  • The jms: URI is defined in the <soap:address>

  • The extension properties are in the <soap:binding>

Define service endpoint or proxy in spring or blueprint

The JAXWS endpoint or proxy can be defined like in the SOAP/HTTP case. Just use a jms: uri like described above.

In CXF 3 it is possible to omit the jndi settings. Just specify an endpoint like this:

Example 42. Endpoint in spring

<bean id="ConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
    <property name="brokerURL" value="tcp://localhost:61616"/>
</bean>
<jaxws:endpoint id="CustomerService"
    address="jms:queue:test.cxf.jmstransport.queue?timeToLive=1000"
    implementor="com.example.customerservice.impl.CustomerServiceImpl"/>
</jaxws:endpoint>

or a Client like this:

Example 43. Proxy in spring

<bean id="ConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
    <property name="brokerURL" value="tcp://localhost:61616"/>
</bean>
<jaxws:client id="CustomerService"
    address="jms:queue:test.cxf.jmstransport.queue?timeToLive=1000"
    serviceClass="com.example.customerservice.CustomerService">
</jaxws:client>

The connection factory will be looked up as a bean in the context. By default the name "ConnectionFactory" is assumed but it can be configured using the jndiConnectionFactoryName uri parameter.

Alternatively the connection factory can be set using the ConnectionFactoryFeature.

Publishing a service with the JAVA API

Developers who don't wish to modify the WSDL file can also publish the endpoint information using Java code. For CXF's SOAP over JMS implementation you can write the following:

// You just need to set the address with JMS URI
String address = "jms:jndi:dynamicQueues/test.cxf.jmstransport.queue3"
   + "?jndiInitialContextFactory"
   + "=org.apache.activemq.jndi.ActiveMQInitialContextFactory"
   + "&jndiConnectionFactoryName=ConnectionFactory&jndiURL" 
   + "=tcp://localhost:61500";
Hello implementor = new HelloImpl();
JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean();
svrFactory.setServiceClass(Hello.class);
svrFactory.setAddress(address);
// And specify the transport ID with SOAP over JMS specification
svrFactory.setTransportId(
   JMSSpecConstants.SOAP_JMS_SPECIFICIATION_TRANSPORTID);
svrFactory.setServiceBean(implementor);
svrFactory.create();

NOTE: For tests it can be useful to create an embedded broker like this:

public final void run() {
    try {            
         broker = new BrokerService();
         broker.setPersistent(false);
         broker.setPersistenceAdapter(new MemoryPersistenceAdapter());
         broker.setTmpDataDirectory(new File("./target"));
         broker.setUseJmx(false);
         if (brokerName != null) {
             broker.setBrokerName(brokerName);
         }        broker.addConnector(brokerUrl1);
         broker.start();
    } catch (Exception e) {
         e.printStackTrace();
    }
}
Consume the service with the API

Sample code to consume a SOAP-over-JMS service is as follows:

public void invoke() throws Exception {
   // You just need to set the address with JMS URI
   String address = 
      "jms:jndi:dynamicQueues/test.cxf.jmstransport.queue3"
      + "?jndiInitialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory"
      + "&jndiConnectionFactoryName=ConnectionFactory"
      + "&jndiURL=tcp://localhost:61500";
   JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
   // And specify the transport ID with SOAP over JMS specification
   factory.setTransportId(
      JMSSpecConstants.SOAP_JMS_SPECIFICIATION_TRANSPORTID);
   factory.setServiceClass(Hello.class);
   factory.setAddress(address);
   Hello client = (Hello)factory.create();
   String reply = client.sayHi(" HI");
   System.out.println(reply);
}

// Alternatively using the JAXWS API with jms details defined in WSDL while avoiding JNDI
SOAPService2 service = new SOAPService2(wsdl, serviceName); // Using the generated service
ConnectionFactory cf = new ActiveMQConnectionFactory("tcp://localhost:61500");
ConnectionFactoryFeature cff = new ConnectionFactoryFeature(cf);
Greeter greeter = service.getPort(portName, Greeter.class, cff); 
// Connection Factory can be set as a feature in CXF >= 3.0.0

If you specify queue or topic as variant and use cxf >= 3.0.0 then the jndi settings are not necessary.

svrFactory.setAddress("jms:queue:test.cxf.jmstransport.queue?timeToLive=1000");
// For CXF >= 3.0.0
svrFactory.setFeatures(Collections.singletonList(new ConnectionFactoryFeature(cf)));

In this case case the connection factory is supplied using a feature. For CXF 2.x the connection factory can only be supplied using jndi.

Using the JMSConfigFeature

Standard JMS transport configuration in CXF is done by defining a JMSConduit or JMSDestination. There is however an easier configuration option more conformant to Spring dependency injection. Additionally the new configuration offers many more options. For example it is not necessary anymore to use JNDI to resolve the connection factory. Instead it can be defined in the Spring configuration.

The following example configs use the p-namespace from Spring 2.5 but the old Spring bean style is also possible.

Inside a features element the JMSConfigFeature can be defined.

<jaxws:client id="CustomerService"
   xmlns:customer="http://customerservice.example.com/"
   serviceName="customer:CustomerServiceService"
   endpointName="customer:CustomerServiceEndpoint" address="jms://"
   serviceClass="com.example.customerservice.CustomerService">
   <jaxws:features>
      <bean xmlns="http://www.springframework.org/schema/beans"
         class="org.apache.cxf.transport.jms.JMSConfigFeature"
         p:jmsConfig-ref="jmsConfig"/>
   </jaxws:features>
</jaxws:client>

In the above example it references a bean "jmsConfig" where the whole configuration for the JMS transport can be done.

A jaxws Endpoint can be defined in the same way:

<jaxws:endpoint 
   xmlns:customer="http://customerservice.example.com/"
   id="CustomerService" 
   address="jms://"
   serviceName="customer:CustomerServiceService"
   endpointName="customer:CustomerServiceEndpoint"
   implementor="com.example.customerservice.impl.CustomerServiceImpl">
   <jaxws:features>
      <bean class="org.apache.cxf.transport.jms.JMSConfigFeature"
         p:jmsConfig-ref="jmsConfig" />
   </jaxws:features>
</jaxws:endpoint>

The JMSConfiguration bean needs at least a reference to a connection factory and a target destination.

<bean id="jmsConfig" class="org.apache.cxf.transport.jms.JMSConfiguration"
   p:connectionFactory-ref="jmsConnectionFactory"
   p:targetDestination="test.cxf.jmstransport.queue"
/>

If your ConnectionFactory does not cache connections you should wrap it in a Spring SingleConnectionFactory. This is necessary because the JMS Transport creates a new connection for each message and the SingleConnectionFactory is needed to cache this connection.

<bean id="jmsConnectionFactory" 
   class="org.springframework.jms.connection.SingleConnectionFactory">
   <property name="targetConnectionFactory">
      <bean class="org.apache.activemq.ActiveMQConnectionFactory">
         <property name="brokerURL" value="tcp://localhost:61616"/>
      </bean>
   </property>
</bean>
Using JMSConfiguration from Java

To do this from Java, you need to initialize a JMSConfiguration object, then store a reference to it in a JMSConfigFeature, and then add that to the features in the server factory. The code that follows is fragmentary. Note that you can't use query parameters in the endpoint URI that you set in the server factory, all the configuration has to be in the JMSConfiguration object.

public static JMSConfiguration newJMSConfiguration(String taskId, String jmsBrokerUrl) {
        String destinationUri = "jms:queue:" + taskId;
        JMSConfiguration conf = new JMSConfiguration();
        conf.setRequestURI(destinationUri);
        JNDIConfiguration jndiConfig = new JNDIConfiguration();
        JndiTemplate jt = new JndiTemplate();
        Properties env = new Properties();
        env.put(Context.PROVIDER_URL, jmsBrokerUrl); 
        env.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.activemq.jndi.ActiveMQInitialContextFactory");
        jt.setEnvironment(env);
        jndiConfig.setJndiConnectionFactoryName("ConnectionFactory");
        jndiConfig.setEnvironment(env);
        conf.setJndiTemplate(jt);
        conf.setTargetDestination("com.basistech.jug." + taskId);
        conf.setJndiConfig(jndiConfig);
        conf.setTimeToLive(0);
        return conf;
}
{
        JMSConfigFeature jmsConfigFeature = new JMSConfigFeature();
        JMSConfiguration jmsConfig = JmsUtils.newJMSConfiguration(taskId, jmsBrokerUrl);
        jmsConfig.setConcurrentConsumers(maxServiceThreads);
        jmsConfig.setMaxConcurrentConsumers(maxServiceThreads);
        jmsConfigFeature.setJmsConfig(jmsConfig);
        svrFactory.getFeatures().add(jmsConfigFeature);
        svrFactory.getFeatures().add(jmsConfigFeature);
 
        server = svrFactory.create();
}
JMSConfiguration options

Name

Description

connectionFactory

Mandatory field. Reference to a bean that defines a jms ConnectionFactory. Remember to wrap the connectionFactory like described above when not using a pooling ConnectionFactory

wrapInSingleConnectionFactory

This option was removed since CXF 3.0.0. Will wrap the connectionFactory with a Spring SingleConnectionFactory, which can improve the performance of the jms transport. Default is true.

reconnectOnException

(deprecated) If wrapping the connectionFactory with a Spring SingleConnectionFactory and reconnectOnException is true, will create a new connection if there is an exception thrown, otherwise will not try to reconnect if the there is an exception thrown. Default is false. From CXF 3.0.0, CXF always reconnect on exceptions

targetDestination

JNDI name or provider specific name of a destination. Example for ActiveMQ: test.cxf.jmstransport.queue

destinationResolver

Reference to a Spring DestinationResolver. This allows to define how destination names are resolved to jms Destinations. By default a DynamicDestinationResolver is used. It resolves destinations using the jms providers features. If you reference a JndiDestinationResolver you can resolve the destination names using JNDI.

transactionManager

Reference to a Spring transaction manager. This allows to take part in JTA Transactions with your webservice. You can also register a spring JMS Transaction Manager to have local transactions.

taskExecutor

This option was removed since CXF 3.0.0. Reference to a Spring TaskExecutor. This is used in listeners to decide how to handle incoming messages. Default is a Spring SimpleAsyncTaskExecutor.

useJms11

This option was removed since CXF 3.0.0. true means JMS 1.1 features are used false means only JMS 1.0.2 features are used. Default is false.

messageIdEnabled

Default is true. This option was removed since CXF 3.0.0.

messageTimestampEnabled

Default is true. This option was removed since CXF 3.0.0.

cacheLevel

This option was removed since CXF 3.0.0. Specify the level of caching that the JMS listener container is allowed to apply. (Default is -1) Please check out the java doc of the org.springframework. jms.listener. DefaultMessageListenerContainer for more information

pubSubNoLocal

If true do not receive your own messages when using topics. Default is false.

receiveTimeout

How many milliseconds to wait for response messages. 0 (default) means wait indefinitely. since CXF 3.0, the default value is changed to 60000 (60 seconds)

explicitQosEnabled

If true, means that QoS parameters are set for each message. (Default is false.)

deliveryMode

NON_PERSISTENT = 1 messages will only be kept in memory

PERSISTENT = 2 (default) messages will be persisted to disk

priority

Priority for the messages. Default is 4. See your JMS provider doc for details.

timeToLive

After this time the message will be discarded by the jms provider. Default is 0.

sessionTransacted

If true, means JMS transactions are used. Default is false. In 2.7.x you will also need to register a JMS Transaction Manager with JMSConfiguration in order for transactions to be enabled.

concurrentConsumers

This option was removed since CXF 3.0.0. Minimum number of concurrent consumers for listener (default is 1).

maxConcurrentConsumers

This option was removed since CXF 3.0.0. Maximum number of concurrent consumers for listener (default 1).

maxConcurrentTasks

This option was removed since CXF 3.0.0. (deprecated) Maximum number of threads that handle the received requests. Default 10.

messageSelector

jms selector to filter incoming messages (allows to share a queue)

subscriptionDurable

Default is false.

durableSubscriptionName

 

messageType

text (default) binary byte

pubSubDomain

false (default) means use queues true means use topics

jmsProviderTibcoEms

True means that the jms provider is Tibco EMS. Default is false. Currently this activates that the principal in the SecurityContext is populated from the header JMS_TIBCO_SENDER. (available from cxf version 2.2.6)

maxSuspendedContinuations

Since CXF 3.0.0, The max suspended continuations that the JMS destination could have, if the current suspended continuations number exceeds the max value, the JMSListenerContainer will be stopped. The default value is -1, which means disable this feature.

reconnectPercentOfMax

Since CXF 3.0.0, If the JMSListenerContainer is stopped due to the current suspended continuation exceeds the max value, the JMSListenerContainer will be restarted when the current suspended continuation below the value of (maxSuspendedContinuations*reconnectPercentOfMax/100). The default value is 70.

createSecurityContext

(Since 2.7.14, 3.0.3) true (default) means create user security context for incoming messages.

propogateExceptions

(Since 2.7.15) 2.7.x only true (default) means that any exceptions occurring while processing the incoming message will be propagated. This setting is only relevant when a transaction manager and sessionTransacted are set.

UDP Transport

CXF provides a transport plugin to support transporting small (under about 60K) message payloads over UDP. It supports both unicast and multicast packet transfers. To use the UDP transport, you just need to include the cxf-rt-transports-udp module on the classpath and use a "udp://host:port" style URL for the address:

JaxWsServerFactoryBean factory = new JaxWsServerFactoryBean();
factory.setBus(getStaticBus());
factory.setAddress("udp://localhost:8888");
factory.setServiceBean(new GreeterImpl());
server = factory.create();

That will start the server on localhost UDP port 8888. You can also omit the hostname (udp://:8888) to bind to all the addresses or use one of the multicast addresses (example: udp://239.255.255.250:3702) to respond to the appropriate broadcasts.

For client configuration, similar to the server side, you just need to use the appropriate UDP url in order for the client to use UDP. If the hostname is specified in the URL, the Datagram will be sent directly to the host:port. If the hostname is not specified, the Datagram will be sent as a broadcast to the specific port. If the hostname is a multicast address, the Datagram will be sent Multicast to the given port.

UDP is different than the other CXF transports in that it allows multiple responses to be received for a single request. For example, if you send out a request via a multicast or broadcast, several servers could respond to that request. The basic JAX-WS generated interfaces only allow a single response to be returned to the application. However, if you use the JAX-WS Asynchronous methods, you can have CXF call the AsyncHandler for each response. To enable this, set the request property "udp.multi.response.timeout" to a timeout value greater than 0. CXF will wait that long for responses to come in before returning back to the application.

// wait 3 seconds for responses
((BindingProvider)proxy).getRequestContext().put(
   "udp.multi.response.timeout", 3000);
proxy.greetMeAsync("World", new AsyncHandler<String>() {
   public void handleResponse(Response<Object> res) {
      System.out.println(res.get());
   }
});

The CXF SOAP binding supports the use of the SOAP over UDP specification URL's for transporting SOAP messages over UDP. Just using "soap.udp" as the scheme part of the UDP URL (instead of just "udp") will enable the SOAP over UDP support. The main difference between using the pure UDP CXF transport and the SOAP over UDP support is that SOAP over UDP requires the use of WS-Addressing headers whereas the pure CXF UDP transport does not. The WS-Addressing header can add significant size to the SOAP messages. With UDP limiting the size of the packets to under 64K, that can be significant.