规划 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）

　　各个部件的责任

　　部件之间的耦合关系和原则，应避免的事项，例如，展现服务和业务流程服务不可直接调用数据服务，而必须通过核心业务服务;换句话说，数据服务不可直接与展现服务和业务流程服务有耦合关系

　　各个部件应支持那些科技和标准（例如：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），描绘所计划采用的产品，以及如何通过这些产品间的交互，来实现解决方案。

查看本文来源