为什么 WSDL 引入 wsdl:message?
为什么 WSDL 引入 wsdl:message?还有消息部分?
与在操作参数(输入、输出、故障)中直接使用 XSD 相比,它们可以带来哪些优势?
它们(带有 wsdl 消息部分的 wsdl 消息)如何比 XSD 更抽象?
为什么它不是这样组织的:
<operation name="GetEndorsingBoarder">
<input type="xsd:string"/>
<output type="xsd:string, xsd:int, xsd:boolean"/>
<fault "type="xsd:string""/>
</operation>
Why WSDL introduces wsdl:message? And message parts?
What the advantage they could bring over the direct using of the XSD in the operations parameters (input, output, fault)?
How they (wsdl messages with wsdl message parts) can be more abstract then XSD?
Why it is not organized for example that way:
<operation name="GetEndorsingBoarder">
<input type="xsd:string"/>
<output type="xsd:string, xsd:int, xsd:boolean"/>
<fault "type="xsd:string""/>
</operation>
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我明白了:
消息不仅仅指定操作的参数。
消息及其部分在绑定中引用。应该可以以不同的方式绑定不同的部分:
我错过了这一点,因为“非 SOAP '文字'”绑定非常罕见。
I got it:
Messages not just specify operation's parameters.
Messages and theirs parts are referred in the bindings. It should be possible to bind different parts differently:
I have missed this since "non SOAP 'literal'" bindings are so uncommon.
XSD
描述DATA
方面,例如 Web 服务调用的数据方面,而WSDL
描述 Web 服务的目的(方法调用)。您通常无法仅从数据中找出方法调用。查看 Cheeso 和 Marc 关于从 XSD 文件生成 WSDL 的回答
编辑: 源
消息
描述了之间交换的数据Web 服务的提供者和消费者,每个 Web 服务都有两条消息:1)输入:Web服务的参数
2) 输出:从Web服务返回数据
每个
message
有零个或多个part
参数(Web服务函数的每个参数一个) 每个part 参数与
types
容器元素中定义的具体类型关联。这里,定义了两个消息元素。第一个表示请求消息SayHelloRequest,第二个表示响应消息SayHelloResponse。
这些消息中的每一个都包含一个单独的部分元素。对于请求,该部分指定了函数参数;在本例中,我们指定一个firstName 参数。对于响应,该部分指定函数返回值;在本例中,我们指定单个问候语返回值。
A
XSD
describes theDATA
aspects, for example data aspects of webservice call whereas theWSDL
describes the purpose of the web services (method calls). You cannot typically figure out the method calls from your data alone.Check out Cheeso and Marc answers on Generating a WSDL from an XSD file
EDIT: source
The
message
describes the data being exchanged between the web services' provider and consumer and each web service has two messages:1) input: parameters of the web service
2) output: return data from the web service
Each
message
has zero or morepart
parameters (one for each parameter of the web service's function) Eachpart
parameter associates with a concrete type defined in thetypes
container element.Here, two message elements are defined. The first represents a request message SayHelloRequest, and the second represents a response message SayHelloResponse.
Each of these messages contains a single part element. For the request, the part specifies the function parameters; in this case, we specify a single firstName parameter. For the response, the part specifies the function return values; in this case, we specify a single greeting return value.