This presentation is a primer on WSDL Bindings. It s part of our series to help prepare you for creating BPEL projects. We recommend you review this presentation before taking an ActiveVOS course or before you use the ActiveVOS Designer. Before you view this presentation, we recommend that you review the Schema and WSDL Primers, also available from Active Endpoints. 1
This primer is a continuation of the series that began with the Schema and WSDL Primers. It is intended to give you a chance to review and refresh your knowledge of these topics before taking an ActiveVOS training class or using the ActiveVOS Designer. We recommend that you have at least this basic knowledge of these topics before taking a class from Active Endpoints or using the ActiveVOS products. 2
This slide shows the structure of a WSDL document. The definitions section of a WSDL file can be conceptually divided into two sections, the Abstract and the Concrete: The Abstract section defines the Interface to a Web Service and contains the messages and operations provided by the Web Service. The Concrete section defines the Web Service Implementation. The Bindings define how a PortType is accessed and how the messages are formatted. This includes the transport mechanism and the payload format. The Bindings are then bound to one or more Endpoint References i.e., URLs - to form a Service. During design time BPEL is concerned with abstract definitions. We concern ourselves with the concrete aspects of WSDL when the process is deployed and executed. 3
Before we begin our examination of WSDL Bindings, let's quickly review the WSDL basics. Types and elements used in a WSDL file are defined in Schema (.xsd) files. The Messages that are exchanged with our partner services are defined using either simple schema types or user-defined types and elements. These messages serve to exchange the data used by the operations. The operations are grouped into porttypes and the porttypes are bound to specific message protocols and packaging through the use of bindings. 4
The purpose of a WSDL binding is to wrap a message in a known package type (for example, SOAP) and to allow it to be transported to/from a partner using a known protocol (for example, HTTP). A single porttype can have multiple bindings, because its operations can be called by many different partners, each using its own message format and protocol. WSDL includes built-in extensions for defining SOAP based Web Services. 5
A SOAP binding has two arguments that define the form of the message: Style and Use. The Style argument defines how the SOAP body is structured (RPC or Document) and the Use argument defines the encoding rules (Encoded or Literal). 6
There are two values available for the "style" attribute: RPC and Document. An RPC structure places the message inside a wrapper that is named after the Operation and namespace that the Operation is defined in. A Document style messages is constructed with just the contents of the WSDL message itself, as defined by the message s schema definition. 7
The "use" attribute declares whether the message parts are encoded, using some encoding rules, or defined by a schema. If they are Encoded they represent the data according to a defined set of rules that can be found at the URL shown in the "encoding style." If they are Literal they follow an XML schema definition type that defines the SOAP message payload. 8
The WS-Interoperability (or WS-I) Basic Profile defines a number of profiles that clarify certain Web Service specifications such as WSDL and XML Schema. This Basic Profile defines acceptable style/use pairs and their abstract definitions. Conformance with WS-I Basic Profile is intended to enhance interoperability between Web Service stacks. 9
This diagram shows the generic structure of a WSDL binding. Notice that for every WSDL element we must have a corresponding non-wsdl element defined. This is where the non- WSDL extensions, such as SOAP extensions are defined. The next slide shows an example that uses the SOAP extensions in this manner. 10
This slide shows how each of the WSDL definitions are bound with a non-wsdl extension, for instance we have bound a wsdl:binding with a soap:binding, a wsdl:operation with a soap:operation. If we didn t want to use a soap:binding we would simply replace the SOAP extensions with the non-wsdl extensions of our choice. 11
Here is the code view of the diagram on the previous slide. For clarification the WSDL definitions are shown in black and the non-wsdl extension definitions, in this case SOAP extensions, are shown in red. If we take a closer look at the SOAP binding, we see that "rpc" is defined as the style and "HTTP" is being used as the transport mechanism. If we look closer at the soap:body we see that the use attribute is set to "encoded". The encoding that is used is defined by the encodingstyle attribute. 12
This slide is showing the WSDL definitions for the two different styles of SOAP bindings that we saw earlier. On the left are RPC/Literal and RPC/Encoded definitions and on the right is an example of the Document style. All three examples are defining the same request-response operation with the same message names. However, in order to be WS-I compliant, the RPC style message parts are defined using schema types and the document style is defined using schema elements. 13
The slide shows what the messages look like for each of the three definitions we saw on the previous slide. On the left side notice that both RPC messages contain the name of the operation as the root element within the soap:body. Following the operation name comes an element with the name of the message part defined for the wsdl:message. Notice that in the RPC/Encoded example a type attribute is added to the name of the message part element. The Document example, shown on the right, does not contain the name of the wsdl:operation in the soap:body. The contents of the soap:body simply uses the literal contents of the element defined in the wsdl:message part definition. 14
Now that you have completed this Primer on WSDL Bindings, check the Active Endpoints website for other materials to help you with your BPEL projects. As a reminder, Primers are available in PDF format from Active Endpoints. To find out more about Schema, WSDL or other BPEL-related topics, go to the Active Endpoints website at the address shown on this slide. 15