mySOA

MYSOA：敏捷的、治理的并且可持续的作者WilliamElKaim译者马国耀发布于2010年5月26日下午10时21分SOA是在各种报道中频繁提及的一个话题。在阅读了很多书、文章、软件提供商们的各种白皮书以及博客文章之后，我仍然在探索如何才能使之成为现实。本文的主要目的是邀您一起参与我们的SOA之旅，不过它针对我们的一些限制使用我们自己的“语言”进行描述的。我们称之为mySOA方法。SOA显然指得是我们要构建灵活的，治理的并可持续的跨企业的业务和技术的服务，甚至可扩展至更广阔范围（云或B2B等）。“我的”是因为Web2.0的变革使得服务越来越多地用于社会交互，而不仅仅是点到点的交互。“我的”还意味着它专注于我们的需求且与我们公司的业务对齐。我们并不求为该领域提供一个尖端的解决方案，甚至不求提供统一的方法论（我们使用的术语是内部团队合作的结果）。但我们希望它将提供一个基础，能帮助你在此之上构建你的SOA方法，或者能鼓励你在该主题上扩展知识。最后，为了描述得尽可能具体些，文中将提到我们所使用的工具提供商或者工具平台。我们诚挚地建议你购买任何技术解决方案之前要在你所面对的特定的上下文环境中做概念验证。因为，没有放之四海皆准的法则，特别是mySOA。一、前言1.1mySOA方法mySOA方法基于三大主干：敏捷，治理以及可持续性mySOA是敏捷的敏捷意味着我们将不再总是遵循那些文字所提到的“你必须”和“你应该”的法则（如，你必须要有业务战略，你必须要有管理层的支持，你必须采用自顶向下的方法，你应该预先做好宏大的规划）。我们将通过迭代的方法，通过小团队管理特定服务集合的方方面面。目标是创建我们所谓的“服务刀片”，它们可以被插入或重用在不同的业务及技术的环境中的。刀片服务A刀片服务B刀片服务C标准安全数据敏捷思路：因为在快节奏而且扁平互联的世界中，企业要生存，必须要敏捷。因为我们的开发团队使用SCRUM，因此转向敏捷非常自然。也很必要，因为金融危机使得我们无法得到一大笔预算来开展若干年的完全丰满的SOA项目。mySOA方法要求治理我们不仅把治理作为支撑业务和IT的新动力，还将它作为加强合作和对齐的方法。信任是最大的挑战，而且总是这样，因为（出于整体利益的考虑）一些团队要将他们原有的决策权交出去并且要接受一些新规则。敏捷还包含另外一层含义，即对例外管理应该作为治理流程的本身的一部分。mySOA方法应该是可持续的SOA要允许对功能和技术竖井进行逐步且可持续性的改造，这样才能设计出可被各种业务流程重用并且灵活的服务。而往往在一段时间内我们致力于寻找充分的资产为业务提供价值而不是重用。如果我们不得不开发一个portlet来为某个特定客户提供业务服务（如CO2计算器），那么我们一定会这么做，它可能被重用也可能不会，但这是最后才考虑的事情。可持续性还意味着，即便某些人（参与SOA之旅的人）会因为SOA的成熟以及新业务模型或组织的产生而必须变换角色，还是要保证他们参与进来。往往，SOA项目的结局是成本的降低，外包（投资海外可能更为贴切）以及帮助构建SOA的团队的解散。mySOA立足于人，在公司内且把公司的每个人看作功臣并提升其价值。mySOA的重心是为企业带来附加值。1.2mySOA——选择你的通往成熟之路SOA支持建立敏捷的企业，但是通往mySOA天堂的路却取决于你自己。对于任何SOA项目或新方案，都要独立定位并让所有股东都能理解其开销、风险以及可能的收益级别，这点非常重要。图1是一个来自可持续的IT社区的某个SOA项目的分类模型，它的优势是能够在整改的、大检修的或扩展的SOA环境中为你的项目进行清晰地定位。图1：通往成熟SOA之路（来自可持续IT）1.整改的SOA.不侵入现有资产：需要现有系统的辅助暴露服务；它不同于对现有系统的重写；此类SOA依赖于现有系统的质量；此类SOA可能在有限的情况下快速见效。2.大检修的SOA利用服务重构现有的应用系统；可以充分利用IT基础设施；业务规则和业务逻辑依然封装在应用程序的代码之中。3.扩展的SOA使用能提升系统灵活性的解决方案：业务规则管理系统、主数据管理及业务流程管理等。扩展的SOA是最“昂贵”（从时间、资源和投资上看）的，但是它能带来的实质性结果也最多。扩展的SOA才是目标。为了遵循通往该目标的敏捷的方式，最佳的路径是通过某些过渡性的阶段，在这些过渡阶段中把主数据、业务规则和语义映射等从将要被访问的Web服务的应用程序中清晰地分离出来，并在此基础之上建立服务。1.3mySOA卓越中心（ICC）建设我们做的第一件事是创建一个整合卓越中心（ICC，IntegrationCompetencyCenter）。该中心的命名故意没有使用“SOA”，因为“整合”是业务更容易理解也更喜欢看到的。这并不代表将来不会有所改变（还是可持续性，我们的工作始终建立在过去的基础之上，而且是以敏捷的方式！）。ICC是一个分布式的组织，它主要由两个团体构成，如图2所示。解决方案中心（SolutionCenter）的任务是确保对所有项目的不变的可持续的执行，专家中心（CenterofExpertise）则为项目提供随需应变的敏捷的分布式的支持（或征求咨询公司）。图2：ICC的两个组成部分整合卓越管理中心（ICC）方案解决中心专家中心ICC图表是我们创建的第一份文档，它定义了以下行动范围：业务层业务整合及创新：在各业务单元间普及并宣传业务整合能力的价值。业务域治理：通过定义服务提供方的SLA以及关键功能需求来支持业务（列出要提供的业务服务清单，这些服务独立于技术）。IT层技术治理：创建技术标准并定义验证这些标准的规则，特别是围绕服务设计及接口设计的标准。ICC开发了一个技术标准最小集合作为必须要遵循的关键架构准则，如XML模式标准、WSDL模式标准、服务级定义模板标准等。ICC还专门开放了一个内部网站和wiki，用于讨论并进行答疑。服务开发周期治理：ICC并不负责服务的开发，因此它应与敏捷的验证点联合才能确保所有的工作都是依照治理规则完成的（必要时还要改进治理流程，治理流程本身也是敏捷的）。服务交付和运行时治理：全局地交付服务，负责安全，SLA，并在需要时创建适配的虚拟“服务”（或端点）。ICC管理所有服务的技术接口。解决方案中心由一个分布式敏捷的团队组成，该团队的成员都是全职员工，而将其部分工作时间花在SOA之上。这样就可以避免“巴別塔”综合征，并能使这些成员忙活于如何让实际的项目更加成熟，而不仅仅是管理和作报告。必要时该团队还可以雇佣合同工。图3对ICC所提供的服务进行了归纳。图3：ICC组织提供的服务1.4mySOA寻找服务一直以来的一个关键问题是如何找到服务?如何找到合适的服务粒度？答案依然是很难。我们遵循3种不同的方法：自顶向下——业务服务诱导法敏捷——遵循敏捷开发流程自底向上——改建式开发(BrownfieldDevelopment)业务服务诱导法（自顶向下）详细讨论如何发现业务服务已经超出了本文的范围。不过我们建议你阅读《可持续IT架构》[1]一书或者在这里免费得到发布在知识共享平台（creativecommons）的文档及培训资料。你可以遵循一些非常通用的步骤：定义产品服务及他们的依赖：特定于有限业务域的业务价值链是什么（用敏捷的方式去做）；定义业务对象，它们的生命周期及关系；定义主数据；创建用于对业务对象或业务交互周期进行映射的业务服务;尽早定义或预见服务的可变性。敏捷——遵循敏捷的开发方法另一种方法是利用敏捷的开发流程，通过使用“向前版本控制策略”。与整合团队合作，设定优先级，开发并进行测试。当然在多个迭代中都建立服务接口可能会产生一些问题，因为服务是不断发展的，而且服务用户是不喜欢服务接口如此不断地变化，然而为了快速地实现能够满足需求的服务，这是不得已而付出的代价。每个团队都要理解一点，如果要避免在未来进行全盘设计（这种全盘设计并非一定能奏效），他们就应遵循一些规则。此外，还可以通过制定一些技术标准并经常进行检测来避免全盘设计的发生。沟通依然是关键所在。这里不存在灵丹妙药，但是敏捷的确是为“恰当的”业务需求在“恰当的”时间寻找“恰当的”服务的一种令人惊讶的方法（适时比正确更为重要）。改建式开发改建式开发是IT工业中常用的一个词语，它通常用于描述需要在现有（或遗留的）应用或系统之间开发新软件系统的问题域。这意味这任何新的软件架构必须要考虑到与现有的正在运行的系统之间的共存性问题。若要了解更多信息，我们推荐阅读《吞下IT大象》[2]。在这种情况下，我们建议：对数据进行挖掘。全面了解你的系统所包含的数据并尽力挖掘其最大价值。控制其生命周期。这是一个前提条件，比如，我们使用Convertigo对遗留的后台办公数据进行访问，这样就不会破坏现有的流程，业务规则以及安全限制。保证其质量。这点不能忽视，而忽视它往往是最常见的失误。定义一个权威的数据版本。定义谁是它的管理者，谁使用它的拷贝进行工作。你可以使用MDM工具或构建一个联邦MDM（通常需要在其之上部署一些中间件来管理数据的同步及分发）数据要面向服务，这是数据部分的最新型的工作。这项工作并不简单，因为它将带来DBMS端优化的工作负担和复杂性。Informatica将计划推出其新平台V9，它将为数据管理，数据集成和数据服务提供统一的方法。为了在构建平台时更好地理解客户的问题，他们与来自不同客户企业的架构师们（包括我）进行了热烈的讨论。我推荐你阅读该对话中提到的一些经验及心得。开源数据集成提供商也纷纷涌向这块肥肉，其中包括Talend和Xaware等。二、SOA实践方法阅读服务标识方面的文献，如AccentureSIF，BPM携手SOAHandshake，InfoQ关于SOA标识方面的文章，这本关于写作方面的文档，最后当然还少不了ThomasErl百科.以下是一组非常有用的最佳实践。避免通用服务，服务必须要有特定的价值。服务效用依赖于服务的多变性以及多版本。服务提供信息的某种特别的视图。服务总是要遵循某个生命周期，而且服务应当被管理起来。2.1敏捷治理的必要性由于要管理的服务数量可能快速增长，所以我们决定关注那些最“重要的”服务（这也是我们团队的决定）。重要性的依据是业务需求（如客户的要求，新产品功能等）以及技术需求（如安全支持，REST支持，内容交付网络等）确定的。所以，我们创建了一个治理进阶来实现服务重要性与服务治理力度的对齐：1.完全治理的：由ICC管理的服务——该类服务在全局范围内使用，并且对于遵循ICC治理规则的业务是至关重要的。2.已知的且委托治理的：本地管理的服务——该类服务由本地资助开发并且遵循本地的治理规则。3.已知的，无治理（使用时风险自担）：未管理的服务——任何不遵循适当的治理规则或未被监控的服务。4.所有的：监控的——跟踪SLA，条件允许时会生成报告。5.快照模式：遵循治理——已经量化技术需求以及SLA需求并且能随时进行验证。不论如何，服务都应该在统一的存储库中声明并进行分类。服务提供者是服务的所有者，它可以是企业的内部提供者也可以是外部提供者。不论选择的是那种服务治理级别，服务提供者都应该遵循以下基础规则集。服务提供者要：对服务开发生命周期的方方面面负责。熟知ICC定义的标准；确保服务设计遵循ICC标准；确保服务实现遵循SLA；保证2，3级支持可用；确保在生产环境中同时运行的服务的版本不超过2个。ICC负责管理服务并进行敏捷的垃圾回收。它检查服务是否依然有用，是否依然在使用中。这对于避免产生无止境的服务目录非常关键。2.2服务分类在我们的SOA视野中，所有内部业务部门都应该对交付服务作出贡献。架构蓝图可用于新系统的设计和旧系统的重构。对于业务决策者，理解组件的业务价值及其商品化级别有助于作出创建、购买、或租借（服务）的决定，甚至还可能因为提供服务而发现业务机会。对于架构师而言，对不同分类的深入理解不仅有助于对现有服务以及新服务进行分类，还有助于