A standard request-reply scenario. An XML message request is transformed and the result is sent back to the original consumer of the XSLT endpoint. The sequence of events include:

• XML message in
• XSL transformation of message
• Transformed result out

A standard one-way invocation. An XML message request is transformed, and the result is sent (not to the original consumer but rather) to another endpoint in the JBI environment. The sequence of events include:

• XML message in
• XSL transformation of message
• Transformed result out to third party

A representation of the adapter pattern, this scenario applies two separate XSL transformations. This scenario is useful when there are two existing web services (having incompatible input and output) which must be integrated.

The first existing service acts as a consumer to the XSLT endpoint, sending a request. This message is transformed to match the input of the second service.

The second service is then invoked in an asynchronous manner. When the response from the second service arrives via the NMR, it is transformed to match the expected reply to the first (consuming) service. The sequence of events include:

• XML message in
• XSL transformation of message using first XSL style sheet
• Invoke service, sending transformed message as input
• Receive response from invoked service endpoint
• XSL transformation of response using second XSL style sheet
• Reply to original sender with transformed third party response

<xsltmap>
  <requestReplyService>
    <input partnerLink="{foo}pl0" 
      roleName="server" 
      portType="portType" 
      operation="operation" 
      messageType="{ns}msg-name" 
      file="map.xsl" 
      transformJBI="false" />
  </requestReplyService>

<filterOneWay>
  <input partnerLink="{foo}pl1" 
    roleName="server"
    portType="portType" 
    operation="operation" 
    messageType="{ns}msg-name 
    file="map.xsl" />
    transformJBI="false" /> 
  <output partnerLink="{bar}pl2"
    roleName="client" 
    portType="outPortType" 
    operation="outOp" /> 
  </filterOneWay>

<filterRequestReply> 
  <input partnerLink="{foo}pl1" 
    roleName="server" 
    portType="portType" 
    operation="operation" 
    messageType="{ns}msg-name"
    file="map.xsl"
    transformJBI="false" />
  <output partnerLink="{bar}pl2"
    roleName="client"
    portType="outPortType"
    operation="outOp"
    messageType="{ns}msg-name"
    file="map2.xsl"
    transformJBI="false" />
  </filterRequestReply>
</xsltmap>

To support multiple-part WSDL 1.1 message definitions, the JBI specification defines an XML document format for “wrapping” WSDL 1.1 message parts. Since the XSLT Service Engine does not lend itself to transforming multiple message parts, the XSLT SE instead supports the transformation of the entire JBI message wrapper. To enable this transformation, the transformJBI attribute flag must be set to true; the default value is false if the attribute is not specified in the xsltmap.xml file.

It is important to note that when this attribute is set to true, the XSL style sheet MUST generate a properly formed JBI message wrapper document. Failure to do so will result in mishandled message exchanges. As noted in the Java Business Integration (JBI) 1.0 specification, the wrapping of message parts allows both consumer and provider to interact using this well-known mapping to a “wrapped doc-literal” form of the message that is used for normalized message content.

A wrapped literal document must conform to the schema given in the listing below.

default namespace jbi = "http://java.sun.com/xml/ns/jbi/wsdl-11-wrapper"
start =
element message {
attribute version { xsd:decimal },
attribute type { xsd:QName },
attribute name { xsd:nmtoken }?,
part*
}
part =
element part {
# part value
( (element* { text }) | text)
} 

See the Java Business Integration (JBI) 1.0 specification for additional information on the normalized message context schema for wrapper document for WSDL 1.1-defined messages.

To eliminate the need of parsing the WSDL to determine the output message definition (as it is required in a JBI message wrapper), this attribute must be specified for all non-JBI transformations. That is, if the 'transformJBI' attribute is "false", then the 'messageType' attribute MUST be specified. The value of this attribute usually takes the form: {msg-def-ns}msg-def.

Due to a dependency on the design-time XSLT project (part of the NetBeans IDE), XSLT service units used outside the NetBeans environment do not benefit from the functionality built into the XSLT project. Specifically, the generation of the SU's jbi.xml file and the creation of a distributable/deployable SU must be done manually.