The extensions used to describe XML format bindings are defined in the namespace
http://cxf.apache.org/bindings/xformat. Fuse Services Framework tools use the prefix
xformat to represent the XML binding extensions. Add the following line to your contracts:
xmlns:xformat="http://cxf.apache.org/bindings/xformat"
To map an interface to a pure XML payload format do the following:
Add the namespace declaration to include the extensions defining the XML binding. See XML binding namespace.
Add a standard WSDL
bindingelement to your contract to hold the XML binding, give the binding a uniquename, and specify the name of the WSDLportTypeelement that represents the interface being bound.Add an
xformat:bindingchild element to thebindingelement to identify that the messages are being handled as pure XML documents without SOAP envelopes.Optionally, set the
xformat:bindingelement'srootNodeattribute to a valid QName. For more information on the effect of therootNodeattribute see XML messages on the wire.For each operation defined in the bound interface, add a standard WSDL
operationelement to hold the binding information for the operation's messages.For each operation added to the binding, add the
input,output, andfaultchildren elements to represent the messages used by the operation.These elements correspond to the messages defined in the interface definition of the logical operation.
Optionally add an
xformat:bodyelement with a validrootNodeattribute to the addedinput,output, andfaultelements to override the value ofrootNodeset at the binding level.
![]() | Note |
|---|---|
If any of your messages have no parts, for example the output message for an operation that returns void, you must set
the |
When you specify that an interface’s messages are to be passed as XML documents, without a SOAP envelope, you must take care to ensure that your messages form valid XML documents when they are written on the wire. You also need to ensure that non-Fuse Services Framework participants that receive the XML documents understand the messages generated by Fuse Services Framework.
A simple way to solve both problems is to use the optional rootNode attribute on either the
global xformat:binding element or on the individual message’s
xformat:body elements. The rootNode attribute specifies the QName for
the element that serves as the root node for the XML document generated by Fuse Services Framework. When the
rootNode attribute is not set, Fuse Services Framework uses the root element of the message part as the root
element when using doc style messages, or an element using the message part name as the root element when using rpc style
messages.
For example, if the rootNode attribute is not set the message defined in
Example 6.1 would generate an XML document with the root element lineNumber.
Example 6.1. Valid XML Binding Message
<type ... > ... <element name="operatorID" type="xsd:int"/> ... </types> <message name="operator"> <part name="lineNumber" element="ns1:operatorID"/> </message>
For messages with one part, Fuse Services Framework will always generate a valid XML document even if the
rootNode attribute is not set. However, the message in Example 6.2 would generate
an invalid XML document.
Example 6.2. Invalid XML Binding Message
<types> ... <element name="pairName" type="xsd:string"/> <element name="entryNum" type="xsd:int"/> ... </types> <message name="matildas"> <part name="dancing" element="ns1:pairName"/> <part name="number" element="ns1:entryNum"/> </message>
Without the rootNode attribute specified in the XML binding, Fuse Services Framework will generate an
XML document similar to Example 6.3 for the message defined in Example 6.2. The generated XML
document is invalid because it has two root elements: pairName and
entryNum.
If you set the rootNode attribute, as shown in Example 6.4 Fuse Services Framework will
wrap the elements in the specified root element. In this example, the rootNode attribute is defined for
the entire binding and specifies that the root element will be named entrants.
Example 6.4. XML Binding with rootNode set
<portType name="danceParty"> <operation name="register"> <input message="tns:matildas" name="contestant"/> </operation> </portType> <binding name="matildaXMLBinding" type="tns:dancingMatildas"> <xmlformat:binding rootNode="entrants"/> <operation name="register"> <input name="contestant"/> <output name="entered"/> </binding>
An XML document generated from the input message would be similar to Example 6.5. Notice that the XML document now only has one root element.
Example 6.5. XML Document generated using the rootNode attribute
<entrants>
<pairName>
Fred&Linda
<entryNum>
123
</entryNum>
</entrants>You can also set the rootNode attribute for each individual message, or override the global
setting for a particular message, by using the xformat:body element inside of the message binding. For
example, if you wanted the output message defined in Example 6.4 to have a different root element from the input
message, you could override the binding's root element as shown in Example 6.6.
Example 6.6. Using xformat:body
<binding name="matildaXMLBinding" type="tns:dancingMatildas"> <xmlformat:binding rootNode="entrants"/> <operation name="register"> <input name="contestant"/> <output name="entered"> <xformat:body rootNode="entryStatus" /> </output> </operation> </binding>






![[Note]](imagesdb/note.gif)


