SOA 新业务语言 新系统架构——构建SOA

SOA 新业务语言 新系统架构——构建SOA

对于企业业务来说，面向服务的架构(SOA)最大的优点就是灵活的响应能力。企业经常受到各种各样变化的影响：市场、供应链、战略流程、规则等。SOA可以建立一个灵活的环境，可靠地应对各种变化。原因在于SOA将自动化功能以可重用的方式重组，这样便可快速配置新的或修正的流程。
　　但仅仅依靠一个架构来实现敏捷性是不够的。敏捷性来自可提供敏捷流程的各个方面。开发、重构或者建立正确的服务都需要对业务有很深的了解。
　　由于标准化的最佳实践、深层通信及数据协议和工业“开放性”的发展方向，SOA几乎经历了一场敏捷性的完美风暴。企业集成的努力及面向对象等理论的发展逐渐形成了最佳实践。由于因特网的发展，管接技术(plumbing)成为深入了解和普及集成的必须。而客户的需求、开源及信息公开运动则促成了开放性的发展。
　　为什么说几乎是一场完美的风暴呢?因为与之前的技术一样，SOA只是一种使能技术。如果没有对当前业务流程的深入了解，或对流程变化的总体认识，便不能正确地选择组件，也就不能形成完美的敏捷性。
　　SOA不只是怎么做的问题，真正的业务规划应该从做什么开始。简单地说，如果不知道该“做什么”，那么即使知道该“怎么做”，做出来的东西也是不相干的。
　　

用蓝图(Blueprints)实现“中间相遇”

　　有什么可以指引这些新架构方法和底层技术的应用呢?
　　有什么可以防止SOA实践者只是简单地进行整理而没有取得SOA真正的敏捷性和业务目标的一致性呢?
　　有什么能保证整理好的“SOA”架构能带来可观的效益呢?
　　在SOA领域里，关于治理的重要性已经讨论了很多，但这仍然是一个怎么做的问题，而不是做什么。比如设计时的治理，要支持组件的重用，这是SOA的一个重要方面。如果不能重用为什么还要花钱进行这种重用性开发呢?但对决定重用哪些部分的过程的讨论却很少。而且，成功的先决条件应该是一个可以指导选择或创建能真正实现敏捷性的组件的模型，这样组件才能支持新的或更高层次的业务流程。
　　关于以自上而下(top down)还是自下而上(bottom up)的方式采用SOA也有许多讨论。两种方式都有不同的优缺点。自上而下的方式可以让你“感觉不错”，因为这种方式是基于充分分析与调查的基础之上，但却容易导致无限制地进行描述或制定标准，即“分析乏力”，以至计划赶不上需求与技术的更新。
　　自下而上的方式便于迅速着手，通常是为了追求新技术，并有“有机(organic)”方法的优点。然而，这种方式也常常导致不可重用的组件或没有组织性的服务，虽然符合部分面向服务的规则，却不能提供真正的敏捷性或再现业务服务一致性。
　　还有一种“中间相遇”(meet in the middle)的策略可以将两者的优点很好地结合起来。深入了解业务目标并将其重组，以及支持这些目标的过程是最容易控制和规划的方法。但“最好的规划”也可用于自下而上的方法，即先开始，然后在过程中重构、学习经验，并支持根据不断变化的优先级、需求和技术进行细粒度的调整。
由于支持平行开发，“中间相遇”的方法通常具有时间上的优越性，而自上而下的方法通常代表不同的组织和规则。但这也正是需要解决的问题。两个为“中间相遇”而努力的团队需要精准地了解彼此之间将怎样连接。这可不是马马虎虎就能解决的问题。

　　一个代表当前及期望状态的全面的分层模型(一般称为蓝图)可以有效地支持“中间相遇”的方法。这个方法需要自上而下方法的清晰的追踪性，而蓝图正好可以提供这一点。有了这样一个蓝图，最终将使“宏伟目标”发挥最大效益，并可以根据基础设施与流程需求进行平行开发。
　　这是SOA实践者提供的建议，可以建立有着很好可视性并且需求简单的观点验证(proof-of-concept)，以保持注意力。在交互开发的蓝图中采用这种方法可以从业务目标到帮助实现目标的基础设施自上而下地探索追踪性。以进行足够的高层建模与定义作为基础，确定早期开发的关键过程;但要及早进入开发过程为下一步积累经验，做到见多识广并且信心十足。
　　因为蓝图良好的可追踪性，可以察看当前实现或观点验证(poc)所满足的需求。还可以作为捕捉实现SOA化企业过程中每一步中变化的规划，并提供合适的组件以获得最大的敏捷性。蓝图是一种通用语言，定义了顶端的业务结构与底层的系统架构之间的接触点。蓝图可以确保计划能真正的“中间相遇”。
　　实质上，蓝图也就是各企业的“架构复本”，并且由于实际上它是由软件工具启动的，因此称之为数位模型更为贴切。在蓝图中，治理成为一种实现这个“复本”的控制和通信架构。计划可以提供进度与资源以进行蓝图中“现状(as is)”模型与“将来(to be)”模型之间的差距分析(gap analysis)。
　　由于蓝图中各层之间的可追踪性，可以通过经过优化的业务目标确定需要变化的业务流程，再根据业务流程确定底层的自动控制和组件，最后确定需要变化的基础设施。有了蓝图，便很容易根据业务范围、投资回报率、可用资源或其它非直接与架构和技术有关的因素对项目进行优化。这样便能并行执行计划，并保证可根据进度提供所有组件，实现IT与业务目标的一致性。

来源：SOA应对敏捷企业变化http://soa.csdn.net/page/ea2ccde0-36fd-40e7-968a-bd557faa9c32

IBM

IBM发现并指出了5个可以帮助客户更加容易地着手实施一个SOA项目的切入点。这些切入点包括:以人员(People)、流程(process)、信息(Information)为中心的方法、以及系统连接性(connectivity)和重用现有资产的能力(creating and reusing services)。

以人员为中心的SOA切入点，能够为企业提供综合信息，以及在业务流程中交互的视图，提升人员生产力。美国汉诺威(Hanover)保险公司通过部署 SOA 门户，处理业务的速度提高了 75%。

以流程为中心的SOA切入点，是一种借助重新利用和优化流程，快速部署创新的业务模式。美国Wachovia公司通过单一流程实现了80%的自动化，将客户服务进行了进一步创新。

以信息为中心的SOA切入点，以嵌入式(in-line)或现场(in-context)的方法提供可靠信息服务，提高企业业务洞察力，从而降低风险。应用此方法，大众汽车公司的员工招聘效率提高了20%。

SOA连接切入点，将连接作为基础以支持以业务为中心的SOA。它通过具备任意互连( any-to-any connectivity )的新型业务渠道提供服务，实现安全、一致的用户体验。同时相比定制集成或FTP* 可节省2到4倍的费用。

SOA创建和再利用服务的切入点，能够轻松实现SOA管理的再利用。通过再利用可降低成本、缩减周期、拓展核心应用，同时再利用现有应用的费用只是重新编写新应用所需费用的五分之一。

Microsoft

Microsoft advocates a ―” middle out” approach which combines both top-down and bottom-up methodologies. In this approach, SOA efforts are driven by strategic vision and business need, and are met through incremental, iterative SOA projects that are designed to deliver on business goals one business need at a time. Microsoft has been using this technique to assist customers with their SOA initiatives since the .NET framework was first released in 1999.

《SOA概念、技术与设计》

SOA交付策略：自顶而下、自底而上、敏捷

面向服务分析：服务建模

面向服务设计：WSDL、SOAP

面向服务设计：SOA组合指导原则

面向服务设计：服务设计

面向服务设计：业务流程设计

WS-*扩展