After you have created the collaboration object and bound its triggering port to an instance of a web services connector, you are ready to use the WSDL Configuration Wizard. Using binding, port name, operation and other data you specified for the collaboration, business object definition, and connector, the utility produces the a WSDL implementation file (*.impl.wsdl), a WSDL interface file (*.wsdl), and an xml schema file (*.xsd). These files are a composite of the collaboration exposed as a web service, and the utility allows you to specify whether to generate these as separate files or as one file. The utility supports SOAP over HTTP, HTTPS, and JMS protocols. Configuration information for the protocol listener framework is retrieved from the connector-specific property ProtocolListenerFramework. This property also makes the list of listeners available.
To run the WSDL Configuration Wizard:
Figure 58. WSDL Configuration Wizard
As shown in Figure 58, the columns are as follows:
The configuration wizard creates a WSDL operation for each triggering port of a collaboration object that is bound to a web services connector. The creation of the operation is based on the business objects that are associated with the invocation of this collaboration.
The configuration wizard determines that a business object is in the TLO format by reading the object-level ASI ws_eventtlo. If the ASI property is set to true, the business object is a TLO. Using the TLO, the following WSDL properties are found:
To create WSDL operations based on TLOs, a collaboration can be configured in two ways, with and without maps.
A collaboration is generally configured to accept Generic Business Object (GBO) requests. That is, the collaboration template triggering ports subscribe to GBOs. To use TLOs in this case, the collaboration must be bound to a web services connector, and the connector must support the transformation of the GBO to TLOs via maps. Figure 59 shows this scenario.
When the collaboration and connector are configured in this way, the wizard determines that the TLO business object will be used to create the operations described in the WSDL document. This determination is made by inspecting the connector-supported business objects and associated maps. It is important for the run-time processing of the web services connector that the configured maps always transform the collaboration's GBO to one and only one TLO. Also, it is important that the source and destination business objects of the inbound map translate to the destination and source business objects of the outbound map, respectively.
The wizard also supports processing TLOs without maps. In this case, the collaboration template's triggering ports subscribe to TLOs directly. Because the web services connector supports the TLOs, maps are not required. Figure 60 illustrates this scenario.
When the collaboration and connector have been configured in this way, the wizard uses the TLO business object found in the collaboration to create the operations described in the WSDL document. The wizard determines that no maps are configured for this port.
Support for non-TLO business objects allows you to use pre-existing collaborations and maps for exposing as web services. For this reason the wizard also supports creating WSDL operations using business objects that are not in TLO format.
Similar to the TLO process, the wizard determines that a business object is in non-TLO format by reading the object-level ASI ws_eventtlo. If the ASI property does not exist or exists but is set to something other than true, this business object is a non-TLO. A non-TLO is any business object that does not adhere to the web services TLO structure. Using the non-TLO, the wizard discovers the following properties:
To create WSDL operations based on non-TLOs, a collaboration can be configured in two ways, with and without maps.
Collaborations are generally configured to accept Generic Business Object (GBO) requests. At the same time, there may be pre-existing maps that transform the GBO from the collaboration to a non-TLO business object. Figure 62 shows this scenario.
In this case, the wizard uses the non-TLO business object to create WSDL operations described in the WSDL document. It is important for the run-time processing of the web services connector that the configured maps always transform the collaboration's GBO to one and only one non-TLO. Also, it is important that the source and destination business objects of the inbound map translate exactly to the destination and source business objects of the outbound map respectively.
In highly specialized cases, collaborations may be configured to accept requests from business objects other than GBOs. In this case, the non-TLO is a direct business object for the collaboration, and no maps exist. Figure 63 shows this scenario.
Figure 63. Non-TLO without map
In this case, the wizard determines that no maps are configured for this port, so it uses the non-TLO business object to create WSDL operations described in the WSDL document.
The sections below discuss requirements of the WSDL Configuration Wizard that apply to all types of objects (TLOs and non-TLOs) unless otherwise explicitly mentioned. For further information on business object requirements for web services TLOs, see Business object requirements.
The WSDL Configuration Wizard supports the Use property in SOAP Config MOs, but throws an error if the Use value in a SOAP Request BO and the corresponding SOAP Response BO are different. You can set the Use value to literal or encoded to generate a WSDL document. For more information on the Use property and its values, see Style and Use impact on SOAP messages.
Only rpc style is supported for exposing collaborations as web services. If the Style is specified as document in the SOAP Config MO, the wizard will throw an error.
The details attribute inside a SOAP Fault business object can have one child attribute only. Otherwise, the utility generates an error.
The utility accepts Fault business objects. If it encounters multiple Fault business objects, the utility processes the header container of the first or default fault business object. Processing is as follows:
A header fault is processed as soap:headerfault, a child element of soap:header inside the WSDL document binding section. The header fault is processed using the headerfault ASI specified in the header child business object as follows:
Multiple header attributes are specified as SOAP header child business objects inside a SOAP header container business object. A Header container business object is identified by its ASI: soap_location=SOAPHeader. During utility processing, a soap:header element is created inside binding section for each of the attributes inside the header container business object and the following rules apply:
The utility ignores elem_ns ASI at the message part level. Instead, elem_ns is used in second- and lower-level attributes. Second- level business object attributes can be defined in a separate namespace if elem_ns is specified.
SOAP/JMS binding in the port section of the WSDL document contains the jms:address element. The following is an example of jms:address element. (Attributes suffixed with "?" are optional).
<jms:address destinationStyle = "queue" jmsVendorURI = "http://ibm.com/ns/mqseries"? initialContextFactory = "com.ibm.NamingFactory"? jndiProviderURL = "iiop://something:900/wherever"? jndiConnectionFactoryName = "orange" jndiDestinationName = "fred"
jmsProviderDestinationName="trash" />
If the LookupQueuesUsingJNDI connector property is set to true, the value of InputQueue property corresponds to the jndiDestinationName attribute of the jms:address element of the SOAP/JMS binding. The jms:address element is specified in the wsdl:port section. If LookupQueueUsingJNDI is set to false, then the jmsProviderDestinationName attribute is set to InputQueue. InputQueue is the connector property available under the Listener_JMS hierarchical property. The initialContextFactory, jndiProviderURL and jndiConnectionFactoryName properties will be specified only for synchronous processing.
A sample port section from a WSDL document is shown below:
<service name="StockQuoteWebService"> <port name="StockQuoteWebServicePort" binding="intf:StockQuoteBinding"> <soap:address location="http://localhost:8080/wbia/webservices/stockquoteservice"/> </port> </service>
The WSDL Configuration Wizard uses the value of host name and the port from the context path. If the context path contains only the relative path without the host name and port, then the value of host name and port property located under the Listener_HTTP configuration property will be used to specify the location attribute in soap:address xml element.