Apache CXF is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI. The Mule CXF Transport is an evolution of Mule's XFire transport, which provided support for the use of web service integration via Apache CXF. The Mule CXF connector also provides support for WS-Security, WS-Addressing, and WS-Reliable-Messaging.
CXF
CXF Transport
The location of a CXF configuration file, if any needs to be supplied.
Whether or not CXF should write Mule SOAP headers which pass along the correlation and ReplyTo information. This is true by default, but the Mule SOAP headers are only triggered in situations where there is an existing correlation ID and the ReplyTo header is set. (As of 2.2.1)
Initialize the static CXF Bus with a Bus configured to use Mule for all transports. This will affect any CXF generated clients that you run standalone. Defaults to true.
The name of the client class that CXF generated using CXF's wsdl2java tool. You must use wsdl2java if you do not have both the client and the server in the same JVM. Otherwise, this can be optional if the endpoint address is the same in both cases.
The WSDL port you want to use to communicate with the service.
The WSDL port you want to use to communicate with the service.
The class CXF should use to construct its service model for the client.
The reply to endpoint for clients which have WS-Addressing enabled.
Whether the whole SOAP Envelope, or just the body contents should be sent when in proxy mode.
The soapVersion that is going to be used for this endpoint. The specified version is translated into the corresponding bindingId value. This attribute is useful when there's need to avoid the creation of the endpoint with the default binding.
In case the bindingId attribute is set this attribute will override it. If not set and not specified otherwise CXF defaults to SOAP 1.1 binding
Whether or not MTOM (attachment support) is enabled for this endpoint.
The location of the WSDL for your service. If this is a server side endpoint it will served to your users.
Whether or not this endpoint should write Mule SOAP headers which pass along the correlation and ReplyTo information. This is true by default, but the Mule SOAP headers are only triggered in situations where there is an existing correlation ID and the ReplyTo header is set. (As of 2.2.1)
The CXF configuration that should be used.
The binding that should be used for this endpoint. It defaults to the SOAP binding by default.
The WSDL port name of your service.
The service namespace. (As of 2.2.1)
The WSDL service name of your service.
The class CXF should use to construct its service model. This is optional, and by default it will use the implementation class of your component, on inbound cxf endpoint. But it is mandatory for outbound endpoint when using "aegis" frontend.
Whether or not validation should be enabled on this service.
Validation only occurs on inbound server messages.
Additional properties for this service.
The databinding implementation that should be used. By default, this is JAXB for the JAX-WS frontend and Aegis for the simple frontend.
Any CXF features you want to apply to the client/server. See the CXF documentation for more information on features.
Additional incoming interceptors for this service.
Additional incoming fault interceptors.
Additional outgoing interceptors.
Additional outgoing fault interceptors.
The operation you want to invoke on the outbound endpoint.
A placeholder for arbitrary extensions as children of the 'mule' element. Other transports and modules can extend this if they need to add global elements to the configuration (but consider the more specific elements like abstract-connector first).
Spring property element for custom configuration.
Configures the Aegis data binding. See http://cxf.apache.org/docs/aegis-21.html
Configures the Source data binding. See http://stackoverflow.com/questions/4212608/getting-raw-xml-parameter-in-jax-ws-webservice-method
Configures the JAXB data binding. See http://cxf.apache.org/docs/jaxb.html
Configures the Jibx data binding.
Configures the Stax data binding.
Configures a custom data binding.
The location of any additional schema to be included inside the WSDL.
The WebServiceWrapperComponent class allows you to send the result of a web service call to another endpoint.
The URL of the web service.
Specifies that the URL of the web service will be obtained from the message itself.
The WSDL port you want to use to communicate to the service.
The operation you want to invoke on the outbound endpoint.
A WSS4J Password validator which verifies username/password combinations
against the Mule security manager.
The security manager instance to use for the password validator. (Optional)
A WSS4J Password validator which verifies username/password combinations against the Mule security manager.
A map containing the WSS4J configuration. The entry key and value should map to the text strings in WSS4J's WSHandlerConstants and WSConstants.
The key is the name of the element respecting Mule's naming format, it will be afterwards transformed to CamelCase to map the
corresponding constants, e.g. password-callback-class will map to the constant passwordCallbackClass.
A list of validators that allows to override the default validators used to validate a received security token.
A map containing the WSS4J configuration. The entry key and value should map to the text strings in WSS4J's WSHandlerConstants and WSConstants.
The key is the name of the element respecting Mule's naming format, it will be afterwards transformed to CamelCase to map the
corresponding constants, e.g. password-callback-class will map to the constant passwordCallbackClass.
Configuration to enable WS-Security
Name of the WS-Security configuration
Reference to a WS-Security configuration
Custom validators to override the default validators used to validate a received security token.
The custom validator instance to validate the tokens
Override UsernameToken validation providing a custom implementation of the Validator instance
Override SAML1 token validation providing a custom implementation of the Validator instance
Override SAML2 token validation providing a custom implementation of the Validator instance
Override Timestamp validation providing a custom implementation of the Validator instance
Override trust verification on a signature providing a custom implementation of the Validator instance
Override BinarySecurityToken validation providing a custom implementation of the Validator instance