JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Java CAPS XSLT Editor User's Guide     Java CAPS Documentation
search filter icon
search icon

Document Information

Using the XSLT Editor

About the XSLT Service Engine

XSLT Service Engine Features

Request-Reply (requestReplyService)

Invoke-Send (filterOneWay)

Request-Invoke-Reply Chain (filterRequestReply)

Runtime Properties

Starting the Application Server

To Start the GlassFish Application Server

Viewing Service Engine Properties

To View XSLT Service Engine Properties

Runtime Property Descriptions

Configuring the XSLT Service Engine

Use Case 1

Use Case 2

Configuring the XSLT Service Engine

transformJBI attribute

messageType attribute

XSLT Service Engine Component Limitations -- Running the JBI Runtime Separately

Configuring the XSLT Service Engine

No special knowledge of XSL is required to configure an XSLT service unit. The only requirements are a WSDL, an XSL style sheet, and the XSLT map configuration file.

The creation of the WSDL — defining the service, port type, and creating the binding information for the service definition — is a separate step from the XSLT map configuration file. Properly configuring an XSLT service unit means understanding what pieces to migrate from the WSDL into the XSLT map file.

XSLT Projects contain a configuration file called xsltmap.xml . Most of the information needed to configure an XSLT Project as a JBI service unit is contained in a WSDL, which defines the operation an XSLT transformation is implementing. A sample configuration follows:

Use Case 1

<xsltmap>                                            <--Names partnerlink defined in deployed WSDL
                <requestReplyService>                        <-- Matches partnerLink role name
                    <input partnerLink="{foo}p10"        <-- Matches partnerLink portType name
                        roleName="server"                       <-- Operation this transformation implements
                        portType="portType"                    <-- Identifies reply message definition in deployed WSDL
                        operation="operation"                <-- The transformation applied to request
                        messageType="{ns}msg-name"        <-- See details below
                        file="map.xsl"
                        transformJBI="false" />
                </requestReplyService>

Use Case 2

<filterOneWay>                        <--Names partnerlink defined in deployed WSDL
              <input partnerLink="{foo}p11"            <--Matches partnerLink role name
                    roleName="server"                           <--Matches partnerLink portType name
                    portType="portType"                        <--Operation this transformatino implements
                    operation="operation"                    <--Identifies transformed message definition in 
                                                  deployed WSDL
                    messageType="{ns}msg-name                <--The transformation applied to request
                    file="map.xsl" />                           <--See details below
                    transformJBI="false" />                <--Names partnerLink of operation to invoke
                <output partnerLink="{bar}p12"            <--Matches named partnerLink
                    roleName="client"                           <--Matches portType of operation to invoke
                    portType="outPortType"                    <--Operation to invoke/send transformed request
                    operation="outOp" />
            </filterOneWay>

Configuring the XSLT Service Engine

<filterRequestReply>                <--Names partnerlink defined in deployed WSDL
              <input partnerLink="{foo}p11"            <--Matches partnerLink role name
                    roleName="server"                           <--Matches partnerLink portType name
                    portType="portType"                        <--Operation this transformatino implements
                    operation="operation"                    <--Identifies transformed message definition in 
                                                  deployed WSDL
                    messageType="{ns}msg-name                <--The transformation applied to request
                    file="map.xsl" />                           <--See details below
                    transformJBI="false" />                <--Names partnerLink of operation to invoke
                <output partnerLink="{bar}p12"            <--Matches named partnerLink
                    roleName="client"                           <--Matches portType of operation to invoke
                    portType="outPortType"                    <--Operation to invoke/send transformed request
                    operation="outOp" />                    <--Identifies reply message definition in 
                                                  deployed WSDL
                    messageType="{ns}msg-name"            <--Transformation applied to response from 
                                                   invoked operation
                    file="map2.xsl"                            <--See details below
                    transformJBI="fales" />
                </filterRequestReply>
            </xsltmap>

transformJBI attribute

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 Service Engine 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.

messageType attribute

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 .

XSLT Service Engine Component Limitations — Running the JBI Runtime Separately

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 service unit's jbi.xml file and the creation of a distributable/deployable service unit must be done manually.