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

Mag*_*nus 17 java versioning service version web

背景:

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

有很多关于Web服务版本化的信息,我们的决定是使用以下方法来版本化我们的Web服务:

  • 保留URL中的版本(我知道有些人反对这个,但主要是关于REST服务)
  • 保留命名空间中的版本

但是,现在我们正在决定如何实际实现这一点,而在这里我们还没有找到关于最佳实践的大量信息.我们使用(Java):

  • 用于定义Web服务(和Web服务API)的注释
  • 用XML注释注释的POJO bean,用于定义内容
  • 用于转换/转换到业务层和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
Run Code Online (Sandbox Code Playgroud)

所以,这里我们有重复的代码.我们的想法简而言之:

  • 代码重复.将是几个具有相同代码的类.也许在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
Run Code Online (Sandbox Code Playgroud)
  • 可能很难清楚地看到什么构成了特定版本的Web服务.在维护代码时,误操作可能更容易影响以前版本的Web服务
  • 没有代码重复.仅将更改实现为新类

这两种方法都不是最佳方法,但我们没有找到关于此的更多信息.所以,我的问题是: 你会使用哪两种方法?或者你会采取完全不同的方法?

小智 6

从Java生成wsdls时,我会使用包解决方案:

com.company.webservice.v3.  
Run Code Online (Sandbox Code Playgroud)

它存在代码重复问题,但是POJO和转换器之间的版本之间存在差异,因此代码重用可能不太可行.主要优点是,如果你想摆脱旧版本,你只需要删除相关的包.

我会在URL中保留versionnumber,因为你还没有做REST.此外,如果仍使用某些版本,您可以签入访问日志.