【IT168 专稿】

    很高兴有机会和大家聊聊SOA。SOA谈了好多年，但还有很多人不知道它是干嘛的。今天试图站在不同的角度讲SOA，然后会举一些实际的例子。

什么情况用SOA？

    首先当我们讲SOA的时候，一定要把望远镜拉远一点。很多人问我，开发一个P2P应用，怎么用SOA，我为什么用Service？其实这里有一个误解，SOA是希望你用它来看待企业整体IT的全部。把整个企业的IT建设成为一个以服务为中心的应用生态系统，它的目标是什么？为什么要调整这样一个思路，不再是把视线局限在一个又一个应用，而是把抽象的级别先定位到服务，并将整个企业的IT单独作为一个服务的生态系统去看待，目的是社会那么？背后的驱动力又是什么呢？
    SOA首先需要明确一件很重要的事情，就是希望把IT的抽象程度提高，一上来就谈用户界面，一上来就谈业务人员关心的端到端过程。这个过程是业务人员理解，而且在此基础上去考虑规则。如何在企业层面管理这些，则是摆在CEO、CFO面前的东西。而我们做技术的人员，太热爱所谓设计模式，非常喜欢这些微观的东西带来的美感，却很难发现业务层面需要的东西。
    我们希望在业务层面有一个端到端的、水平整合的业务流程，而且这个业务流程是弹性的。同时当业务流程和要求发生变化时，可以比较准确地追踪到它的影响是在IT世界里的哪一部分，反之亦然。
    这就使得我们的灵活性和应对变化的能力加强，IT和业务之间的互动变得更好。这也试图引发对应用本身的看法上的改变。今天绝大多数人还在谈论“我有一个应用是分三层的”等等这些是有问题的。这是一个紧耦合的世界，没有办法在分布式的大级别里实现灵活应对。
    所以，让我们抛开应用的概念，相反我们要把它分解成在一个分布式的世界里可以流动起来的相关组件。怎样才能让他们流动起来呢？有一个有趣的想法，比如我们要提供更高一些的抽象级别，直接从业务层面开始。我们站在整个企业的业务流程端点，即最终的用户，他们可能是你的雇员，或者是你的客户，或者是你的业务合作伙伴。从他们的角度，我们看到的将是这个业务所呈现的、外在的业务活动和业务规则。以业务过程为基础，出现了一个业务模式方面的描述。这样的描述在一些成熟行业已经涌现。比如电信行业里有SID，就是描述业务人员可理解的信息对象。我们希望这些能够深入每一个行业，每一个企业，用标准的方式来描述。后面我会讲一些例子。
    然后我们会逐层抽象和影射。这一做法表现为若干层面上的东西。首先是业务模型和业务架构层面，以及IT架构所形成的、要看到的东西。作为一个企业的主架构师、CTO、CIO，我们需要这样一个技术人员或者一个团队，站在EA的角度，从业务和IT战略出发，确立所需要的几个重要架构。
    首先是业务层面的视图，怎样定义整个企业级业务活动和业务数据所形成的BQ。接着分解成不同的维度，先是业务活动，业务处理，业务过程方面的一个所谓的架构视图，然后需要在用户互动部分构造出用户部分，还有数据部分，这三部分完成后，如何将这些系统和应用互联互通。然后我们会有照顾整个IT系统运营部署管理的系统。最后是安全。
    作为一个主架构师，要非常清楚地站在EA的角度，把SOA整体架构做出来。我们要有一系列的方法论和工具，在服务的整个生命周期中，帮助我们处理跟服务分析、建模、实现、部署、管理、优化等相关事情。
    这里有一个问题就是，怎样从架构方式出发，得到整个企业业务数据相关的服务，这点经常被做SOA的人忽视。另外，还有一些粗粒度的考虑。我们要考虑是在原始架构上，还是在SOA上面实现这些服务。总体来说，有三件事情需要做，第一件非常宏观，第二件是程序，第三件就是具体的平台。

SOA开发过程

    下面我们讲讲SOA的开发过程。它跟传统开发有着极其紧密的、相互利用的关系。过去我们看到的往往是一个部门需要的应用，单个的应用，而不是企业范围的应用。尽管很多同事或者朋友都在问一个问题：老毛，我今天确实只是需要做一个应用，我真的不需要去关注整个企业范围的问题，那么为什么我需要站在全局的角度看待这个事情呢？这里面有一个很重要的事情。伴随着前面谈论的端到端的需求，我们需要对Service应用的看法做一些调整。如果我们的做法是先在业务层面上做一个高层抽象，从高层抽象往下走，这是IBM所提供的方法。别的公司都是类似的。通过业务分析，业务建模，得到粗粒度的定义，然后开始往下走。往下走的时候，就会进一步运用到传统世界里面所熟悉的东西，可能是J2EE，也可能是别的，这要看实现的方式。
    左上方我们看到不同人员都要介入端到端的流程里面，它牵涉到多个应用。这样一个场景，我们要用过去的视图开发，往往有两种模式，一种模式是所有事情都做J2EE开发。另外一种模式是通过点对点方式，将这些应用攒到一起，完成端到端的应用。这一做法无法满足未来快速应变的需求，所以我们引入Service抽象级别，这是一个技术环境下粗粒度的接口。
    这些Service有些是需要重新开发的，有些是已有的，有些是在原有基础上组合起来的。不同的应用都有技术边界，都是刚性的。为了打破这些刚性边界，首先需要提供标准化描述的接口，通过XML或者Service描述形成的世界。

SOA经典实例

    接下来我们看几个例子，大家可以看到我们是怎么做的。

1. 案例一——三星公司
    这个是我们给韩国三星公司做的一个系统，是整个工程里面的一小部分。
    首先是一个背景的分析，可以肯定整个是关于其销售管理的系统，以及与客户关系管理和销售相关的方面。
    我们看到现有系统状况是这样的，有些老系统，有些是靠人与人相互打交道完成的，也会看到BEA的系统，IBM的产品，还有一些主机。现在的做法很多是靠人和人之间通过邮件等的传递来实现。他们希望能够将这样一个过程改变成端到端整合起来的系统，最关键的是希望把所有应用中整合的功能和数据变成一个系统、成文的东西。
    我们怎么做呢？这是一个部署图。在这里我们的做法是，首先做一个业务层次的建模，实现一些粗粒度的服务，以及与数据相关的服务和与业务应用及处理相关的服务。紧接着，粗粒度业务层次的东西转化为Service描述和DB描述。在具体做服务分析和标识的时候，使用到一个系统化的方法SOMA。分析服务的方法有三种，包括up-bottom、bottom-up和校验过程。
    做完分析之后，我们想办法用业务的语言把服务描述出来，并将它转化为XML描述。同时，考虑描述与此业务相关的业务规则、业务相约，包括安全方面等非功能性要求。
    然后进入服务实现决策层次。可以看到，高层工作完成以后，就映射到传统J2EE里。这是我们新建的Service，创建了J2EE的插件，它与已有的数据库和原有数据打交道，实现应用。
    这是我们的物理部署。表面上它只是做一个流程，在这个流程里面所做的服务可以在别的流程使用。
    这就是我们和他们的业务人员、IT团队和业务团队一起做的事情。可以看到，不同系统提供不同的能力，这些能力能不能成为一个服务，是通过服务的建模分析来决定的。
    这就是我们在三星所做的。

2. 案例二——中海集运
    我们还可以看一下在中远集运所做的。中远集运的问题就比较多一些，它有很多系统和要求，还有包括美国等的全球站点，每个站点都有很多应用，通过平台传递这些商务数据。客户希望通过这一平台来做什么呢？需要确定集装箱的仓位、改变运货时间等。还有就是报关。而且托运客户经常提要求，修改的地方非常多，这是很可怕的事情。
    怎样将所有应用放在一起，形成一个富有弹性、端到端的系统，来应对VIP客户变来变去的要求，应对各种法律上的变动、口岸的变动？我们从业务角度进行分析，建立了一些业务场景。业务分析后，我们对它现有的IT系统也做了分析。我们发现一个客户的订单会跑很远，牵涉到很多系统，海关系统，税务系统，重要客户系统，核心业务系统等。所以，这是有问题的，我们采取了一些策略。
    这里可以提的一点，SOA特别适合敏捷软件的开发。当你用SOA方式构造一个系统的时候，其实给了你一个特别好的机会。在中远集运这个案例中，过去的开发模式比较多的是瀑布模型，所以我们建议他们用敏捷的方法来开发，这对他们的IT部门也是一个很好的事情。
    事实上，我们当时的分析和设计过程是什么样的呢？前面它整体的业务过程，从这个大的业务过程，对它进行分解，成为业务人员能够理解的过程和活动。这个过程是我们跟他们的业务人员一起做的。这个过程中并不轻松，因为这些事情不能完全依赖业务人员，业务人员因为没有这个概念，容易弄的很乱。如果按六西格玛的一些规则来看，其实有些业务人员的做法是错的，所以我们不能完全按照他的方法来做。
    这边是非常粗粒度的，是我们开发的一个工具，你们也可以用自己的工具。这边是细粒度的，更多是技术层面、功能层次、实现层次上的。所以，我们谈的不仅仅是业务上的粗粒度能力，也存在一些技术上的细粒度组件等，以及对粗粒度的服务共享到什么层次。这两个层次都打通了，这个SOA就有点意思了。
    在IT世界里，是数据稳定，还是应用稳定呢？是数据更稳定。应用相对来讲要容易变化，流程又容易变化一些，再往上用户界面的东西变化太多了。所以对一个极其重要的世界进行切分，就是企业应用当中数据和应用的切分。数据和应用首先要做一个粗粒度的切分。
    我们将这个系统各种各样的实景拿出来，这有点像ER图，但是我们更多站在使用的角度去看，看在相关的场景里怎么利用这些数据进行访问。为什么说SOA是在粗粒度上工作？很多时候，有些同学或者朋友跟我说：老毛，我这个Web Service不就是一个Java接口，然后分布起来用吗？这就很有问题，绝对是一个误导。
    事实上，我们给它做了一个调整，在此基础上覆盖了一个标准层。到现在为止，我还是觉得利用文件、目录、数据库还是有意义的。但是，对于业务层面上，我们已经定义出有价值的东西，还是用分布式计算的东西。这是一个标准的做法，你可以有自己的做法，基本思路是一样的。
    这些是新开发的一些EDI业务服务，包括原有系统，杂七杂八的系统。因为他们需要跟很多客户打交道，我们做了这个东西可以让更多的客户参与进来。我们只是用一个视图，转化为J2EE的视图，跟过去并没有什么大的区别。
    这是部署，包括高可用性。事实上做完这件事情以后，带来的效果还是比较好的。过去，它在世界各地增加一个新的港口，大概要好几个人干好几个月，换成新的方式，基本上是业务人员和IT人员配合，用几天的时间就可以了。这是很好的例子。另外，增加一个新报文，业务层面说要好几周好几个人，现在也是一两个人一两天就可以，收效非常明显。

企业级的SOA

    通常来讲，SOA其实是一个企业级范围的东西，与单个应用的开发是两回事。所以，多少会牵涉到企业IT战略和业务战略相关的方面。
    这是我们当时讨论的整体转型的要点，整体要点还是Service的弹性和灵活应变的事件。我们用动画的方式展示出来，提供以一种面向企业服务的方式。

SOA治理

    SOA治理，是很多技术人员很少想的事。作为一个大公司的CTO、CIO，需要考虑战略层面的事情。你发现整个SOA一上来就谈业务的事情，是企业范围，而不是一个部门，一个应用。所以，它跟业务战略和IT战略有天然密切的联系。正是因为这样的一个高度联系，使得治理本身变得很重要。在业务世界里面都是公司治理，假如你是一个上市公司，你公布任何信息都是经得起检验的。公司治理有一套做法。然后是IT治理，这两者之间有一个SOA治理。
    SOA治理最主要的内容牵涉到整个服务生命周期治理的框架。它解决的问题很简单，为什么我要开发这个服务？如果我开发这个服务，请问谁来付这笔钱？这个服务在运营期间所带来的利润谁来分，谁获益？我提供的服务分享给你用，你这个部门出多少钱给我？出了问题谁来负责？谁来决定这个应用的开启和废止？这些事情都是SOA治理最核心的问题，这个问题放在企业环境里，具有非常重大的现实意义。
    我在这里增加一个例子，是一个国内做的非常好的SOA实例。首先这个CIO有一个战略思考，我的IT架构怎样适应业务流程的变化；如何集成异构系统的数据一体化；如何广域集成异构实时数据库和关系数据库；如何构建统一系统支持平台，不再走系统集成老路。所有这些问题，包括安全问题，都是他特别希望解决的。
    他希望的目标是什么？就是支持灵活的企业目标和业务模型，适应快速变化的电力市场，面向灵活、开放的工业标准等。这些目标怎么实现？就是架构高层战略决定。他说我要用虚拟化技术把业务集成起来，形成高效用的平台，然后以XML为基础，形成一个主体数据库。XML数据库是非常靠前的技术，我估计大家还没有尝试过它。XML的重要目标是用自描述、自完备的方式去描述业务的数据，这是一个最重要的目标。他说我用一个广域异构数据库整合，在这个基础上提供数据服务。我觉得他走的非常靠前，非常了不起。他说我有了这些服务，用点对点Web服务进行后端应用整合，用Portlet服务门户进行前端整合。他们的UI都是业务人员定制的，很了不起。
    事实上，他还有很多思考。和他交流很受启发。他实现的就是非常完整的端到端的流程。还有比如遗留系统等SOA策略。实际上他制订了自己的策略，新系统怎么搞，遗留系统怎么搞，怎么实施，他都有自己的标准和要求，对业务人员的要求也有全面的计划。
    你看他的治理，包括自有规划、SOA制度和标准规范体系，有管理角色和技术角色，有开发过程不同阶段的规范，包括文档级别。在这个公司里你想上一个应用，首先要经过一个流程。你想用数据，必须找数据管理员，不可以随便用，随便加。不符合SOA的标准？对不起，就做不了。中国还是有一些CIO非常有水准，做的非常好。
    这就是我补充的一个实际例子。做一个小结，就是SOA不要把它小用。如果作为一个单个应用，不要浪费你的精力，用Web Service就可以了。做SOA不要忘了，业务驱动是重要目标，企业范围内企业架构作为一种全局规划。