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发展的蓝图、路线图和指导规范，完成参考架构的规划。接着便可开始根据路线图中制定的项目，以渐进的方式，通过一致的服务工程方法，一个接一个项目去执 行，并在此过程中，逐渐将蓝图中的服务基础设施搭建起来。