加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 综合聚焦 > 资源网站 > 资源 > 正文

web-services – 定义soap服务(通用操作与特定操作)的最佳实践是

发布时间:2020-12-14 18:37:58 所属栏目:资源 来源:网络整理
导读:我的情况如下: 我有一个标准化的数据库,我在其中保存有关机场的地理信息.结构是: airport --is in-- city --is in-- country --is in-- continent 现在我想让用户管理这些数据,而不是让他们直接访问数据库.我们需要通过Web服务提供此管理界面. 现在,在设计
我的情况如下:

我有一个标准化的数据库,我在其中保存有关机场的地理信息.结构是:

airport --is in--> city --is in--> country --is in--> continent

现在我想让用户管理这些数据,而不是让他们直接访问数据库.我们需要通过Web服务提供此管理界面.

现在,在设计服务时,我们讨论了如何定义操作.我们提出了不同的解决方案:

解决方案A:具体操作

对于四个表(机场,城市,国家,大陆)中的每一个,我们定义了3个操作:

>插入
>得到
>更新

这将导致12个操作,其中2个请求/响应对象= 24个对象

要创建一个包含所有依赖项的全新机场,至少需要4个请求.

解决方案B:通用

只有一个操作,通过参数控制.此操作能够创建管理数据库所需的一切.

该操作将决定需要做什么并执行它.如果发生错误,它将回滚所有内容.

==> 1操作= 2个高度复杂的请求/响应对象

解决方案C:在中间见面1

每个表一个通用操作,它能够执行get,insert,update,就像解决方案B一样,但每个都集中在一个表上.

==> 4个操作= 8个复杂的请求/响应对象

解决方案D:在中间见面2

每个操作一个通用操作(获取,插入,删除),它可以在每个表上工作并解决依赖关系.

==> 3个操作= 6个稍微复杂的请求/响应对象

由于这是相当抽象的,所以用于创建请求对象的简化示例(JFK /纽约/美国/北美):

解决方案A:

要求1/4:

<insertContinent>North America</insertContinent>

要求2/4:

<insertCountry continent="North America">USA</insertCountry>

要求3/4:

<insertCity country="USA">New York</insertCity>

要求4/4:

<insertAirport city="New York">JFK</insertAirport>

解决方案B:

要求1/1:

<action type="insertCountry" parent="North America">USA</action>
<action type="insertAirport" parent="New York">JFK</action>
<action type="insertContinent" parent="">North America</action>
<action type="insertCity" parent="USA">New York</action>

解决方案C:

要求1/4:

<countryAction type="insert" parent="North America">USA</countryAction>

要求2/4:

<airportAction type="insert" parent="New York">JFK</airportAction>

要求3/4:

<continentAction type="insert" parent="">North America</continentAction >

要求4/4:

<cityAction type="insert" parent="USA">New York</cityAction >

解决方案D:
要求1/1:

<insert airport="JFK" city="New York" country="USA" continent="North America" />

解决方案D对我来说似乎相当优雅,因此我尝试将其放在XSD中:

码:

<complexType name="NewContinent">
    <sequence>
        <element name="NAME" type="string"></element>
    </sequence>
</complexType>

<complexType name="NewCountry">
    <sequence>
        <element name="ISOCODE" type="string"></element>
        <element name="NAME" type="string"></element>
        <choice>
            <element name="newCONTINENT" type="tns:NewContinent"></element>
            <element name="CONTINENT" type="string"></element>
        </choice>
    </sequence>
</complexType>

<complexType name="NewCity">
    <sequence>
        <element name="IATA" type="string"></element>
        <element name="NAME" type="string"></element>
        <choice>
            <element name="COUNTRY" type="string"></element>
            <element name="newCOUNTRY" type="tns:NewCountry"></element>
        </choice>
    </sequence>

</complexType>

<complexType name="NewAirport">
    <sequence>
        <element name="IATA" type="string"></element>
        <element name="NAME" type="string"></element>
        <choice>
            <element name="CITY" type="string"></element>
            <element name="newCITY" type="tns:NewCity"></element>
        </choice>
    </sequence>

</complexType>

相应的请求将如下所示:

<complexType name="Request">
    <choice>
        <element name="AIRPORT" type="tns:NewAirport"></element>
        <element name="CITY" type="tns:NewCity"></element>
        <element name="COUNTRY" type="tns:NewCountry"></element>
        <element name="CONTINENT" type="tns:NewContinent"></element>
    </choice>
</complexType>

现在我的问题:这真的是最好的解决方案吗? XSD是否足以理解,发生了什么?

解决方法

据推测,您正在编写一个协议层,可以了解您的不同消息类型.您还需要一个应用程序层来解析消息的内容.您提到的不同方法将改变这两层之间的解析负担.例如:

解决方案A:协议层执行所有解析并返回数据和命令.应用程序层可以只使用数据.这也称为RPC模式.

优点:您可以验证您的消息.您可以将消息直接映射到应用程序调用.

缺点:如果您需要对界面进行更改,则协议会发生变化.

解决方案B:协议层返回两个值和一个命令.应用程序层必须使用该命令将值解析为类型.

优点:协议永远不会改变.

缺点:您无法验证消息.您的应用程序代码更复杂.

解决方案C:协议层返回两个已知类型和一个必须解析的命令.应用程序层可以解析命令并使用数据.

优点:我想不出任何,似乎不是一个很好的妥协.

缺点:仅解析部分完成.

解决方案D:协议层返回已知类型(实现它的方式)和通用命令.应用程序层必须查看它接收的数据并将通用命令转换为特定命令.这与REST架构类似.

优点:调用是不同的操作,因此您可以缓存获取响应.

缺点:应用程序层的复杂性

REST模型的实现方式通常与您概述的不同.它使用HTTP GET,POST,PUT,DELETE消息来传递任意文档.参数作为URL的一部分给出.例如:

<insert airport="JFK" city="New York" country="USA" continent="North America" />

<insert URL="airport?city=Chicago">ORD</insert>

或者,如果您正在使用HTTP,它将成为机场URL的POST请求,其中包含城市的参数,其内容是有关机场的信息.请注意,对于具有多个元素和混合类型的更多合并数据,其中一些变得更加清晰.例如,如果您要发送机场缩写,长名称和海拔高度.

我认为REST架构可以很好地适用于您描述的界面.只要你需要做的就是支持CRUD操作.有许多网站可以为您提供REST架构风格的优缺点.

我个人更喜欢RPC样式(解决方案A)和一些REST-ful属性.我希望协议能够进行解析工作并验证消息.这通常是人们实现SOAP Web服务接口的方式.

您的界面今天可能看起来很简单,但明天您的一位客户会要求您拨打一个不太适合REST模型的新电话,并且您会发现自己将其嵌入现有的四条消息中.

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读