So how does a BOD Specific WSDL look when implementing the STAR Web Services Transport? STAR includes with the XML Schemas for STAR 5 the BOD Specific WSDL for all the BODs. These are grouped by the recommended Verb and Noun pairing outlined in the Verb Usage Guidelines available on the STAR Website. The WSDL files may be found in the following directory:

Figure 5.1. WSDL Directory Structure

There are roughly about 60 WSDL definition files, and these are automatically generated with the base information necessary for minimum compliance with the STAR Web Services transport. These WSDL files do not implement any of the Security, or Reliable Messaging that may be needed by a particular implementation. They are provided as templates for users to update for their particular requirements.

Figure 5.2. BOD Specific Service and Operations

On the surface, there is little difference between the structure of the BOD Specific WSDL and a generic transport. You still have operations, transport types, bindings, messages, and services. The root soap body elements that carry the payload are still the same, and the manifest information that is transmitted is the same as well. These all have to be the same for both a generic and BOD specific WSDL to be able to interoperate with each other.

Differences start to show once you reach the definition of the elements that make up the operation as shown in the figure belowFigure 19.

Figure 5.3. BOD Specific Process Message Definition

A BOD specific WSDL will refer to a very strongly typed definition for the payload element. This allows the WSDL to fully describe the type of content expected to be sent with the type of operation that is being invoked. Further, the payload element itself describes the type of BOD to be carried and the multiplicity of the content.It also describes where attachment data should occur and in what order the payload information should be sent.

Figure 5.4. BOD specific strongly typed payload

If schema validation is performed and the information does not appear in the order that is specified, a SOAP fault must be returned before the information ever reaches the receiving application.