文章
面向服务的架构
|
|||
|
作者:Jürgen Kress、Berthold Maier、Hajo Normann、Danilo Schmeidel、Guido Schmutz、Bernd Trops、Clemens Utschig-Utschig、Torsten Winterberg
探讨将工厂方法用于面向服务的现代软件开发的基础知识。
行业 SOA 文章系列的一部分
2013 年 7 月
在本文中,我们将介绍并探讨将工厂方法用于面向服务的现代软件开发的基础知识,尝试将 SOA 行业化与服务合同相结合。作为服务开发人员和设计人员,我们如何成功满足工厂需求并实现行业化 SOA 基本特征,同时符合服务合同级别的标准?
人们已发现按照合同进行思考是对底层实现进行虚拟化的粒度采购战略所必需的。一般来说,合同还可以作为业务单元和 IT 团队之间、各种云计算技术之间,以及面向未来的敏捷企业的通用语言。
假设在今天的“前行业化”时代中,合同已被组织孤岛和科技孤岛以及最佳解决方案所取代。在今天的 SOA 环境中,功能组件都是针对具体应用创建的,往往会造成冗余并且在接口级别缺乏组织级标准化。这些组件在“孤岛”环境中运行良好,其中的“应用 SOA”架构尤其适合单一应用环境:
图 1 展示了通过将标准化设计和结构用作接口和交换数据的框架,在应用程序中组合服务是多么简单:

如果一个业务活动服务 (BAS) 包含多个“应用 SOA”的不同设计的业务实体服务,所交换的数据结构差异很大。可以针对每个应用服务构造一个差别很大的“合同”业务对象(图 2)。

图 3 显示,虽然所有服务都基于 SOAP 和 WSDL 之类的底层标准,但每个经过编译的服务是多么需要高水平的集成工作。不同数据类型的结构特征导致大量的集成工作。

由于缺乏行业标准,所以服务使用也需要高水平的集成工作,这就导致服务重用工作很难维护且成本高昂。这些缺点导致开发人员更愿意自己构建功能而不是使用服务。集成工作因此成为通往成功采用 SOA 道路上的主要障碍。
该解决方案在于域级标准,这些标准位于功能数据交换和技术横截面数据交换级别。选择使用 LEGO® 比喻来说明服务合同中标准化的必要性,因为 LEGO® 积木块结构的均匀性可产生完美的契合。LEGO® 积木块就算只有一个小瑕疵或者小凸起也无法正确安装到其他积木块上。同样,仅通过标准化交换的数据就可以简化服务重用。
图 4 显示了基于相同标准的服务怎样才能像用 LEGO® 积木块搭建的结构那么容易组合。这就是 SOA 的必杀技。构件连接器(集成层)将变得非常小或者干脆消失。

行业化方法一个最重要的特征是接口或“服务级别协议”的域级标准化。该协议是一个合同,服务可通过其用户进入其中,而且该协议是作为流程和门户的功能组件进行合并的 BAS 的先决条件。不需要大量的集成工作,可通过企业资产管理 (EAM) 或业务流程管理 (BPM) 信息板评估 SLA 合规性。
可以设想在 SOA 信息板上集中确定规范,作为在整个企业或组织内建立标准的一种选择。SOA 治理任务检查并验证其使用情况以及否符合适用的规范。这些治理任务需要大量工作才能符合标准接口的规范,这对每个服务来说都是必须完成的任务。可通过实现模型驱动生成服务合同来减少这方面的工作,从而使服务开发人员可以重点关注服务实现。

SOA 架构师为参考数据类型和横截面数据类型定义业务对象数据类型,为应对各种错误做好准备。底层业务对象及其属性作为对象模型保存在中央信息库中,如统一建模语言(UML)。服务设计人员定义合同时使用这个集中的对象存储库,并将该存储库“放入”生成器中,按照之前指定的规则创建服务接口。该流程演示了工具专家如何根据所选数据、横截面数据和参考数据定义标准化 WSDL 的编译。
在运行时交换 SOAP 消息。标准化填写 SOAP 头(还包含用于信息板评估的重要信息)是企业服务总线 (ESB) 的任务之一。ESB 仅针对该任务进行一次配置,通常无需编写服务的开发人员进一步参与。
现在,根据中央架构标准创建接口规范、WSDL 和 SOAP 消息。超越这个标准结构或者在其外部生成服务合同是不可能的。从开发人员规范和监视规范合规性的治理任务转向生成器驱动的合同制造流程,这是将工厂方法用于行业化 SOA 的关键方面。