WSDL abstract vs concrete messages

问题

I am learning about WSDL from online documentation and came across definitions about abstract message and concrete message:

Message definitions are always considered to be an abstract definition of the message content. A message binding describes how the abstract content is mapped into a concrete format.

However, in some cases, the abstract definition may match the concrete representation very closely or exactly for one or more bindings, so those binding(s) will supply little or no mapping information.

However, another binding of the same message definition may require extensive mapping information. For this reason, it is not until the binding is inspected that one can determine "how abstract" the message really is.

Please help me in understanding what the above definition means? Can you please provide some examples for the same.

When we call a message as Abstract and when it will be called as concrete in WSDL terms?

回答1:

The message part is considered abstract as it does not really define how the content formatting of the actual SOAP message will look like. Please have a look at this IBM article which does a great job on presenting the differences between the available binding styles in WSDL.

Taking the example from this article where the WSDL contract should define a method like public void myMethod(int x, float y); you can declare something like that in the WSDL contract:

<message name="myMethodRequest">
    <part name="x" type="xsd:int"/>
    <part name="y" type="xsd:float"/>
</message>
<message name="empty"/>

<portType name="PT">
    <operation name="myMethod">
        <input message="myMethodRequest"/>
        <output message="empty"/>
    </operation>
</portType>

<binding .../>

Here you just declare the expected elements of a message but you don't really define here how the actual SOAP message matching this definition looks like. This happens in the binding section.

WSDL offers here RPC/encoded ...

<soap:envelope>
    <soap:body>
        <myMethod>
            <x xsi:type="xsd:int">5</x>
            <y xsi:type="xsd:float">5.0</y>
        </myMethod>
    </soap:body>
</soap:envelope>

... RPC/literal ...

<soap:envelope>
    <soap:body>
        <myMethod>
            <x>5</x>
            <y>5.0</y>
        </myMethod>
    </soap:body>
</soap:envelope>

... and Document/literal

<soap:envelope>
    <soap:body>
        <xElement>5</xElement>
        <yElement>5.0</yElement>
    </soap:body>
</soap:envelope>

Document/literal is actually not complete here as you furthermore create own types for xsd:int and xsd:float and use this types instead of these types as your message type:

<types>
    <schema>
        <element name="xElement" type="xsd:int"/>
        <element name="yElement" type="xsd:float"/>
    </schema>
</types>

<message name="myMethodRequest">
    <part name="x" element="xElement"/>
    <part name="y" element="yElement"/>
</message>
<message name="empty"/>

<!-- same port type -->
<portType name="PT">
    ...

<binding ... />

Every method has its strength and its weaknesses - please have a look on the IBM article for further information therefore. Due to the limitations and weaknesses RPC/encoded, RPC/literal and document/literal bare are not used that often - instead a modification of document/literal is used - document/literal wrapped. Here the advantages of all styles are thrown into one single style - which has its further limits of only allowing one <part .../> element for a message:

<types>
    <schema>
        <element name="myMethod">
            <complexType>
                <sequence>
                    <element name="x" type="xsd:int"/>
                    <element name="y" type="xsd:float"/>
                </sequence>
            </complexType>
        </element>
        <element name="myMethodResponse">
            <complexType/>
        </element>
    </schema>
</types>
<message name="myMethodRequest">
    <part name="parameters" element="myMethod"/>
</message>
<message name="empty">
    <part name="parameters" element="myMethodResponse"/>
</message>

<!-- again same port type -->

<binding ... />

This results in a SOAP message like this:

<soap:envelope>
    <soap:body>
        <myMethod>
            <x>5</x>
            <y>5.0</y>
        </myMethod>
    </soap:body>
</soap:envelope>

However, document/literal wrapped is not really part of the WSDL:

In document/literal style of messaging, there exists a pattern which is known as wrapped-document/literal. This is just a pattern, and is not a part of WSDL specification. This pattern has a mention in JSR 224 (JAX-WS: Java API for XML based web services). (Source)

Hope this also answers somehow your other questions: 1, 2

Furthermore, the actual transportation may happen on different protocols like HTTP, JMS, SMTP, ..., as already explained by @Namphibian and @JqueryLearner. This happens within the binding section where you define which protocol and binding style (RPC or document) should be used for which operations:

<binding type="glossaryTerms" name="b1">
   <soap:binding style="document"
   transport="http://schemas.xmlsoap.org/soap/http" />
   <operation>
     <soap:operation soapAction="http://example.com/getTerm"/>
     <input><soap:body use="literal"/></input>
     <output><soap:body use="literal"/></output>
  </operation>
</binding>

HTH

回答2:

Abstract WSDL contains messages without the transport protocol

Concrete WSDl is abstract WSDl plus transport protocol

Transport protocol may be JMS or HTTP

来源：https://stackoverflow.com/questions/20899520/wsdl-abstract-vs-concrete-messages

标签

java

web-services

wsdl