WSDL Rule Interpretation

Transferred from: http://www.blogjava.net/baoyaer/articles/116413.html

A WSDL document can be divided into two parts. The top part consists of an abstract definition, and the bottom part consists of a specific description. The abstract section defines SOAP messages in a platform-and language-independent way, and they do not contain any random or language-dependent elements. This defines a range of services that can be implemented by different Web sites. Things that vary with the site, such as serialization, fall into the bottom part because it contains a specific definition.
L Abstract Definition
Types
Independence with machine and language type definition

Messages
Include function parameters (input and output separate) or document description

Porttypes
The message definition in the Reference message section describes the function signature (operation name, input parameter, output parameter)

2 Specific definitions
Bindings
Each operation of the Porttypes section is implemented in this binding

Services
Determine the port address of each binding



In the following figure, the arrow connector represents the relationship between different columns of the document. The dots and arrows represent references or use relationships. The double arrows represent the modify relationship. The arrow in the-I represents the inclusion relationship. In this way, each messages column uses the definition of the types bar, the Porttypes column uses the Messages column definition, the bindings column refers to the Porttypes bar, the services bar references the bindings bar, The Porttypes and bindings columns contain the operation element, and the services bar contains the port element. The operation element in the Porttypes column is further modified or described by the operation element in the Bindings column.




First look at a simple Java code, which we use as the WSDL service implementation code:

ClassTest{
public string Echo (String u){
return "Hello " + u;
}
}

Look at the file it exported:

The first line declares that the document is XML. Although this is not required, it helps the XML parser decide whether to parse the WSDL file or just make an error. The second line is the root element of the WSDL document,:<definitions>. Some properties are attached to the root element, just like the <schema> child element for the <types> element.

<?XML version= "1.0" encoding= "UTF-8"?>
-<Wsdl:definitionsTargetNamespace= "Http://localhost/axis/Test2.jws"
xmlns:wsdl= "http://schemas.xmlsoap.org/wsdl/"
Xmlns:xsd= "Http://www.w3.org/2001/XMLSchema"
Xmlns:soapenc= "http://schemas.xmlsoap.org/soap/encoding/"
Xmlns:wsdlsoap= "Http://schemas.xmlsoap.org/wsdl/soap/"
Xmlns:apachesoap= "Http://xml.apache.org/xml-soap"
xmlns:intf= "Http://localhost/axis/Test2.jws" &NBSP;
                                        Xmlns:impl= "Http://localhost/axis/Test2.jws" >< Span style= "color: #000000;" >
- <!--&NBSP;
wsdl created  by apache axis version: 1.4
built on apr 22, 2006  ( 06:55:48&NBSP;PDT)

  --> 

After you have defined the operations (or methods), you now need to specify the parameters that will be sent to them and returned from them. In WSDL terminology, all parameters are called "Messages". It is useful to think that you are delivering messages and that the results are returned. A method call is an operation that prepares to return a message in response to an incoming message.

The <message> element contains the messages bar. If we think of the operation as a function, the,<message> element defines the parameter of that function. Each <part> child element in the <message> element matches a parameter. Input parameters are defined in the <message> element, separated from the output parameters-the output parameter has its own <message> element. Both input and output parameters have their corresponding <part> elements in the <message> elements of the input and output. The output <message> element ends with "Response", just like the "Fooresponse" used previously. Each <part> element has a name and type attribute, just as the function's arguments have parameter names and parameter types.

-<Wsdl:messageName= "Echoresponse">//Message returned
<Wsdl:partName= "Echoreturn"Type= "Xsd:string"/>
</Wsdl:message>
-<Wsdl:messageName= "Echorequest">//Requested message
<Wsdl:partName= "U"Type= "Xsd:string"/>
</Wsdl:message>

<definitions>element contains one or more <portType>element, in fact, each element is a series of elements that you want to represent operation。 Alternatively, you can consider a single portType element as a logical grouping of the various methods that make up a class. For example, if your supply chain management solution needs to interact between customers and suppliers, you are most likely to define the functionality that interacts with them separately, that is, you will define a portType for both the user and the vendor. Each portType should be called Service, so the entire WSDL file becomes a collection of services.

-<Wsdl:porttypeName= "Test2">//A porttype can be seen as a class
-<Wsdl:operationName= "echo"Parameterorder= "U">//A operation is a way of
<Wsdl:inputName= "Echorequest" message= "Impl:echorequest"  />  //input message
  < Span style= "color: #0000ff;" ><wsdl:output name = "Echoresponse"  message = "Impl:echoresponse"   /> //Return message
  </wsdl:operation>
  </ WSDL:PORTTYP>

Message Delivery and transport:
I define operations and messages in an abstract way, without regard to the details of the implementation. In fact, the task of WSDL is to define or describe the WEB service and then provide a reference to the external framework to define how the WSDL user will implement the services. You can use this framework as a " binding ()" Between the WSDL abstraction definition and their implementation binding .

Currently, the most popular binding ( binding ) technique is the use of Simple Object Access Protocol (SOAP). WSDL will specify a SOAP server that can access the actual implementation of the WEB service, and since then the entire task of soap is to bring the user from the WSDL file to its implementation.

<wsdl:binding name= "test2soapbinding" type= "Impl:test2">

<wsdlsoap:binding/> elements. The purpose of this element is to declare that SOAP will be used as a binding and transport service

  <wsdlsoap:binding>The element has two properties: style and transport. A style is an optional property that describes the nature of the operation within the binding. The transport property specifies that HTTP is the lower-level transport service that the binding will use. The SOAP client reads the SOAP structure from the WSDL file and coordinates with the SOAP server on the other end.
<Wsdlsoap:bindingStyle= "RPC"Transport= "Http://schemas.xmlsoap.org/soap/http" />

Wsdl<operation>Element, which represents the specific action, respectively. Each<operation>element provides the binding details of the respective operation. Therefore, I have provided anotherextensibilityElement, which is<wsdlsoap:operation/>(It is still an empty element, related to the operation it occurred). The<soap:operation/>The SOAPAction element has a property that the SOAP client will use to create the SOAP request.

The following binds the WSDL description to the specific implementation, where the SOAP method is used

-<Wsdl:operationName= "echo">
<Wsdlsoap:operationSOAPAction=""/>
-<Wsdl:inputName= "Echorequest">
<Wsdlsoap:bodyUse= "encoded"Encodingstyle= "http://schemas.xmlsoap.org/soap/encoding/"Namespace= "Http://DefaultNamespace"/>
</Wsdl:input>
-<Wsdl:outputName= "Echoresponse">
<Wsdlsoap:bodyUse= "encoded"Encodingstyle= "http://schemas.xmlsoap.org/soap/encoding/"Namespace= "Http://localhost/axis/Test2.jws"/>
</Wsdl:output>
</Wsdl:operation>
</Wsdl:binding>
The following associates the published service with the previous SOAP binding
-<Wsdl:serviceName= "Test2service">
-<Wsdl:portName= "Test2" binding= "impl:test2soapbinding">
<wsdlsoap:address location= "Http://localhost/axis/Test2.jws" />
</Wsdl:port>
</wsdl:service>

Each namespace attribute declares an abbreviation, which is used in the document. For example, "Xmlns:xsd" defines an abbreviation (XSD) for Http://www.w3.org/2001/XMLSchema. This allows a reference to the namespace simply by prefixing it with a name, such as: "XSD" in "xsd:int" is a valid type name. Normal scope rules can be applied to the thumbnail prefix. In other words, the element defined by the prefix is valid only in the element.

What's the namespace pie for? The role of namespace is to avoid naming conflicts. If I create a Web service where the WSDL file contains an element named "foo" and you want to supplement it with another service connection, the WSDL file for another service cannot contain an element named "foo". Two server programs can take the same name only if they represent exactly the same thing in two cases. If there is a difference between the namespace, My Network Service "Foo" can be expressed completely different from the other network Service "foo" meaning. In your client, you can refer to my "foo" as long as you restrict it.

See the following example: Http://www.infotects.com/fooService#foo is a fully restricted name, equivalent to "Carlos:foo" if I declare Carlos as http://www.infotects.com/ A shortcut to Fooservice. Note that URLs in namespace are used to determine their uniqueness and are also easy to locate. The URL points to a location that does not have to be an actual network address, or you can use a GUID to replace or supplement the URL. For example, the GUID "335db901-d44a-11d4-a96e-0080ad76435d" is a valid namespace assignment.

The TargetNamespace property declares a namespace, and the names of all the declarations in the element are listed therein. In the WSDL example, the targetnamespace of,<definitions> ishttp://tempuri.org/wsdl。 This means that all names declared in the WSDL document belong to this namespace. The <schema> element has its own targetnamespace property, and its value ishttp://tempuri.org/xsd, all the names defined in the <schma> element belong to this namespace and not to the target namespace of main.

The following line of the <schema> element declares the default namespace. All valid names in the schema belong to this namespace.

WSDL rule Interpretation (RPM)