SOA代表了面向服务的架构。
例1 (来自真实世界) :你去餐馆订餐,您的订单首先进入到柜台,然后在厨房进行食物准备,最后服务员提供的食物。因此,为了实现一个餐厅订购服务,您需要三个逻辑部门/服务协同工作(计帐,厨房和服务员)。在软件世界同样的方法称为业务服务。
例2 (软件世界) :你去亚马逊订购了一本书,有不同的服务,如支付网关,库存系统,货运系统等共同完成一本书的订购。
所有的服务是自包含的,合乎逻辑。他们就像黑盒子。总之,我们并不需要了解业务服务的内部工作细节。对于外部世界,它只是一个能够使用消息交互的黑盒子。
SOA代表了面向服务的架构。 SOA是一种使用松耦合的黑盒子服务构建业务应用的体系架构,这些服务可以通过编排连接在一起以实现特定的功能。
B) SOA服务是黑匣子。在SOA中,服务隐藏有内在的复杂性。他们只使用交互消息,服务接受和发送消息。通过虚拟化一个服务为黑盒子,服务变得更松散的耦合。
C) SOA服务应该是自定义: SOA服务应该能够自己定义。
D) SOA服务维持在一个列表中: SOA服务保持在一个中央存储库。应用程序可以在中央存储库中搜索服务,并调用相应服务。
E) SOA服务可以编排和链接实现一个特定功能: SOA服务可以使用了即插即用的方式。例如,“业务流程”中有两个服务“安全服务”和“订单处理服务” 。从它的业务流程可以实现两种类型:一,您可以先检查用户,然后处理订单,或反之亦然。是的,你猜对了,使用SOA可以松散耦合的方式管理服务之间的工作流。
可重复使用的服务通过业务活动标识,这个业务活动是使用服务规范(设计时合同)描述的。
一个服务约束是,包括安全性,QoS,SLA,使用策略,可以由多个运行时的合同 多个接口(WSDL中的Web服务)以及多个实现(代码)定义的。
可重复使用的服务应在被管制在其从设计到运行整个企业级生命周期。其重用应通过规范流程来推动,重用应该是可测量的。
====================================================================
通常,一个架构师进行系统架构顶层设计时,必须考虑使用者的利益,不能单单实现软件的功能,还要考虑到软件的性能Scalable 可用性available/usable 安全性等软件质量,还要借鉴社区的最佳实践和经验形成的模式和反模式,避免重蹈覆辙和陷阱,再大胆采取最新的软件技术(比如用REST替代SOAP等)。
服务的提出其实隐含了两个概念,服务提供者和服务消费者,这两者之间有一个合同约定,这非常类似我们现实生活中签订的服务合同,A单位和B单位分别是服务的提供者和消费者,两者签订了一个服务合同,规定A为B提供某项服务。服务就是提供一些公共需求的设施,通过一个工作过程能提供帮助,使用,让使用者受益。
服务具体有如下:Windows Service:如PC定位者RPC Locator, 事件日志EventLog, DHCP Client,;. 软件服务Software Service,如分布式服务Distribution Service, 警告服务Alert Service 安全服务 Security Service, 日志服务;业务服务Business Service,如 帐号和客户服务,销售服务,订单服务,采购服务。
服务两个重要特点:自治和管制,自治代表服务不能被外部势力牵制,比如如果一个服务内部处理中需要调用外部资源或等待外部流程结束,这种等待不能影响服务本身的调用,如果一个服务分为显式对外和隐式内部两个部分,那么自治是针对隐式内部,意味着我们不能在具体一个服务中直接使用同步代码实现复杂功能。如:
public AServiceImpl implements AService{
public void productSale(...){
Product product = productService.getProduct();
int inventory = InventoryService.getInventory(product);
int price = priceService.getPrice(product);
}
}
在AServiceImpl的productSale方法中,我们获得商品的库存和定价,都是通过同步的RPC实现调用的,这样造成productSale方法依赖于InventoryService和priceService,无法实现自身自治。
实现服务真正自治,实际就是解决类之间依赖耦合的问题,消息是一种方式,但是基于消息又有两种通讯方式,基于请求响应和基于事件的EDA。
从服务自治可以看出,为什么要提出服务必须自治,因为服务是受管制的,在实际业务活动中,不同服务是被不同部分管理,比如定价服务归属财务部门系统,库存归属仓库系统,涉及系统之间调用协调不能自己使用同步RPC,而是需要消息。
在实际应用中,很多单位使用SOA主要看中其能够无缝整合新旧系统,称为EAI企业应用整合,下图是苏宁的一种SOA图,使用ESB企业服务总线这样的消息系统整合了新旧各种系统。
使用SOA和ESB能够灵活实现业务流程管理,工作流的管理BPM,如下图,一个订单的产生可能需要几个部门批准才能完成,而且这几个部门经常是变化的,如何灵活实现这种批准流程的定制也成为SOA实现的一部分,如下:
注意图中1 2 3 4 5 6 7 8 9标注的订单处理流程步骤,这种不同服务之间调用处理顺序可通过BPM进行灵活定制
目前提供SOA全套解决方案和产品的厂商很多,包括IBM SAP和Oracle,国内金蝶用友浪潮软件等等,比如苏宁的SOA是以SAP为主的八国联军组装,既然SOA中间件服务商已经为我们提供了成熟的架构方案和产品,那么作为SOA使用者是否就无需顶层架构设计了呢?当然不是,SOA使用者要根据自己业务进行模块划分,进行领域建模设计,根据DDD领域驱动设计将业务分解为一个上下文模块,然后再用服务作为对外接口,内部封装的是DDD聚合根,而传统SOA作法是内部封装的是数据表的DTO,从而导致SOA服务内部腐烂堵塞,违背SOA自治和可用性等原则约束。具体可见DDD领域驱动设计。
====================================================