Apache CXF Software Architecture Guide
Info | ||
---|---|---|
| ||
This is work in progress. PLease feel free to fill in some of the missing sections. |
Table of Contents
Table of Contents | ||||
---|---|---|---|---|
|
...
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
- Software Architecture, Wikipedia
- Sample S/W Architecture Document, Rational Software Corporation
- Documenting your Software Architecture, by Jim Alateras (March 2006)
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:
- 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. - Writing of the actual message to the
OutputStream
- Call to
conduit.close(message)
: this closes and disposes of any existing resources for the message sending.
A message sender may also register aMessageObserver
with the Conduit. If theConduit
is synchronous, theMessageObserver
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
Tooling
...
Build Support
...
...
Here's a small example of what might happen when we publish a service via the JAX-WS Endpoint.publish()
method.
- Call to
Endpoint.publish("http://localhost/service", myService)
- The
EndpointImpl
creates a Service from themyService
object using theJaxWsServiceFactoryBean
using the class and/or WSDL - An
EndpointInfo
is created for theEndpoint.publish
URL - A
JaxWsEndpointImpl
is created from theEndpointInfo
. This contains the JAX-WS endpoint specific interceptors - The
JaxWsEndpointImpl
creates aBinding
andDestination
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
...