Overview

...

Note: You can also review the CXF Architecture explained by Naveen Balani and Rajeev Hathi: Apache CXF Architecture Overview.

Bus

The bus is a provider of shared resources to the CXF runtime. Examples for such shared resources are: wsdl managers, binding factory managers etc. The bus can easily be extended to include your own custom resources or services, or you can replace default resources like the HTTP destination factory (based on Jetty) with your own (possibly based on Tomcat).
This is made possible by dependency injection: the default bus implemenation is based on Spring, which wires the runtime components together for you.
The SpringBusFactory searches for all bean configuration files in the META-INF/cxf directories on your classpath, and builds an application context from them. The bean configuration files included in the application context construction are:

...

See Configuration of the Bus for an example of how to customise the bus by supplying your own bean configuration file and Configuration of Runtime Constructed Objects for more information on the special case of injecting into objects created by the runtime (as opposed to objects created by the IOC container itself).

Front-ends

Front-ends provide a programming model to interact with CXF. The primary front-end at the moment is JAX-WS. The JAX-WS implementation is cleanly separated from the rest of CXF – like the bindings and core. They provide functionality through interceptors that are added to Services and Endpoints. See also Front-ends.

JAX-WS Front-end

Under development

JAX-RS Front-end

Under development

Javascript Front-end

Under development

Simple Front-end

Under development

Messaging & Interceptors

CXF is built on a generic messaging layer comprised of Messages, Interceptors, and InterceptorChains. Interceptors are the fundamental unit of functionality. By dividing up how messages are processed and sent, this gives CXF a very flexible architecture. It can be reconfigured at any point in the processing. This also gives CXF the ability to pause & resume interceptor chains.

...

Interceptors are uni-directional and are inherently unaware of whether they are dealing with a request, response, or fault.

Phase Interceptors

CXF provides an InterceptorChain implementation called the PhaseInterceptorChain. When Interceptors are added to the chain, they are grouped into ordered phases.  A PhaseInterceptor may provide guidance as to how it is to be ordered within the phase.

...

Before it was mentioned how chains were very dynamic and flexible. In our above example, we could add interceptors specific to that service once it is resolved. Or we could pause the chain once while we wait for some external chain, like an asynchronous service response.

Fault Handling

At any point during processing, an interceptor may throw a Fault, or a derivative of a Fault like the SoapFault. This will cause the chain to stop invoking and unwind it. Unwinding consists of calling handleFault on each interceptor that was invoked in reverse order.

InterceptorChains have the concept of a fault interceptor. Once the chain is unwound, the fault interceptor is invoked with the message that caused the fault. The fault interceptor may trigger a new chain which then invokes a specified set of interceptors meant to handle faults.

Exchanges

In addition to the concept of a Message, there is the concept of the Exchange. The exchange class holds a references to the in, out and fault messages for the current message exchange.

It also holds properties specific to the exchange, and not just the message. For instance the Exchange holds the Service that is current being invoked in it.

Reentrant InterceptorChains

An interesting feature of the PhaseInterceptorChain is that it is reentrant. This can be powerful and slightly dangerous. This feature is only used in CXF during the sending of an outgoing message, The SoapOutInterceptor is the best example:

public void handleMessage(Message m) {
  writeSoapEnvelopeStart();
  writeSoapBodyStart();

  // invoke next interceptor, which writes the contents of the SOAP Body
  m.getInterceptorChain().doIntercept(m);
  writeSoapBodyEnd();

  writeSoapEnvelopeEnd();
}

The Service Model

The Service model is the representation of a service within CXF. It is made up of two parts. First there is the ServiceInfo which contains a WSDL-like model of the service and its operations, bindings, and endpoints. Second, there is the Service itself, which contains the ServiceInfo, data-binding information, service interceptors, service properties, and more.

...

ServiceInfo
+-Interface: InterfaceInfo
| +-Operations: Collection<OperationInfo>
| | +- Input: MessageInfo
| | +- Output: MessageInfo
| | +- Faults: Collection<MessageInfo>
+-Bindings: Collection<BindingInfo>
| +-Operations: Collection<BindingOperationInfo>
+-Endpoints: Collection<EndpointInfo>

Data Bindings

Data Bindings implement the mapping between XML and Java. Data bindings convert data to and from XML, produce XML schema, and provide support for wsdl2java code generation. Not all data bindings support all of this functionality. At very least, a data binding must provide the data conversion. See Data Binding Architecture for details.

Protocol Bindings

Bindings provide ways to map concrete formats & protocols on top of transports. A binding contains two main parts, a BindingFactory and a Binding. A BindingFactory builds a Binding from the service model's BindingInfo. The binding contains interceptors specific to the binding and also implements the createMessage() method, which creates a Message implementation specific for that binding.

The Soap Binding

The prototypical binding is SOAP. It has its own Message class called the SoapMessage. It adds the ability to hold the current SoapVersion and the headers for the message.

...

1. StaxInInterceptor: Creates an XMLStreamReader from an incoming InputStream
2. ReadHeadersInterceptor: Reads the headers into the SoapMessage
3. MustUnderstandInterceptor: Checks the MustUnderstand attributes of all the headers against all the SoapInterceptor's getUnderstoodHeaders method.
4. SoapOutInterceptor:

XML Binding

Transports

CXF includes its own transport abstraction layer to hide transport specific details from the binding and front end layers.

...

1. Call conduit.prepare(message): this starts the message sending. At this point a Conduit may initiate a connection and set the OutputStream for the outgoing message.
2. Writing of the actual message to the OutputStream
3. Call to conduit.close(message): this closes and disposes of any existing resources for the message sending.
   A message sender may also register a MessageObserver with the Conduit. If the Conduit is synchronous, the MessageObserver will be notified once a response has been received.

Destinations

Destinations are the basis for receiving incoming messages. A destination is created from a DestinationFactory:

...

The most common MessageObserver used in CXF is the ChainInitiationObserver. This takes the incoming message, creates a message Exchange & PhaseInterceptorChain, then starts the chain.

Endpoints

Putting it all Together

A JAX-WS example

...