The author: Carlos C. Tapang
Infotects
July 2001
Absrtact: As long as WSDL is used, that is, it is possible to automatically generate Proxy for Web services in a way that is truly not restricted by language and platform. (Total 28 pages printed)
Content
Reasons to use WSDL
WSDL file Structure
WSDL Case File
Name space
SOAP messages
Description of the XML structure in the WSDL type and Information section
<portType> <operation> Elements
<binding> <operation> Elements
File type
<service> <port> Elements
Total
Resource
Reasons to use WSDL
The standard of the Web communication protocol, in the end, is enforced by a certain authority; or do people really think that the advantage of being true is the price that must be paid? Many of the standards that have been put forward are endless. There are times when the standards that are not used by the public, laws or government rules are still hard to use: like, Ada programming language.
I believe that the point at which standards can be gained is the reason why standards are universal. For example, the point of the railroad service is that even the rails of different companies can be connected together, that is to say, the products of different companies must be integrated. As a result, several manufacturers have launched the SOAP standard together. WSDL (Web services Description Language, Network Service description) easily brings together the network service provider and service users, and easy access to the SOAP's advantages. The train rails built by different companies are easier to integrate; After all, it is necessary to agree on the distances between the two rails. But the situation is much more complicated for web services. The first thing that must be achieved is to specify the standard format of the interface.
One point has always been that SOAP does not require an interface to describe language. If SOAP is purely a standard for communication, then what it needs is a language that describes the content. SOAP messages can actually be used to transmit type information, so soap allows you to decide the type in an active way. But unless you know the name, the parameters, and the type of the function, there is no way to actually call any function. If you do not use WSDL, you can make sure that the call is made from the file you provide or check the line messages. But both of these methods require human intervention and may therefore be a mistake in the process. If you use WSDL, you can automatically generate Proxy for Web services in a way that is truly not restricted by language and platform. Like a CORBA or COM IDL file, the WSDL file is also a contract between the client and the server.
Note that although the design of WSDL is intended to be a link to a communication protocol other than soap, the purpose of this article is to have a WSDL connected to soap on HTTP. And although the primary use of SOAP is a remote program or a call to a function, the WSDL can specify the transferred file under SOAP. WSDL 1.1 has been submitted to the Consortium in the form of note (Notice book) (please refer to http://www.w3.org/TR/wsdl.html).
WSDL file Structure
The map is helpful if you want to understand any XML file. The following diagram illustrates the structure of the WSDL; it is an XML file that shows the relationship between the five sections of the WSDL file.
The WSDL file can be divided into two groups of sections. The upper group is composed of abstract definition (abstraction definitions), and the lower group is composed of defined (concrete descriptions). The way to define SOAP messages in an abstract section is to exclude the limitations of the platform and language, so that they do not contain any specific elements of the computer or language. In this way, different Web sites can be used as a service of its definition. Specific information such as serialization, and so on, is handled in the next section with a description of the body.
Abstract definition
Types (Type)
Not subject to the definition of computer and language restrictions.
Messages (information)
Contains function parameters (input and output separation) or file description.
Porttypes (port type)
According to the message definition in the Messages area, we explain the function signature (name, input, input parameters).
Defining
Bindings (link)
In the Porttypes section, specify the link for each business.
Services (Service)
Specifies the port address of each link.
In the diagram, the arrows are connected, and there is a connection between the different sections of the file. The point is connected to the arrow to represent a "reference" or "use" relationship. The arrows connect to represent the "modify (modifier)" relationship. The arrows connect to represent the "inclusive (contains)" relationship. Therefore, the Messages area uses the definition of the Types area, the definition of the Messages area in the Porttypes area, the bindings section in the Porttypes section, and the Services section in the Bindings section. The Porttypes and bindings sections contain the operating elements, while the Services section contains the port elements. The bindings element in the section will modify or further explain the operating elements in the Porttypes section.
As a basis, this article will use standard XML technology to explain the WSDL file. The term "element" refers to an XML element, and the term "attributes" refers to the element nature. So:
<element attribute= "Attribute-value" >contents</element>
The content can be transferred in a way that consists of more than one element. The root element is the top-most element, and all other elements in the file are under it. Child elements are permanently attached to other parent elements.
Please note that there is only one Types area, or even no such section at all. All other sections can have 0 or one, or more, parent elements. For example, the Messages section can have 0, or more <message> elements. The WSDL structure description rules that all sections must be arranged in order: Inbound, type, message, PortType, link, and service. Each abstract section may be located in a different file and will be transferred to the main document.
[Chart 1] abstract and defining
WSDL Case File
Now please delve into the WSDL case file to view its structure and workings. Please remember that this is a very simple example of a WSDL file. Its purpose is only to explain the most obvious function. The following sections have more detailed discussions.
<?xml version= "1.0" encoding= "UTF-8"?>
<definitions name= "Foosample"
Targetnamespace= "http://tempuri.org/wsdl/"
Xmlns:wsdlns= "http://tempuri.org/wsdl/"
Xmlns:typens= "Http://tempuri.org/xsd"
Xmlns:xsd= "Http://www.w3.org/2001/XMLSchema"
xmlns:soap= "http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:stk= "Http://schemas.microsoft.com/soap-toolkit/wsdl-extension"
xmlns= "http://schemas.xmlsoap.org/wsdl/" >
<types>
<schema targetnamespace= "Http://tempuri.org/xsd"
Xmlns= "Http://www.w3.org/2001/XMLSchema"
Xmlns:soap-enc= "http://schemas.xmlsoap.org/soap/encoding/"
Xmlns:wsdl= "http://schemas.xmlsoap.org/wsdl/"
elementformdefault= "qualified" >
</schema>
</types>
<message name= "Simple.foo" >
<part name= "arg" type= "Xsd:int"/>
</message>
<message name= "Simple.fooresponse" >
<part name= "Result" type= "Xsd:int"/>
</message>
<porttype name= "Simpleporttype" >
<operation name= "foo" parameterorder= "arg" >
<input message= "Wsdlns:Simple.foo"/>
<output message= "Wsdlns:Simple.fooResponse"/>
</operation>
</portType>
<binding name= "simplebinding" type= "Wsdlns:simpleporttype" >
<stk:binding preferredencoding= "UTF-8"/>
<soap:binding style= "RPC"
transport= "Http://schemas.xmlsoap.org/soap/http"/>
<operation name= "foo" >
<soap:operation
soapaction= "Http://tempuri.org/action/Simple.foo"/>
<input>
<soap:body use= "encoded" namespace= "http://tempuri.org/message/"
encodingstyle= "http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output>
<soap:body use= "encoded" namespace= "http://tempuri.org/message/"
encodingstyle= "http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>
</binding>
<service name= "Foosampleservice" >
<port name= "Simpleport" binding= "wsdlns:simplebinding" >
<soap:address location= "http://carlos:8080/FooSample/FooSample.asp"/>
</port>
</service>
</definitions>
The following is a brief description of this sample document. Later, we will discuss each section in detail.
The first line declares that this file is XML. Although it is not necessary, it can help the XML parser decide whether to parse this WSDL file or to produce a bug. The second line is the root element:<definitions> in the WSDL file. There are several named space declarations, which are attached to this root element and to the <schema> child elements of the <types> element.
<types> elements are composed of types sections. If no data type is to be declared, this section can be omitted. In the example WSDL, the type of the program is not supposed to be declared, but the Types section is used to declare the named space described in this document.
The <message> element is composed of the Messages section. If you are going to work as a function, the <message> element can define the parameters to the function. Each <part> child element in the <message> element is applied to one of the parameters. Enter the parameters into a single <message> element and separate it from the input parameters that are in your <message> element. At the same time, input and output parameters, in the input and output <message> elements, each have their corresponding <part> elements. According to the habit, the name of the <message> element is output, as "fooresponse", will end with "response". Each <part> element is also known as a type, as the function must be known as the type.
If used in file Exchange, the WSDL can use the <message> element to explain the exchange of the file.
The types of <part> elements can be the type of XSD base type, SOAP definition type (SOAPENC), WSDL definition type (WSDL), or the definition of Types region.
In the Porttypes section, you can have 0 or one, or more <portType> elements. Because of the abstract PortType definition, it can be placed in different files, so there are 0 <portType> elements in the WSDL file. In the example above, there is only one <portType> element. As you can see, the,<porttype> element defines one or more professions in the <operation> element. This example shows only a <operation> element named "foo". This name is the same as the name of the function. <operation> elements can have one or two, or three child elements: that is, <input>, <output> and <fault> elements. The information in each <input> and <output> element will take a look at the related <message> elements in the Messages section. Therefore, the whole <portType> element in the example, as the following C function declares:
int foo (int arg);
This example is sufficient to say that compared to C,xml is a more redundant language. (including the <message> element, this example uses 12 rows of XML to declare the function, and the same action, C just one line.) )
The bindings section can have 0 or one or more <binding> elements. The goal is to specify how each <operation> call and response is sent online. The Services section can also have 0 or one or more <service> elements. It contains <port> elements, each of which participates in a <binding> element in the bindings section. The bindings and Services sections are composed of a description of the WSDL file.
Name space
In the root element <definitions> and child element <schema>, there are named spaces:
<definitions name= "Foosample"
Targetnamespace= "http://tempuri.org/wsdl/"
Xmlns:wsdlns= "http://tempuri.org/wsdl/"
Xmlns:typens= "Http://tempuri.org/xsd"
Xmlns:xsd= "Http://www.w3.org/2001/XMLSchema"
xmlns:soap= "http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:stk= "Http://schemas.microsoft.com/soap-toolkit/wsdl-extension"
xmlns= "http://schemas.xmlsoap.org/wsdl/" >
<types>
<schema targetnamespace= "Http://tempuri.org/xsd"
Xmlns= "Http://www.w3.org/2001/XMLSchema"
Xmlns:soap-enc= "http://schemas.xmlsoap.org/soap/encoding/"
Xmlns:wsdl= "http://schemas.xmlsoap.org/wsdl/"
elementformdefault= "qualified" >
</schema>
</types>
Each named space will declare a quick notation for the namespace to be used in the file. For example, "xmlns:xsd" can define a fast notation (XSD) that represents a named space Http://www.w3.org/2001/XMLSchema. In this way, you can then take a look at this namespace in the file, in a very simple manner, as long as you embed the first "xsd" before the name, and the "xsd:int" is the qualified type name. The general domain setting rules can be applied to the top of this quick word. That is to say, the first word defined in an element is used only in that element.
What are the reasons for using a named space? The purpose of the name space is to avoid naming conflicts. If I set up a Web service, the WSDL file contains an element called "foo", and you want to take my Web service, in combination with another complementary service; If you do not use a named space, another Web service, in its WSDL file, will never be able to use the name of the "foo". Unless, in the case of both, the two services do not use the same name, they mean exactly the same thing. But if you use two different namespaces, the meaning of my Web service's "foo" is different from the "foo" of another Web service. On the client side, you must take a look at my "foo" in the form of an embedded header (prefixing or qualifying). For example, if I declare Http://www.infotects.com/fooService's quick note to be Carlos, Http://www.infotects.com/fooService#foo this fully qualified name, can be equal to " carlos:foo". Note that using a URI as a named space not only ensures its uniqueness, but also allows the use of a addressable device in a file. The address that the URI points to does not have to be a true web address. You can also use GUIDs instead of or recharge URIs. For example, guid"335db901-d44a-11d4-a96e-0080ad76435d" is a valid naming space indicator.
All the names declared in the elements are attached to the named spaces declared by the targetnamespace. In the WSDL case file, the targetnamespace representing <definitions> is http://tempuri.org/wsdl. What it means is that all the names declared in this WSDL file are attached to this name space. Because the <schema> element has its own targetnamespace, and its value is http://tempuri.org/xsd, so all the names defined in this <schema> element are in this named space, But not in the main target name space.
The next line of code is located in the <schema> element, which declares a preset named space. The names of all the unqualified that are embedded in the structure belong to this name space.
Xmlns= "Http://www.w3.org/2001/XMLSchema"
SOAP messages
For the client and server using the WSDL file, one of the meanings that it represents is the content that can be decided on the line. While SOAP uses low-level messaging such as IP and HTTP, the application can determine the high level of communication that is used between a particular client and a particular server end of the user's path. In other words, if you take "echoint" as an example, by using the echo-back input integer, the number of parameters, the type of each reference, the way in which the parameters are passed (serialized), etc., will form an application-specific communication protocol. There are many ways to specify this kind of communication, but I think using WSDL is the best way. In this view, the WSDL is not just a "interface", it is a communication protocol to specify the language. If you go beyond the fixed message protocol such as IP and HTTP, and access the domain of the application's specialized messaging, the WSDL fits exactly what we need.
The WSDL can specify whether the SOAP message conforms to RPC or file type. As used in the example, the external aspect of the RPC message is like a function call with 0 or more parameters. File-like messages are flat (flatter) and do not require so many nesting layers. The following XML message is sent and received using the SoapClient object of MS SOAP Toolkit 2.0 (MSTK2) to parse the results of the WSDL case file.
"foo (5131953)" From the client's function call ":
<?xml version= "1.0" encoding= "UTF-8" standalone= "no"?>
<soap-env:envelope
Soap-env:encodingstyle= "http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soap-env= "http://schemas.xmlsoap.org/soap/envelope/" >
<SOAP-ENV:Body>
<m:foo xmlns:m= "http://tempuri.org/message/" >
<arg>5131953</arg>
</m:foo>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Received by the server (response):
<?xml version= "1.0" encoding= "UTF-8" standalone= "no"?>
<soap-env:envelope
Soap-env:encodingstyle= "http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soap-env= "http://schemas.xmlsoap.org/soap/envelope/" >
<SOAP-ENV:Body>
<soapsdk1:fooresponse xmlns:soapsdk1= "http://tempuri.org/message/" >
<result>5131953</result>
</SOAPSDK1:fooResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
This function calls the message and its response, is the correct valid XML. SOAP messages are composed of <Envelope> elements that contain a selection of <Header> elements, with at least one <body> element. To send and receive messages, there is only one <Body> element in the main <Envelope> element. The RPC function calls the message's main body, there is an element named after the "foo" name, and there is a "fooresponse" element in the response host. This foo element has a single argument as shown in the example WSDL, which is named <arg>. Similarly, Fooresponse also has a <result>. In this complex WSDL bindings section, note the way encodingstyle, envelopes, and message naming spaces are specified.
<binding name= "simplebinding" type= "Wsdlns:simpleporttype" >
<stk:binding preferredencoding= "UTF-8"/>
<soap:binding style= "RPC"
transport= "Http://schemas.xmlsoap.org/soap/http"/>
<operation name= "foo" >
<soap:operation
soapaction= "Http://tempuri.org/action/Simple.foo"/>
<input>
<soap:body use= "encoded"
Namespace= "http://tempuri.org/message/"
encodingstyle=
"http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output>
<soap:body use= "encoded"
Namespace= "http://tempuri.org/message/"
encodingstyle=
"http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>
</binding>
