“这阵子参与编写一本SOA
专刊，因篇幅关系，部分内容无法纳入，在此将其以博客形式发表。”
SOA 参考架构 (Reference Architecture) 是一个框架，使各个项目都有一个遵从的依据，借以促进一致性、最佳实践典范，和标准化。参考架构并不受限于目前的
IT 现况，而应该针对一个经过深思熟虑的愿景目标，可以说是 IT 指导未来所有的新开发工作，借以实现该目标的参考依据。一般来说，2-3
年的规划，是一个比较合适的涵盖范围，既能提供足够的时间来达成面向服务的转型，而又不至于过于长远而虚幻。因此，参考架构提供了一个沟通目标愿景的方
法，协助部门和角色各异的 IT 人员，逐渐朝向该目标会合。
高效的 SOA 需要采用新的方法来对待 IT 基础设施，并且根据个别企业的需求来量身定做，并将服务基础架构、共享的技术服务、安全服务，以及信息／数据、和遗留系统访问服务等，全部定义在内。
为了满足 SOA 的要求，所有公司都需要 SOA 参考架构和路线图，来指导部署一套能随时间演进、而逐渐丰富的工业级服务基础设施，同时指导对面向服务应用的开发和管理。
此外，企业也需要对参与 SOA 架构的各个个别系统的设计，进行监管，并在适当的地方，建立通用服务，透过协作来发挥更高的效率。对于这些举措，连接端点的标准化（通过建立定义清晰的契约和接口），是达成
IT 系统一致性的先决条件。
SOA 参考架构指导所有实施 SOA 的各个项目，能共同朝向企业级服务，和 SOA 基础架构标准方向的集中发展，尽早使企业从中获益。换句话说，参考架构规划的重点，在于开发一个特定于某个企业需要、切实可行的路线图，以填补当前和愿景
目标之间的鸿沟；评估用于开发、部署和管理、监控的现有系统和技术，定义目标状态愿景，目标参考架构模型。
SOA 参考架构可说是指导 SOA 成功的蓝图，其作用包括：
- 促进 IT 与业务的紧密配合： 参考架构的制定，以业务驱动力和 IT 目标为出发点，分析 SOA
解决方案能对这些驱动力带来多大的正面影响，进而为从目前 IT 现况演化到愿景架构，定出实现架构、相关规范及路线图。参考架构因此提供了从业务和
IT 目标，到实现架构间的可跟踪性，是业务与 IT 之间进行沟通的重要媒介，是企业实现业务灵活性、可管理性和变更规划的基础。
- 协助企业向重用、团队协作和资源共享的文化迁移：参考架构确立了 SOA 架构标准和技术部署的最佳实践，为日后各个
SOA 的实施项目，订立架构遵从性的度量标准和指标。
参考架构并非一成不变。在一个新的 SOA 策略与规划迭代中，SOA 的参考架构和规范标准，可能需要针对新的业务、IT
情况，和已实施的 SOA 项目中得到的反馈，进行调整，因此，SOA 参考架构不仅是 IT 模板，也是也描述
SOA 原则和标准的活文档。
我们可以将参考架构的内容，粗分为两大部分：
- 对服务建立一套共同的词汇和做法，包括：
- 服务的正式定义 – 例如服务必须由契约 (contract)、接口 (interface)，和实现
(implementation) 所组成
- 服务的分类（核心业务功能服务，数据服务，展现服务等），以及各类服务的设计原则和建议
- 接口标准 (JMS, RMI, HTTP 等)，建议的接口样式（例如：尽量采用粗粒度、异步的服务调用模式），可靠性要求等
- 需要遵从的 WS-* 标准
- 安全策略
- 服务版本控制策略
- 服务和数据模型采用规范
- 服务生命周期定义
- 与服务基础设施，例如企业服务总线 (ESB)、业务流程管理 (BPM)、注册库 (Registry)、资产库
(Repository) 等相关的规范，包括：
- 必须支持什么样的部署配置
- 必须具备什么样的能力
- 各个部件的责任
- 部件之间的耦合关系和原则，应避免的事项，例如，展现服务和业务流程服务不可直接调用数据服务，而必须通过核心业务服务；换句话说，数据服务不可直接与展现服务和业务流程服务有耦合关系
- 各个部件应支持那些科技和标准（例如：SCA, SDO…）
- 有哪些安全顾虑需要考虑，如何管理权限
- 要采用哪些产品
由于在规划服务基础设施参考架构时，需要涵盖几类 SOA 参与者和干系人 (stakeholders)
各自不同的顾虑，包括架构师、程序员、和负责部署、运营、监控的
IT 人员，我们可以采用一个针对服务基础设施参考架构调整过的 4+1 视图（如下），来协助我们分离顾虑，来将不同层面的规范和目标架构一一制定，通过逻辑、实现、部署，和进程等四个视图，配合最佳实践典范和模式，来对参考
架构的各个层面，进行描述和规范，如附图。
图说: 为 SOA 参考架构调整过的 4+1 视图，源于 Kruchten 在 1997 年发表的《Architectural
Blueprints – the 4+1 view model of software architecture》
图说: 服务基础设施参考架构的逻辑视图 (Logical View)
图说: 服务基础设施逻辑视图下的功能视图 (Functional View)
图说: 服务基础设施参考架构的实现视图实例（场景为某电信客户的 provisioning service），描绘所计划采用的产品，以及如何通过这些产品间的交互，来实现解决方案
参考架构的规划过程（如下图），应先起于业务驱动力 (business drivers) 分析，可有助确保目标架构能够支持业务的发展策略和方向，展现
SOA 建设对业务的价值，彰显 SOA 投资的正当性，并获得相关业务部门的经费赞助。以金融行业为例，业务驱动力包括像是：
- 提升效率
- 借贷流程优化
- 呼叫中心优化
- 增长销售额，并显著超越同业
- 快速灵活地推出创新的金融商品
- 扩展客户关系，统合客户数据
- 交叉销售
- 依据关系定价的策略
- 降低成本
这一类的价值驱动。分析业务的价值驱动后，接着考虑各种 IT 目标，以及它们如何支持这些业务驱动力；例如：
- 从关注各业务线烟囱／竖井式的应用系统，转向专注于跨系统／业务线的流程／服务
- IT 资产重用
- 提高跨部门协作的业务流程的透明度
并且应订立评价标准，作为日后考核实现各价值驱动力的指标。接着下来，我们可以根据业务和 IT 驱动力，进一步制定恰当的
SOA 策略，考虑采用 SOA，将对那些业务线，在那些驱动力方面，产生最大的价值，据以订立实施 SOA
项目的优先级别。
图说: 参考架构规划过程
图说: 从业务驱动力和价值链分析，来找出应优先考虑采用 SOA 来协助提升的业务和 IT 能力。
√√代表 SOA 项目能产生很大的正向影响，依此类推。
针对各价值驱动力，我们可以参考附图中的矩阵分析方式，从价值链或业务线中的各个主要的职能（纵向），和各个识别出来的业务和
IT 驱动力（横向），对 SOA 所可能产生的正面影响力，一一进行评估，进而挑选出面向服务解决方案最能嘉惠的业务能力，作为首期实施
SOA 项目的切入点。图中的范例只是一个三万尺高空的起点，在真实的情况下，往往会针对范例中某个或某几个得分较高的业务线，往下展开细化，对该业务线中的各个
主要业务能力，进一步进行 SOA 价值驱动力分析；换句话说，价值链分析中的各个职能域，应该自粗到细，逐步钻取、drill
down 到适当的深度，才能更精准地确定 SOA 能对哪些要迫切改善的业务能力，带来最大价值。
依据业务和 IT 驱动力，选定了 SOA 策略后。接着应根据企业目前的现况，和未来 2-3 年的目标，进行差距分析，并根据最佳实践典范
(best practices)，制定 SOA 发展的蓝图、路线图和指导规范，完成参考架构的规划。接着便可开始根据路线图中制定的项目，以渐进的方式，通过一致的服务工程方法，一个接一个项目去执
行，并在此过程中，逐渐将蓝图中的服务基础设施搭建起来。 | 
