分析和设计

　　分析和设计的内容包括若干活动，通过这些活动，可根据功能和非功能需求集来指定初始的 IT 体系结构。其他一些活动也可作为分析和设计的基础，这些活动对初始的体系结构加以细化，使抽象级别由分析级进入设计级，这一细化程度足以让开发人员生成和编写出实现代码。

　　SOA分析和设计也可以指以下术语中的一个或多个：

• 　　服务建模
• 　　面向服务的分析和设计
• 　　面向服务的建模和体系结构 (SOMA)
• 　　Rational Unified Process for Service-Oriented Modeling and Architecture (RUP SOMA)

　　分析会在较高的(概念级)抽象级别上对将要构建的系统进行描述。分析的输入是一组需求和现有的资产(或是应用程序或系统)。输出则是对需要构建的各个方面的描述。分析对 SOA来说是关重要的，因为通过分析，可以在服务标识期间使 IT 与业务保持一致。分析结果将作为输入在设计中使用。

　　设计会描述将要构建的系统，更重要的是，它还会对如何构建加以描述。

　　大多数体系结构工作是在分析和设计的工作流中、在项目的细化阶段执行的。

　　面向服务的分析和设计利用了分析和设计原则(如面向对象的开发或基于组件的开发中的原则)。例如，您也许还记得所谓的面向对象的分析和设计 (OOAD)。不过，必须注意的是，SOA的工作始终在于服务(而不是对象或组件)。

　　注意：分析级模型常会发展为设计级模型，所以对于分析和设计而言只有一套 RUP 原则。

　　面向服务的分析和设计工作的主要输出是一个服务模型(即先前所说的服务规范)和一个设计模型，服务模型记录了面向服务的系统中所有重要的体系结构部件，而设计模型则进一步阐述了服务模型应如何实现的细节。这两个模型对 SOA设计进行了说明，开发者可以据此明白无误地执行这一实现。

　　在下列各部分中将描述相关任务，为您介绍面向服务的分析和设计的相关术语。

　　注意：术语标识 和规范 适用于基于组件的开发中，而术语规范 和实现 则是由通用建模语言 (Unified Modeling Language, UML) 定义的。这三个术语构成了 RUP SOMA 的核心活动(术语的含义未变)。

　　服务标识

　　服务标识是核心的面向服务的分析活动。服务标识的目的是将各个分组的概念化服务及其*作标识出来。

　　这些经过标识的服务对于业务而言是有意义的，业务需要这些服务。事实上，业务分析师会帮助软件架构师进行这项工作。下一部分将介绍服务设计原则，您会了解到对服务逻辑分组的需求、对服务及其*作的业务名的需求。这些都是在服务标识期间决定的，其间使用了多种技术，RUP SOMA中描述的那些技术也包括在内。

　　我们来深入了解一下：

　　自顶向下方法

　　业务体系结构工作从一组业务目标开始，标识出一个或多个应予关注的业务流程，这在 SOA中是*典型的。通过业务建模工作，可能会出现已经过设计的业务流程(即未来的流程)，对于正在设计中的系统，它们可以被视为功能性的需求。

　　自顶向下方法旨在分解业务元素(主要是业务流程和用例)，然后将它们细化为适合服务的粒度。在使用自顶向下方法的过程中，您通常要在业务任务中标识出各种服务*作。这种做法的好处在于，您可以确保标识的服务与业务保持一致。

　　自底向上方法

　　自底向上方法旨在分析现有的 IT 资产(如遗留的应用程序和系统)，找出可以作为服务公开的功能，以便重用它们。

　　重用是 SOA的一个重要组成部分，对于 SOA的成功是极为关键的。您可能知道，遗留应用程序(即已经部署的应用程序)是您的公司宝贵的资产，应该加以利用。例如，自底向上方法将分析现有的信息管理系统 (IMS) 事务或 COBOL 程序。

　　对于自底向上的分析，有一句忠告：您必须谨慎从事，不要盲目地公开现有的 IT 功能。例如，用于创建、读取、更新、删除 (CRUD) 数据的各项服务的粒度可能太小，无法与业务保持一致。

　　SOA的反思：SOA架构的本质

　　我一直在反思SOA到底是什么，是一种什么样的架构。虽然了解到一些基于SOA构架的产品，但总觉得依然“隔着一层纸”，并不清楚什么才是真正的SOA架构。

　　年初的时候，写过一篇名为“国内EAI正当时，BPM为时尚早，Workflow持续增长，SOA依然概念”的Blog日志。那个时候，我认为SOA还依然是个很“虚”的概念。而现在，我只能说：Sorry，那时候的我，错了。SOA已经不再是概念，而是一个实实在在的构架了。

　　在写完那篇帖子之后，我一直在反思SOA到底是什么，是一种什么样的架构。因为在在TIBCO中国研发工作的原因，可以接触到TIBCO的一些新的SOA产品。

　　虽然了解到一些基于SOA构架的产品，但总觉得依然“隔着一层纸”，并不清楚什么才是真正的SOA架构。

　　很多时候，我依然会认为SOA构架只是满足把应用暴露成Service(或者说是WebService)，以SOAP等之类的消息进行信息的传输，以及基于Service之间的一些业务逻辑的整合应用(比如BPEL)等。

　　我相信，这样的困惑，在国内很多中间件产品、应用产品中都存在，在很多国内的开发人员、架构师心中也存在。

　　昨天，有幸参加了CSDN主办的“SOA产业链及未来企业软件趋势”研讨会，收获不小。参见昨天写的blog随感“参加“SOA产业链及企业软件趋势研讨会”的感想”。经过那些专家们(毛、Tiger、李勇、梁耀文等)的解惑，对SOA是一种什么样的构架，有了一些更深刻的认识。

　　但说真的，如果不是目前在TIBCO中国研发工作的经历，以及所接触到一些国外新产品构架的巨变，仅凭昨天的听讲，也很难把握毛先生他们所说的那些SOA理念。

　　具体昨天有哪些重要的理念就不在重复的叙述了，参看“参加“SOA产业链及企业软件趋势研讨会”的感想”，里面有详细的叙述。

　　今天只谈反思：SOA架构的本质。

　　刚刚看到一篇新闻，讲的是SAP代号为A1S的新产品软件设计方法，参见“新闻分析：解密代号A1S”。这和昨天研讨会上，SAP的李勇先生，所阐述的一些观点很类似：SAP的产品在往SOA架构迁移中，经历了三个大的步骤：步，提供更好的服务层面的容器或平台的支持;第二步，把业务抽象成服务，确切地说，是抽象业务对象(Business Object);第三步，把面向垂直或水平层面的各个产品，基于业务对象进行整合。

　　事实上，这就包含了昨天各个专家所阐述的SOA架构的本质：一切围绕业务对象(Business Object)或业务模型(Business Model)，于“服务”，只是这些业务模型暴露出来的形式，因为以统一的服务形式暴露出来，更便于不同供应商和客户之间的信息交互。

　　在Gartner十年前提出SOA概念的时候(1996年)，尚没有web service技术。SOA架构的本质，并不是说把你的应用或者组件包装成Service就是SOA，而是说，你需要基于一种构架，能够让你的产品能够更适应“业务敏捷性(Business Agility)”。但是这种业务敏捷性仅仅是一家提供商或产品是很难满足的，肯定需要各个不同的供应商协助完成，不同的产品之间能够比较容易的进行消息交互。这样的灵活度肯定不是传统的基于消息的EAI产品所能够满足的，需要一种新的协议或标准来支撑。—— 当Web Service诞生之后，所有的大厂商都发现这是一种*符合他们需求的技术。

　　但是服务的本质，是在后端能够提供一套“业务模型”。而制成这种业务模型或业务对象构建的技术，正好就是前几年所热炒的“模型驱动构架(Model-Driven-Architecture)”。事实上，现在各大厂商都在基于这个构架在转变自己的产品构架，BEA，IBM，TIBCO都在进行着这样的巨变。

　　在回头想想我们常说的“SOA真理三角”：数据(Data)——组件架构(Component Architecture)——组合(Composition)。因为几乎所有的业务模型终需要被“业务对象+业务组件”反映出来，而它们之间需要进行一系列的组合和交互，来满足业务的处理。

　　在SOA联盟组织的SDO和SCA标准，正是用于解决数据和组件模型描述的问题，这方面几乎所有的EAI厂商都加盟进来了，IBM、BEA、IONA、Oracle、SAP、Sybase、TIBCO、Software AG等等，这其中好包含国内的普元软件。