如何处理版本化 SOAP Web 服务的代码？

背景：

• 我们的网络服务是公司内部的，但有许多不同的系统使用它们
• 我们将努力尽可能多地弃用/删除API的旧版本

有很多关于 Web 服务版本控制的信息，我们的决定是使用以下方法来对 Web 服务进行版本控制：

• 在URL中保留版本（我知道有些人反对这一点，但主要是关于REST服务）
• 将版本保留在命名空间中。

但是，现在我们正在决定如何实际实现这一点，在这里我们没有找到太多最佳实践的信息。我们使用（Java）：

• 用于定义我们的 Web 服务（和 Web 服务 API）的注释
• 使用 XML 注释注释的 POJO 豆，用于定义内容
• 用于从/到业务层和 Web 服务 pojo 的转换器类
• 春天

因此，要将旧版本保留在 Web 服务上，我们需要保留旧版本的代码。为此，我们基本上研究了两种不同的方法：

1）对于每个新版本，制作相关代码的完整新副本

此方法如下所示：

com.company.webservice.v3. -all of the web service classes, POJO’s and converters go here
com.company.webservice.v4. -all of the web service classes, POJO’s and converters go here

因此，在这里我们复制了代码。简而言之，我们的想法是：

• 代码重复。将是具有相同代码的多个类。也许在Eclipse中令人困惑。
• 完全隔离，易于确定特定版本的构成
• 将影响以前版本服务功能的风险降至最低

2）使用spring只制作受更改影响的每个类的副本

这种方法意味着使用Spring IoC并让所有版本的Web服务尽可能多地使用相同的代码。只有当我们做出影响行为/api的更改时，我们才会制作这些类的新版本。例如：

com.company.webservice.beans.MyXMLAnnotatedPOJOv3.java
com.company.webservice.beans.MyXMLAnnotatedPOJOv4.java
com.company.webservice.translators.MyXTranslatorv1.java
com.company.webservice.translators.MyXTranslatorv2.java

• 可能很难清楚地看到 Web 服务的特定版本构成。在维护代码时，可能更容易通过错过影响Web服务的先前版本
• 无代码重复。只有更改作为新类实现

这两种方法都不是最佳选择，但我们没有找到太多有关这方面的信息。所以，我的问题是：你会使用这两种方法中的哪一种？或者你会采取一种完全不同的方法吗？