Author: buildbot
Date: Mon Mar 27 17:47:50 2017
New Revision: 1009163
Log:
Production update by buildbot for cxf
Modified:
websites/production/cxf/content/cache/docs.pageCache
websites/production/cxf/content/docs/cxf-architecture.html
websites/production/cxf/content/docs/maven-cxf-codegen-plugin-wsdl-to-java.html
Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/cxf/content/docs/cxf-architecture.html
==============================================================================
--- websites/production/cxf/content/docs/cxf-architecture.html (original)
+++ websites/production/cxf/content/docs/cxf-architecture.html Mon Mar 27
17:47:50 2017
@@ -116,17 +116,12 @@ Apache CXF -- CXF Architecture
<td height="100%">
<!-- Content -->
<div class="wiki-content">
-<div id="ConfluenceContent"><h1
id="CXFArchitecture-ApacheCXFSoftwareArchitectureGuide">Apache CXF Software
Architecture Guide</h1>
+<div id="ConfluenceContent"><h1
id="CXFArchitecture-ApacheCXFSoftwareArchitectureGuide">Apache CXF Software
Architecture Guide</h1><p>This document provides an architectural overview of
the Apache CXF services framework.</p><h2
id="CXFArchitecture-TableofContents">Table of Contents</h2><p><style
type="text/css">/*<![CDATA[*/
+div.rbtoc1490636832619 {padding: 0px;}
+div.rbtoc1490636832619 ul {list-style: outline;margin-left: 0px;}
+div.rbtoc1490636832619 li {margin-left: 0px;padding-left: 0px;}
-<p>This document provides an architectural overview of the Apache CXF services
framework.</p>
-
-<h2 id="CXFArchitecture-TableofContents">Table of Contents</h2>
-<style type="text/css">/*<![CDATA[*/
-div.rbtoc1435780173236 {padding: 0px;}
-div.rbtoc1435780173236 ul {list-style: outline;margin-left: 0px;}
-div.rbtoc1435780173236 li {margin-left: 0px;padding-left: 0px;}
-
-/*]]>*/</style><div class="toc-macro rbtoc1435780173236">
+/*]]>*/</style></p><div class="toc-macro rbtoc1490636832619">
<ul class="toc-indentation"><li><a shape="rect"
href="#CXFArchitecture-ApacheCXFSoftwareArchitectureGuide">Apache CXF Software
Architecture Guide</a>
<ul class="toc-indentation"><li><a shape="rect"
href="#CXFArchitecture-TableofContents">Table of Contents</a></li><li><a
shape="rect"
href="#CXFArchitecture-ArchitecturalGoalsandConstraints">Architectural Goals
and Constraints</a></li><li><a shape="rect"
href="#CXFArchitecture-CXF-API">CXF-API</a>
<ul class="toc-indentation"><li><a shape="rect"
href="#CXFArchitecture-Bus">Bus</a></li><li><a shape="rect"
href="#CXFArchitecture-Howservicecallsareprocessed">How service calls are
processed</a></li><li><a shape="rect"
href="#CXFArchitecture-Front-ends">Front-ends</a></li><li><a shape="rect"
href="#CXFArchitecture-Messaging&Interceptors">Messaging &
Interceptors</a></li><li><a shape="rect"
href="#CXFArchitecture-TheServiceModel">The Service Model</a></li><li><a
shape="rect" href="#CXFArchitecture-DataBindings">Data Bindings</a></li><li><a
shape="rect" href="#CXFArchitecture-ProtocolBindings">Protocol
Bindings</a></li><li><a shape="rect"
href="#CXFArchitecture-Transports">Transports</a></li><li><a shape="rect"
href="#CXFArchitecture-AJAX-WSexample">A JAX-WS example</a></li></ul>
@@ -134,112 +129,38 @@ div.rbtoc1435780173236 li {margin-left:
<ul class="toc-indentation"><li><a shape="rect"
href="#CXFArchitecture-References">References</a></li></ul>
</li></ul>
</li></ul>
-</div>
-
-<h2 id="CXFArchitecture-ArchitecturalGoalsandConstraints">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>
-<ul><li>Embeddable</li><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-* and related
specifications support</li><li>Tools for code generation and WSDL
validation</li><li>Flexible deployment</li></ul>
-
-
-<h2 id="CXFArchitecture-CXF-API">CXF-API</h2>
-
-<p>The overall CXF architecture is primarily made up of the following
parts:</p>
-<ol><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 & 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></ol>
-
-
-<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="confluence-embedded-file-wrapper"><img
class="confluence-embedded-image confluence-thumbnail"
src="cxf-architecture.data/cxf_architecture.png"></span></p>
+</div><h2 id="CXFArchitecture-ArchitecturalGoalsandConstraints">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><ul><li>Embeddable</li><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-* and related
specifications support</li><li>Tools for code generation and WSDL
validation</li><li>Flexible deployment</li></ul><h2
id="CXFArchitecture-CXF-API">CXF-API</h2><p>The overall CXF architecture is
primarily made up of the following parts:</p><ol><li>Bus: Contains a registry
of extensions, interceptors and Properties</li><li>Front-end: Front-ends
provide a programming model to create s
ervices.</li><li>Messaging & 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></ol><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="confluence-embedded-file-wrapper"><img
class="confluence-embedded-image confluence-thumbnail"
src="cxf-architecture.data/cxf_architecture.png"></span></p><h3
id="CXFArchitecture-Bus">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 extende
d 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 shape="rect" class="external-link"
href="http://www.springsource.com/developer/spring"; rel="nofollow">Spring
Framework</a>, which wires the runtime components together for you.</p><p>The
<code>SpringBusFactory</code> searches for all bean configuration files in the
<code>META-INF/cxf</code> directories on your classpath, and builds an
application context from them. The bean configuration files included in the
application context construction
are:</p><ul><li><code>META-INF/cxf/cxf.xml</code> (e.g., in
<code>cxf-rt-core</code>
only)</li><li><code>META-INF/cxf/cxf-extension.xml</code> (e.g. in
<code>cxf-rt-bindings-soap</code>)</li><li><code>META-INF/cxf/cxf-pr
operty-editors.xml</code> (e.g. in
<code>cxf-rt-transports-http</code>)</li></ul><p>See <a shape="rect"
href="configuration-of-the-bus.html">Configuration of the Bus</a> for an
example of how to customize the bus by supplying your own bean configuration
file and <a shape="rect"
href="configuration-of-runtime-constructed-objects.html">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
id="CXFArchitecture-Howservicecallsareprocessed">How service calls are
processed</h3><p>
-<h3 id="CXFArchitecture-Bus">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 shape="rect" class="external-link"
href="http://www.springsource.com/developer/spring"; rel="nofollow">Spring
Framework</a>, which wires the runtime components together for you.</p>
-<p>The <code>SpringBusFactory</code> searches for all bean configuration files
in the <code>META-INF/cxf</code> directories on your classpath, and builds an
application context from them. The bean configuration files included in the
application context construction are:</p>
-<ul><li><code>META-INF/cxf/cxf.xml</code> (e.g., in <code>cxf-rt-core</code>
only)</li><li><code>META-INF/cxf/cxf-extension.xml</code> (e.g. in
<code>cxf-rt-bindings-soap</code>)</li><li><code>META-INF/cxf/cxf-property-editors.xml</code>
(e.g. in <code>cxf-rt-transports-http</code>)</li></ul>
+<span class="gliffy-container" id="gliffy-container-25591945-3414"
data-fullwidth="1269" data-ceoid="44806"
data-edit="${diagramEditLink.getLinkUrl()}"
data-full="${diagramZoomLink.getLinkUrl()}"
data-filename="MessageFlowOnClientSide">
-<p>See <a shape="rect" href="configuration-of-the-bus.html">Configuration of
the Bus</a> for an example of how to customize the bus by supplying your own
bean configuration file and <a shape="rect"
href="configuration-of-runtime-constructed-objects.html">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>
+ <map id="gliffy-map-25591945-9767" name="gliffy-map-25591945-9767"></map>
-<h3 id="CXFArchitecture-Howservicecallsareprocessed">How service calls are
processed</h3>
+ <img class="gliffy-image" id="gliffy-image-25591945-3414" width="600"
height="274" data-full-width="1269" data-full-height="580"
src="https://cwiki.apache.org/confluence/download/attachments/44806/MessageFlowOnClientSide.png?version=4&modificationDate=1298215366000&api=v2";
alt="MessageFlowOnClientSide" usemap="#gliffy-map-25591945-9767">
-
-
-
-
-
-<span class="gliffy-container" id="gliffy-container-25591945-9785"
data-fullwidth="1269" data-ceoid="44806"
data-edit="${diagramEditLink.getLinkUrl()}"
data-full="${diagramZoomLink.getLinkUrl()}"
data-filename="MessageFlowOnClientSide">
-
- <map id="gliffy-map-25591945-1830" name="gliffy-map-25591945-1830"></map>
-
- <img class="gliffy-image" id="gliffy-image-25591945-9785" width="1269"
height="580" data-full-width="1269" data-full-height="580"
src="https://cwiki.apache.org/confluence/download/attachments/44806/MessageFlowOnClientSide.png?version=4&modificationDate=1298215366000&api=v2";
alt="MessageFlowOnClientSide" usemap="#gliffy-map-25591945-1830">
-
- <map class="gliffy-dynamic" id="gliffy-dynamic-map-25591945-9785"
name="gliffy-dynamic-map-25591945-9785"></map>
+ <map class="gliffy-dynamic" id="gliffy-dynamic-map-25591945-3414"
name="gliffy-dynamic-map-25591945-3414"></map>
</span>
+</p><p>Client Side</p><p>
-<p>Client Side</p>
-
-
+<span class="gliffy-container" id="gliffy-container-25591953-5605"
data-fullwidth="1222" data-ceoid="44806"
data-edit="${diagramEditLink.getLinkUrl()}"
data-full="${diagramZoomLink.getLinkUrl()}"
data-filename="MessageFlowOnServerSide">
-<span class="gliffy-container" id="gliffy-container-25591953-3020"
data-fullwidth="1222" data-ceoid="44806"
data-edit="${diagramEditLink.getLinkUrl()}"
data-full="${diagramZoomLink.getLinkUrl()}"
data-filename="MessageFlowOnServerSide">
+ <map id="gliffy-map-25591953-8767" name="gliffy-map-25591953-8767"></map>
- <map id="gliffy-map-25591953-8227" name="gliffy-map-25591953-8227"></map>
+ <img class="gliffy-image" id="gliffy-image-25591953-5605" width="600"
height="295" data-full-width="1222" data-full-height="600"
src="https://cwiki.apache.org/confluence/download/attachments/44806/MessageFlowOnServerSide.png?version=4&modificationDate=1298310696000&api=v2";
alt="MessageFlowOnServerSide" usemap="#gliffy-map-25591953-8767">
- <img class="gliffy-image" id="gliffy-image-25591953-3020" width="1222"
height="600" data-full-width="1222" data-full-height="600"
src="https://cwiki.apache.org/confluence/download/attachments/44806/MessageFlowOnServerSide.png?version=4&modificationDate=1298310696000&api=v2";
alt="MessageFlowOnServerSide" usemap="#gliffy-map-25591953-8227">
-
- <map class="gliffy-dynamic" id="gliffy-dynamic-map-25591953-3020"
name="gliffy-dynamic-map-25591953-3020"></map>
+ <map class="gliffy-dynamic" id="gliffy-dynamic-map-25591953-5605"
name="gliffy-dynamic-map-25591953-5605"></map>
</span>
-
-<p>Server Side</p>
-
-<h3 id="CXFArchitecture-Front-ends">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 shape="rect"
href="frontends.html">Front-ends</a></p>
-
-<h3 id="CXFArchitecture-Messaging&Interceptors">Messaging &
Interceptors</h3>
-
-<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 & resume interceptor
chains.</p>
-
-<p>Interceptors have a method, <code>handleMessage</code>, 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>
-<ul><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></ul>
-
-
-<p>Interceptors are uni-directional and are inherently unaware of whether they
are dealing with a request, response, or fault.</p>
-
-<h4 id="CXFArchitecture-PhaseInterceptors">Phase Interceptors</h4>
-
-<p>CXF provides an <code>InterceptorChain</code> implementation called the
<code>PhaseInterceptorChain</code>. When Interceptors are added to the chain,
they are grouped into ordered phases.  A <code>PhaseInterceptor</code> 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 <code>ReadHeadersInterceptor</code> and
<code>AddressingInInterceptor</code> would tell the
<code>PhaseInterceptorChain</code> they are in the "dispatch" phase by
returning "dispatch" when <code>getPhase()</code> is called. Additionally, the
<code>ReadHeadersInterceptor</code> could speci
fy that it wants to run before the <code>AddressingInInterceptor</code> by
returning the interceptor id when <code>Interceptor.getBefore()</code> 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 id="CXFArchitecture-FaultHandling">Fault Handling</h4>
-
-<p>At any point during processing, an interceptor may throw a Fault, or a
derivative of a Fault like the <code>SoapFault</code>. 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 faults.</p>
-
-<h4 id="CXFArchitecture-Exchanges">Exchanges</h4>
-
-<p>In addition to the concept of a Message, there is the concept of the
<code>Exchange</code>. The exchange class holds a references to the in, out
and fault messages for the current message exchange.</p>
-
-<p>It also holds properties specific to the exchange, and not just the
message. For instance the <code>Exchange</code> holds the <code>Service</code>
that is current being invoked in it.</p>
-
-<h4 id="CXFArchitecture-ReentrantInterceptorChains">Reentrant
InterceptorChains</h4>
-
-<p>An interesting feature of the <code>PhaseInterceptorChain</code> 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
<code>SoapOutInterceptor</code> is the best example:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
-public void handleMessage(Message m) {
+</p><p>Server Side</p><h3
id="CXFArchitecture-Front-ends">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 shape="rect" href="frontends.html">Front-ends</a></p><h3
id="CXFArchitecture-Messaging&Interceptors">Messaging &
Interceptors</h3><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 & resume
interceptor chains.</p><p>Interceptors have a method, <code>handleMessag
e</code>, 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><ul><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></ul><p>Interceptors are uni-directional and are inherently unaware
of whether they are dealing with a request, response, or fault.</p><h4
id="CXFArchitecture-PhaseInterceptors">Phase Interceptors</h4><p>CXF provides
an <code>InterceptorChain</code> implementation called the
<code>PhaseInterceptorChain</code>. When Interceptors are added to the chain,
they are grouped into ordered phases.  A <code>PhaseInterceptor</code> may
provide guidance as to how it is to be ordered within the phase.</p><p>Let us
take a hypothetical simplified example (NOT
E: 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
<code>ReadHeadersInterceptor</code> and <code>AddressingInInterceptor</code>
would tell the <code>PhaseInterceptorChain</code> they are in the "dispatch"
phase by returning "dispatch" when <code>getPhase()</code> is called.
Additionally, the <code>ReadHeadersInterceptor</code> could specify that it
wants to run before the <code>AddressingIn
Interceptor</code> by returning the interceptor id when
<code>Interceptor.getBefore()</code> 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 id="CXFArchitecture-FaultHandling">Fault
Handling</h4><p>At any point during processing, an interceptor may throw a
Fault, or a derivative of a Fault like the <code>SoapFault</code>. 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 handl
e faults.</p><h4 id="CXFArchitecture-Exchanges">Exchanges</h4><p>In addition
to the concept of a Message, there is the concept of the <code>Exchange</code>.
The exchange class holds a references to the in, out and fault messages for the
current message exchange.</p><p>It also holds properties specific to the
exchange, and not just the message. For instance the <code>Exchange</code>
holds the <code>Service</code> that is current being invoked in it.</p><h4
id="CXFArchitecture-ReentrantInterceptorChains">Reentrant
InterceptorChains</h4><p>An interesting feature of the
<code>PhaseInterceptorChain</code> 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 <code>SoapOutInterceptor</code> is the best
example:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">public void handleMessage(Message m) {
writeSoapEnvelopeStart();
writeSoapBodyStart();
@@ -250,65 +171,12 @@ public void handleMessage(Message m) {
writeSoapEnvelopeEnd();
}
</pre>
-</div></div>
-
-<h3 id="CXFArchitecture-TheServiceModel">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 <code>ServiceInfo</code> 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
<code>ServiceInfo</code>, 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
<code>ServerFactoryBean</code> and <code>ClientProxyFactoryBean</code> 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 <code>ServiceInfo</code>
class. The following image depicts a subset of the Service Model's packaged
API:</p>
-
-<p><span class="confluence-embedded-file-wrapper"><img
class="confluence-embedded-image confluence-thumbnail"
src="cxf-architecture.data/service_model.png"></span></p>
-
-<h3 id="CXFArchitecture-DataBindings">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 shape="rect" href="data-binding-architecture.html">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 id="CXFArchitecture-ProtocolBindings">Protocol Bindings</h3>
-
-<p>Bindings provide ways to map concrete formats and protocols on top of
transports. A binding contains two main parts, a <code>BindingFactory</code>
and a <code>Binding</code>. A <code>BindingFactory</code> builds a
<code>Binding</code> from the service model's <code>BindingInfo</code>. The
binding contains interceptors specific to the binding and also implements the
<code>createMessage()</code> method, which creates a <code>Message</code>
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 id="CXFArchitecture-TheSoapBinding">The Soap Binding</h4>
-
-<p>The prototypical binding is SOAP. It has its own <code>Message</code>
class called the <code>SoapMessage</code>. It adds the ability to hold the
current <code>SoapVersion</code> and the headers for the message.</p>
-
-<p>The <code>Soap</code> binding also adds a special type of interceptor
called the <code>SoapInterceptor</code>. The <code>SoapInterceptor</code> adds
two methods to the <code>Interceptor</code> class:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
-Set<URI> getRoles();
+</div></div><h3 id="CXFArchitecture-TheServiceModel">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 <code>ServiceInfo</code> 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
<code>ServiceInfo</code>, 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 <code>ServerFactoryBean</code> and
<code>ClientProxyFactoryBean</code> 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 <c
ode>ServiceInfo</code> class. The following image depicts a subset of the
Service Model's packaged API:</p><p><span
class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image
confluence-thumbnail"
src="cxf-architecture.data/service_model.png"></span></p><h3
id="CXFArchitecture-DataBindings">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 shape="rect"
href="data-binding-architecture.html">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 id="CXFArchitecture-ProtocolBindings">Protocol
Bindings</h3><p>Bindings provide ways to map concrete f
ormats and protocols on top of transports. A binding contains two main parts,
a <code>BindingFactory</code> and a <code>Binding</code>. A
<code>BindingFactory</code> builds a <code>Binding</code> from the service
model's <code>BindingInfo</code>. The binding contains interceptors specific to
the binding and also implements the <code>createMessage()</code> method, which
creates a <code>Message</code> 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
id="CXFArchitecture-TheSoapBinding">The Soap Binding</h4><p>The prototypical
binding is SOAP. It has its own <code>Message</code> class called the
<code>SoapMessage</code>. It adds the ability to hold the current
<code>SoapVersion</code> and the headers for the message.</p><p>The
<code>Soap</code> binding also adds a special type of interceptor called the
<code>SoapInterceptor</code>. The <code>SoapInterceptor</code> adds two
methods to the <code>Interceptor</code> class:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">Set<URI> getRoles();
Set<QName> getUnderstoodHeaders();
</pre>
-</div></div>
-<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>
-<ol><li><code>StaxInInterceptor</code>: Creates an
<code>XMLStreamReader</code> from an incoming
<code>InputStream</code></li><li><code>ReadHeadersInterceptor</code>: Reads the
headers into the
<code>SoapMessage</code></li><li><code>MustUnderstandInterceptor</code>: Checks
the <code>MustUnderstand</code> attributes of all the headers against all the
<code>SoapInterceptor</code>'s <code>getUnderstoodHeaders</code>
method.</li><li><code>SoapOutInterceptor</code>:</li></ol>
-
-
-<h4 id="CXFArchitecture-AdditionalBindings">Additional Bindings</h4>
-<p>Other bindings include REST/HTTP binding, pure XML binding, and the CORBA
binding.</p>
-
-<h3 id="CXFArchitecture-Transports">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 shape="rect"
href="http://cxf.apache.org/docs/transports.html";>here</a>.</p>
-
-<h4 id="CXFArchitecture-Conduits">Conduits</h4>
-
-<p>Conduits provide the basis for outgoing message sending. A
<code>Conduit</code> is created from a <code>ConduitInitiator</code>. Sending a
message is a multistep pocess:</p>
-<ol><li>Call conduit.prepare(message): this starts the message sending. At
this point a <code>Conduit</code> may initiate a connection and set the
OutputStream for the outgoing message.</li><li>Writing of the actual message to
the <code>OutputStream</code></li><li>Call to
<code>conduit.close(message)</code>: this closes and disposes of any existing
resources for the message sending.<br clear="none">
-A message sender may also register a <code>MessageObserver</code> with the
Conduit. If the <code>Conduit</code> is synchronous, the
<code>MessageObserver</code> will be notified once a response has been
received.</li></ol>
-
-
-<h4 id="CXFArchitecture-Destinations">Destinations</h4>
-
-<p>Destinations are the basis for receiving incoming messages. A destination
is created from a <code>DestinationFactory</code>:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
-DestinationFactoryManager dfManager =
bus.getExtension(DestinationFactoryManager.class);
+</div></div><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><ol><li><code>StaxInInterceptor</code>:
Creates an <code>XMLStreamReader</code> from an incoming
<code>InputStream</code></li><li><code>ReadHeadersInterceptor</code>: Reads the
headers into the
<code>SoapMessage</code></li><li><code>MustUnderstandInterceptor</code>: Checks
the <code>MustUnderstand</code> attributes of all the headers against all the
<code>SoapInterceptor</code>'s <code>getUnderstoodHeaders</code>
method.</li><li><code>SoapOutInterceptor</code>:</li></ol><h4
id="CXFArchitecture-AdditionalBindings">Additional Bindings</h4><p>Other
bindings include REST/HTTP binding, pure XML binding, and the CORBA
binding.</p><h3 id="CXFArchitecture-Transports">Transports</h3><p>CXF includes
its own transport abstraction layer to hide transport specific details from the
binding and front end laye
rs. 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
shape="rect" href="http://cxf.apache.org/docs/transports.html";>here</a>.</p><h4
id="CXFArchitecture-Conduits">Conduits</h4><p>Conduits provide the basis for
outgoing message sending. A <code>Conduit</code> is created from a
<code>ConduitInitiator</code>. Sending a message is a multistep
pocess:</p><ol><li>Call conduit.prepare(message): this starts the message
sending. At this point a <code>Conduit</code> may initiate a connection and set
the OutputStream for the outgoing message.</li><li>Writing of the actual
message to the <code>OutputStream</code></li><li>Call to
<code>conduit.close(message)</code>: this closes and disposes of any existing
resources for the message sending.<br clear="none"> A message sender may also
register a <code>MessageObserver</code> with the
Conduit. If the <code>Conduit</code> is synchronous, the
<code>MessageObserver</code> will be notified once a response has been
received.</li></ol><h4
id="CXFArchitecture-Destinations">Destinations</h4><p>Destinations are the
basis for receiving incoming messages. A destination is created from a
<code>DestinationFactory</code>:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">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";);
@@ -317,30 +185,11 @@ DestinationFactory df = dfManager.getDes
EndpointInfo endpointInfo = ...;
Destination destination = df.getDestination(endpointInfo);
</pre>
-</div></div>
-<p>MessageObservers can then be registered with Destinations. These listen for
incoming messages:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
-MessageObserver myObserver = ...;
+</div></div><p>MessageObservers can then be registered with Destinations.
These listen for incoming messages:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">MessageObserver myObserver = ...;
destination.setMessageObserver(myObserver);
</pre>
-</div></div>
-<p>The most common <code>MessageObserver</code> used in CXF is the
<code>ChainInitiationObserver</code>. This takes the incoming message, creates
a message Exchange & <code>PhaseInterceptorChain</code>, then starts the
chain.</p>
-
-<h3 id="CXFArchitecture-AJAX-WSexample">A JAX-WS example</h3>
-
-<p>Here's a small example of what might happen when we publish a service via
the JAX-WS <code>Endpoint.publish()</code> method.</p>
-<ol><li>Call to <code>Endpoint.publish("http://localhost/service";,
myService)</code></li><li>The <code>EndpointImpl</code> creates a Service from
the <code>myService</code> object using the
<code>JaxWsServiceFactoryBean</code> using the class and/or WSDL</li><li>An
<code>EndpointInfo</code> is created for the <code>Endpoint.publish</code>
URL</li><li>A <code>JaxWsEndpointImpl</code> is created from the
<code>EndpointInfo</code>. This contains the JAX-WS endpoint specific
interceptors</li><li>The <code>JaxWsEndpointImpl</code> creates a
<code>Binding</code> and <code>Destination</code> to listen on.</li></ol>
-
-
-<h2 id="CXFArchitecture-Dependencies">Dependencies</h2>
-<p><a shape="rect"
href="http://cxf.apache.org/docs/cxf-dependency-graphs.html";>CXF's
dependencies</a></p>
-
-<h2 id="CXFArchitecture-Quality">Quality </h2>
-<p>CXF's Software Quality approach is detailed <a shape="rect"
href="http://cxf.apache.org/coding-guidelines.html";>here</a>.</p>
-
-<h3 id="CXFArchitecture-References">References</h3>
-<ul><li><a shape="rect" class="external-link"
href="http://en.wikipedia.org/wiki/Software_architecture";
rel="nofollow">Software Architecture</a>, <em>Wikipedia</em></li><li><a
shape="rect" class="external-link"
href="http://www.ecs.csun.edu/~rlingard/COMP684/Example2SoftArch.htm#Logical%20View";
rel="nofollow">Sample S/W Architecture Document</a>, <em>Rational Software
Corporation</em></li><li><a shape="rect" class="external-link"
href="http://www.oreillynet.com/xml/blog/2006/03/documenting_your_software_arch.html";
rel="nofollow">Documenting your Software Architecture</a>, <em>by Jim
Alateras</em> (March 2006)</li></ul></div>
+</div></div><p>The most common <code>MessageObserver</code> used in CXF is the
<code>ChainInitiationObserver</code>. This takes the incoming message, creates
a message Exchange & <code>PhaseInterceptorChain</code>, then starts the
chain.</p><h3 id="CXFArchitecture-AJAX-WSexample">A JAX-WS
example</h3><p>Here's a small example of what might happen when we publish a
service via the JAX-WS <code>Endpoint.publish()</code> method.</p><ol><li>Call
to <code>Endpoint.publish("http://localhost/service";,
myService)</code></li><li>The <code>EndpointImpl</code> creates a Service from
the <code>myService</code> object using the
<code>JaxWsServiceFactoryBean</code> using the class and/or WSDL</li><li>An
<code>EndpointInfo</code> is created for the <code>Endpoint.publish</code>
URL</li><li>A <code>JaxWsEndpointImpl</code> is created from the
<code>EndpointInfo</code>. This contains the JAX-WS endpoint specific
interceptors</li><li>The <code>JaxWsEndpointImpl</code> creates a
<code>Binding</cod
e> and <code>Destination</code> to listen on.</li></ol><h2
id="CXFArchitecture-Dependencies">Dependencies</h2><p><a shape="rect"
href="http://cxf.apache.org/docs/cxf-dependency-graphs.html";>CXF's
dependencies</a></p><h2 id="CXFArchitecture-Quality">Quality</h2><p>CXF's
Software Quality approach is detailed <a shape="rect"
href="http://cxf.apache.org/coding-guidelines.html";>here</a>.</p><h3
id="CXFArchitecture-References">References</h3><ul><li><a shape="rect"
class="external-link" href="http://en.wikipedia.org/wiki/Software_architecture";
rel="nofollow">Software Architecture</a>, <em>Wikipedia</em></li><li><a
shape="rect" class="external-link"
href="http://www.ecs.csun.edu/~rlingard/COMP684/Example2SoftArch.htm#Logical%20View";
rel="nofollow">Sample S/W Architecture Document</a>, <em>Rational Software
Corporation</em></li><li><a shape="rect" class="external-link"
href="http://www.oreillynet.com/xml/blog/2006/03/documenting_your_software_arch.html";
rel="nofollow">Documenting your Softw
are Architecture</a>, <em>by Jim Alateras</em> (March 2006)</li></ul></div>
</div>
<!-- Content -->
</td>
Modified:
websites/production/cxf/content/docs/maven-cxf-codegen-plugin-wsdl-to-java.html
==============================================================================
---
websites/production/cxf/content/docs/maven-cxf-codegen-plugin-wsdl-to-java.html
(original)
+++
websites/production/cxf/content/docs/maven-cxf-codegen-plugin-wsdl-to-java.html
Mon Mar 27 17:47:50 2017
@@ -226,7 +226,7 @@ Apache CXF -- Maven cxf-codegen-plugin (
</includes>
</configuration>
</pre>
-</div></div><p>wsdlRoot default value is <code>src/main/resources/wsdl</code>
so you may omit this declaration.</p><h3
id="Mavencxf-codegen-plugin(WSDLtoJava)-Example6:Loadingawsdlfromthemavenrepository">Example
6: Loading a wsdl from the maven repository</h3><p>For CXF 2.3 and latter
there is a new config element <wsdlArtifact> which can be used to load a
wsdl file from the maven repository.</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>wsdlRoot default value is <code>src/main/resources/wsdl</code>
so you may omit this declaration.</p><h3
id="Mavencxf-codegen-plugin(WSDLtoJava)-Example6:Loadingawsdlfromthemavenrepository">Example
6: Loading a wsdl from the maven repository</h3><p>There is a
<wsdlArtifact> wsdlOption configuration which can be used to load a wsdl
file from the maven repository.</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"> <configuration>
<wsdlOptions>
<wsdlOption>
@@ -342,18 +342,18 @@ Apache CXF -- Maven cxf-codegen-plugin (
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
- <version>2.2</version>
+ <version>2.2.11</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-xjc</artifactId>
- <version>2.2</version>
+ <version>2.2.11</version>
</dependency>
</dependencies>
</plugin>
</pre>
-</div></div><h3
id="Mavencxf-codegen-plugin(WSDLtoJava)-Otherconfigurationoptions">Other
configuration options</h3><p>The cxf-codegen-plugin has some additional
configuration options that may be useful:</p><div class="table-wrap"><table
class="confluenceTable"><tbody><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p><fork>false/always/once</fork></p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>Forks a separate JVM for the
code generation</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p><additionalJvmArgs>....</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>Additional JVM args set on the forked
process if fork is not false</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p><encoding>UTF-8</encoding></p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>(new in 2.6.1, requires
configuring plugin to use very latest JAXB 2.2 impl
jars)</p></td></tr></tbody></table></div></div>
+</div></div><h3
id="Mavencxf-codegen-plugin(WSDLtoJava)-Otherconfigurationoptions">Other
configuration options</h3><p>The cxf-codegen-plugin has some additional
configuration options that may be useful:</p><div class="table-wrap"><table
class="confluenceTable"><tbody><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p><fork>false/always/once</fork></p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>Forks a separate JVM for the
code generation</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p><additionalJvmArgs>....</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>Additional JVM args set on the forked
process if fork is not false</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p><encoding>UTF-8</encoding></p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>(new in 2.6.1, requires
configuring plugin to use very latest JAXB 2.2.11 impl
jars)</p></td></tr></tbody></table></div></div>
</div>
<!-- Content -->
</td>
![https://cwiki.apache.org/confluence/download/attachments/44806/MessageFlowOnClientSide.png?version=4&modificationDate=1298215366000&api=v2"](https://cwiki.apache.org/confluence/download/attachments/44806/MessageFlowOnClientSide.png?version=4&modificationDate=1298215366000&api=v2"){kind=link}
![https://cwiki.apache.org/confluence/download/attachments/44806/MessageFlowOnServerSide.png?version=4&modificationDate=1298310696000&api=v2"](https://cwiki.apache.org/confluence/download/attachments/44806/MessageFlowOnServerSide.png?version=4&modificationDate=1298310696000&api=v2"){kind=link}