Web服务“强制/可选”字段：XSD设计时间与运行时间 [英] Web Service ‘mandatory/optional’ fields: XSD Design time vs Runtime
问题描述
我们正在构建一堆SOAP Web服务，以便前端各种后台系统的访问。
在定义我们的请求/响应消息XML时，我们看到需要使用不同强制/可选字段的帐户对象的多个服务。
我们应该如何定义和强制对同一消息中的这些强制性/可选字段进行验证？我看到这些选项
1）通过创建不同的帐户复合体类型
强制执行XSD验证：设计时间清晰度
缺点：对象类型的扩散，对象的重用次数
2）通过扩展实现XSD的验证+限制一个基地帐户类型
优点：设计时间清晰度。
缺点：不确定Extend + Restriction功能（java，.Net）的支持
3 ）使用单个帐户类型并在运行时执行验证（即代码）。
优点：简单
缺点：没有设计时间验证。需要通过规范文档传达字段要求。
你有什么想法？
我必须假设：i）你称之为可选字段的一些实际上是不适用于所有帐户的字段（没有意义），ii）我们不是谈论微不足道的情景（像两种类型的帐户，每种类型的两个字段）。
首先，我会说，除非你真的很幸运，从一个要求透视图，那么你将会在某种运行时验证中得到最终结果，无论你要使用什么选项。 XML Schema不能表达一些常见的数据验证要求，如跨场验证;或者简单地因为您的XML中的数据不足以提供规则来验证消息的完整性（消息中的数据是XML未被解析/编组时可用的子集）。
其次，我将避免通过限制来导出新的复杂类型;从创作的角度来看，在重用方面并没有取得很大成就，您可能会遇到XSD解释为代码工具的问题。我喜欢认为通过限制推导出来的原意是为人们提供一种在xsd：重新定义场景中使用的工具;对于那些不想解释由其他人创作的XML模式的人来说。如果一个人拥有（作者）模式，那么可以通过先定义较小对象并从其中扩展来解决需要限制的需要。
<对于对象的扩散，你也可以通过选项＃2获得（与＃1相比）;我的意思是，我所知道的所有工具将为您在XSD中的每个命名（全局）复合类型创建一个类;所以如果你必须有三种类型的帐户，你将有三种情景＃1，如果你选择从一个或者更多的基类扩展四个，当你需要三个专业（具体如果你愿意）时，最后的情况将会是最糟糕的情况。无论如何，从我的经验来看，现实生活中的不同之处不在于真正提示决策的方式。
在XML Schema中扩展基础类型是好的用于重用;然而，重用带来耦合;如果您从前向/后向兼容性角度分析这一点，则扩展基本类型的内容可能会对您不想更改的服务的客户端的XML进行解组（反序列化）他们的代码库，但是您只想为所有人维护一个Web服务端点;在这种情况下，依赖于xsd的前向兼容性策略：在合并器（xsd：sequence）的末尾任何一个将在您的第一个版本中变得无用，并扩展了您的基本类型。
还有更多的东西;因为这样，我不认为有正确的答案，只是为了你设置你的亲/弊的你似乎暗示的标准。
以下所有我喜欢的选项都假设您高度重视要求，以确保服务的前向/后向兼容性，并希望最大限度地减少客户的成本必须处理您的服务（因为XML Schema更改）。
我会说，如果您的所有域（特别是帐户）可以完全建模（假设基本上没有未来的变化）和，有足够的共性来证明重用，然后再选择＃2。否则，选择＃1，因为我还没有看到没有改变的东西...
如果您的域的建模可以完成80％以上（或您认为高的一些数字）和，有足够的通用性来证明重用，那么我仍然会选择＃2，需要注意的是，任何未来扩展的帐户中的共同属性，必须适用于每个个人账户（基本上将您的期权变为混合账户，通过＃1）。
对于其他任何事情，我会去＃1。呃，我不敢相信我写了所有这些...
We are currently building a pile of SOAP Web Service to front the access of various backend systems.
While defining our Request/Response message XML, we see multiple services needing the ‘Account’ object with different ‘mandatory/optional’ fields.
How should we define and enforce the validation of these ‘mandatory/optional’ fields on the same Message? I see these options
1) Enforce validation with XSD by creating different 'Account' Complexe Type
Pros : Design time clarity.
Cons : proliferation of Object Type, Less reuse of Object,
2) Enforce validation with XSD by Extending+Restriction a single base 'Account' type
Pros : Design time clarity.
Cons : Not sure of the support of the Extend+Restriction feature (java, .Net)
3) Using a single 'Account' type and enforcing validation in runtime (ie in the Code).
Pros: Simple
Cons: No design time validation. Need to communicate field requirements via a specification doc.
What are you’re thoughts on that?
I would have to assume that: i) some of what you would call optional fields are actually fields that are not applicable (don't make sense) to all accounts and ii) we're not talking trivial scenarios (like two type of accounts with 2 fields each-kind of thing).
Firstly, I would say that unless you're really lucky, from a requirements perspective, then you're going to end up with some sort of "validation in runtime" no matter what option you're going with. XML Schema can't express some common data validation requirements, such as cross field validation; or simply because the data in your XML is not sufficient to feed the rules to validate the integrity of the message (the data in the message being a subset on what's available at the time the XML is being un/marshalled).
Secondly, I would avoid deriving new complex types through restricton; from an authoring perspective you don't achieve much in terms of reuse, and you might end up with problems in how that is interpreted by your XSD to code tooling. I like to think that the original intention of deriving through restriction was to provide a tool for people to use in xsd:redefine scenarios; for people that wouldn't want to fiddle with XML Schemas that were authored by someone else. If one owns (authors) the schema, one can work around the need to restrict by defining the "lesser" object first and extend from that.
As to the "proliferation of objects", you are kind of getting that with option #2 as well (when compared with #1); what I mean by that, all the tools I know will create a class for each named (global) complex type you have in your XSD; so if you have to have three type of accounts, you'll have three for scenario #1, and four, or so, if you choose to extend from one, or so, base classes; a worst case scenario for the later would be when you need three specializations (concrete if you wish); anyway, from my experience, the difference in real life scenarios is not something that would really tip the decision one way or the other.
Extending base types in XML Schema is good for reuse; however, reuse brings coupling; if you're analysing this from a forward/backward compatibility point of view, extending something in the base type could mess up some of the unmarshalling (deserialization) of the XML for clients of your service(s) that don't want to change their code base, yet you want to maintain only one Web Service endpoint for all; in this case, a forward-compatibility strategy that relies on an xsd:any at the end of a compositor (xsd:sequence) would be rendered useless in your first release that goes and extends your base type.
There is even more; because of this, I don't think there's a correct answer, just for the criteria you seem to imply by setting your pro/cons.
All of my preferred options below assume that you put high value on the requirement to ensure forward/backward compatibility of your services, and you want to minimize the cost of your clients having to deal with your services (because of XML Schema changes).
I would say that if all your domain (accounts in particular) can be fully modeled (assume no future change basically) and that there is enough commonality to justify reuse, then go with option #2. Otherwise, go with option #1 since I have yet to see things that don't change...
If the modeling of your domain can be done 80% or more (or some number that you think is high) and that there is enough commonality to justify reuse, then I would still go with option #2, with the caveat that any future extensions for common attributes across accounts, must be applied for each individual account (basically turning your option into a hybrid, by doing #1).
For anything else, I would go #1. Whew, I can't believe I wrote all of this...
这篇关于Web服务“强制/可选”字段：XSD设计时间与运行时间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
