Page History
...
Our WSDL consists of five major sections:
- TypesAppendix 1 - Writing your own WSDL#Types - A container for data type definitions used by the web service
- MessageAppendix 1 - Writing your own WSDL#Message - A typed definition of the data being communicated
- PorttypeAppendix 1 - Writing your own WSDL#Porttype - A set of operations supported by one or more endpoints
- BindingAppendix 1 - Writing your own WSDL#Binding - A protocol and data format specification for a particular port type
- ServiceAppendix 1 - Writing your own WSDL#Service - The service definition
...
The message section describes the input and output data for each service operation. Each message contains one or more parts. A part can be compared to the parameters of a function call in a traditional programming language. An example of an input and output message with one message part is given below.
| Code Block | ||
|---|---|---|
| ||
<wsdl:message name="Input"> <wsdl:part name="InputData" element="MyTypeDef:TeacherInfo"/> </wsdl:message> <wsdl:message name="Output"> <wsdl:part name="OutputData" element="MyTypeDef:StudentInfo"/> </wsdl:message> |
All input and output messages that are used by your service operations are specified in a message section. Input and output messages can be used by multiple operations.
During import of the WSDL file in the Studio, singlevalued Request and Response entities are created. The name of the message part is used as name for the relation between these generated entities and the type specified in the message.
The element refers to an element in the XSD file. The input and output message part can refer to the same or two different elements. Because of WSI-BP 1.2 compliancy the messages must refer to an element in the XSD and not directly to a simple or complex type.
| UI Text Box | ||
|---|---|---|
| ||
The prefix MyTypeDef refers to the XSD namespace in this example. |
Porttype
The portType element is the most important WSDL element. It describes a web service, the operations that can be performed, and the messages that are involved.
The portType element can be compared to a function library (or a module, or a class) in a traditional programming language.
| Code Block | ||
|---|---|---|
| ||
<wsdl:portType name="PortType">
<wsdl:operation name="DoSomething">
<wsdl:input message="tns:Input" name="Input"/>
<wsdl:output message="tns:Output" name="Output"/>
</wsdl:operation>
</wsdl:portType> |
The name of the portType is not really important for the Studio model. The name of the operation is used as prefix for the name of the generated request and response entities. In the example this would result in the entities DoSomethingRequest and DoSomethingResponse
The input and output messages refer to the messages defined in the 'message' section of the WSDL definition. Each operation can refer to exactly one input and one output message.
...
For Blueriq as a Service we first develop our WSDL and XSD file and generate the Studio domain model based on the XSD file rather than creating the model in the Studio. If the domain model is generated properly we know that the XSD file is valid.
In this section we will describe the various Blueriq domain model structures and how to model them in the XSD file.
The studio elements that can be generated using the XSD file are:
Entity
...
Now that we specified two related entities we are going to add some attributes to the entities. Suppose we want to add attributes to the Teacher entity. We can do that by simply adding attributes to the complex type definition. Each attribute has a name and type. The primitive types like string, integer, date etc. are specified in the W3C XML schema and therefore get the xsd namespace as a prefix.
| UI Text Box | ||
|---|---|---|
| ||
Which prefix should be used to refer to the XML scheme namespace is specified in the XSD header. In the example we use the prefix xsd. |
| Code Block | ||
|---|---|---|
| ||
<xsd:complexType name="Teacher">
<xsd:sequence>
<xsd:element name="TeachesStudents" type="MyTypeDef:Student" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="SocialSecurityNumber" type="xsd:string" use="required"/>
<xsd:attribute name="EmployeeNumber" type="xsd:integer" use="required"/>
</xsd:complexType> |
These type of attribute definitions will result in single value attributes in the Studio domain model. We specified a use option with the value required. Adding this option has no impact on the generated model, but a business engineer can now see that these attributes are required and he should add validation rules to the operation's input message. This way the service will send an error message when the attributes are omitted from the request.
If we would want to add multivalue attributes we would specify them as an element in the sequence part of the complexType definition. We use elements for multivalue attributes because an element has the minOccurs and maxOccurs options.
...
Overview
Content Tools