LibraryPrintFeedback

Configuring Web Service Endpoints

Version 7.1

December 2012
Trademark Disclaimer
Third Party Acknowledgements

Updated: 08 Jan 2014

Revision History

Table of Contents

1. Configuring JAX-WS Endpoints
Configuring Service Providers
Using the jaxws:endpoint Element
Using the jaxws:server Element
Adding Functionality to Service Providers
Configuring Consumer Endpoints
2. Configuring the HTTP Transport
Configuring a Consumer
Using Configuration
Using WSDL
Consumer Cache Control Directives
Configuring a Service Provider
Using Configuration
Using WSDL
Service Provider Cache Control Directives
Using the HTTP Transport in Decoupled Mode
3. Using SOAP Over JMS
Basic configuration
JMS URIs
WSDL extensions
4. Using Generic JMS
Using the JMS configuration bean
Using WSDL to configure JMS
Basic JMS configuration
JMS client configuration
JMS provider configuration
Using a Named Reply Destination
5. Fuse Services Framework Logging
Overview of Fuse Services Framework Logging
Simple Example of Using Logging
Default logging configuration file
Configuring Logging Output
Configuring Logging Levels
Enabling Logging at the Command Line
Logging for Subsystems and Services
Logging Message Content
6. Deploying WS-Addressing
Introduction to WS-Addressing
WS-Addressing Interceptors
Enabling WS-Addressing
Configuring WS-Addressing Attributes
7. Enabling Reliable Messaging
Introduction to WS-RM
WS-RM Interceptors
Enabling WS-RM
Configuring WS-RM
Configuring Fuse Services Framework-Specific WS-RM Attributes
Configuring Standard WS-RM Policy Attributes
WS-RM Configuration Use Cases
Configuring WS-RM Persistence
8. Enabling High Availability
Introduction to High Availability
Enabling HA with Static Failover
Configuring HA with Static Failover
9. Enabling High Availability in Fuse Fabric
Load Balancing Cluster
Introduction to Load Balancing
Configure the Server
Configure the Client
Failover Cluster
10. Packaging an Application
11. Deploying an Application
A. Fuse Services Framework Binding IDs
B. Using the Maven OSGi Tooling
Setting up a Fuse ESB Enterprise OSGi project
Configuring the Bundle Plug-In
C. Conduits
Index

List of Figures

2.1. Message Flow in for a Decoupled HTTP Transport
7.1. Web Services Reliable Messaging
9.1. Fabric Load Balancing for Apache CXF
9.2. Fabric Failover for Apache CXF

List of Tables

1.1. Attributes for Configuring a JAX-WS Service Provider Using the jaxws:endpoint Element
1.2. Attributes for Configuring a JAX-WS Service Provider Using the jaxws:server Element
1.3. Elements Used to Configure JAX-WS Service Providers
1.4. Attributes Used to Configure a JAX-WS Consumer
1.5. Elements For Configuring a Consumer Endpoint
2.1. Elements Used to Configure an HTTP Consumer Endpoint
2.2. HTTP Consumer Configuration Attributes
2.3. http-conf:client Cache Control Directives
2.4. Elements Used to Configure an HTTP Service Provider Endpoint
2.5. HTTP Service Provider Configuration Attributes
2.6. http-conf:server Cache Control Directives
3.1. JMS URI variants
3.2. JMS properties settable as URI options
3.3. JNDI properties settable as URI options
3.4. SOAP/JMS WSDL extension elements
4.1. General JMS Configuration Properties
4.2. JMS endpoint attributes
4.3. JMS Client WSDL Extensions
4.4. JMS provider endpoint WSDL extensions
5.1. Java.util.logging Handler Classes
5.2. Fuse Services Framework Logging Subsystems
6.1. WS-Addressing Interceptors
6.2. WS-Addressing Attributes
7.1. Fuse Services Framework WS-ReliableMessaging Interceptors
7.2. Children of the rmManager Spring Bean
7.3. Children of the WS-Policy RMAssertion Element
7.4. JDBC Store Properties
A.1. Binding IDs for Message Bindings

List of Examples

1.1. Simple JAX-WS Endpoint Configuration
1.2. JAX-WS Endpoint Configuration with a Service Name
1.3. Simple JAX-WS Server Configuration
1.4. Simple Consumer Configuration
2.1. HTTP Consumer Configuration Namespace
2.2. http-conf:conduit Element
2.3. HTTP Consumer Endpoint Configuration
2.4. HTTP Consumer WSDL Element's Namespace
2.5. WSDL to Configure an HTTP Consumer Endpoint
2.6. HTTP Provider Configuration Namespace
2.7. http-conf:destination Element
2.8. HTTP Service Provider Endpoint Configuration
2.9. HTTP Provider WSDL Element's Namespace
2.10. WSDL to Configure an HTTP Service Provider Endpoint
2.11. Activating WS-Addressing using WSDL
2.12. Activating WS-Addressing using a Policy
2.13. Configuring a Consumer to Use a Decoupled HTTP Endpoint
3.1. SOAP over JMS binding specification
3.2. JMS URI syntax
3.3. SOAP/JMS endpoint address
3.4. Syntax for JMS URI options
3.5. Setting a JNDI property in a JMS URI
3.6. JMS URI that configures a JNDI connection
3.7. WSDL contract with SOAP/JMS configuration
4.1. Declaring the Spring p-namespace
4.2. JMS configuration bean
4.3. Adding JMS configuration to a JAX-WS client
4.4. Adding JMS configuration to a JMS conduit
4.5. JMS WSDL extension namespace
4.6. JMS WSDL port specification
4.7. WSDL for a JMS consumer endpoint
4.8. WSDL for a JMS provider endpoint
4.9. JMS Consumer Specification Using a Named Reply Queue
5.1. Configuration for Enabling Logging
5.2. Configuring the Console Handler
5.3. Console Handler Properties
5.4. Configuring the File Handler
5.5. File Handler Configuration Properties
5.6. Configuring Both Console Logging and File Logging
5.7. Configuring Global Logging Levels
5.8. Configuring Logging at the Package Level
5.9. Flag to Start Logging on the Command Line
5.10. Configuring Logging for WS-Addressing
5.11. Adding Logging to Endpoint Configuration
5.12. Adding Logging to Client Configuration
5.13. Setting the Logging Level to INFO
5.14. Endpoint Configuration for Logging SOAP Messages
6.1. client.xml—Adding WS-Addressing Feature to Client Configuration
6.2. server.xml—Adding WS-Addressing Feature to Server Configuration
6.3. Using the Policies to Configure WS-Addressing
7.1. Enabling WS-RM Using Spring Beans
7.2. Configuring WS-RM using WS-Policy
7.3. Adding an RM Policy to Your WSDL File
7.4. Configuring Fuse Services Framework-Specific WS-RM Attributes
7.5. Configuring WS-RM Attributes Using an RMAssertion in an rmManager Spring Bean
7.6. Configuring WS-RM Attributes as a Policy within a Feature
7.7. Configuring WS-RM in an External Attachment
7.8. Setting the WS-RM Base Retransmission Interval
7.9. Setting the WS-RM Exponential Backoff Property
7.10. Setting the WS-RM Acknowledgement Interval
7.11. Setting the WS-RM Maximum Unacknowledged Message Threshold
7.12. Setting the Maximum Length of a WS-RM Message Sequence
7.13. Setting the WS-RM Message Delivery Assurance Policy
7.14. Configuration for the Default WS-RM Persistence Store
7.15. Configuring the JDBC Store for WS-RM Persistence
8.1. Enabling HA with Static Failover—WSDL File
8.2. Enabling HA with Static Failover—Client Configuration
8.3. Configuring a Random Strategy for Static Failover
9.1. WS Server with Fabric Load Balancer Feature
9.2. Client Proxy with Fabric Load Balancer Feature
10.1. Apache CXF Application Manifest
B.1. Adding an OSGi bundle plug-in to a POM
B.2. Setting a bundle's symbolic name
B.3. Setting a bundle's name
B.4. Setting a bundle's version
B.5. Including a private package in a bundle
B.6. Specifying the packages imported by a bundle

The information used to define an endpoint is typically defined in the endpoint's contract. You can use the configuration element's to override the information in the contract. You can also use the configuration elements to provide information that is not provided in the contract.

[Note]Note

When dealing with endpoints developed using a Java-first approach it is likely that the SEI serving as the endpoint's contract is lacking information about the type of binding and transport to use.

You must use the configuration elements to activate advanced features such as WS-RM. This is done by providing child elements to the endpoint's configuration element.

Fuse Services Framework has two elements that can be used to configure a service provider:

The differences between the two elements are largely internal to the runtime. The jaxws:endpoint element injects properties into the org.apache.cxf.jaxws.EndpointImpl object created to support a service endpoint. The jaxws:server element injects properties into the org.apache.cxf.jaxws.support.JaxWsServerFactoryBean object created to support the endpoint. The EndpointImpl object passes the configuration data to the JaxWsServerFactoryBean object. The JaxWsServerFactoryBean object is used to create the actual service object. Because either configuration element will configure a service endpoint, you can choose based on the syntax you prefer.

The attributes of the jaxws:endpoint element configure the basic properties of the endpoint. These properties include the address of the endpoint, the class that implements the endpoint, and the bus that hosts the endpoint.

Table 1.1 describes the attribute of the jaxws:endpoint element.

Table 1.1. Attributes for Configuring a JAX-WS Service Provider Using the jaxws:endpoint Element

AttributeDescription
id Specifies a unique identifier that other configuration elements can use to refer to the endpoint.
implementor Specifies the class implementing the service. You can specify the implementation class using either the class name or an ID reference to a Spring bean configuring the implementation class. This class must be on the classpath.
implementorClass Specifies the class implementing the service. This attribute is useful when the value provided to the implementor attribute is a reference to a bean that is wrapped using Spring AOP.
address Specifies the address of an HTTP endpoint. This value overrides the value specified in the services contract.
wsdlLocation Specifies the location of the endpoint's WSDL contract. The WSDL contract's location is relative to the folder from which the service is deployed.
endpointName Specifies the value of the service's wsdl:port element's name attribute. It is specified as a QName using the format ns:name where ns is the namespace of the wsdl:port element.
serviceName Specifies the value of the service's wsdl:service element's name attribute. It is specified as a QName using the format ns:name where ns is the namespace of the wsdl:service element.
publish Specifies if the service should be automatically published. If this is set to false, the developer must explicitly publish the endpoint.
bus Specifies the ID of the Spring bean configuring the bus used to manage the service endpoint. This is useful when configuring several endpoints to use a common set of features.
bindingUri Specifies the ID of the message binding the service uses. A list of valid binding IDs is provided in Appendix A.
name Specifies the stringified QName of the service's wsdl:port element. It is specified as a QName using the format {ns}localPart. ns is the namespace of the wsdl:port element and localPart is the value of the wsdl:port element's name attribute.
abstract Specifies if the bean is an abstract bean. Abstract beans act as parents for concrete bean definitions and are not instantiated. The default is false. Setting this to true instructs the bean factory not to instantiate the bean.
depends-on Specifies a list of beans that the endpoint depends on being instantiated before it can be instantiated.
createdFromAPI

Specifies that the user created that bean using Fuse Services Framework APIs, such as Endpoint.publish() or Service.getPort().

The default is false.

Setting this to true does the following:

  • Changes the internal name of the bean by appending .jaxws-endpoint to its id

  • Makes the bean abstract

publishedEndpointUrl The URL that is placed in the address element of the generated WSDL. If this value is not specified, the value of the address attribute is used. This attribute is useful when the "public" URL is not be the same as the URL on which the service is deployed.

In addition to the attributes listed in Table 1.1, you might need to use multiple xmlns:shortName attributes to declare the namespaces used by the endpointName and serviceName attributes.

The attributes of the jaxws:server element configure the basic properties of the endpoint. These properties include the address of the endpoint, the class that implements the endpoint, and the bus that hosts the endpoint.

Table 1.2 describes the attribute of the jaxws:server element.

Table 1.2. Attributes for Configuring a JAX-WS Service Provider Using the jaxws:server Element

AttributeDescription
id Specifies a unique identifier that other configuration elements can use to refer to the endpoint.
serviceBean Specifies the class implementing the service. You can specify the implementation class using either the class name or an ID reference to a Spring bean configuring the implementation class. This class must be on the classpath.
serviceClass Specifies the class implementing the service. This attribute is useful when the value provided to the implementor attribute is a reference to a bean that is wrapped using Spring AOP.
address Specifies the address of an HTTP endpoint. This value will override the value specified in the services contract.
wsdlLocation Specifies the location of the endpoint's WSDL contract. The WSDL contract's location is relative to the folder from which the service is deployed.
endpointName Specifies the value of the service's wsdl:port element's name attribute. It is specified as a QName using the format ns:name, where ns is the namespace of the wsdl:port element.
serviceName Specifies the value of the service's wsdl:service element's name attribute. It is specified as a QName using the format ns:name, where ns is the namespace of the wsdl:service element.
start Specifies if the service should be automatically published. If this is set to false, the developer must explicitly publish the endpoint.
bus Specifies the ID of the Spring bean configuring the bus used to manage the service endpoint. This is useful when configuring several endpoints to use a common set of features.
bindingId Specifies the ID of the message binding the service uses. A list of valid binding IDs is provided in Appendix A.
name Specifies the stringified QName of the service's wsdl:port element. It is specified as a QName using the format {ns}localPart, where ns is the namespace of the wsdl:port element and localPart is the value of the wsdl:port element's name attribute.
abstract Specifies if the bean is an abstract bean. Abstract beans act as parents for concrete bean definitions and are not instantiated. The default is false. Setting this to true instructs the bean factory not to instantiate the bean.
depends-on Specifies a list of beans that the endpoint depends on being instantiated before the endpoint can be instantiated.
createdFromAPI

Specifies that the user created that bean using Fuse Services Framework APIs, such as Endpoint.publish() or Service.getPort().

The default is false.

Setting this to true does the following:

  • Changes the internal name of the bean by appending .jaxws-endpoint to its id

  • Makes the bean abstract


In addition to the attributes listed in Table 1.2, you might need to use multiple xmlns:shortName attributes to declare the namespaces used by the endpointName and serviceName attributes.

Table 1.3 describes the child elements that jaxws:endpoint supports.

Table 1.3. Elements Used to Configure JAX-WS Service Providers

ElementDescription
jaxws:handlers Specifies a list of JAX-WS Handler implementations for processing messages.
jaxws:inInterceptors Specifies a list of interceptors that process inbound requests. For more information see .
jaxws:inFaultInterceptors Specifies a list of interceptors that process inbound fault messages. For more information see .
jaxws:outInterceptors Specifies a list of interceptors that process outbound replies. For more information see .
jaxws:outFaultInterceptors Specifies a list of interceptors that process outbound fault messages. For more information see .
jaxws:binding Specifies a bean configuring the message binding used by the endpoint. Message bindings are configured using implementations of the org.apache.cxf.binding.BindingFactory interface.[a]
jaxws:dataBinding [b] Specifies the class implementing the data binding used by the endpoint. This is specified using an embedded bean definition.
jaxws:executor Specifies a Java executor that is used for the service. This is specified using an embedded bean definition.
jaxws:features Specifies a list of beans that configure advanced features of Fuse Services Framework. You can provide either a list of bean references or a list of embedded beans.
jaxws:invoker Specifies an implementation of the org.apache.cxf.service.Invoker interface used by the service. [c]
jaxws:properties Specifies a Spring map of properties that are passed along to the endpoint. These properties can be used to control features like enabling MTOM support.
jaxws:serviceFactory Specifies a bean configuring the JaxWsServiceFactoryBean object used to instantiate the service.

[a] The SOAP binding is configured using the soap:soapBinding bean.

[b] The jaxws:endpoint element does not support the jaxws:dataBinding element.

[c] The Invoker implementation controls how a service is invoked. For example, it controls whether each request is handled by a new instance of the service implementation or if state is preserved across invocations.


The attributes described in Table 1.4 provide the basic information necessary to configure a JAX-WS consumer. You only need to provide values for the specific properties you want to configure. Most of the properties have sensible defaults, or they rely on information provided by the endpoint's contract.

Table 1.4. Attributes Used to Configure a JAX-WS Consumer

AttributeDescription
address Specifies the HTTP address of the endpoint where the consumer will make requests. This value overrides the value set in the contract.
bindingId Specifies the ID of the message binding the consumer uses. A list of valid binding IDs is provided in Appendix A.
bus Specifies the ID of the Spring bean configuring the bus managing the endpoint.
endpointName Specifies the value of the wsdl:port element's name attribute for the service on which the consumer is making requests. It is specified as a QName using the format ns:name, where ns is the namespace of the wsdl:port element.
serviceName Specifies the value of the wsdl:service element's name attribute for the service on which the consumer is making requests. It is specified as a QName using the format ns:name where ns is the namespace of the wsdl:service element.
username Specifies the username used for simple username/password authentication.
password Specifies the password used for simple username/password authentication.
serviceClass Specifies the name of the service endpoint interface(SEI).
wsdlLocation Specifies the location of the endpoint's WSDL contract. The WSDL contract's location is relative to the folder from which the client is deployed.
name Specifies the stringified QName of the wsdl:port element for the service on which the consumer is making requests. It is specified as a QName using the format {ns}localPart, where ns is the namespace of the wsdl:port element and localPart is the value of the wsdl:port element's name attribute.
abstract Specifies if the bean is an abstract bean. Abstract beans act as parents for concrete bean definitions and are not instantiated. The default is false. Setting this to true instructs the bean factory not to instantiate the bean.
depends-on Specifies a list of beans that the endpoint depends on being instantiated before it can be instantiated.
createdFromAPI

Specifies that the user created that bean using Fuse Services Framework APIs like Service.getPort().

The default is false.

Setting this to true does the following:

  • Changes the internal name of the bean by appending .jaxws-client to its id

  • Makes the bean abstract


In addition to the attributes listed in Table 1.4, it might be necessary to use multiple xmlns:shortName attributes to declare the namespaces used by the endpointName and the serviceName attributes.

To add functionality to your consumer or to perform advanced configuration, you must add child elements to the configuration.

Child elements allow you to do the following:

Table 1.5 describes the child element's you can use to configure a JAX-WS consumer.

Table 1.5. Elements For Configuring a Consumer Endpoint

ElementDescription
jaxws:binding Specifies a bean configuring the message binding used by the endpoint. Message bindings are configured using implementations of the org.apache.cxf.binding.BindingFactory interface.[a]
jaxws:dataBinding Specifies the class implementing the data binding used by the endpoint. You specify this using an embedded bean definition. The class implementing the JAXB data binding is org.apache.cxf.jaxb.JAXBDataBinding.
jaxws:features Specifies a list of beans that configure advanced features of Fuse Services Framework. You can provide either a list of bean references or a list of embedded beans.
jaxws:handlers Specifies a list of JAX-WS Handler implementations for processing messages.
jaxws:inInterceptors Specifies a list of interceptors that process inbound responses. For more information see Developing Apache CXF Interceptors.
jaxws:inFaultInterceptors Specifies a list of interceptors that process inbound fault messages. For more information see Developing Apache CXF Interceptors.
jaxws:outInterceptors Specifies a list of interceptors that process outbound requests. For more information see Developing Apache CXF Interceptors.
jaxws:outFaultInterceptors Specifies a list of interceptors that process outbound fault messages. For more information see Developing Apache CXF Interceptors.
jaxws:properties Specifies a map of properties that are passed to the endpoint.
jaxws:conduitSelector Specifies an org.apache.cxf.endpoint.ConduitSelector implementation for the client to use. A ConduitSelector implementation will override the default process used to select the Conduit object that is used to process outbound requests.

[a] The SOAP binding is configured using the soap:soapBinding bean.


HTTP consumer 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. In addition to the HTTP connection properties, an HTTP consumer endpoint can specify how it is secured.

A consumer endpoint can be configured using two mechanisms:

You configure an HTTP consumer endpoint 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 corresponding to the endpoint. The value for the name attribute takes the form portQName.http-conduit. Example 2.2 shows the http-conf:conduit element that would be used to add configuration for an endpoint that is specified by the WSDL fragment <port binding="widgetSOAPBinding" name="widgetSOAPPort> when the endpoint's target namespace is http://widgets.widgetvendor.net.


The http-conf:conduit element has child elements that specify configuration information. They are described in Table 2.1.


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

Table 2.2. HTTP Consumer Configuration Attributes

AttributeDescription
ConnectionTimeout

Specifies the amount of time, in milliseconds, that the consumer attempts to establish a connection before it times out. The default is 30000.

0 specifies that the consumer will continue to send the request indefinitely.

ReceiveTimeout

Specifies the amount of time, in milliseconds, that the consumer will wait for a response before it times out. The default is 30000.

0 specifies that the consumer will wait indefinitely.

AutoRedirect

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

MaxRetransmits

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

AllowChunking

Specifies whether the consumer will send requests using chunking. The default is true which specifies that the consumer will use chunking when sending requests.

Chunking cannot be 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.

Accept

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

AcceptLanguage

Specifies what language (for example, American English) the consumer prefers for the purpose 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 consumer 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.

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.

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 — Specifies that the consumer wants the connection kept open after the initial request/response sequence. If the server honors it, the connection is kept open until the consumer closes it.

  • close(default) — 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 consumer to a service provider. See Consumer Cache Control Directives.

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 on 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.

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.

If the AutoRedirect attribute is set to true and the request is redirected, any value specified in the Referer attribute is overridden. The value of the HTTP Referer property is set to the URL of the service that redirected the consumer’s original request.

DecoupledEndpoint

Specifies the URL of a decoupled endpoint for the receipt of responses over a separate provider->consumer connection. For more information on using decoupled endpoints see, Using the HTTP Transport in Decoupled Mode.

You must configure both the consumer endpoint and the service provider endpoint 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.

ProxyServerType

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

  • HTTP(default)

  • SOCKS


Table 2.3 lists the cache control directives supported by an HTTP consumer.

Table 2.3. http-conf:client Cache Control Directives

DirectiveBehavior
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 either 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, the consumer can accept a stale response of any age.

min-fresh

The consumer wants a response that is still 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 can 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 adhere to the behavior mandated by the standard directive.


HTTP service provider 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 service provider endpoint can be configured using two mechanisms:

The http-conf:server element is used to configure the properties of a service provider endpoint's HTTP connection. Its attributes, described in Table 2.5, specify the connection's properties.

Table 2.5. HTTP Service Provider Configuration Attributes

AttributeDescription
ReceiveTimeout

Sets the length of time, in milliseconds, the service provider attempts to receive a request before the connection times out. The default is 30000.

0 specifies that the provider will not timeout.

SuppressClientSendErrors

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.

SuppressClientReceiveErrors

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

HonorKeepAlive

Specifies whether the service provider honors requests for a connection to remain open after a response has been sent. The default is false; keep-alive requests are ignored.

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 service provider to a consumer. See Service Provider Cache Control Directives.

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.

The primary use of content encodings is to allow documents to be compressed using some encoding mechanism, such as zip or gzip. Fuse Services Framework performs no validation on content codings. It is the user’s responsibility to ensure that a specified content coding is supported at application level.

ServerType

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


Table 2.6 lists the cache control directives supported by an HTTP service provider.

Table 2.6. http-conf:server Cache Control Directives

DirectiveBehavior
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 the 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 revalidate expired entries that relate to a response before that entry can be used in a subsequent response.

proxy-revalidate

Does the same as must-revalidate, except that it can only be enforced on shared caches and is ignored by private unshared caches. When 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

Does 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. When using this directive, the proxy-revalidate directive must also be used.

cache-extension

Specifies additional extensions to the other cache directives. Extensions can 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 adhere to the behavior mandated by the standard directive.


Using the HTTP transport in decoupled mode adds extra layers of complexity to the processing of HTTP messages. While the added complexity is transparent to the implementation level code in an application, it might be important to understand what happens for debugging reasons.

Figure 2.1 shows the flow of messages when using HTTP in decoupled mode.


A request starts the following process:

  1. The consumer implementation invokes an operation and a request message is generated.

  2. The WS-Addressing layer adds the WS-A headers to the message.

    When a decoupled endpoint is specified in the consumer's configuration, the address of the decoupled endpoint is placed in the WS-A ReplyTo header.

  3. The message is sent to the service provider.

  4. The service provider receives the message.

  5. The request message from the consumer is dispatched to the provider's WS-A layer.

  6. Because the WS-A ReplyTo header is not set to anonymous, the provider sends back a message with the HTTP status code set to 202, acknowledging that the request has been received.

  7. The HTTP layer sends a 202 Accepted message back to the consumer using the original connection's back-channel.

  8. The consumer receives the 202 Accepted reply on the back-channel of the HTTP connection used to send the original message.

    When the consumer receives the 202 Accepted reply, the HTTP connection closes.

  9. The request is passed to the service provider's implementation where the request is processed.

  10. When the response is ready, it is dispatched to the WS-A layer.

  11. The WS-A layer adds the WS-Addressing headers to the response message.

  12. The HTTP transport sends the response to the consumer's decoupled endpoint.

  13. The consumer's decoupled endpoint receives the response from the service provider.

  14. The response is dispatched to the consumer's WS-A layer where it is correlated to the proper request using the WS-A RelatesTo header.

  15. The correlated response is returned to the client implementation and the invoking call is unblocked.

The SOAP over JMS protocol is defined by the World Wide Web Consortium(W3C) as a way of providing a more reliable transport layer to the customary SOAP/HTTP protocol used by most services. The Fuse Services Framework implementation is fully compliant with the specification and should be compatible with any framework that is also compliant.

This transport uses JNDI to find the JMS destinations. When an operation is invoked, the request is packaged as a SOAP message and sent in the body of a JMS message to the specified destination.

To use the SOAP/JMS transport:

  1. Specify that the transport type is SOAP/JMS.

  2. Specify the target destination using a JMS URI.

  3. Optionally, configure the JNDI connection.

  4. Optionally, add additional JMS configuration.

You specify the address of the JMS target destination when specifying the WSDL port for the endpoint. The address specification for a SOAP/JMS endpoint uses the same soap:address element and attribute as a SOAP/HTTP endpoint. The difference is the address specification. JMS endpoints use a JMS URI as defined in the URI Scheme for JMS 1.0. Example 3.2 shows the syntax for a JMS URI.


Table 3.1 describes the available variants for the JMS URI.


The options portion of a JMS URI are used to configure the transport and are discussed in JMS URIs.

Example 3.3 shows the WSDL port entry for a SOAP/JMS endpoint whose target destination is looked up using JNDI.


For working with SOAP/JMS services in Java see Using SOAP over JMS in Developing Applications Using JAX-WS.

As shown in Example 3.2, you can append one or more options to the end of a JMS URI by separating them from the destination's address with a question mark(?). Multiple options are separated by an ampersand(&). Example 3.4 shows the syntax for using multiple options in a JMS URI.


Table 3.4 shows all of the WSDL extension elements you can use to configure the JMS transport.

Table 3.4. SOAP/JMS WSDL extension elements

ElementDefaultDescription
soapjms:jndiInitialContextFactory Specifies the fully qualified Java class name of the JNDI provider. Equivalent to setting the java.naming.factory.initial Java system property.
soapjms:jndiURL Specifies the URL that initializes the JNDI provider. Equivalent to setting the java.naming.provider.url Java system property.
soapjms:jndiContextParameter Enables you to specify an additional property for creating the JNDI InitialContext. Use the name and value attributes to specify the property.
soapjms:jndiConnectionFactoryName Specifies the JNDI name of the JMS connection factory.
soapjms:deliveryModePERSISTENTSpecifies whether to use JMS PERSISTENT or NON_PERSISTENT message semantics. In the case of PERSISTENT delivery mode, the JMS broker stores messages in persistent storage before acknowledging them; whereas NON_PERSISTENT messages are kept in memory only.
soapjms:replyToName 

Explicitly specifies the reply destination to appear in the JMSReplyTo header. Setting this property is recommended for SOAP invocations that have request-reply semantics. If this property is not set the JMS provider allocates a temporary queue with an automatically generated name.

The value of this property has an interpretation that depends on the variant specified in the JMS URI, as follows:

  • jndi variant—the JNDI name of the destination.

  • queue or topic variants—the actual name of the destination.

soapjms:priority4Specifies the JMS message priority, which ranges from 0 (lowest) to 9 (highest).
soapjms:timeToLive0Time, in milliseconds, after which the message will be discarded by the JMS provider. A value of 0 represents an infinite lifetime.

Example 3.7 shows a WSDL contract for a SOAP/JMS service. It configures the JNDI layer in the binding scope, the message delivery details in the service scope, and the reply destination in the port scope.

Example 3.7. WSDL contract with SOAP/JMS configuration

<wsd;definitions ...
1    xmlns:soapjms="http://www.w3.org/2010/soapjms/"
  ... >
  ...
  <wsdl:binding name="JMSGreeterPortBinding" type="tns:JMSGreeterPortType">
    ...
2    <soapjms:jndiInitialContextFactory>
      org.apache.activemq.jndi.ActiveMQInitialContextFactory
    </soapjms:jndiInitialContextFactory>
    <soapjms:jndiURL>tcp://localhost:61616</soapjms:jndiURL>
    <soapjms:jndiConnectionFactoryName>
      ConnectionFactory
    </soapjms:jndiConnectionFactoryName>
    ...
  </wsdl:binding>
  ...
  <wsdl:service name="JMSGreeterService">
    ...
3    <soapjms:deliveryMode>NON_PERSISTENT</soapjms:deliveryMode>
    <soapjms:timeToLive>60000</soapjms:timeToLive>
    ...
    <wsdl:port binding="tns:JMSGreeterPortBinding" name="GreeterPort">
4      <soap:address location="jms:jndi:dynamicQueues/test.cxf.jmstransport.queue" />
5      <soapjms:replyToName>
        dynamicQueues/greeterReply.queue
      </soapjms:replyToName>
      ...
    </wsdl:port>
    ...
  </wsdl:service>
  ...
</wsdl:definitions>

The WSDL in Example 3.7 does the following:

1

Declare the namespace for the SOAP/JMS extensions.

2

Configure the JNDI connections in the binding scope.

3

Configure the JMS delivery style to non-persistent and each message to live for one minute.

4

Specify the target destination.

5

Configure the JMS transport so that reply messages are delivered on the greeterReply.queue queue.

The Fuse Services Framework generic JMS transport can connect to any JMS provider and work with applications that exchange JMS messages with bodies of either TextMessage or ByteMessage.

There are two ways to enable and configure the JMS transport:

The JMS configuration bean uses the Spring p-namespace to make the configuration as simple as possible. To use this namespace you need to declare it in the configuration's root element as shown in Example 4.1.


You specify the JMS configuration by defining a bean of class org.apache.cxf.transport.jms.JMSConfiguration. The properties of the bean provide the configuration settings for the transport.

Table 4.1 lists properties that are common to both providers and consumers.

Table 4.1. General JMS Configuration Properties

PropertyDefaultDescription
connectionFactory-ref Specifies a reference to a bean that defines a JMS ConnectionFactory.
wrapInSingleConnectionFactorytrueSpecifies whether to wrap the ConnectionFactory with a Spring SingleConnectionFactory. Doing so can improve the performance of the JMS transport when the specified connection factory does not pool connections.
reconnectOnExceptionfalseSpecifies whether to create a new connection in the case of an exception. This property is only used when wrapping the connection factory with a Spring SingleConnectionFactory.
targetDestination Specifies the JNDI name or provider specific name of a destination.
replyDestination Specifies the JMS name of the JMS destinations where replies are sent. This attribute allows you to use a user defined destination for replies. For more details see Using a Named Reply Destination.
destinationResolver Specifies a reference to a Spring DestinationResolver. This allows you to define how destination names are resolved. 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 Specifies a reference to a Spring transaction manager. This allows the service to participate in JTA Transactions.
taskExecutor Specifies a reference to a Spring TaskExecutor. This is used in listeners to decide how to handle incoming messages. By default the transport uses the Spring SimpleAsyncTaskExecutor.
useJms11falseSpecifies whether JMS 1.1 features are available.
messageIdEnabledtrueSpecifies whether the JMS transport wants the JMS broker to provide message IDs. Setting this to false causes the endpoint to call its message producer's setDisableMessageID() method with a value of true. The JMS broker is then given a hint that it does not need to generate message IDs or add them to the messages from the endpoint. The JMS broker can choose to accept the hint or ignore it.
messageTimestampEnabledtrueSpecifies whether the JMS transport wants the JMS broker to provide message time stamps. Setting this to false causes the endpoint to call its message producer's setDisableMessageTimestamp() method with a value of true. The JMS broker is then given a hint that it does not need to generate time stamps or add them to the messages from the endpoint. The JMS broker can choose to accept the hint or ignore it.
cacheLevel3Specifies the level of caching allowed by the listener. Valid values are 0(CACHE_NONE), 1(CACHE_CONNECTION), 2(CACHE_SESSION), 3(CACHE_CONSUMER), 4(CACHE_AUTO).
pubSubNoLocalfalseSpecifies whether to receive messages produced from the same connection.
receiveTimeout0Specifies, in milliseconds, the amount of time to wait for response messages. 0 means wait indefinitely.
explicitQosEnabledfalseSpecifies whether the QoS settings like priority, persistence, and time to live are explicitly set for each message or if they are allowed to use default values.
deliveryMode1

Specifies if a message is persistent. The two values are:

  • 1(NON_PERSISTENT)—messages will be kept memory

  • 2(PERSISTENT)—messages will be persisted to disk

priority4Specifies the message's priority for the messages. JMS priority values can range from 0 to 9. The lowest priority is 0 and the highest priority is 9.
timeToLive0Specifies, in milliseconds, the message will be available after it is sent. 0 specifies an infinite time to live.
sessionTransactedfalseSpecifies if JMS transactions are used.
concurrentConsumers1Specifies the minimum number of concurrent consumers created by the listener.
maxConcurrentConsumers1Specifies the maximum number of concurrent consumers by listener.
messageSelector Specifies the string value of the selector. For more information on the syntax used to specify message selectors, see the JMS 1.1 specification.
subscriptionDurablefalseSpecifies whether the server uses durrable subscriptions.
durableSubscriptionName Specifies the string used to register the durable subscription.
messageTypetextSpecifies 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 ByteMessage.
pubSubDomainfalseSpecifies whether the target destination is a topic.
jmsProviderTibcoEmsfalseSpecifies if your JMS provider is Tibco EMS. This causes the principal in the security context to be populated from the JMS_TIBCO_SENDER header.
useMessageIDAsCorrelationIDfalseSpecifies whether JMS will use the message ID to correlate messages. If not, the client will set a generated correlation ID.

As shown in Example 4.2, the bean's properties are specified as attributes to the bean element. They are all declared in the Spring p 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 line shown in Example 4.5 to the definitions element of your contract.


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 used in WSDL is identical to the one used in the configuration file. Its attributes are listed in Table 4.2.


The jms:address WSDL element uses a jms:JMSNamingProperties child element to specify additional information needed to connect to a JNDI provider.

To run a simple example of logging follow the instructions outlined in a Simple Example of Using Logging.

For more information on how logging works in Fuse Services Framework, read this entire chapter.

To change the log level and output destination of the log messages in the wsdl_first sample application, complete the following steps:

  1. Run the sample server as described in the Running the demo using java section of the README.txt file in the InstallDir/samples/wsdl_first directory. Note that the server start command specifies the default logging.properties file, as follows:

    PlatformCommand
    Windowsstart java -Djava.util.logging.config.file=%CXF_HOME%\etc\logging.properties demo.hw.server.Server
    UNIXjava -Djava.util.logging.config.file=$CXF_HOME/etc/logging.properties demo.hw.server.Server &

    The default logging.properties file is located in the InstallDir/etc directory. It configures the Fuse Services Framework loggers to print WARNING level log messages to the console. As a result, you see very little printed to the console.

  2. Stop the server as described in the README.txt file.

  3. Make a copy of the default logging.properties file, name it mylogging.properties file, and save it in the same directory as the default logging.properties file.

  4. Change the global logging level and the console logging levels in your mylogging.properties file to INFO by editing the following lines of configuration:

  5. Restart the server using the following command:

    PlatformCommand
    Windowsstart java -Djava.util.logging.config.file=%CXF_HOME%\etc\mylogging.properties demo.hw.server.Server
    UNIXjava -Djava.util.logging.config.file=$CXF_HOME/etc/mylogging.properties demo.hw.server.Server &

    Because you configured the global logging and the console logger to log messages of level INFO, you see a lot more log messages printed to the console.

The default logging configuration file, logging.properties, is located in the InstallDir/etc directory. It configures the Fuse Services Framework loggers to print WARNING level messages to the console. If this level of logging is suitable for your application, you do not have to make any changes to the file before using it. You can, however, change the level of detail in the log messages. For example, you can change whether log messages are sent to the console, to a file or to both. In addition, you can specify logging at the level of individual packages.

[Note]Note

This section discusses the configuration properties that appear in the default logging.properties file. There are, however, many other java.util.logging configuration properties that you can set. For more information on the java.util.logging API, see the java.util.logging javadoc at: http://java.sun.com/j2se/1.5/docs/api/java/util/logging/package-summary.html.

The Java logging utility, java.util.logging, uses handler classes to output log messages. Table 5.1 shows the handlers that are configured in the default logging.properties file.


[Important]Important

The handler classes must be on the system classpath in order to be installed by the Java VM when it starts. This is done when you set the Fuse Services Framework environment.

Example 5.2 shows the code for configuring the console logger.


The console handler also supports the configuration properties shown in Example 5.3.

Example 5.3. Console Handler Properties

java.util.logging.ConsoleHandler.level = WARNING 1
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter 2

The configuration properties shown in Example 5.3 can be explained as follows:

1

The console handler supports a separate log level configuration property. This allows you to limit the log messages printed to the console while the global logging setting can be different (see Configuring Logging Levels). The default setting is WARNING.

2

Specifies the java.util.logging formatter class that the console handler class uses to format the log messages. The default setting is the java.util.logging.SimpleFormatter.

Example 5.4 shows code that configures the file handler.


The file handler also supports the configuration properties shown in Example 5.5.

Example 5.5. File Handler Configuration Properties

java.util.logging.FileHandler.pattern = %h/java%u.log 1
java.util.logging.FileHandler.limit = 50000 2
java.util.logging.FileHandler.count = 1 3
java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter 4

The configuration properties shown in Example 5.5 can be explained as follows:

1

Specifies the location and pattern of the output file. The default setting is your home directory.

2

Specifies, in bytes, the maximum amount that the logger writes to any one file. The default setting is 50000. If you set it to zero, there is no limit on the amount that the logger writes to any one file.

3

Specifies how many output files to cycle through. The default setting is 1.

4

Specifies the java.util.logging formatter class that the file handler class uses to format the log messages. The default setting is the java.util.logging.XMLFormatter.

You can use the com.xyz.foo.level configuration property described in Configuring logging at an individual package level to set fine-grained logging for specified Fuse Services Framework logging subsystems.

Table 5.2 shows a list of available Fuse Services Framework logging subsystems.

Table 5.2. Fuse Services Framework Logging Subsystems

SubsystemDescription
org.apache.cxf.aegis Aegis binding
org.apache.cxf.binding.coloc colocated binding
org.apache.cxf.binding.http HTTP binding
org.apache.cxf.binding.jbi JBI binding
org.apache.cxf.binding.object Java Object binding
org.apache.cxf.binding.soap SOAP binding
org.apache.cxf.binding.xml XML binding
org.apache.cxf.bus Fuse Services Framework bus
org.apache.cxf.configuration configuration framework
org.apache.cxf.endpoint server and client endpoints
org.apache.cxf.interceptor interceptors
org.apache.cxf.jaxws Front-end for JAX-WS style message exchange, JAX-WS handler processing, and interceptors relating to JAX-WS and configuration
org.apache.cxf.jbi JBI container integration classes
org.apache.cxf.jca JCA container integration classes
org.apache.cxf.js JavaScript front-end
org.apache.cxf.transport.http HTTP transport
org.apache.cxf.transport.https secure version of HTTP transport, using HTTPS
org.apache.cxf.transport.jbi JBI transport
org.apache.cxf.transport.jms JMS transport
org.apache.cxf.transport.local transport implementation using local file system
org.apache.cxf.transport.servlet HTTP transport and servlet implementation for loading JAX-WS endpoints into a servlet container
org.apache.cxf.ws.addressing WS-Addressing implementation
org.apache.cxf.ws.policy WS-Policy implementation
org.apache.cxf.ws.rm WS-ReliableMessaging (WS-RM) implementation
org.apache.cxf.ws.security.wss4j WSS4J security implementation

You can log the content of the messages that are sent between a service and a consumer. For example, you might want to log the contents of SOAP messages that are being sent between a service and a consumer.

To see the logging of SOAP messages modify the wsdl_first sample application located in the InstallDir/samples/wsdl_first directory, as follows:

  1. Add the jaxws:features element shown in Example 5.14 to the cxf.xml configuration file located in the wsdl_first sample's directory:


  2. The sample uses the default logging.properties file, which is located in the InstallDir/etc directory. Make a copy of this file and name it mylogging.properties.

  3. In the mylogging.properties file, change the logging levels to INFO by editing the .level and the java.util.logging.ConsoleHandler.level configuration properties as follows:

  4. Start the server using the new configuration settings in both the cxf.xml file and the mylogging.properties file as follows:

    PlatformCommand
    Windowsstart java -Djava.util.logging.config.file=%CXF_HOME%\etc\mylogging.properties demo.hw.server.Server
    UNIXjava -Djava.util.logging.config.file=$CXF_HOME/etc/mylogging.properties demo.hw.server.Server &
  5. Start the hello world client using the following command:

    PlatformCommand
    Windowsjava -Djava.util.logging.config.file=%CXF_HOME%\etc\mylogging.properties demo.hw.client.Client .\wsdl\hello_world.wsdl
    UNIXjava -Djava.util.logging.config.file=$CXF_HOME/etc/mylogging.properties demo.hw.client.Client ./wsdl/hello_world.wsdl

The SOAP messages are logged to the console.

WS-RM ensures the reliable delivery of messages between a source and a destination endpoint. The source is the initial sender of the message and the destination is the ultimate receiver, as shown in Figure 7.1.


The flow of WS-RM messages can be described as follows:

This entire process occurs symmetrically for both the request and the response message; that is, in the case of the response message, the server acts as the RM source and the client acts as the RM destination.

To enable WS-RM add the WS-RM and WS-Addressing interceptors to the Fuse Services Framework bus, or to a consumer or service endpoint using Spring bean configuration. This is the approach taken in the WS-RM sample that is found in the InstallDir/samples/ws_rm directory. The configuration file, ws-rm.cxf, shows the WS-RM and WS-Addressing interceptors being added one-by-one as Spring beans (see Example 7.1).

Example 7.1. Enabling WS-RM Using Spring Beans

<?xml version="1.0" encoding="UTF-8"?>
1<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/
   beans http://www.springframework.org/schema/beans/spring-beans.xsd">
2   <bean id="mapAggregator" class="org.apache.cxf.ws.addressing.MAPAggregator"/>
   <bean id="mapCodec" class="org.apache.cxf.ws.addressing.soap.MAPCodec"/>
3   <bean id="rmLogicalOut" class="org.apache.cxf.ws.rm.RMOutInterceptor">
        <property name="bus" ref="cxf"/>
   </bean>
   <bean id="rmLogicalIn" class="org.apache.cxf.ws.rm.RMInInterceptor">
        <property name="bus" ref="cxf"/>
   </bean>
   <bean id="rmCodec" class="org.apache.cxf.ws.rm.soap.RMSoapInterceptor"/>
   <bean id="cxf" class="org.apache.cxf.bus.CXFBusImpl">
4        <property name="inInterceptors">
            <list>
                <ref bean="mapAggregator"/>
                <ref bean="mapCodec"/>
                <ref bean="rmLogicalIn"/>
                <ref bean="rmCodec"/>
            </list>
        </property>
5        <property name="inFaultInterceptors">
            <list>
                <ref bean="mapAggregator"/>
                <ref bean="mapCodec"/>
                <ref bean="rmLogicalIn"/>
                <ref bean="rmCodec"/>
            </list>
        </property>
6        <property name="outInterceptors">
            <list>
                <ref bean="mapAggregator"/>
                <ref bean="mapCodec"/>
                <ref bean="rmLogicalOut"/>
                <ref bean="rmCodec"/>
            </list>
        </property>
7        <property name="outFaultInterceptors">
            <list>
                <ref bean="mapAggregator">
                <ref bean="mapCodec"/>
                <ref bean="rmLogicalOut"/>
                <ref bean="rmCodec"/>
            </list>
        </property>
    </bean>
</beans>

The code shown in Example 7.1 can be explained as follows:

1

A Fuse Services Framework configuration file is a Spring XML file. You must include an opening Spring beans element that declares the namespaces and schema files for the child elements that are encapsulated by the beans element.

2

Configures each of the WS-Addressing interceptors—MAPAggregator and MAPCodec. For more information on WS-Addressing, see Deploying WS-Addressing.

3

Configures each of the WS-RM interceptors—RMOutInterceptor, RMInInterceptor, and RMSoapInterceptor.

4

Adds the WS-Addressing and WS-RM interceptors to the interceptor chain for inbound messages.

5

Adds the WS-Addressing and WS-RM interceptors to the interceptor chain for inbound faults.

6

Adds the WS-Addressing and WS-RM interceptors to the interceptor chain for outbound messages.

7

Adds the WS-Addressing and WS-RM interceptors to the interceptor chain for outbound faults.

The WS-Policy framework provides the infrastructure and APIs that allow you to use WS-Policy. It is compliant with the November 2006 draft publications of the Web Services Policy 1.5—Framework and Web Services Policy 1.5—Attachment specifications.

To enable WS-RM using the Fuse Services Framework WS-Policy framework, do the following:

  1. Add the policy feature to your client and server endpoint. Example 7.2 shows a reference bean nested within a jaxws:feature element. The reference bean specifies the AddressingPolicy, which is defined as a separate element within the same configuration file.


  2. Add a reliable messaging policy to the wsdl:service element—or any other WSDL element that can be used as an attachment point for policy or policy reference elements—to your WSDL file, as shown in Example 7.3.


You can configure WS-RM by:

  • Setting Fuse Services Framework-specific attributes that are defined in the Fuse Services Framework WS-RM manager namespace, http://cxf.apache.org/ws/rm/manager.

  • Setting standard WS-RM policy attributes that are defined in the http://schemas.xmlsoap.org/ws/2005/02/rm/policy namespace.

You must encode the details of the replicas in your cluster in your service WSDL file. Example 8.1 shows a WSDL file extract that defines a service cluster of three replicas.

Example 8.1. Enabling HA with Static Failover—WSDL File

1<wsdl:service name="ClusteredService">
2    <wsdl:port binding="tns:Greeter_SOAPBinding" name="Replica1">
        <soap:address location="http://localhost:9001/SoapContext/Replica1"/>
    </wsdl:port>

3    <wsdl:port binding="tns:Greeter_SOAPBinding" name="Replica2">
        <soap:address location="http://localhost:9002/SoapContext/Replica2"/>
    </wsdl:port>

4    <wsdl:port binding="tns:Greeter_SOAPBinding" name="Replica3">
        <soap:address location="http://localhost:9003/SoapContext/Replica3"/>
    </wsdl:port>

</wsdl:service>

The WSDL extract shown in Example 8.1 can be explained as follows:

1

Defines a service, ClusterService, which is exposed on three ports:

  1. Replica1

  2. Replica2

  3. Replica3

2

Defines Replica1 to expose the ClusterService as a SOAP over HTTP endpoint on port 9001.

3

Defines Replica2 to expose the ClusterService as a SOAP over HTTP endpoint on port 9002.

4

Defines Replica3 to expose the ClusterService as a SOAP over HTTP endpoint on port 9003.

You can configure HA with static failover to use a random strategy instead of the sequential strategy when selecting a replica. The random strategy selects a random replica service each time a service becomes unavailable, or fails. The choice of failover target from the surviving members in a cluster is entirely random.

To configure the random strategy, add the configuration shown in Example 8.3 to your client configuration file.

Example 8.3. Configuring a Random Strategy for Static Failover

<beans ...>
1    <bean id="Random" class="org.apache.cxf.clustering.RandomStrategy"/>
    
    <jaxws:client name="{http://apache.org/hello_world_soap_http}Replica3"
                  createdFromAPI="true">
        <jaxws:features>
            <clustering:failover>
2                <clustering:strategy>
                    <ref bean="Random"/>
                </clustering:strategy>
            </clustering:failover>
        </jaxws:features>
    </jaxws:client>
</beans>

The configuration shown in Example 8.3 can be explained as follows:

1

Defines a Random bean and implementation class that implements the random strategy.

2

Specifies that the random strategy is used when selecting a replica.

The following fragment from a Spring XML file shows how to add the fabric load balancer feature, FabricLoadBalancerFeature, to an Apache CXF bus. Any Apache CXF endpoints subsequently created on this bus will automatically have the load-balancer feature enabled.

The following beans are used to install the fabric load-balancer feature:

The following fragment from a blueprint XML file shows how to add the fabric load balancer feature, FabricLoadBalancerFeature, to an Apache CXF bus. Any Apache CXF endpoints subsequently created on this bus will automatically have the load-balancer feature enabled.

The following beans are used to install the fabric load-balancer feature:

Example 9.1 shows a complete Spring XML example of a WS endpoint configured to use the fabric load balancing feature.

Example 9.1. WS Server with Fabric Load Balancer Feature

<?xml version="1.0" encoding="UTF-8"?>
<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:osgi="http://www.springframework.org/schema/osgi"
    xmlns:osgix="http://www.springframework.org/schema/osgi-compendium"
    xmlns:ctx="http://www.springframework.org/schema/context"
    xmlns:cxfcore="http://cxf.apache.org/core"
    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://www.springframework.org/schema/osgi
            http://www.springframework.org/schema/osgi/spring-osgi.xsd
        http://www.springframework.org/schema/context
            http://www.springframework.org/schema/context/spring-context.xsd
        http://www.springframework.org/schema/osgi
            http://www.springframework.org/schema/osgi/spring-osgi.xsd
        http://www.springframework.org/schema/osgi-compendium
            http://www.springframework.org/schema/osgi-compendium/spring-osgi-compendium.xsd
        http://cxf.apache.org/core
            http://cxf.apache.org/schemas/core.xsd
">

    <!-- Configuration Admin entry -->
    <osgix:cm-properties id="cmProps"
        persistent-id="org.fusesource.example.fabric.lb">
      <prop key="portNumber">8191</prop>
    </osgix:cm-properties>

    <!-- placeholder configurer -->
    <ctx:property-placeholder properties-ref="cmProps" />


    <!-- Create the WS endpoint -->
    <jaxws:endpoint id="HTTPEndpoint"
        implementor="org.fusesource.example.PersonImpl"
        address="http://localhost:${portNumber}/PersonServiceCF"/>


    <!-- Reference the fabric agent -->
    <osgi:reference id="IZKClient"
        interface="org.linkedin.zookeeper.client.IZKClient" />

    <!-- Configure the Fabric load balancer feature -->
    <bean id="fabricLoadBalancerFeature"
          class="org.fusesource.fabric.cxf.FabricLoadBalancerFeature">
        <property name="zkClient" ref="IZKClient" />
        <property name="fabricPath" value="demo/lb" />
    </bean>

    <!-- Add the feature to the bus -->
    <cxfcore:bus>
      <cxfcore:features>
        <ref bean="fabricLoadBalancerFeature" />
      </cxfcore:features>
    </cxfcore:bus>

</beans>

The preceding Spring XML configuration consists of the following main sections:

  • Setting up OSGi Configuration Admin—the osgix:cm-properties element and the ctx:property-placeholder element set up the OSGi Configuration Admin service, enabling you to substitute the WS endpoint's IP port number using the placeholder, ${portNumber}.

    Use of the OSGi Configuration Admin service is optional, but it provides a convenient way of creating a cluster of WS servers listening on different ports. With the configuration shown here, you can deploy the same server bundle into different container instances, using the OSGi Configuration Admin service to customise the IP port of each deployed server instance.

  • Creating the WS endpoint—create the WS endpoint in the usual way, using the jaxws:endpoint element. By default, this endpoint is automatically associated with the default bus instance, which has load balancing enabled. The only unusual aspect of this endpoint definition is that the OSGi Configuration Admin service is used to define the port number in the endpoint's address (through the ${portNumber} placeholder).

  • Enabling the fabric load balancing feature—the fabric load balancing feature is installed in the default bus instance, as previously described. In this example, the fabricPath property is set to the value, demo/lb.

To deploy the WS endpoint in a fabric, you need to create the appropriate profiles. Because you want to create a cluster of WS endpoints, it makes sense to define multiple profiles, where each WS endpoint gets its own profile. For example, you could define the following set of profiles for deployment:

Assuming that the example server bundle (containing the WS endpoint implementation) is stored in the local Maven repository and has the Maven coordinates, org.fusesource.example/cxf-lb-server/1.0-SNAPSHOT, you can create the cxf-lb-server base profile by entering the following console commands:

karaf@root> profile-create --parents cxf cxf-lb-server
karaf@root> profile-edit -f fabric-cxf cxf-lb-server
karaf@root> profile-edit -b mvn:org.fusesource.example/cxf-lb-server/1.0-SNAPSHOT cxf-lb-server

You can then create the cxf-lb-server-8185 profile and the cxf-lb-server-8186 profile as follows:

karaf@root> profile-create --parents cxf-lb-server cxf-lb-server-8185
karaf@root> profile-create --parents cxf-lb-server cxf-lb-server-8186
karaf@root> profile-edit -p org.fusesource.example.fabric.lb/portNumber=8185 cxf-lb-server-8185
karaf@root> profile-edit -p org.fusesource.example.fabric.lb/portNumber=8186 cxf-lb-server-8186

The cxf-lb-server-8185 profile and the cxf-lb-server-8186 profile are now ready to be deployed to the container of your choice, using the fabric:container-change-profile command.

The following fragment from a Spring XML file shows how to add the fabric load balancer feature, FabricLoadBalancerFeature, directly into a WS client proxy instance.

The fabric load balancer feature is installed directly into the WS client proxy by inserting it as a child of the jaxws:features element (or, as in this case, by inserting a bean reference to the actual instance). The following beans are used to initialise the fabric load-balancer feature:

The following fragment from a blueprint XML file shows how to add the fabric load balancer feature, FabricLoadBalancerFeature, directly into a WS client proxy instance.

The fabric load balancer feature is installed directly into the WS client proxy by inserting it as a child of the jaxws:features element (or, as in this case, by inserting a bean reference to the actual instance). The following beans are used to initialise the fabric load-balancer feature:

As an alternative to using XML configuration, you can enable the fabric load balancing feature on the client side by programming directly in Java. The following example shows how to enable fabric load balancing on a proxy for the Hello Web service.

In this example, the fabricPath property is set to the value, demo/lb (which matches the example value used by the server in Example 9.1).

The address that the client proxy accesses is set to a dummy value, http://dummyaddress, because this value is not used. When the client is initialized, the load balancer feature substitutes the address value retrieved from the demo/lb node of the fabric registry.

Example 9.2 shows a detailed Spring XML example of how to configure a WS client proxy with the fabric load balancer feature.

Example 9.2. Client Proxy with Fabric Load Balancer Feature

<?xml version="1.0" encoding="UTF-8"?>
<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:osgi="http://www.springframework.org/schema/osgi"
    xmlns:cxfcore="http://cxf.apache.org/core"
    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://www.springframework.org/schema/osgi
            http://www.springframework.org/schema/osgi/spring-osgi.xsd
        http://www.springframework.org/schema/osgi
            http://www.springframework.org/schema/osgi/spring-osgi.xsd
        http://cxf.apache.org/core
            http://cxf.apache.org/schemas/core.xsd
">

    <!-- Create a client proxy, with load balancing enabled -->
    <jaxws:client id="personServiceProxy"
        address="http://dummyaddress"
        serviceClass="org.fusesource.example.Person">
        <jaxws:features>
            <ref bean="fabricLoadBalancerFeature" />
        </jaxws:features>
    </jaxws:client>

    <!-- Inject the client proxy into a bean... -->
    <!-- (not shown) -->


    <!-- Reference the fabric agent -->
    <osgi:reference id="IZKClient"
        interface="org.linkedin.zookeeper.client.IZKClient" />

    <!-- Configure the Fabric load balancer feature -->
    <bean id="fabricLoadBalancerFeature"
          class="org.fusesource.fabric.cxf.FabricLoadBalancerFeature">
        <property name="zkClient" ref="IZKClient" />
        <property name="fabricPath" value="demo/lb" />
    </bean>

</beans>

Figure 9.2 gives an overview of the fabric failover mechanism for Apache CXF endpoints.


In this example, two WS servers are created, with the URIs, http://localhost:8185/Foo and http://localhost:8186/Foo. In both servers, the failover feature is configured to store the cluster endpoints under the path, demo/fo, in the fabric registry. The cluster endpoints stored under demo/fo are ordered. The first endpoint in the cluster is the master and all of the other endpoints are slaves.

The failover algorithm works as follows:

  1. When the WS client starts, it is configured to look up the cluster path, demo/fo, in the fabric registry. The failover feature initially returns the first address registered under demo/fo (the master).

  2. At some point, the master server could fail. The client determines whether the master has failed by catching the exception that occurs when it tries to make an invocation: if the caught exception matches one of the exceptions in a specified list (by default, just the java.io.IOException), the master is deemed to have failed and the client now ignores the corresponding address entry under demo/fo.

  3. The client selects the next address entry under demo/fo and attempts to connect to that server. Assuming that this server is healthy, it is effectively the new master.

  4. At some point in the future, if the failed old master is restarted successfully, it creates a new address entry under demo/fo after the existing entries, and is then available to clients, in case the other server (or servers) fail.

The configuration of WS servers and WS clients in the failover case is similar to the load balancing case (see Configure the Server and Configure the Client), except that instead of instantiating and referencing a FabricLoadBalancerFeature bean, you must instantiate and reference a FabricFailOverFeature bean.

For example, in Spring XML you can create a FabricFailOverFeature bean instance as follows:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    ...
    xmlns:osgi="http://www.springframework.org/schema/osgi"
    ...
    xmlns:cxfcore="http://cxf.apache.org/core"
>
    ...
    <!-- Reference the fabric agent -->
    <osgi:reference id="IZKClient"
        interface="org.linkedin.zookeeper.client.IZKClient" />

    <!-- Configure the Fabric load balancer feature -->
    <bean id="failoverFeature"
          class="org.fusesource.fabric.cxf.FabricFailOverFeature">
        <property name="zkClient" ref="IZKClient" />
        <property name="fabricPath" value="ZKPath" />
    </bean>
    ...
</beans>

Remember to customise the value of the fabricPath property and to reference the appropriate bean ID (failoverFeature in the preceding example).



[1] You can get a list of the bundle IDs using the osgi list command.


The Fuse ESB Enterprise OSGi tooling uses the Maven bundle plug-in from Apache Felix. The bundle plug-in is based on the bnd tool from Peter Kriens. It automates the construction of OSGi bundle manifests by introspecting the contents of the classes being packaged in the bundle. Using the knowledge of the classes contained in the bundle, the plug-in can calculate the proper values to populate the Import-Packages and the Export-Package properties in the bundle manifest. The plug-in also has default values that are used for other required properties in the bundle manifest.

To use the bundle plug-in, do the following:

  1. Add the bundle plug-in to your project's POM file.

  2. Configure the plug-in to correctly populate your bundle's manifest.

A Maven project for building an OSGi bundle can be a simple single level project. It does not require any sub-projects. However, it does require that you do the following:

  1. Add the bundle plug-in to your POM.

  2. Instruct Maven to package the results as an OSGi bundle.

[Tip]Tip

There are several Maven archetypes you can use to set up your project with the appropriate settings.

Before you can use the bundle plug-in you must add a dependency on Apache Felix. After you add the dependency, you can add the bundle plug-in to the plug-in portion of the POM.

Example B.1 shows the POM entries required to add the bundle plug-in to your project.

Example B.1. Adding an OSGi bundle plug-in to a POM

...
<dependencies>
  <dependency> 1
    <groupId>org.apache.felix</groupId>
    <artifactId>org.osgi.core</artifactId>
    <version>1.0.0</version>
  </dependency>
...
</dependencies>
...
<build>
  <plugins>
    <plugin> 2
      <groupId>org.apache.felix</groupId>
      <artifactId>maven-bundle-plugin</artifactId>
      <configuration>
        <instructions>
          <Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName> 3
          <Import-Package>*,org.apache.camel.osgi</Import-Package> 4
          <Private-Package>org.apache.servicemix.examples.camel</Private-Package> 5
        </instructions>
      </configuration> 
    </plugin>
  </plugins>
</build>
...

The entries in Example B.1 do the following:

1

Adds the dependency on Apache Felix

2

Adds the bundle plug-in to your project

3

Configures the plug-in to use the project's artifact ID as the bundle's symbolic name

4

Configures the plug-in to include all Java packages imported by the bundled classes; also imports the org.apache.camel.osgi package

5

Configures the plug-in to bundle the listed class, but not to include them in the list of exported packages

[Note]Note

Edit the configuration to meet the requirements of your project.

For more information on configuring the bundle plug-in, see Configuring the Bundle Plug-In.

By default, the OSGi manifest's Export-Package list is populated by all of the packages in your local Java source code (under src/main/java), except for the deault package, ., and any packages containing .impl or .internal.

[Important]Important

If you use a Private-Package element in your plug-in configuration and you do not specify a list of packages to export, the default behavior includes only the packages listed in the Private-Package element in the bundle. No packages are exported.

The default behavior can result in very large packages and in exporting packages that should be kept private. To change the list of exported packages you can add an Export-Package child to the plug-in's instructions element.

The Export-Package element specifies a list of packages that are to be included in the bundle and that are to be exported. The package names can be specified using the * wildcard symbol. For example, the entry com.fuse.demo.* includes all packages on the project's classpath that start with com.fuse.demo.

You can specify packages to be excluded be prefixing the entry with !. For example, the entry !com.fuse.demo.private excludes the package com.fuse.demo.private.

When excluding packages, the order of entries in the list is important. The list is processed in order from the beginning and any subsequent contradicting entries are ignored.

For example, to include all packages starting with com.fuse.demo except the package com.fuse.demo.private, list the packages using:

!com.fuse.demo.private,com.fuse.demo.*

However, if you list the packages using com.fuse.demo.*,!com.fuse.demo.private, then com.fuse.demo.private is included in the bundle because it matches the first pattern.

C

configuration
HTTP consumer connection properties, The client element
HTTP consumer endpoint, Using Configuration
HTTP service provider connection properties, The server element
HTTP service provider endpoint, Using Configuration
CreateSequence, How WS-RM works
CreateSequenceResponse, How WS-RM works

D

driverClassName, Configuring WS-persistence

H

high availability
client configuration, Add the clustering feature to your client configuration
configuring random strategy, Configuring a random strategy
configuring static failover, Overview
enabling static failover, Overview
static failover, HA with static failover
http-conf:authorization, The conduit element
http-conf:basicAuthSupplier, The conduit element
http-conf:client, The client element
Accept, The client element
AcceptEncoding, The client element
AcceptLanguage, The client element
AllowChunking, The client element
AutoRedirect, The client element
BrowserType, The client element
CacheControl, The client element, Consumer Cache Control Directives
Connection, The client element
ConnectionTimeout, The client element
ContentType, The client element
Cookie, The client element
DecoupledEndpoint, The client element, Configuring the consumer
Host, The client element
MaxRetransmits, The client element
ProxyServer, The client element
ProxyServerPort, The client element
ProxyServerType, The client element
ReceiveTimeout, The client element
Referer, The client element
http-conf:conduit, The conduit element
name attribute, The conduit element
http-conf:contextMatchStrategy, The destination element
http-conf:destination, The destination element
name attribute, The destination element
http-conf:fixedParameterOrder, The destination element
http-conf:proxyAuthorization, The conduit element
http-conf:server, The destination element, The server element
CacheControl, The server element, Service Provider Cache Control Directives
ContentEncoding, The server element
ContentLocation, The server element
ContentType, The server element
HonorKeepAlive, The server element
ReceiveTimeout, The server element
RedirectURL, The server element
ServerType, The server element
SuppressClientReceiveErrors, The server element
SuppressClientSendErrors, The server element
http-conf:tlsClientParameters, The conduit element
http-conf:trustDecider, The conduit element

J

jaxws:binding, Elements, Adding functionality
jaxws:client
abstract, Basic Configuration Properties
address, Basic Configuration Properties
bindingId, Basic Configuration Properties
bus, Basic Configuration Properties
createdFromAPI, Basic Configuration Properties
depends-on, Basic Configuration Properties
endpointName, Basic Configuration Properties
name, Basic Configuration Properties
password, Basic Configuration Properties
serviceClass, Basic Configuration Properties
serviceName, Basic Configuration Properties
username, Basic Configuration Properties
wsdlLocation, Basic Configuration Properties
jaxws:conduitSelector, Adding functionality
jaxws:dataBinding, Elements, Adding functionality
jaxws:endpoint
abstract, Attributes
address, Attributes
bindingUri, Attributes
bus, Attributes
createdFromAPI, Attributes
depends-on, Attributes
endpointName, Attributes
id, Attributes
implementor, Attributes
implementorClass, Attributes
name, Attributes
publish, Attributes
publishedEndpointUrl, Attributes
serviceName, Attributes
wsdlLocation, Attributes
jaxws:exector, Elements
jaxws:features, Elements, Adding functionality
jaxws:handlers, Elements, Adding functionality
jaxws:inFaultInterceptors, Elements, Adding functionality
jaxws:inInterceptors, Elements, Adding functionality
jaxws:invoker, Elements
jaxws:outFaultInterceptors, Elements, Adding functionality
jaxws:outInterceptors, Elements, Adding functionality
jaxws:properties, Elements, Adding functionality
jaxws:server
abstract, Attributes
address, Attributes
bindingId, Attributes
bus, Attributes
createdFromAPI, Attributes
depends-on, Attributes
endpointName, Attributes
id, Attributes
name, Attributes
publish, Attributes
serviceBean, Attributes
serviceClass, Attributes
serviceName, Attributes
wsdlLocation, Attributes
jaxws:serviceFactory, Elements
JMS
specifying the message type, Specifying the message type
JMS destination
specifying, Specifying the JMS address
jms:address, Specifying the JMS address
connectionPassword attribute, Specifying the JMS address
connectionUserName attribute, Specifying the JMS address
destinationStyle attribute, Specifying the JMS address
jmsDestinationName attribute, Specifying the JMS address
jmsiReplyDestinationName attribute, Using a Named Reply Destination
jmsReplyDestinationName attribute, Specifying the JMS address
jndiConnectionFactoryName attribute, Specifying the JMS address
jndiDestinationName attribute, Specifying the JMS address
jndiReplyDestinationName attribute, Specifying the JMS address, Using a Named Reply Destination
jms:client, Specifying the message type
messageType attribute, Specifying the message type
jms:JMSNamingProperties, Specifying JNDI properties
jms:server, Specifying the configuration
durableSubscriberName, Specifying the configuration
messageSelector, Specifying the configuration
transactional, Specifying the configuration
useMessageIDAsCorrealationID, Specifying the configuration
JMSConfiguration, Specifying the configuration
JNDI
specifying the connection factory, Specifying the JMS address

M

Maven archetypes, Useful Maven archetypes
Maven tooling
adding the bundle plug-in, Adding a bundle plug-in
maxLength, Maximum length of an RM sequence
maxUnacknowledged, Maximum unacknowledged messages threshold

N

named reply destination
specifying in WSDL, Specifying the JMS address
using, Using a Named Reply Destination

R

random strategy, Configuring a random strategy
replicated services, Overview
RMAssertion, WS-Policy RMAssertion Children

S

Sequence, How WS-RM works
SequenceAcknowledgment, How WS-RM works
static failover, HA with static failover
configuring, Overview
enabling, Overview

W

WS-Addressing
using, Configuring an endpoint to use WS-Addressing
WS-RM
AcknowledgementInterval, Acknowledgement interval
AtLeastOnce, Message delivery assurance policies
AtMostOnce, Message delivery assurance policies
BaseRetransmissionInterval, Base retransmission interval
configuring, Configuring WS-RM
destination, How WS-RM works
driverClassName, Configuring WS-persistence
enabling, Enabling WS-RM
ExponentialBackoff, Exponential backoff for retransmission
externaL attachment, External attachment
initial sender, How WS-RM works
InOrder, Message delivery assurance policies
interceptors, Fuse Services Framework WS-RM Interceptors
maxLength, Maximum length of an RM sequence
maxUnacknowledged, Maximum unacknowledged messages threshold
passWord, Configuring WS-persistence
rmManager, Children of the rmManager Spring bean
source, How WS-RM works
ultimate receiver, How WS-RM works
url, Configuring WS-persistence
userName, Configuring WS-persistence
wsam:Addressing, Configuring an endpoint to use WS-Addressing
WSDL extensors
jms:address (see jms:address)
jms:client (see jms:client)
jms:JMSNamingProperties (see jms:JMSNamingProperties)
jms:server (see jms:server)
wsrm:AcksTo, How WS-RM works
wswa:UsingAddressing, Configuring an endpoint to use WS-Addressing