Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Apache CXF Software Architecture Guide

Info
titleNote...

This is work in progress. PLease feel free to fill in some of the missing sections.

Table of Contents

Table of Contents
maxLevel3
styleoutline

...

In the upcoming sections, we'll take a look at each layer in turn and examine how they work together.

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

Purpose

...

Scope

This Software Architecture Document (web page) provides an architectural overview of the Apache CXF services framework.

...

References

Architectural Representation

...

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 ReadHeadersInterceptor and AddressingInInterceptor would tell the PhaseInterceptorChain they are in the "dispatch" phase by returning "dispatch" when getPhase() is called. Additionally, the ReadHeadersInterceptor could specify that it wants to run before the AddressingInInterceptor by returning the interceptor id when Interceptor.getBefore() is called.

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.

...

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.

...

Conduits provide the basis for outgoing message sending. A Conduit is created from a ConduitInitiator. Sending a message is a multistep pocess:

  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.

...

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

Dependencies

CXF's dependencies

Tooling

...

Build Support

...

...

Here's a small example of what might happen when we publish a service via the JAX-WS Endpoint.publish() method.

  1. Call to Endpoint.publish("http://localhost/service", myService)
  2. The EndpointImpl creates a Service from the myService object using the JaxWsServiceFactoryBean using the class and/or WSDL
  3. An EndpointInfo is created for the Endpoint.publish URL
  4. A JaxWsEndpointImpl is created from the EndpointInfo. This contains the JAX-WS endpoint specific interceptors
  5. The JaxWsEndpointImpl creates a Binding and Destination to listen on.

Architectural Goals and Constraints

...

  • Embeddable
  • High performance
  • Easy configuration
  • Intuitive and easy to use
  • Clean separation of front-ends from the core code
  • Data formats support
  • Data bindings support
  • Protocol bindings support
  • Multiple transports support
  • Multiple Programming Languages Support
  • WS-* and related specifications support
  • Tools for code generation and WSDL validation
  • Flexible deployment

Deployment View

CXF's deployment view can be seen through dependency charts here...

Size and Performance

...

Quality

...