Apache CXF Software Architecture GuideThis document provides an architectural overview of the Apache CXF services framework. Table of ContentsArchitectural Goals and ConstraintsThe Apache CXF services framework seeks to build the necessary infrastructure components for services. Goals for CXF are many and include:
CXF-APIThe overall CXF architecture is primarily made up of the following parts:
In the upcoming sections, we'll take a look at each layer in turn and examine how they work together.
BusThe bus, being CXF's backbone, is a provider of shared resources to the CXF runtime. Examples for such shared resources include WSDL managers and binding factory managers. 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 another web container such as Apache Tomcat). This extensibility is made possible by dependency injection; the default bus implementation is based on Spring Framework, which wires the runtime components together for you. The
See Configuration of the Bus for an example of how to customize 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). How service calls are processed
Client Side
Server Side Front-endsFront-ends provide a programming model to interact with CXF. JAX-WS, JAX-RS, Simple and Javascript front-end APIs are provided by CXF . Each implementation is cleanly separated from the rest of CXF, just like the bindings and the core. Front-ends provide functionality through interceptors that are added to Services and Endpoints. See also Front-ends Messaging & InterceptorsCXF 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 have a method,
Interceptors are uni-directional and are inherently unaware of whether they are dealing with a request, response, or fault. Phase InterceptorsCXF provides an Let us take a hypothetical simplified example (NOTE: these phases and interceptors don't necessarily exist in CXF). Let us say we are parsing a SOAP message. We may want to have two phases. First, a dispatch phase which parses the soap headers and determines which service to route the Message to. Second, an unmarshal phase which binds the SOAP body to JAXB objects. In the first dispatch phase we could implement this via two interceptors, first a ReadHeadersInterceptor which parses the headers and second a WS-AddressingInInterceptor which determines which service we're invoking from the WS-Addressing header. In the second unmarshal phase, we have just a single JAXBUnmarshallerIntercptor. Both the 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 HandlingAt any point during processing, an interceptor may throw a Fault, or a derivative of a Fault like the InterceptorChains have the concept of a fault observer. Once the chain is unwound, the fault interceptor is invoked with the message that caused the fault. The fault observer may trigger a new chain which then invokes a specified set of interceptors meant to handle faults. ExchangesIn addition to the concept of a Message, there is the concept of the It also holds properties specific to the exchange, and not just the message. For instance the Reentrant InterceptorChainsAn interesting feature of the 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 ModelThe Service model is the representation of a service within CXF. It is made up of two parts. First there is the A service can be constructed from many different sources including classes and WSDLs (1.1 or 2.0). Typically front-ends are responsible for creating a service via service factories. Factory components such as The Service model itself is contained in the
Data BindingsData bindings implement the mapping between XML elements and Java objects. 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. Currently supported data bindings include JAXB 2.x (default) and Aegis. Protocol BindingsBindings provide ways to map concrete formats and protocols on top of transports. A binding contains two main parts, a CXF currently supported the following bindings protocols: SOAP 1.1, SOAP 1.2, REST/HTTP, pure XML and CORBA. The Soap BindingThe prototypical binding is SOAP. It has its own The Set<URI> getRoles(); Set<QName> getUnderstoodHeaders(); These inform the SOAP interceptors as to what headers and roles the particular SOAP interceptor understands. It has many interceptors designed to handle SOAP messages:
Additional BindingsOther bindings include REST/HTTP binding, pure XML binding, and the CORBA binding. TransportsCXF includes its own transport abstraction layer to hide transport specific details from the binding and front end layers. Currently supported transports include: HTTP, HTTPs, HTTP-Jetty, HTTP-OSGI, Servlet, local, JMS, In-VM and many others via the Camel transport for CXF such as SMTP/POP3, TCP and Jabber. Learn more about transports here. ConduitsConduits provide the basis for outgoing message sending. A
DestinationsDestinations are the basis for receiving incoming messages. A destination is created from a DestinationFactoryManager dfManager = bus.getExtension(DestinationFactoryManager.class);
// Find a DestinationFactory for the SOAP HTTP transport
DestinationFactory df = dfManager.getDestinationFactory("http://schemas.xmlsoap.org/wsdl/soap/http");
// TODO: outline building of EndpointInfo
EndpointInfo endpointInfo = ...;
Destination destination = df.getDestination(endpointInfo);
MessageObservers can then be registered with Destinations. These listen for incoming messages: MessageObserver myObserver = ...; destination.setMessageObserver(myObserver); The most common A JAX-WS exampleHere's a small example of what might happen when we publish a service via the JAX-WS
DependenciesQualityCXF's Software Quality approach is detailed here. References
|
