SOA实施要点:
1、 SOA的构建次序。是从上到下还是从下到上?我个人倾向于从大局进行把握,因为SOA中重要的不是技术,而是对业务的定位。如果从下往上去设计服务的话可能会做很多重复劳动工作,或者在真正去用的时候返工。应该在设计的时候进行足够的需求调研,挖掘出业务的核心并对外提供。但是设计时候肯定会有很多没考虑到的东西,或者说想的过于粗,那么在开发的时候也可以进一步去讨论需要公开的服务,补充上粒度比较细的那一部分。也就是说先把握大局从上到下,然后抓住细节从下到上。
2、 SOA的测试过程。作为客户端程序,在需要的服务尚未建立的时候,需要自己创建基于接口的FAKE服务进行测试,等服务在网络端点上部署之后使用服务代理进行替换(当然,理想的方式是由客户端代理自动生成FAKE服务和测试数据)。作为服务的主办者,需要在服务发布之前对服务的边界、逻辑和性能进行严格的测试,作为服务端是不知道我的客户是什么的,我要处理所有可能的情况。
3、 SOA的持续建设。虽然说契约是不变的,但不代表服务不变。服务的业务逻辑是需要不断完善的。服务也是可以扩充的。没有什么事情是在一开始的时候就完美的,如果服务没有持续建设作为保障的话,可能花费很大时间做出来的服务并没有多少人愿意来使用,导致整个服务层越来越孤立越来越偏离SOA,最终导致SOA实施的失败。我们不要去怕服务做的不好,不好的地方就去不断修正,如果服务没有客户来消费的话那就很危险了。
4、 SOA的基础结构。不管是叫ESB或者其他什么名词,基础结构总是需要的,而且应该在实施前进行这个基础结构的建设。其中有一些东西是非常重要的。一是可靠性的保证服务,比如如何去做服务的负载均衡,如何去做事务,如何去做服务的流量控制,如何实现消息的加密和安全。第二是服务的监控和管理,比如服务调用的异常记录,系统的状态,系统的配置,系统的部署。第三是服务的中介,比如服务的路由、异步队列、消息转换。第四点是服务的管理平台的平台,比如流程管理、契约管理、部署管理。从技术上说这个基础结构应该是尽量对开发人员透明的,并且也是也是需要不多的人为的参与,以代码生成工具、AOP、管理工具等方式实现。这一套框架是SOA开发前期需要完成的,也是技术难度最大的。在完成后对开发人员进行技术上的培训和流程上的培训。
SOA概念误解:
1、 SOA 不是技术(当然也不是WEB服务)、不是产品、不是新概念、不是一尘不变的。SOA是SO的A,也就是说是符合面向服务思想的架构(可能需要WEB服务作为某项技术来参与,但不能说它就是WEB服务)。SOA的成功需要一套产品的支持,但本身不是产品。SOA为什么不是新概念?我们生活中需要用到各种服务,我们只需要按照要求,写一些表格(契约),对方就会给我们结果,这不是SOA是什么,计算机硬件中很多地方也是SOA的思想(其实我一直觉得软件工程走在硬件工程的后面,很多开发上的思想在硬件设计中都能找到原型)。SOA没有实施结束的那一天,一定是不断变化不断改进的。
2、 SOA可大可小,可以是企业内部的,也可以是企业与企业间的,可以是同构平台也可以是异构平台,因此,SOA很难套用,甚至没有哪个公司对SOA的实施是一模一样的。SOA可能会很简单也可能会很复杂,复杂不是说技术上的复杂,很多时候在于管理上的复杂性,因为里面融合了业务,业务是会变化的。复杂性还体现在可能是基于老系统进行实施,需要考虑到数据兼容问题以及数据集中的问题。
3、 SOA不一定是一层的。没有规定服务的消费者一定是客户端,服务的消费者可以是服务,也就是服务的组合,多层的服务能进一步提高重用。