SOAP：如何在不破坏现有客户端的情况下扩展类型？
我有一个使用 Apache Axis 2 实现的 SOAP 服务。它有一个 Message 类型，它具有以下定义
<xs:complexType name="Message">
<xs:sequence>
<xs:element minOccurs="0" name="id" type="xs:int"/>
<xs:element minOccurs="0" name="caption" nillable="true" type="xs:string"/>
<xs:element minOccurs="0" name="text" nillable="true" type="xs:string"/>
<xs:element minOccurs="0" name="source" nillable="true" type="xs:string"/>
</xs:sequence>
</xs:complexType>
我必须将 source 元素替换为对复杂的引用输入源。在避免破坏现有客户的同时，最好的方法是什么？
I have a SOAP Service that is implemented using Apache Axis 2. It has a type Message which has the following definition
<xs:complexType name="Message">
<xs:sequence>
<xs:element minOccurs="0" name="id" type="xs:int"/>
<xs:element minOccurs="0" name="caption" nillable="true" type="xs:string"/>
<xs:element minOccurs="0" name="text" nillable="true" type="xs:string"/>
<xs:element minOccurs="0" name="source" nillable="true" type="xs:string"/>
</xs:sequence>
</xs:complexType>
I have to replace the source element with a reference to a complex type Source. What is the best way to do this while avoiding to break existing clients?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Martin Fowler 提供了一篇关于架构版本控制和扩展点的精彩文章。然而，由于您现在没有扩展点，这不适合您。业界广泛使用的一种方法是在给定时间点拥有多个版本的 WSDL 和 XSD。因此，如果您的 Web 服务是使用四个组件指定的：
，并且您需要引入非向后兼容的更改，您可以复制组件#1 和#2 并为它们定义另一个名称空间，例如
“http://www.example.org/abc_v2”。您必须为新版本的服务（#3）生成一个提供程序，并“以某种方式”将其与组件#4 集成 - 毫无疑问，这是丑陋的部分。这种方法是有效的，尽管它并不好，因为您复制了许多需要维护的代码。如果您遵循这种方法，您应该为仍在使用服务版本 1 的所有客户端定义一个截止日期，以便您稍后可以删除重复的代码。
总而言之，这不是很好，但也是一个选择。
Martin Fowler provided a great article about schema versioning and extension points. Neverthess, as you don't have extension points today this is not an option for you. An approach heavily used in the industry is having more than one version of your WSDLs and XSDs at a given point in time. So if your Web Service is specified using four components:
and you are required to introduce non-backward compatible changes, you can duplicate components #1 and #2 and define another namespace for them, e.g.
"http://www.example.org/abc_v2". You have to generate a provider for the new version of your service (#3) and 'somehow' integrate it with component #4 - no question, this is the ugly part.This approach works, although it is not nice as you duplicate a lot of code that wants to be maintained. If you follow this approach you should define a deadline for all clients still using version 1 of your service, so you can get rid of the duplicated code later.
To conclude, not nice but an option.