WSDL学习笔记1——WSDL支持的4种消息交换方式

WSDl定义了4种操作类型，其中请求-响应是最普通的操作类型：





类型 定义
One-way 此操作可接受消息，但不会返回响应。
Request-response 此操走可接受一个请求并会返回一个响应
Solicit-response 此操作可发送一个请求，并会等待一个响应。
Notification 此操作可发送一条消息，但不会等待响应。



1、One - way 操作



一个one - way 操作的例子：



Wsdl代码
1.<message name = "newTermValues">
2. <part name = "term" type = "xs:string"/>
3. <part name = "value" type = "xs:string">
4.</message>
5.
6.<portType name = "glossaryTerms">
7. <operation name = "setTerm">
8. <input name = "newTerm" message = "newTermValues"/>
9. </operation>
10.</portType>
<message name = "newTermValues">
<part name = "term" type = "xs:string"/>
<part name = "value" type = "xs:string">
</message>

<portType name = "glossaryTerms">
<operation name = "setTerm">
<input name = "newTerm" message = "newTermValues"/>
</operation>
</portType>
在这个例子中, 端口 “glossaryTerms” 定义了一个名为 “setTerm” 的 one-way 操作。

这个 “setTerm” 操作可接受新术语表项目消息的输入, 这些消息使用一条名为 “newTermValues” 的消息, 此消息带有输入

参数 “term” 和 “value”。不过, 没有为这个操作定义任何输出。





2、Request - Response 操作



一个 request-response 操作的例子：



Wsdl代码
1.<message name = "getTermRequest">
2. <part name = "term" type = "xs:string">
3.</message>
4.<message name = "getTermResponse">
5. <part name = "value" type = "xs:string"/>
6.</message>
7.
8.<portType name = "glossaryTerms">
9. <operation name = "getTerm">
10. <input message = "getTermRequest"/>
11. <output message = "getTermResponse"/>
12. </operation>
13.</portType>
<message name = "getTermRequest">
<part name = "term" type = "xs:string">
</message>
<message name = "getTermResponse">
<part name = "value" type = "xs:string"/>
</message>

<portType name = "glossaryTerms">
<operation name = "getTerm">
<input message = "getTermRequest"/>
<output message = "getTermResponse"/>
</operation>
</portType>

在这个例子中, 端口 “glossaryTerms” 定义了一个名为 “getTerm” 的 request-response 操作。

“getTerm” 操作会请求一个名为 “getTermRequest” 的输入消息, 此消息带有一个名为 “term” 的参数, 并将返回一个名为

“getTermResponse” 的输出消息, 此消息带有一个名为 “value” 的参数。



《JAVA WebService》一书中, P88页：

5.2.5 <portType> Element



The <portType> element specifies a subset of operations supported for an endpoint of a web service. In a

sense, a <portType> element provides a unique identified to a group of actions that can be executed at a

single endpoint.



The <operation> element represents an operation. This element is an abstract definition of an action

supported by a web service. A WSDL <operation> element is analogous to a Java method definition. A WSDL

operation can have input and output messages as part of its action. The <operation> tag defines the name

of the action by using a name attribute, defines the input message by the <input> subelement, and defines

the output message by the <output> subelement. The <input> and <output> elements reference

<message> elements defined in the same WSDL document or an imported one. A <message> element can

represent a request, response, or a fault.



Continuing with the Z39.50 ASN.1 sample, the WSDL file defines a single <portType> element:



<portType name = "ez3950PortTypes">



This element declares that this endpoint has a set of operations that jointly referenced as ez3950PortTypes.

The following lines define the <operation> elements for this <portType>:



Wsdl代码
1.<portTyle>
2.<!-- Request-response Operations (client initiated) -->
3. <operation name = "iniit">
4. <input message = "initRequest"/>
5. <output message = "initResponse"/>
6. </operation>
7. <operation name = "search">
8. <input message="searchRequest"/>
9. <output message="searchResponse"/>
10. </operation>
11. <operation name="present">
12. <input message="presentRequest"/>
13. <output message="presentResponse"/>
14. </operation>
15. <operation name="sort">
16. <input message="sortRequest"/>
17. <output message="sortResponse"/>
18. </operation>
19. <operation name="scan">
20. <input message="scanRequest"/>
21. <output message="scanResponse"/>
22. </operation>
23. <operation name="delete">
24. <input message="deleteRequest"/>
25. <output message="deleteResponse"/>
26. </operation>
27. <operation name="resourceReport">
28. <input message="resourceReportRequest"/>
29. <output message="resourceReportResponse"/>
30. </operation>
31. <operation name="extendedServices">
32. <input message="extendedServicesRequest"/>
33. <output message="extendedServicesResponse"/>
34. </operation>
35. <operation name="close">
36. <output message="close"/>
37. <input message="close"/>
38. </operation>
39.
40.<!-- Solicit-response Operation (Server initiated) -->
41. <operation name = "accessControl">
42. <output message = "accessControlResponse"/>
43. <input message = "accessControlRequest"/>
44. </operation>
45. <operation name = "resourceControl">
46. <output message="resourceControlResponse"/>
47. <input message="resourceControlRequest"/>
48. </operation>
49. <operation name="close">
50. <output message="close"/>
51. <input message="close"/>
52. </operation>
53.
54.<!-- Notification Operations (Server initiated) -->
55. <operation name = "segmenty">
56. <output message = "segmentRequest"/>
57. </operation>
58.
59.<!-- One-way Operations (Client initiated) -->
60. <operation name = "triggerResourceControl">
61. <input message = "triggerResourceControlRequest"/>
62. </operation>
63.</portType>
<portTyle>
<!-- Request-response Operations (client initiated) -->
<operation name = "iniit">
<input message = "initRequest"/>
<output message = "initResponse"/>
</operation>
<operation name = "search">
<input message="searchRequest"/>
<output message="searchResponse"/>
</operation>
<operation name="present">
<input message="presentRequest"/>
<output message="presentResponse"/>
</operation>
<operation name="sort">
<input message="sortRequest"/>
<output message="sortResponse"/>
</operation>
<operation name="scan">
<input message="scanRequest"/>
<output message="scanResponse"/>
</operation>
<operation name="delete">
<input message="deleteRequest"/>
<output message="deleteResponse"/>
</operation>
<operation name="resourceReport">
<input message="resourceReportRequest"/>
<output message="resourceReportResponse"/>
</operation>
<operation name="extendedServices">
<input message="extendedServicesRequest"/>
<output message="extendedServicesResponse"/>
</operation>
<operation name="close">
<output message="close"/>
<input message="close"/>
</operation>

<!-- Solicit-response Operation (Server initiated) -->
<operation name = "accessControl">
<output message = "accessControlResponse"/>
<input message = "accessControlRequest"/>
</operation>
<operation name = "resourceControl">
<output message="resourceControlResponse"/>
<input message="resourceControlRequest"/>
</operation>
<operation name="close">
<output message="close"/>
<input message="close"/>
</operation>

<!-- Notification Operations (Server initiated) -->
<operation name = "segmenty">
<output message = "segmentRequest"/>
</operation>

<!-- One-way Operations (Client initiated) -->
<operation name = "triggerResourceControl">
<input message = "triggerResourceControlRequest"/>
</operation>
</portType>


These <operation> elements are grouped according to their behavior. When an operation is defined in a

WSDL document, it is made to be abstract; it is purely an operation definition, but how that operation is

mapped to a real function is defined later (i.e., the operation can behave in a number of different ways

depending on the actual definition). The WSDL specification defines the following behavioral patterns as

transmission primitives:



• Request-response
• Solicit-response
• One-way
• Notification
First, the operation can follow a request-response model, in which a web service client invokes a request

and expects to receive a synchronous response message. This model is defined by the presence of both

<input> and <output> elements. The <input> element must appear before the <output> element. This order

indicates that the operation first accepts an input message (reqeust) and then sends an output message

(response). This model is similar to a normal procedure call, in which the calling method blocks until the called

method returns its result.



Second, the operation can follow a solicit-response model, in which the web service solicits a response from

the client, expecting to receive a response. This model is defined as having both <input> and <output>

elements. The <output> element must appear before the <input> element. This order indicates that the

operation first sends an output message (solicit) and then receives an input message (response).



Third, the operation can be a one-way invocation, in which the web sevice client sends a message to the

web service without expecting to receive a response. This model is defined by a single <input> message

with no <output> message. This model indicates that the operation receives input messages (one-way

invocation), but doesn't deliver a response to the client.



Fourth, the operation can be a notification, in which the web services sends a one-way message to the client

without expecting a response. This model is defined by a single <output> message and no <input>

message. It indicates that the operation sends output messages asynchronously; i.e., the messages are not

in response to a request, but can be sent at any time. The operation doesn't expect a response to the

messages it sends.



annotate:

For the request-response and solicit-response models, an optional <fault> element can be
included. This element refers to another message. A <fault> message will be transmitted
if any processing, system, or application errors occur. The <fault> message is delivered to
the client in a request-response and to the web service in the solicit-response model.



The value assigned to the name attribute of each <operation> element must be unique within the scope of

the <portType>, not just the <operation>. The value assigned to the message attrubute of an <input> or

<output> element must match one of the names of the <message> elements defined in the same WSDL or

in an imported one.