WSDL元素结构示意图如下图所示:
其中:
1)Types是一个数据类型定义的容器,包含了所有在消息定义中需要的XML元素的类型定义。
2)Message具体定义了在通信中使用的消息的数据结构,Message元素包含了一组Part元素,每个Part元素都是最终消息的一个组成部分,每个Part都会引用一个DataType来表示它的结构。Part元素不支持嵌套。
3)PortType具体定义了一种服务访问入口的类型,何谓访问入口的类型呢?就是传入/传出消息的模式及其格式。
一个PortType可以包含若干个Operation,而一个Operation则是指访问入口支持的一种类型的调用。以上三种结构描述了调用Web服务的抽象定义,这三部分与具体Web服务部署细节无关,是可复用的描述(每个层次都可以复用)。
4)Service描述的是一个具体的被部署的Web服务所提供的所有访问入口的部署细节,一个Service往往会包含多个服务访问入口,而每个访问入口都会使用一个Port元素来描述。
5)Port描述的是一个服务访问入口的部署细节,包括通过哪个Web地址(URL)来访问,应当使用怎样的消息调用模式来访问等。其中消息调用模式则是使用Binding结构来表示。
6)Binding结构定义了某个PortType与某一种具体的网络传输协议或消息传输协议相绑定,从这一层次开始,描述的内容就与具体服务的部署相关了。比如可以将PortType与SOAP/HTTP绑定,也可以将PortType与MIME/SMTP相绑定等。
元素是最重要的WSDL元素。
它可描述一个Web service可被执行的操作以及相关的消息。
可以把元素比作传统编程语言中的一个函数库(或一个模块,或一个类)。
端口包含如下类型:
1)一个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操作的例子:
<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”的参数。
一个绑定的例子:
<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>
<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>
binding元素有“name”和“type”两个属性。“name”属性定义binding的名称,而“type”属性指向binding的端口,在这个例子中是“glossaryTerms”端口。
soap:binding元素有“style”和“transport”两个属性。“style”属性可取值为“rpc”或“document”。
在这个例子中我们使用“document”。“transport”属性定义SOAP使用的协议,在这个例子中使用HTTP。
operation元素定义了每个端口提供的操作符。对于每个操作,相应的SOAP行为都需要被定义。同时必须知道如何对输入和输出进行编码。在这个例子中使用了“literal”。
TCP和UDP都属于网络传输协议,如果要构架高效的网络应用,就应该从传输层着手,但是对于经典的浏览器网页和服务器端通信场景,如果单纯的使用更底层的传输协议则会变得麻烦。
你开发了一个服务,调用它,它做了一些事情并返回结果。那么,它需要花多长时间?为什么有时候它花的时间比用户期望的要长?在这篇文章中,我将从最基础的讲起,然后逐步介绍一些标准的术语,同时着重强调一些需要知道的关键点。
在日常工作中,应用出现性能问题是不可避免的,绝大部分公司都没有专门的性能团队,出现问题还是需要我们自己去排查处理,所以掌握基本的性能知识和技能就显得很有必要,也是开发工程师进阶的必要条件
这是一个彻底无服务,易于分享的网页软件形式,它所有的内容都集中在Url数据中,所见即所得,不需要网络和注册安装,同时适配全平台,用户还能随时修改逻辑,没有的服务器成本
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!