Web服务“必选/可选”字段: XSD设计时与运行时

Question

我们目前正在构建一堆SOAP Web服务，用于各种后端系统的访问。

在定义请求/响应消息XML时，我们看到多个服务需要具有不同“强制/可选”字段的“Account”对象。

我们应该如何在同一消息中定义和执行这些“必选/可选”字段的验证？我看到了这些选项

1)通过创建不同的“Account”复杂类型，使用XSD强制执行验证

优点:设计时清晰。

缺点:对象类型的激增，对象的重用较少，

2)通过使用单个基本‘Extending+Restriction’类型使用XSD强制执行验证

优点:设计时清晰。

缺点:不确定是否支持Extend+Restriction特性(java、.Net)

3)使用单一的'Account‘类型并在运行时强制验证(即在代码中)。

优点:简单

缺点:没有设计时验证。需要通过规范文档传达现场要求。

你对此有何感想？

Answer 1

我将不得不假设: i)一些你所说的可选字段实际上是不适用于(没有意义的)所有帐户的字段，ii)我们谈论的不是微不足道的场景(比如两种类型的帐户，每个帐户有两个字段-类似的东西)。

首先，我要说的是，除非你真的很幸运，否则从需求的角度来看，无论你使用什么选项，你最终都会得到某种“运行时验证”。XML Schema不能表达一些常见的数据验证需求，比如跨域验证；或者仅仅是因为XML中的数据不足以提供验证消息完整性的规则(消息中的数据是在XML被解组/编组时可用的数据的子集)。

其次，我会避免通过restricton派生新的复杂类型；从创作的角度来看，您不会在重用方面取得太大成就，而且最终可能会遇到XSD如何解释代码工具的问题。我认为通过限制派生的初衷是为人们提供一个在xsd中使用的工具:重定义场景；为那些不想摆弄其他人编写的XML模式的人提供一个工具。如果一个人拥有(作者)模式，他可以通过首先定义"lesser“对象并由此扩展来绕过限制的需要。

至于“对象的激增”，你也可以使用选项#2 (与#1相比)；我的意思是，我所知道的所有工具都会为你的XSD中的每个命名(全局)复杂类型创建一个类；因此，如果你必须有三种类型的帐户，那么你将有三种类型的帐户，如果你选择从一个左右的基类扩展，那么就会有四个左右；对于后者，最糟糕的情况是当你需要三个专门化(如果你想具体的话)；无论如何，根据我的经验，现实生活场景中的差异并不会以某种方式真正改变决定。

在XML Schema中扩展基类型有利于重用；但是，重用带来了耦合；如果您从向前/向后兼容性的角度分析这一点，那么扩展基类型中的某些内容可能会使不想更改其代码库的服务客户端的XML反编组(反序列化)变得混乱；在这种情况下，依赖于合成器(xsd:sequence)末尾的xsd:any的向前兼容性策略将在您的第一个发行版中变得无用，因为它使用并扩展了您的基类型。

还有更多；正因为如此，我不认为有一个正确的答案，仅仅是为了你似乎通过设置你的赞成/反对而暗示的标准。

下面我的所有首选选项都假定您高度重视确保服务的向前/向后兼容性的需求，并且希望最小化客户端必须处理您的服务的成本(因为XML Schema更改)。

我想说的是，如果你所有的域(特别是账户)都可以被完全建模(假设将来基本上不会改变)，和有足够的共性来证明重用是合理的，那么就使用选项#2。否则，使用选项#1，因为我还没有看到没有变化的东西...

如果你的领域的建模可以完成80%或更多(或者一些你认为很高的数字)，和有足够的共同性来证明重用是合理的，那么我仍然会使用选项#2，但需要注意的是，未来所有跨帐户的通用属性扩展都必须应用于每个单独的帐户(通过执行#1，基本上将您的选项转换为混合选项)。

至于其他任何事情，我会选择#1。呼，我不敢相信我写了所有这些……