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^TM 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.