cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [CONF] Apache CXF Documentation > CXF Architecture
Date Sun, 20 Feb 2011 23:19:00 GMT
    <base href="">
            <link rel="stylesheet" href="/confluence/s/2036/9/1/_/styles/combined.css?spaceKey=CXF20DOC&amp;forWysiwyg=true"
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="">CXF
    <h4>Page <b>edited</b> by             <a href="">Christian
                         <h4>Changes (3)</h4>
<div id="page-diffs">
                    <table class="diff" cellpadding="0" cellspacing="0">
            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">{gliffy:name=MessageFlowOnServerSide|align=left|size=L|version=1}
<br> <br></td></tr>
            <tr><td class="diff-unchanged" >h1. Apache CXF Software Architecture
Guide <br> <br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
            <tr><td class="diff-unchanged" > <br>{gliffy:name=MessageFlowOnClientSide|align=left|size=L|version=4}
            <tr><td class="diff-added-lines" style="background-color: #dfd;">Client
Side <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">{gliffy:name=MessageFlowOnServerSide|align=left|size=L|version=1}
<br>Server Side <br> <br></td></tr>
            <tr><td class="diff-unchanged" >h3. Front-ends <br> <br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
    </div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h1><a name="CXFArchitecture-ApacheCXFSoftwareArchitectureGuide"></a>Apache
CXF Software Architecture Guide</h1>

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

<div class='panelMacro'><table class='infoMacro'><colgroup><col width='24'><col></colgroup><tr><td
valign='top'><img src="/confluence/images/icons/emoticons/information.gif" width="16"
height="16" align="absmiddle" alt="" border="0"></td><td><b>Note...</b><br
/>This guide is awork in progress.  Please feel free to fill in some of the incomplete

<h2><a name="CXFArchitecture-TableofContents"></a>Table of Contents</h2>
<style type='text/css'>/*<![CDATA[*/
div.rbtoc1298243895692 {margin-left: 1.5em;padding: 0px;}
div.rbtoc1298243895692 ul {list-style: outline;margin-left: 0px;}
div.rbtoc1298243895692 li {margin-left: 0px;padding-left: 0px;}

/*]]>*/</style><div class='rbtoc1298243895692'>
    <li><a href='#CXFArchitecture-ApacheCXFSoftwareArchitectureGuide'>Apache CXF
Software Architecture Guide</a></li>
    <li><a href='#CXFArchitecture-TableofContents'>Table of Contents</a></li>
    <li><a href='#CXFArchitecture-ArchitecturalGoalsandConstraints'>Architectural
Goals and Constraints</a></li>
    <li><a href='#CXFArchitecture-CXFAPI'>CXF-API</a></li>
    <li><a href='#CXFArchitecture-Bus'>Bus</a></li>
    <li><a href='#CXFArchitecture-Howservicecallsareprocessed'>How service calls
are processed</a></li>
    <li><a href='#CXFArchitecture-Frontends'>Front-ends</a></li>
    <li><a href='#CXFArchitecture-Messaging%26Interceptors'>Messaging &amp;
    <li><a href='#CXFArchitecture-TheServiceModel'>The Service Model</a></li>
    <li><a href='#CXFArchitecture-DataBindings'>Data Bindings</a></li>
    <li><a href='#CXFArchitecture-ProtocolBindings'>Protocol Bindings</a></li>
    <li><a href='#CXFArchitecture-Transports'>Transports</a></li>
    <li><a href='#CXFArchitecture-Endpoints'>Endpoints</a></li>
    <li><a href='#CXFArchitecture-AJAXWSexample'>A JAX-WS example</a></li>
    <li><a href='#CXFArchitecture-Dependencies'>Dependencies</a></li>
    <li><a href='#CXFArchitecture-Tooling'>Tooling</a></li>
    <li><a href='#CXFArchitecture-BuildSupport'>Build Support</a></li>
    <li><a href='#CXFArchitecture-DeploymentView'>Deployment View</a></li>
    <li><a href='#CXFArchitecture-SizeandPerformance'>Size and Performance</a></li>
    <li><a href='#CXFArchitecture-Quality'>Quality</a></li>
    <li><a href='#CXFArchitecture-Appendix'>Appendix</a></li>
    <li><a href='#CXFArchitecture-Definitions%2CAcronymsandAbbreviations'>Definitions,
Acronyms and Abbreviations</a></li>
    <li><a href='#CXFArchitecture-References'>References</a></li>

<h2><a name="CXFArchitecture-ArchitecturalGoalsandConstraints"></a>Architectural
Goals and Constraints</h2>
<p>The Apache CXF services framework seeks to build the necessary infrastructure components
for services. Goals for CXF are many and include:</p>
	<li>High performance</li>
	<li>Easy configuration</li>
	<li>Intuitive and easy to use</li>
	<li>Clean separation of front-ends from the core code</li>
	<li>Data formats support</li>
	<li>Data bindings support</li>
	<li>Protocol bindings support</li>
	<li>Multiple transports support</li>
	<li>Multiple Programming Languages Support</li>
	<li>WS-&#42; and related specifications support</li>
	<li>Tools for code generation and WSDL validation</li>
	<li>Flexible deployment</li>

<h2><a name="CXFArchitecture-CXFAPI"></a>CXF-API</h2>

<p>The overall CXF architecture is primarily made up of the following parts:</p>
	<li>Bus: Contains a registry of extensions, interceptors and Properties</li>
	<li>Front-end: Front-ends provide a programming model to create services.</li>
	<li>Messaging &amp; Interceptors: These provide the low level message and pipeline
layer upon which most functionality is built.</li>
	<li>Service Model: Services host a Service model which is a WSDL-like model that describes
the service.</li>
	<li>Pluggable Data Bindings: ...</li>
	<li>Protocol Bindings: Bindings provide the functionality to interpret the protocol.</li>
	<li>Transports: Transportfactory creates Destinations (Receiving) and Conduits (Sending)</li>

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

<p><span class="image-wrap" style=""><a class="confluence-thumbnail-link 455x305"
src="/confluence/download/thumbnails/44806/cxf_architecture.png" style="border: 0px solid
black" /></a></span></p>

<h3><a name="CXFArchitecture-Bus"></a>Bus</h3>
<p>The 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).</p>

<p>This extensibility is made possible by dependency injection; the default bus implemenation
is based on <a href="Spring" class="external-link"
rel="nofollow">Spring</a>, which wires
the runtime components together for you.</p>

<p>The <tt>SpringBusFactory</tt> searches for all bean configuration files
 in the <tt>META-INF/cxf</tt> directories on your classpath, and builds an application
context from them. The bean configuration files included in the application context construction
	<li><tt>META-INF/cxf/cxf.xml</tt> (e.g., in <tt>cxf-rt-core</tt>
	<li><tt>META-INF/cxf/cxf-extension.xml</tt> (e.g. in <tt>cxf-rt-bindings-soap</tt>)</li>
	<li><tt>META-INF/cxf/cxf-property-editors.xml</tt> (e.g. in <tt>cxf-rt-transports-http</tt>)</li>

<p>See <a href="/confluence/display/CXF20DOC/Configuration+of+the+Bus" title="Configuration
of the Bus">Configuration of the Bus</a> for an example of how to customize the bus
by supplying your own bean configuration file and <a href="/confluence/display/CXF20DOC/Configuration+of+Runtime+Constructed+Objects"
title="Configuration of Runtime Constructed Objects">Configuration of Runtime Constructed
Objects</a> 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).</p>

<h3><a name="CXFArchitecture-Howservicecallsareprocessed"></a>How service
calls are processed</h3>

<map name='GLIFFY_MAP_44806_MessageFlowOnClientSide'></map>
<table width="100%">
        <td align="left">
                <caption align="bottom">
                        <img style="border: none; width: 1269px; height: 580px;"

<p>Client Side</p>

<map name='GLIFFY_MAP_44806_MessageFlowOnServerSide'></map>
<table width="100%">
        <td align="left">
                <caption align="bottom">
                        <img style="border: none; width: 1208px; height: 550px;"

<p>Server Side</p>

<h3><a name="CXFArchitecture-Frontends"></a>Front-ends</h3>

<p>Front-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 <a href="/confluence/display/CXF20DOC/Frontends"

<h3><a name="CXFArchitecture-Messaging%26Interceptors"></a>Messaging &amp;

<p>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 &amp;
resume interceptor chains.</p>

<p>Interceptors have a method, <tt>handleMessage</tt>, which allows them
to act on the Message.These Interceptors can then be built up into chains of interceptors,
straightforwardly called InterceptorChains. Some examples include:</p>
	<li>An interceptor which parses just the headers of a SOAP message into DOM elements</li>
	<li>A WS-Security interceptor which decrypts or authenticates an incoming message.</li>
	<li>An outgoing data binding interceptor which serializes the result</li>

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

<h4><a name="CXFArchitecture-PhaseInterceptors"></a>Phase Interceptors</h4>

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

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

<p>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.</p>

<h4><a name="CXFArchitecture-FaultHandling"></a>Fault Handling</h4>

<p>At any point during processing, an interceptor may throw a Fault, or a derivative
of a Fault like the <tt>SoapFault</tt>. 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.</p>

<p>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

<h4><a name="CXFArchitecture-Exchanges"></a>Exchanges</h4>

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

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

<h4><a name="CXFArchitecture-ReentrantInterceptorChains"></a>Reentrant InterceptorChains</h4>

<p>An interesting feature of the <tt>PhaseInterceptorChain</tt> 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 <tt>SoapOutInterceptor</tt>
is the best example:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
<span class="code-keyword">public</span> void handleMessage(Message m) {

  <span class="code-comment">// invoke next interceptor, which writes the contents of
the SOAP Body
</span>  m.getInterceptorChain().doIntercept(m);


<h3><a name="CXFArchitecture-TheServiceModel"></a>The Service Model</h3>

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

<p>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 <tt>ServerFactoryBean</tt> and <tt>ClientProxyFactoryBean</tt>
can used with the front-end to create, publish and consume web services. The factory classes
build up the service model and configure the service interceptors, data bindings and more.</p>

<p>The Service model itself is contained in the <tt>ServiceInfo</tt> class.
The following image depicts a subset of the Service Model's packaged API:</p>

<p><span class="image-wrap" style=""><a class="confluence-thumbnail-link 601x505"
src="/confluence/download/thumbnails/44806/service_model.png" style="border: 0px solid black"

<h3><a name="CXFArchitecture-DataBindings"></a>Data Bindings</h3>

<p>Data 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 <a href="/confluence/display/CXF20DOC/Data+Binding+Architecture"
title="Data Binding Architecture">Data Binding Architecture</a> for details. Currently
supported data bindings include JAXB 2.x (default), Aegis, Apache XMLBeans, Service Data Objects
(SDO) and JiBX (under development).</p>

<h3><a name="CXFArchitecture-ProtocolBindings"></a>Protocol Bindings</h3>

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

<p>CXF currently supported the following bindings protocols: SOAP 1.1, SOAP 1.2, REST/HTTP,
pure XML and CORBA.</p>

<h4><a name="CXFArchitecture-TheSoapBinding"></a>The Soap Binding</h4>

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

<p>The <tt>Soap</tt> binding also adds a special type of interceptor called
the <tt>SoapInterceptor</tt>. The <tt>SoapInterceptor</tt> adds two
methods to the <tt>Interceptor</tt> class:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
Set&lt;URI&gt; getRoles();
Set&lt;QName&gt; getUnderstoodHeaders();
<p>These inform the SOAP interceptors as to what headers and roles the particular SOAP
interceptor understands.</p>

<p>It has many interceptors designed to handle SOAP messages:</p>
	<li><tt>StaxInInterceptor</tt>: Creates an <tt>XMLStreamReader</tt>
from an incoming <tt>InputStream</tt></li>
	<li><tt>ReadHeadersInterceptor</tt>: Reads the headers into the <tt>SoapMessage</tt></li>
	<li><tt>MustUnderstandInterceptor</tt>: Checks the <tt>MustUnderstand</tt>
attributes of all the headers against all the <tt>SoapInterceptor</tt>'s <tt>getUnderstoodHeaders</tt>

<h4><a name="CXFArchitecture-REST%2FHTTPBinding"></a>REST/HTTP Binding</h4>

<h4><a name="CXFArchitecture-PureXMLBinding"></a>Pure XML Binding</h4>

<h4><a name="CXFArchitecture-CORBABinding"></a>CORBA Binding</h4>

<h3><a name="CXFArchitecture-Transports"></a>Transports</h3>

<p>CXF 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 <a href=""
class="external-link" rel="nofollow">here</a>.</p>

<h4><a name="CXFArchitecture-Conduits"></a>Conduits</h4>

<p>Conduits provide the basis for outgoing message sending. A <tt>Conduit</tt>
is created from a <tt>ConduitInitiator</tt>. Sending a message is a multistep
	<li>Call conduit.prepare(message): this starts the message sending. At this point a
<tt>Conduit</tt> may initiate a connection and set the OutputStream for the outgoing
	<li>Writing of the actual message to the <tt>OutputStream</tt></li>
	<li>Call to <tt>conduit.close(message)</tt>: this closes and disposes of
any existing  resources for the message sending.<br/>
A message sender may also register a <tt>MessageObserver</tt> with the Conduit.
If the <tt>Conduit</tt> is synchronous, the <tt>MessageObserver</tt>
will be notified once a response has been received.</li>

<h4><a name="CXFArchitecture-Destinations"></a>Destinations</h4>

<p>Destinations are the basis for receiving incoming messages. A destination is created
from a <tt>DestinationFactory</tt>:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
DestinationFactoryManager dfManager = bus.getExtension(DestinationFactoryManager.class);

<span class="code-comment">// Find a DestinationFactory <span class="code-keyword">for</span>
the SOAP HTTP transport
</span>DestinationFactory df = dfManager.getDestinationFactory(<span class="code-quote">"http:<span
<span class="code-comment">// TODO: outline building of EndpointInfo
</span>EndpointInfo endpointInfo = ...;
Destination destination = df.getDestination(endpointInfo);
<p>MessageObservers can then be registered with Destinations. These listen for incoming
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
MessageObserver myObserver = ...;
<p>The most common <tt>MessageObserver</tt> used in CXF is the <tt>ChainInitiationObserver</tt>.
This takes the incoming message, creates a message Exchange &amp; <tt>PhaseInterceptorChain</tt>,
then starts the chain.</p>

<h3><a name="CXFArchitecture-Endpoints"></a>Endpoints</h3>

<h3><a name="CXFArchitecture-AJAXWSexample"></a>A JAX-WS example</h3>

<p>Here's a small example of what might happen when we publish a service via the JAX-WS
<tt>Endpoint.publish()</tt> method.</p>
	<li>Call to <tt>Endpoint.publish("http://localhost/service", myService)</tt></li>
	<li>The <tt>EndpointImpl</tt> creates a Service from the <tt>myService</tt>
object using the <tt>JaxWsServiceFactoryBean</tt> using the class and/or WSDL</li>
	<li>An <tt>EndpointInfo</tt> is created for the <tt>Endpoint.publish</tt>
	<li>A <tt>JaxWsEndpointImpl</tt> is created from the <tt>EndpointInfo</tt>.
This contains the JAX-WS endpoint specific interceptors</li>
	<li>The <tt>JaxWsEndpointImpl</tt> creates a <tt>Binding</tt>
and <tt>Destination</tt> to listen on.</li>

<h2><a name="CXFArchitecture-Dependencies"></a>Dependencies</h2>
<p><a href="" class="external-link"
rel="nofollow">CXF's dependencies</a></p>

<h2><a name="CXFArchitecture-Tooling"></a>Tooling</h2>

<h2><a name="CXFArchitecture-BuildSupport"></a>Build Support</h2>

<h2><a name="CXFArchitecture-DeploymentView"></a>Deployment View</h2>

<h2><a name="CXFArchitecture-SizeandPerformance"></a>Size and Performance</h2>

<h2><a name="CXFArchitecture-Quality"></a>Quality </h2>
<p>CXF's Software Quality approach is detailed <a href=""
class="external-link" rel="nofollow">here</a>.</p>

<h2><a name="CXFArchitecture-Appendix"></a>Appendix</h2>

<h3><a name="CXFArchitecture-Definitions%2CAcronymsandAbbreviations"></a>Definitions,
Acronyms and Abbreviations</h3>
	<li>Bus -</li>
	<li>Conduit -</li>
	<li>CORBA - Common Object Request Broker Architecture is a standard for interoperability
in heterogeneous computing environments. It enables applications to cross boundaries of different
computing machines, operating systems, and programming languages. It specifies how client
applications can invoke operations on server objects. &#8211; <a href=""
class="external-link" rel="nofollow"></a></li>
	<li>Data Binding -</li>
	<li>Endpoint -</li>
	<li>Fault -</li>
	<li>Front-end -</li>
	<li>HTTP - Hypertext Transfer Protocol. A protocol used on the Internet by web browsers
to transport text and graphics. It is focuses on grabbing a page at a time, rather setting
up a session. Applets also use it to download jars, classes and resources. Browsers use to
download files and images, not just HTML text. &#8211; <a href=""
class="external-link" rel="nofollow"></a></li>
	<li>HTTPS - Hypertext Transer Protocol Secure. Used for encrypted communication between
browsers and servers. All transmission of HTTP data are made with the SSL protocol. &#8211;
<a href="" class="external-link" rel="nofollow"></a></li>
	<li>IDL -</li>
	<li>JAXB - Java API For XML Data Binding. You can think of JAXB as like a hobbled,
wasteful serialization scheme that reads and writes XML files. The idea is its writes a custom
Java progam for you that will then write or read the XML file. You can also think of it as
a way of reading XML files, getting much of the bubblegum automatically generated for you.
It is my preferred way to read XML, but it still half-assed (as is everything in XML). It
takes your XSD and constructs a getter and setter for each potential tag. The advantage is
the getters and setters use Java types e.g. enum, int, String and XMLGregorianCalendar…
not just String the way DOM does. Unfortunately, JAXB ignores the bounds specifications in
your XSD schema. You must validate the XML document with your XSD separately. To use it, compose
and validate your xsd file describing your XML files. &#8211; <a href=""
class="external-link" rel="nofollow"></a></li>
	<li>JAX-RS -</li>
	<li>JAX-WS -</li>
	<li>Javadoc -</li>
	<li>Java EE -</li>
	<li>Javascript - A Web scripting language that is used in both browsers and Web servers.
Like all scripting languages, it is used primarily to tie other components together or to
accept user input. &#8211; <a href="" class="external-link"
	<li>JBI -</li>
	<li>JiBX -</li>
	<li>JMS -</li>
	<li>Maven -</li>
	<li>Protocol Binding -</li>
	<li>REST -</li>
	<li>SAAJ -</li>
	<li>SDO - An acronym for Service Data Object. A ...</li>
	<li>Service Model -</li>
	<li>SOAP - The Simple Object Access Protocol (SOAP) uses a combination of XML-based
data structuring and the Hyper Text Transfer Protocol (HTTP) to define a standardized method
for invoking methods in objects distributed in diverse operating environments across the Internet.
&#8211; <a href="" class="external-link" rel="nofollow"></a></li>
	<li>Spring Framework -</li>
	<li>Transport -</li>
	<li>WSDL - WSDL is an XML format for describing network services as a set of endpoints
operating on messages containing either document-oriented or procedure-oriented information.
&#8211; <a href="" class="external-link" rel="nofollow"></a></li>
	<li>WS-* -</li>
	<li>XML - An acronym for Extensible markup Language. A general-purpose specification
used for creating markup languages. This specification allows for the creation of custom tags
in structured text files.</li>

<h3><a name="CXFArchitecture-References"></a>References</h3>
	<li><a href="" class="external-link"
rel="nofollow">Software Architecture</a>, <em>Wikipedia</em></li>
	<li><a href=""
class="external-link" rel="nofollow">Sample S/W Architecture Document</a>, <em>Rational
Software Corporation</em></li>
	<li><a href=""
class="external-link" rel="nofollow">Documenting your Software Architecture</a>,
<em>by Jim Alateras</em> (March 2006)</li>

        <div id="commentsSection" class="wiki-content pageSection">
        <div style="float: right;">
            <a href=""
class="grey">Change Notification Preferences</a>
        <a href="">View
        <a href="">View
        <a href=";showCommentArea=true#addcomment">Add

View raw message