【IT168 专稿】
会议时间：2008年1月13日下午
会议地点：北京九华山庄

嘉宾： 
    IBM中国开发中心Web2.0首席架构师、IBM资深技术主管毛新生

    曾任IBM软件集团企业解决方案部大中华区和北亚地区首席架构师与IBMSOA中国设计中心技术主管，在企业级软件方面拥有广泛、扎实、深厚的理论功底和丰富的设计与项目实施经验，2006年，曾被授予“IBM资深技术主管”称号，成为中国内地第一位获此殊荣的IBM技术人员，在全球也仅有1000多位IBM员工享有这样的荣誉。毛新生先生于2000年加入IBM，曾先后在北京大学和IBM中国研究院从事研发工作，以研究人员、开发经理和架构师的身份从事过信息检索、语音技术及其中间件，门户、普及计算、Linux、网格计算、Web Service、SOA、Web2.0等领域的很多工作。

主持人：
    感谢苏先生给我们带来的精彩演讲。
    下面我们隆重推出在中国软件开发领域明星一般的人物，IBM的毛新生先生。大家如果关注他，就知道他在两个领域有非常深的造诣，下面的时间交给毛先生，让他发表精彩的演讲。

毛新生：
    谢谢孟总，过誉了。
    今天很高兴有机会和大家聊一下SOA的题目，聊这个是因为IT公司做得不好，这个东西弄了好多年，但是也不知道它干吗的。今天试图再讲一下，讲的不好，大家出门的时候痛贬就好了。

    我是站在不同的角度看SOA的概述，然后会看一些实际的例子。

    首先我觉得当我们讲SOA的时候，一下子要把望远镜拉远一点，我跟程序员聊天的时候，很多人说我开发一个P2P的应用，这个东西怎么用SOA，我为什么动用Service，其实这里面有一个误解，SOA是希望你看待整个企业整体的IT全部。把整个企业的IT建设成为一个所谓的以服务为中心的应用生态系统，它的目标是什么，为什么要调整这样一个思路，不再是把眼睛局限在一个又一个的应用，而是不抽象的级别先定位到服务，并且将整个企业的IT单独是一个服务的生态系统去看待，它的目的就是为什么，它的背后驱动力是什么。

   明确很重要的事情，就是希望把IT的抽象程度提高，不要一上来就是USK，一上来就谈用户界面，一上来就谈业务人员关心的端到端的过程，这个过程是业务人员理解的，而且在这个基础上去考虑这个规则，如何在企业层面管理这些东西。这些都是摆在CEO、CFO面前要看的东西。我觉得你们做技术的人很幸运，我看过IBM的业务人员，老板都操着F词汇，就是为什么这样做。因为我们做技术的，太热爱这些模式，非常喜欢这些微观带来的美感，但是很难发现业务层面需要的东西在这里。
其实途径是这样的，我们是希望在业务层面上一个端到端水平整合的业务流程，而且这个业务流程是弹性的，同时它跟IT世界里面各种各样的应用，不管在那里，用什么技术做，谁来做本公司本部门，还是别的公司，别的部门提供的，没关系。但业务领域的流程和要求发生变化的时候，可以比较准确的追踪到它的影响是在IT世界里面哪一个部分，反之亦然。

    这些东西就使得我们的灵活性，应付变化的能力加强。而且IT和业务之间的互动变得更好。这样一种试图是引发了对应用本身的一种看法上的改变。我们今天绝大多数的成员还在谈论说我有一个应用是分三层的等等这些是有问题的。但是你可以告诉我，我已经在J2EE上做了，其实这是一个级耦合的世界里面，没有办法在分布式的大级别里面完成灵活应对。

    所以说让我们抛去应用的概念，相反我们要把它打成在一个分布的世界可以流动起来的相关组件，怎么样才能让他们流动起来呢？有一个有趣的想法：比如说我们要提供更高一点的抽象级别，直接从业务层面开始，所以我们说站在整个企业的业务流程端点，就是最终的用户，或者是你的雇员，或者是你的客户，或者是你的业务合作伙伴的角度入手，我们看到的将是这个业务所呈现的外在的，你业务的活动，业务的规则，业务的过程为基础，出现了一个业务模式方面的描述。这样一些描述在一些非常成熟行业已经涌现了，在电信行业里面有SID，就是描述业务人员可理解的信息对象，还有ET不同层次的角度描述电信业务活动，相关的业务规则，以及这些活动是怎么构成的，端到端过程帮助电信提供服务给它的客户这样一个业务过程的模型，业务流程的模型。我们也可以看到LOUNET帮助大家去认识这些供应链。从数据角度，从业务流程的角度，行业也提出了很多的标准。

     我们希望这样的东西能够到每一个行业，每一个企业，它是用标准的方式来描述，后面我会讲例子。

    然后我们会逐层抽象和影射，这样一个做法，事实上表现为若干个层面上的东西，我们看看首先是业务模型和业务架构层面的，以及IT架构所形成的所要看到的东西，作为一个企业的主架构师、CTO、CIO，我们需要这样一个技术人员，或者一个团队站在EA的角度，从业务和IT的战略出发，去确立我们所需要的几个重要的架构。首先是业务层面上的一个试图，我怎么样去定义出整个企业级的业务活动和业务数据所形成的BQ。

    然后开始往下走，分解成不同的维度，首先是站在业务的活动，业务的处理，业务的过程方面出现的一个所谓的架构视图，然后需要在用户互动的部分，构造出用户部分，还有数据的部分，这三部分做完以后，我们怎么将这些系统和应用互联互通。

    然后往下走，我们会有照顾整个所有IT系统运营部署管理的系统。然后是安全。

    我们作为一个主架构师，要非常清楚的站在EA的角度，把SOA整体架构做出来。

    我们要有一系列的方法论和工具，在服务的整个生命周期当中，帮助我们处理跟服务的分析，建模，实现部署管理，优化相关的事情。

    实际这方面有一个问题就是怎样从架构方式出发，得到整个企业业务数据相关的服务，这点经常被做SOA的人忽视。另外还有一些粗粒度的考虑。然后我们要考虑从原始架构上做事情，还是在SOA上面实现这些服务。另外我们已有的系统怎么通过SOE的方式拿进去。总体来讲，有三个事情需要做的，第一个非常宏观的，第二个就是程序，第三个就是具体的平台，
谈完这个事情以后，我们需要讲讲，SOA的开发过程，跟传统的开发是有个及其紧密的关系，是一个相互利用的关系。也就是说我们做SOA开发的时候，其实只是在过去的开发模式上增加了一个粗向程式，而不是增加很多的调整。过去我们眼睛看看的往往是一个部门需要的应用，单个的应用，而不是企业范围的。尽管很多同事，或者是朋友在问一个问题，老毛，我今天确实只是需要做一个应用，我真的不需要去关注整个企业范围的问题，那么为什么我需要站在全局的角度看待这个事情呢？这里面有一个很重要的事情。伴随着我们前面谈论的端到端的要求。对Service应用的看法，我们需要做一些调整。如果我们用它来做的时候，做法是先在业务层面上做一个高层的抽象，从高层的抽象往下走。所以实质上你看到IBM所提供的方法，别的公司都是类似的，我们站在业务的角度，用所谓的BS，不再用USKS，它还有用，但是我们用SOA来做的，应该用更抽象的，更大的点去做。我们通过业务的分析，业务的建模，得到粗粒度的定义，然后才开始往下走。往下走的时候，就会进一步意识到传统世界里面所熟悉的东西，可能是J2EE，或者是LAN，这要看做事情的方式。

    左上方我们看到不同的人员都要介入到端到端的流程里面，其实它牵涉到多个应用，这样的一个场景，我们要用过去的视图开发，往往有两种模式，一种模式是我不做这个事情，所有的事情都是做J2EE开发的。另外通过点对点方式，为了达成这个目标，老板让我做这样一个场景，就做这样一个场景，我们将这些应用传在一起，完成端到端的应用。但是这样一个做法，无法满足未来快速应变的做法，所以我们引入一个所谓的Service抽象一别，就是一个技术环境下粗粒度的接口，没有什么。