web-services - 定义 SOAP 服务(通用与特定操作)的最佳实践是什么？

Question

我的情况如下:

我有一个规范化的数据库，其中保存了有关机场的地理信息。结构是:

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

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

现在，在设计服务时，我们遇到了关于如何定义操作的讨论。我们提出了不同的解决方案:

方案一:具体操作

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

插入

获取

更新

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

要创建一个具有所有依赖项的全新机场，至少需要 4 个请求。

解决方案 B:通用

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

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

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

方案C:中途见面1

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

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

方案D:中途见面2

每个操作(get、insert、delete)一个通用操作，它可以在每个表上工作并解决依赖关系。

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

示例

由于这是相当抽象的，因此为创建请求对象提供了一个简化示例(JFK/New York/USA/North America):

解决方案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 是否足以理解，这是怎么回事？

Answer 1

大概您正在编写一个可以理解您的不同消息类型的协议(protocol)层。您还需要一个应用层来解析消息的内容。您提到的不同方法将转移这两层之间的解析负担。例如:

解决方案 A :协议(protocol)层完成所有解析并返回数据和命令。应用层只能使用数据。这也称为 RPC 模式。

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

缺点:如果您需要更改接口(interface)，则您的协议(protocol)会更改。

解决方案 B :协议(protocol)层返回两个值和一个命令。应用层必须使用命令将值解析为类型。

优点:协议(protocol)永远不会改变。

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

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

优点:我想不出，似乎不是一个很好的折衷方案。

缺点:仅部分完成解析。

解决方案 D :协议(protocol)层返回已知类型(您实现它的方式)和通用命令。应用层必须查看它接收到的数据并将通用命令转换为特定命令。这类似于 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 架构风格的优缺点。

我个人更喜欢带有一些 REST-ful 属性的 RPC 样式(解决方案 A)。我希望协议(protocol)完成解析工作并验证消息。这通常是人们实现 SOAP Web 服务接口(interface)的方式。

您的界面今天可能看起来很简单，但明天您的一位客户会要求您进行一个不太适合 REST 模型的新调用，您会发现自己将其嵌入到现有的四个消息中。