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

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

 

 

类型 定义

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

 

   1、One - way 操作

 

    一个one - way 操作的例子：

 

        <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 操作的例子：

 

        <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>:

 

<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.