Spring-WS概览
Spring Web Services(下面简称Spring-WS)是Spring的一个子项目,主要关注与构建contract-first的web service。在解释contract-first之前,我们先来说说contract-last的web service。
我们曾经使用XFire将bean导出成一个web service——首先要编写服务实现的java代码,然后在Spring中配置bean,最后使用XFireExporter导出web service。我们从不需要显式地定义服务的规则(contract,即WSDL和XSD)。相反,XFire会在服务被部署之后自动地产生这个规则。这就是contract-last。
由于contract-last的方式非常简单,所以它在web service开发中很常用。使用这种方式,开发人员不需要操作复杂的WSDL和XSD文件。他们只需要编写一个Java服务类,然后利用web service框架将它SOAP化即可。不过存在一个问题:如果以这种方式开发web service,那么它产生的contract就将应用程序内部API的反射,但通常你的应用的内部API总是比预期变化的要快。任何API的变更都意味着服务contract的变更,从而导致使用你服务的客户的变更。
这就是经典的web service版本命名问题。改变web service的contract比改变客户代码要容易得多。试想你的web service有1000个用户。一旦你修改了服务的contract,那么你的1000个客户都将无法使用服务,除非他们也进行修改以适应新的服务contract。这个问题的一个常用解决方案就是在所有用户都变更完代码之前维护一个服务的多个版本,但是这会导致维护成本的增加。
更好的一个解决方案就是避免服务contract的变更。如果非要进行变更,那么变更不能破坏和以前版本的兼容性。可以想见,如果服务contract是自动产生的,这就是很困难的事情。
简而言之,contract-last的问题在于服务最重要的部分:contract,是后来添加进来的。一个contract-last的web service关注于服务如何被实现而不是它应该做什么。
解决contract-last的方法就是把它放到头部——先产生contract然后在确定它如何被实现——这就是contract-first方式的web service。这种方式不是编写关于应用程序会是什么样子的规则。这是一个实用主义的方法,因为它只关注于服务的预想样子而不是它将以何种方式被实现。下面我们就先创建一个contract-first的web service,这涉及到三个步骤,如下图所示:
为了更好地说明基于Spring的web service,我们创建一个扑克牌估算服务,如下图所示:
因为我们要创建一个contract-first的web service,所以我们首先需要做的就是定义一个服务contract。(未完待续)