我们不能忘记,几乎没有什么解决方案是在不考虑现有应用程序的情况下构建的,这些现有应用程序提供了支持解决方案的功能或解决方案必须与之交互的功能。
所以应当对将作为任何解决方案的一部分加以复用的现有旧应用程序进行编目,并确定它们的功能,这是极其重要的。 通过面向服务的解决方案,我们能够采用许多方法将新的服务与现有的功能进行集成。 下图展示了这些方法:
-
将现有功能合并为一个服务。在此情况下,我们希望原样保留功能,但使用工具或中间件来将现有的功能展现为一个服务。 例如,IBM 提供了将旧的 CICS 事务展现为 SOAP Web service 的能力。
-
用一个服务合并和替换现有功能。在此情况下,我们按照前面所述对功能进行合并,但我们使用得到的服务规范在以后重新开发该服务,方法是替换原来的服务并将客户重定向到新的实施。
-
使用更服从于服务调用的适配器。在某些情况下,无法合并功能并将其显现为一个服务,但是可以将该功能合并到更易于集成的对象中,例如消息队列接口或 Java Connector
Architecture(JCA)。这使得新服务能够访问相应的功能。
-
将功能集成到服务中。很明显,在某些情况下,只需将旧功能用作服务实施内的逻辑组件,新服务就可以访问相应的旧功能。
第三和第四种方法提供的灵活性应当是最大的,这是因为这两种方法使用的是现有的功能,但并不继续按原样向客户显现该功能。 而第一和第二种方法在将现有功能合并为服务时可能会引起问题,这是因为 Web service 协议的性能与本机数据格式和
XML 的不匹配可能会引起性能问题。
必须对现有软件资产及其依赖关系和接口进行分析,以便确定是否需要进行更改才能支持业务功能。例如,为了替旧的业务功能实施创建 Web service
接口,分析可能涉及到检测联机事务、批处理作业,或有助于执行此功能的持久数据存储的组合和流程。 可能必须更改现有应用程序的当前设计才能支持此功能。 还需要确定使用所期望的服务质量创建 Web service 接口时可能遇到的任何障碍。 例如,业务功能的整体批处理实施在作为服务调用时可能需要亚秒级的响应时间。
将现有资产合并为一个服务模式
然而,在某些情况下,可以开发一个旧服务分区,其中有一组低级别的旧功能单独显现为服务。 只有较高级别的服务才能访问此分区,利用它们向服务使用者展示更详细的以业务为准的规范。
对旧功能的此封装应视为一种临时解决方案,只应在充分了解合并技术的性能特性时才采用。 有关更多信息,请参阅概念解决方案分区。
从某种角度来看,旧功能合并是服务供应商模型元素的一种简化形式,它通过一个单独的服务实现只具有单一操作的单个规范。 下图展示了旧功能“更新客户地址”的该模式。
在定制此模式时,您可能需要执行以下操作:
-
一组现有功能可能由同一组件提供,因此应使用相同的服务供应商。
-
上述模式是自动生成的;最好使用“exec${service}”格式对缺省的操作名称进行重命名。
-
类似地,对缺省生成的消息进行重命名也是很有意义的;与此同时,应对消息结构进行建模。
-
缺省的模式假定操作获取一条输入消息并返回一条消息;旧功能可能不返回任何消息,或仅返回一个通知,因此应当对生成的操作签名进行修正。
-
架构设计师/设计人员应确保为服务供应商上的“allowedBindings”属性指定正确的值。
|