"一切都在流动，没有什么是持久的。一切都在融化，没有什么是固定不变的" - 赫拉克利特(Heracleitus)

大约在2003年中的时候，SOA的概念逐渐进入人们的视野，一时间众人乐此不疲的发表各自对SOA的见解。SOA已经成 为IT业，尤其是软件开发及系统集成领域从业者的热门话题。很多的权威机构也纷纷预测SOA的美妙前景，例如，Gartner 预言，到了 2008 年，至少 60% 的企业将使用 SOA 作为其IT架构。抛开喧嚣躁动以及随声附和，对于软件开发者而言，经过了一年多的概念灌输，伴随着不断增长的困惑，更多的人希望能静下心来看一看：究竟怎 样的系统架构是符合SOA设计的，而又有哪些技术可以用来实现SOA呢？特别是企业服务总线(Enterprise Service Bus, ESB)， 看起来更是SOA中一个玄虚的概念，本系列文章将通过实际的案例分析来详细讲解在SOA系统中是怎样实施ESB的。

本系列文章将直接面向广大的软件开发人员， 首先以直观的方式介绍什么是ESB， 然后引入一个实际案例，以此为基础，详细介绍怎样一步一步实现ESB。现在我们谈论SOA和ESB的时候都不再是空中楼阁，IBM作为SOA的倡导者，已 经提供了很好的产品来实现我们的设想。我们会在本系列中的第二、第三部分中分别介绍基于WebSphere 6 和IBM EAI产品的两种实现方式， 然后在第四部分中介绍在复杂的企业应用场景中总线(Bus)怎样互联， 怎样扩展。希望通过本系列文章，能让广大读者朋友快速掌握ESB的实际开发技巧。

回页首

关于SOA

关于SOA的概念，你可以找到很多的文章从不同的角度来描述它，不同的软件提供商也有不同的定义方式。BEA有流体计算， 微软有Indigo 和SOA-building， SAP有ESA。 每个人都可以从不同的视角来理解SOA，从程序员的角度，SOA是一种全新的开发技术，新的组件模型，比如说Web Service；从架构设计师的角度，SOA就是一种新的设计模式，方法学；从业务分析人员的角度，SOA就是基于标准的业务应用服务。从概念的角 度，IBM对SOA的定义是最为全面的，既SOA是一种构造分布式系统的方法，它将业务应用功能以服务的形式提供给最终用户应用或其他服务。SOA包括如 下要素:

• 一个体系架构，用开放的标准将软件资产(Asset)化为服务
• 提供标准的方法来表示软件资产及其交互
• 单独的软件资产作为构造单元，被重复使用来开发其他应用
• 将关注点从细节实现转移到应用(application)组装
• 整合企业外部的应用（B2B）的方式
• 开发（现在）和整合（未来）的统一

本文针对的读者是软件开发人员，站在开发人员的角度，往往希望软件开发能够满足对于开发效率、可靠性、易维护性、易管理等多方面的更高要求。让我们通过回顾软件开发的演化过程来看一看SOA出现的必然性：

• 面向机器语言(Monolithic)的开发模式：需要根据不同平台的机器语言来开发代码。
• 面向过程(Procedure)的开发模式：独立于机器的程序语言(C, Pascal等)使开发过程变得简单了，用过程来代表一个抽象的代码集合，包装重用现成的代码。
• 面向对象(Object)的开发模式：用更接近现实的对象来表述一个相对完整的事物。面向对象的语言(Smalltalk，Java等)，提供了更抽象的封装和重用模式。面向对象的开发强调从现实世界问题域到软件程序的直接映射，更接近人类的自然思维方式。
• 面向组件(Component)的模式：随着软件开发规模的扩大，在涉及分布式、异构等复杂特征的环境中，代码 级别的重用性差，可维护性差，效率低的弱点是不可逾越的，因此人们以架构运行环境(如.Net，J2ee等)来提供完善的支撑平台，从而把开发者解放出 来，更专注于业务核心的开发。而这些业务功能(Business Function) 以组件的形式(DCOM， EJB等)发布运行在架构运行环境中。软件开发的重用模式也上升到业务组件的级别。
• 面向服务(SOA)的模式：当软件的使用范围扩展到更广阔的范围，往往会面对更加复杂的IT环境和更加灵活多变 的需求。服务(Service)的概念出现了，人们将应用(Application)以业务服务(Business Service)的形式公布出来供别人使用，而完全不需要去考虑这些业务服务运行在哪一个架构体系上，因为所有的服务都讲着同样的语言。SOA考虑了业务 发展的长期性，体现了"变化就是永恒"的思想。SOA的核心体现在企业应用或者业务功能上的"重用"和"互操作"，而不再把IT与业务对立起来，这可以被 视为在IT驱动业务的方向上迈出的重要一步。

我们注意到，SOA同样也强调重用(Reuse)， 但是相对于传统的代码重用，对象重用，和部件重用，SOA的重用粒度更粗。SOA的重用在于业务级的应用，即服务的重用，这与软件的发展规律是相一致的。 在软件发展的过程中，软件重用的对象越来越接近我们的现实生活。通过部件的重用，软件的开发更具效率，并且开始试图用组件表达业务模式。但是，IT人员仍 很难对业务人员解释清楚IT结构怎样映射到业务模型上。然而，IT架构与业务模型的弥合是不可避免的方向。现代企业的业务环境所面临的最大挑战就是变化， 规则在变，需求在变，而对变化做出最快的反应，尽快地适应变化，成为企业占得先机，成功运作的关键。很多企业的业务环境依赖于他们的IT架构，因此，IT 部门往往直接承载了业务变化带来的压力。每一个具体的业务变化，都直接反应到对现有的IT平台的要求：要么企业IT架构本身对变化自适应，要么IT架构能 够在短时间内根据新的业务规则做出调整。这就是SOA架构提出的根本原因，我们需要一种更加贴近业务的IT架构，能够直接描绘业务，对那些不懂IT技术的 业务领域专家来说，业务服务却是他们最熟悉的，也就是说是SOA把软件重用的对象从IT人员上升到了业务人员。因此，我们可以说SOA与其它的模式相比， 最大的进步在于它与业务的关联性，"服务"对应到实际业务。IT通过"服务"与业务发生了密切的关系，业务人员和IT人员都可以专注于业务逻辑的实现，而 共同的语言就是"服务"。

但不是什么场合都适用SOA。通常来讲，SOA适用于较为复杂的IT架构，经常需要与外部复杂的IT环境交互，并且需要快 速地应对频繁发生的业务变化。就像你不可能在控制洗衣机的芯片上使用EJB开发一样，如果你的IT环境规模很小，足以灵活地应对变化，不需要与其他的异构 IT环境频繁交互，那么SOA带来的好处就不足以抵消它给你带来的系统复杂性。但是，即令如此，你也并没有被完全排除在SOA的大趋势之外。SOA是如此 地倍受瞩目，我们可以预见到它的迅猛发展，因此即使你的内部IT架构本身并不是基于SOA的，你也还有机会参与到未来的SOA架构中去。例如，将你的某个 业务以服务的形式发布到某个外部SOA平台上供别人使用，作为第三方SOA平台的一个服务提供者(Service Provider)存在。

在选择SOA的实施方案时，要记住，软件的具体实现技术诸如Web 服务与SOA是两回事，SOA是一个概念，方法学， 或者用一个更时髦的词：一种模型。而Web 服务呢？它是一种具体的实现技术，就像EJB一样。SOA ≠ Web服务。不过公平地讲，Web 服务倒确实是目前最适合实现SOA的技术之一，用Web 服务来封装业务服务是个不错的选择。因为Web服务是标准的，WS-I协议保证了来自不同厂商的Web服务即使运行在不同的平台上，底层的实现机理不同也 可以顺利交互，这是以前的任何一种技术如CORBA，EJB，或DCOM都不能做到的。而且，Web服务的定义与实现是分开描述的，即松散耦合，因此，可 以很方便地替换服务的内在实现而不会对现有的系统造成任何冲击，这也极大地促进了IT架构的灵活性。

对于SOA更进一步的了解，可以参考IBM developerWorks上其他SOA相关的文章(请参见参考资料)，我们的系列文章将主要讨论ESB，因此不再此过多地论述SOA了。为了使我们下面的论述更顺畅，请先牢记典型的SOA架构有哪些基本的要求：

1. SOA在相对较粗的粒度上对应用服务或业务模块进行封装与重用；
2. 服务间保持松散耦合，基于开放的标准， 服务的接口描述与具体实现无关；
3. 灵活的架构 -服务的实现细节，服务的位置乃至服务请求的底层协议都应该透明；

回页首

ESB

让我们暂时回到网络技术不普及的时代，你怎样在两台机器之间传递文件？我还记得为了给实验室的每台机器安装Borland C++的环境，猜猜我动用了什么：一根"串口线"。不过，我仍然觉得庆幸，好在每台机器都运行同样的操作系统- DOS(很少有人还记得DOS中有Interlnk这样一个命令吧)， 用来通过串口线在两台机器间传递流文件。否则我将不得不用软盘来拷贝所有的安装文件。我那个时候的梦想就是，哪一天有这么一个叫做"网络"的东西能够把实 验室里面所有机器都连接起来，而不用我在各机器之间跑来跑去。

让我们回归主题，你现在已经基本明白了什么是SOA。假定你已经按照SOA的思想提炼出了各种业务服务，公布出来，同样， 你发现其他很多人也做了同样的事情。大家都很振奋，开始踊跃的尝试，我调用你的一个服务，你调我的一个服务。啊哈！大家都SOA了。且慢，那么这个SOA 给你们带来了什么好处呢？Ok，现在我可以在J2EE环境里调用.Net的组件了，但是原来没有SOA的时候也可以做到的呀。只要两个节点之间互相认可对 方的方式，即使不存在公开/统一的服务界面也可以实现点到点的互联。因此我们不得不承认，如果我们只有服务，而服务的请求者和服务的提供者之间仍然需要这 种显式的点到点的调用，那么这就不是一个典型的SOA架构。请看图二，服务的参与双方都必须建立1对1 的联系。这样一个结构与我十几年前的那种互联的方式何其相似！但是，还记得我们上面提到的SOA三个基本要素吗？显然第三点没有做到。

因此，在SOA中，我们还需要这样一个中间层，能够帮助实现在SOA架构中不同服务之间的智能化管理。最容易想到的是这样 一个HUB-Spoke结构，在SOA架构中的各服务之间设置一个类似于Hub的中间件，由它充当整个SOA架构的中央管理器的作用。请看图三，现在服务 的请求者和提供者之间有了一个智能的中转站， 服务的请求者不再需要了解服务提供者的细节。不错！看上去是一个好的SOA结构。事实上，传统的EAI就是通过这样一种方式来试图解决企业内部的应用整合 问题。

EAI的目标是支持对现有IT系统的重新利用，通过EAI技术能够将不同的软件和系统串联起来，延长这些应用系统的生命周 期。传统的EAI，往往使用如CORBA和COM等的消息中间件进行分布式，跨平台的程序交互，修改企业资源规划以达到新的目标，使用中间件、XML等方 法来进行数据分配。因此，实际上传统的EAI是部件级的重用。很不幸的是，基于部件的架构没有统一的标准，因此，各个厂商都有各自不同的EAI解决方案， 你会看到各种各样的中间件平台。如果EAI碰到了异构的IT环境，就必须分别考虑怎样在各个不同的中间件之间周旋，来实现合理的互联方式，你不得不考虑各 种复杂的可能性。因此，你所见过的大多数传统EAI解决方案都比较笨重。

再回顾一下我们上面介绍过的SOA的应用场景：复杂的企业级架构。如果我们选择Hub的模式来构建SOA基础架构，从纯粹 逻辑的角度，可能会出现哪些问题呢？首先，整个SOA架构的性能，如果每个服务的请求都经过中央Hub的中转，那么Hub的负担会很重，速度会随着参与者 的增多而愈来愈慢；其次，这样的系统会很脆弱，一旦Hub出错，整个SOA架构都会瘫痪；最后，这样的架构会破坏SOA的开放性原则，参与者运行在一个相 对封闭的环境中，扩展起来十分麻烦。因此，这也不是理想的SOA架构。

好了，现在该ESB登场了，请看我们的正解：

它与前面的Hub结构有什么不同呢？首先，它比单一Hub的形式更开放，总线结构有无限扩展的可能；其次，真正体现了 SOA的理念， 一切皆为服务，服务在总线(BUS)中处于平等的地位。即使我们需要一些Hub，那么它们也是以某种服务的形式部署在总线上，相比上面的结构要灵活的多。 这就是ESB，我们需要给它一个明确的定义：ESB是一种在松散耦合的服务和应用之间标准的集成方式。它可以作用于：

• 面向服务的架构 -分布式的应用由可重用的服务组成
• 面向消息的架构 - 应用之间通过ESB发送和接受消息
• 事件驱动的架构 - 应用之间异步地产生和接收消息

很不幸，上面的定义看上去很拗口，我们暂且用一句较通俗的话来描述它：ESB就是在SOA架构中实现服务间智能化集成与管 理的中介。而它与SOA的关系要相对好理解一些：ESB是逻辑上与SOA 所遵循的基本原则保持一致的服务集成基础架构，它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能。可以这样说，ESB是特定环境下(SOA 架构中)实施EAI的方式： 首先，在ESB系统中，被集成的对象被明确定义为服务，而不是传统EAI中各种各样的中间件平台，这样就极大简化了在集成异构性上的考虑，因为不管有怎样 的应用底层实现，只要是SOA架构中的服务，它就一定是基于标准的。

其次，ESB明确强调消息(Message)处理在集成过程中的作用，这里的消息指的是应用环境中被集成对象之间的沟通。 以往传统的EAI实施中碰到的最大的问题就是被集成者都有自己的方言，即各自的消息格式。作为基础架构的EAI系统，必须能够对系统范畴内的任何一种消息 进行解析。传统的EAI系统中的消息处理大多是被动的，消息的处理需要各自中间件的私有方式支持，例如API的方式。因此尽管消息处理本身很重要，但消息 的直接处理不会是传统EAI系统的核心。ESB系统由于集成对象统一到服务，消息在应用服务之间传递时格式是标准的，直接面向消息的处理方式成为可能。如 果ESB能够在底层支持现有的各种通讯协议，那么对消息的处理就完全不考虑底层的传输细节，而直接通过消息的标准格式定义来进行。这样，在ESB中，对消 息的处理就会成为ESB的核心，因为通过消息处理来集成服务是最简单可行的方式。这也是ESB中总线(Bus)功能的体现。其实，总线的概念并不新鲜，传 统的EAI系统中，也曾经提出过信息总线的概念，通过某种中间件平台，如CORBA来连接企业信息孤岛，但是，ESB的概念不仅仅是提供消息交互的通道， 更重要的是提供服务的智能化集成基础架构。

最后，事件驱动成为ESB的重要特征。通常服务之间传递的消息有两种形式，一种是调用(Call)， 即请求/回应方式，这是常见的同步模式。还有一种我们称之为单路消息(One-way)，它的目的往往是触发异步的事件， 发送者不需要马上得到回复。考虑到有些应用服务是长时间运行的，因此，这种异步服务之间的消息交互也是ESB必须支持的。除此之外，ESB的很多功能都可 以利用这种机制来实现，例如，SOA中服务的性能监控等基础架构功能，需要通过ESB来提供数据，当服务的请求通过ESB中转的时候，ESB很容易通过事 件驱动机制向SOA的基础架构服务传递信息。

回页首

ESB的适用场景及要素

首先，我们来看一看ESB有哪些基本的功能。既然ESB会以中介的身份出现，它就必须有两方面的考虑，首先它必须了解被它 中介的两个端点：1)服务的请求者以及请求者对服务的要求，2)服务的提供者和它所提供服务的描述；其次，它必须具有某种机制能够完成中介的任务。我们把 这两类考虑归纳为ESB的两个基本功能：面向服务的原数据(MetaData)管理功能 和中介(Mediation)功能。 作为SOA的重要构成部分，ESB承担的重任还包括怎样将企业架构中已存在的业务服务连接到总线上来，我们称之为适配器(Adapter)功能。尽管服务 本身已经用公开的接口来描述，但具体的实现还是运行在不同的环境中，因此，ESB还应该提供对服务底层协议的支持，譬如应用协议J2ee，.Net， 通讯协议如Http，JMS等等。除此之外，还需要对具体应用中涉及到的服务加以管理，如性能，可靠性，安全性等等。

ESB 提供了最基本的功能来保障SOA系统的运行，这些功能应该包含下列内容：

• 在总线范畴内对服务的注册命名及寻址管理功能 - 服务的Meta-data管理
• 面向服务的中介功能
  • 提供位置透明性的服务路由和定位服务
  • 多种消息传递型式(请求/响应，单路请求，发布/订阅等等)
  • 支持广泛使用的传输协议(Http，JMS，MQ等等)
• 支持多种服务集成方式，比如 JCA、Web 服务、Messaging、Adaptor
• 对服务管理的支持，如服务调用的记录、测量和监控数据的提供

很多时候，很难界定哪些功能是应该由SOA的基础架构(infrastructure)提供的，而哪些应该放在ESB的范 畴内来解决。笔者认为，放大或突出ESB在SOA架构中的地位并不很恰当。比较合理的解释是：ESB应该构筑在完善的SOA架构上，做它应该做的事-服务 集成。至于怎样集成，应该根据你的上下文环境，考虑有哪些SOA的基础设施可供你使用，然后再基于SOA的基础架构来实现你的ESB设计。

在更高的层次，ESB还提供诸如服务代理，协议转换等等功能，我们称之为ESB的应用模式(ESB usage pattern)。作为SOA架构的服务集成功能提供者，我们可以总结出的一些比较常用的应用模式，例如：

1）协议转换模型，用于当服务的请求者与服务提供者基于不同协议时的消息转换情形

2）消息广播模式，用于事件驱动多个动作或者消息广播的情形

3）服务匹配模式，用于需要动态选择服务提供者的情形，例如可以根据消息的内容，或负载情况，或服务级别约定(SLA)，来为服务请求者选择合适的服务。

这里我们只列举了3个典型的模式，而这样的例子实在太多了，发挥你的创造性，你还会想出来更多的，这也是ESB的魅力所 在。但是，在ESB的设计上，注意不能喧宾夺主，ESB的功能在于帮助服务的集成，而不是参与业务逻辑。业务逻辑应该封装在业务服务中，或通过业务编排服 务(Process Service)来组织。

回页首

实战

关于ESB，目前还没有被一致接受的标准。我们可以通过选择成熟的EAI 中间件来实现服务的集成与互操作性。这样做的好处是你的开发过程会很顺畅，因为它已经足够稳定且有丰富的工具支持。通常这样的EAI产品在目前阶段都还不 是基于开放的标准，例如IBM的WebSphere MQ5.3，作为IBM EAI实现ESB的消息平台，就不是开放的标准。如果一定要选择开放标准的ESB实现方式，Web 服务加上WS-* 协议几乎是我们唯一的选择，但毕竟SOA、ESB仍处于起步的阶段，一方面我们还没有很成熟的产品支持所有的WS-*协议，另一方面这些WS-* 协议本身还处在频繁变化的阶段。因此当你选择ESB实施方案的时候，最好考虑平衡ESB实施、开发的工作量。

这里你可能会有疑问，既然SOA架构追求开放性，为什么我们要容忍用私有的ESB产品如IBM WBI/MQ来构建SOA架构的集成环境？这是一个好问题。SOA始终是我们追求的大目标，开放是必然的趋势，这是毋庸置疑的。但是，请注意ESB的定 义，至少到目前为止，还没有明确的要求它的实现一定是开放的，每一个软件供应商对它都可能有不同的理解和实现的策略。我们不用怀疑ESB将来的开放之路， 但至少在目前阶段，我们不能坐下来等待它的到来。 其实，ESB充当的是SOA中的中介角色，因此，即使将来ESB变化了，对服务的请求者和服务的提供者都不会造成很大的冲击，因为它本来就是对用户透明 的。举个例子，J2EE，它的标准一直在变化中，但是大家通常都能接受它的变化，社会总是要进步的，IT也一样。你不可能因为J2EE 两年以后要出1.6就不再使用现在的1.4了。

IBM目前可以用于ESB实施的产品也可以分为两大阵营：

1. 以目前稳定的产品如WS MQ，WBI Message Broker，Tivoli等为代表的EAI解决方案。
2. 以WAS6 SIBUS为代表的专用ESB平台。

现有的EAI解决方案，可能涉及如下的IBM软件产品：

• WebSphere BI Message Broker用于提供ESB的message 中介功能(Mediation)
• WebSphere MQ / JMS 用于消息传输服务
• WebSphere Process Choreographer 用于实现服务流程
• WebSphere Adaptor用于连接遗留系统
• Web Service Gateway用于实现Web服务 Proxy，屏蔽企业内部/外部Web服务的实现细节

WAS6 中提供了崭新的消息服务平台WPM(WebSphere platform messaging)，并基于这一平台提供了ESB的一个具体实现- SIBus(Service Integration Bus) 它可以支持同步和异步的消息通信。总线(Bus)通过互联的消息引擎管理消息源。同时支持基于Web服务和JMS，MQ格式的消息交互。你可以从WAS6 身上看到IBM战略的变化，SIBus只是IBM加大对于SOA支持的一步，你还会很快看到更多的变化，例如独立的ESB产品，ESB的开发工具等等。但 是，你完全不必担心，这些变化都会保持兼容性，现在SOA的投入，无论是以哪一种方式，都会在IBM的SOA整体考虑之中。

上述的两种方案并不是对立的，你可以选择基于成熟产品实现ESB，也可以尝试一下IBM的最新技术。这两种方案甚至可以互联，见图八。我们将在系列的第四部分讲解这一较为复杂的场景。

在本系列文章接下来的三部分中，我们将继续详细描述ESB的具体实现步骤。

回页首

结束语

本文向您介绍了SOA以及ESB 的基本知识，确定了一些 ESB 实现中最常见的基本功能，论述了ESB产生的必要性，以及ESB在SOA中的地位。

回页首

参考资料

• Patterns: Service-oriented Architecture and Web Services红皮书，SG24-6303-00，2004 年 4 月，作者 Endrei M。 等。
• "理解面向服务的体系结构中企业服务总线场景和解决方案，第 1 部分"(developerWorks，2003 年 12 月)作者 Rick Robinson。
• Patterns: Implementing an SOA using an Enterprise Service Bus，SG24-6346-00，作者 Martin Keen 等。
• Enterprise service bus - making SOA real作者 Beth Hutchison， Peter Lambros， Rob Phippen， Marc-Thoms Schimdt

关于作者

     1996年，Gartner最早提出SOA。2002年12月，Gartner提出SOA是"现代应用开发领域最重要的课题"，SOA并不是一个新事 物，IT组织已经成功建立并实施SOA应用软件很多年了，BEA、IBM、等厂商看到了它的价值，纷纷跟进。SOA的目标在于让IT变得更有弹性，以更快 地响应业务单位的需求，实现实时企业(Real-Time Enterprise，这是Gartner为SOA描述的愿景目标)。而BEA的CIO Rhonda早在2001年6月就提出要将BEA的IT基础架构转变为SOA，并且从对整个企业架构的控制能力、提升开发效率、加快开发速度、降低在客户 化和人员技能的投入等方面取得了不错的成绩。

　　SOA是在计算环境下设计、开发、应用、管理分散的逻辑(服务)单元的一种规范。这个定义决定了SOA的广泛性。SOA要求开发者从服务集成的 角度来设计应用软件，即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考，并考虑复用现有的服务，或者检查如何让服务被重复利用。SOA 鼓励使用可替代的技术和方法(例如消息机制)，通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后，这种消息机制的应用允许公司仅通过调整原 有服务模式而非被迫进行大规模新的应用代码的开发，使得在商业环境许可的时间内对变化的市场条件做出快速的响应。

　　SOA也不仅仅是一种开发的方法论--它还包含管理。例如，应用SOA后，管理者可以方便的管理这些搭建在服务平台上的企业应用，而不 是管理单一的应用模块。其原理是，通过分析服务之间的相互调用，SOA使得公司管理人员方便的拿到什么时候、什么原因、哪些商业逻辑被执行的数据信息，这 样就帮助了企业管理人员或应用架构师迭代地优化他们的企业业务流程、应用系统。

　　SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚，轻松应对企业商业服务变化、发展的需要。企业环境中单个应用程序 是无法包容业务用户的(各种)需求的，即使是一个大型的ERP解决方案，仍然不能满足这个需求在不断膨胀、变化的缺口，对市场快速做出反应，商业用户只能 通过不断开发新应用、扩展现有应用程序来艰难的支撑其现有的业务需求。通过将注意力放在服务上，应用程序能够集中起来提供更加丰富、目的性更强的商业流 程。其结果就是，基于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合。服务是从业务流程的角度来看待技术的--这是从上向下看的。这种角度 同一般的从可用技术所驱动的商业视角是相反的。服务的优势很清楚：它们会同业务流程结合在一起，因此能够更加精确地表示业务模型、更好地支持业务流程。相 反我们可以看到以应用程序为中心的企业应用模型迫使业务用户将其能力局限为应用程序的能力。

　　企业流程(enterprise process)是流经企业框架的空气，它赋予业务模型里的组件以生命，并更加清晰地定义了它们之间的关系。流程定义了同业务模型进行交互操作的专门方 法。例如，会计可能是企业服务系统的一个组件--但是将发票寄给客户却是一个业务流程。服务被定义用来支持业务流程，因而贯穿整个流程始终的是：各种服务 组件在流程和逻辑实现过程中的装配操作。理解业务流程是定制服务的关键所在。

二、SOA 的描述所适用的原则

• 利用显式的与实现无关的接口来定义服务。
• 利用强调位置透明性和可互操作性的通信协议。
• 封装可重用业务功能的服务的定义。

图 1说明了这些原则。注意，虽然 Web 服务技术非常符合这些原则，但它并不是唯一符合这些原则的技术。

图 1: SOA 的原则

为了实现 SOA，应用程序和基础架构都必须支持 SOA 原则。启用 SOA 应用程序涉及到创建服务接口，服务接口可以直接也可以间接地通过使用适配器用于现有的或新的功能。从最基本的级别来看，启用该基础架构涉及到规划功能来将服务请求路由和传递给正确的服务提供者。然而，基础架构支持在不影响服务的客户端的情况下由另一个服务实现替代原有的服务实现也是至关重要的。这不仅需要根据 SOA 原则指定服务接口，而且需要基础架构允许客户端代码以独立于所涉及的服务位置和通信协议的方式来调用服务。

三、ESB是什么？

根据维基百科的ESB定义，ESB有如下特性：

1. 它是面向服务架构的实现。
2. 它通常是操作系统和编程语言无关的；它应能在Java和.Net应用程序之间工作。
3. 它使用XML（可扩展标识语言）作为标准通信语言。
4. 它支持Web服务标准。
5. 它支持消息传递（同步、异步、点对点、发布-订阅）。
6. 它包含基于标准的适配器（如J2C/JCA），用于集成传统系统。
7. 它包含对服务编制（orchestration）和编排（choreography）的支持。
8. 它包含智能、基于内容的路由服务（itenerary路由）。
9. 它包含标准安全模型，用于ESB的认证、授权和审计。
10. 它包含转换服务（通常是使用XSLT），在发送应用和接收应用之间转换格式，简化数据格式和值的转换。
11. 它包含基于模式（schema）的验证，用于发送和接收消息。
12. 它可以统一应用业务规则，充实其它来源的消息，分拆和组合多个消息，以及处理异常。
13. 它可以条件路由，或基于非集中策略的消息转换，即不需要集中规则引擎。
14. 它可监视不同SLA（服务级别合约）的消息响应门限，以及在SLA中定义的其它特性。
15. 它（常常）简化“服务类别”，向更高或更低优先级用户做出适当的响应。
16. 它支持队列，在应用临时不可用时用来保存消息。
17. 它由（地理）分布式环境中的选择性部署应用适配器组成

对于其中一些厂商（IBM、微软）来说，ESB是将一系列能力联结在一起的一种模式，而其他厂商认为ESB是一种产品。在2005年，微软Identity Platform的产品经理Rich Turner写道：

ESB[产品]是一根聪明的管子，用来连接各个愚笨的节点。[……]Web Service的途径让节点本身也变得聪明，减少了对底下聪明管道的需要，并确保了跨越任何平台与设备的开放的通讯。

• OWASP Top 10 - 2010 Document
• OWASP Top 10 - 2010 - wiki
• OWASP Top 10 - 2010 Presentation

The OWASP Top 10 Web Application Security Risks for 2010 are:

• A1: Injection
• A2: Cross-Site Scripting (XSS)
• A3: Broken Authentication and Session Management
• A4: Insecure Direct Object References
• A5: Cross-Site Request Forgery (CSRF)
• A6: Security Misconfiguration
• A7: Insecure Cryptographic Storage
• A8: Failure to Restrict URL Access
• A9: Insufficient Transport Layer Protection
• A10: Unvalidated Redirects and Forwards

Please help us make sure every developer in the ENTIRE WORLD knows about the OWASP Top 10 by helping to spread the word!!!

As you help us spread the word, please emphasize:

• OWASP is reaching out to developers, not just the application security community
• The Top 10 is about managing risk, not just avoiding vulnerabilities
• To manage these risks, organizations need an application risk management program, not just awareness training, app testing, and remediation

We need to encourage organizations to get off the penetrate and patch mentality. As Jeff Williams said in his 2009 OWASP AppSec DC Keynote: “we’ll never hack our way secure – it’s going to take a culture change” for organizations to properly address application security.

If you are interested in doing a presentation on the OWASP Top 10, please feel free to use all or parts of this:

Introduction

The OWASP Top Ten provides a powerful awareness document for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Project members include a variety of security experts from around the world who have shared their expertise to produce this list. Versions of the 2007 were translated into English, French, Spanish, Japanese, Korean and Turkish and other languages. Translation efforts for the 2010 version are underway and they will be posted as they become available.

We urge all companies to adopt this awareness document within their organization and start the process of ensuring that their web applications do not contain these flaws. Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code.

SecondLife服务器构成

SecondLife（下简称SL）的服务器端包括这六大类服务器：Login server（登陆服务器）；User server（用户服务器）；Space server（空间服务器）；Data server（即数据服务器）；Simulator（即模拟器），常被称为SIM；Other servers（其他服务器），包含若干不同功能服务器，林登公司（Linden）似乎对它们的详情有所保留。

   下面对这六大类服务器进行详细解释。

1、Login server，登录服务器。是运行在login.agni.lindenlab.com上的CGI脚本。顾名思义，就是用来验证用户名和密码的。验证后还要决定用户登录到什么区域：是用户的家、还是上次离开SL时的区域或者URL指定的某个区域。接下来要找到运行该区域的模拟器，验证用户是否被允许连接到该区域。最后向模拟器发出连接请求，并告知客户端连接到何处。

2、User server，用户服务器。曾被用来处理用户登录，即登录服务器现在的功能。现在负责管理即时通讯（instant message）会话，尤其是组内即时通讯。

3、Space server，空间服务器。处理基于不同网格X，Y坐标间消息的路径选择。模拟器与空间服务器会话以便被其登记在案，还可以发现自己的邻居是谁。作用与网络概念中路由器相仿。

4、Data server，数据服务器。处理与中心数据库、日志服务器、仓库数据库以及搜索数据库的连接（上述4种服务器属于第6类其他服务器），代表模拟器运行查询。（注： SL 服务器网格中只有一个中心服务器，日志服务器，而仓库服务器以及搜索服务器分别有多个，或者在某个范围内，前两者与后两者分别是一对多的关系。）

5、Simulator，模拟器。这是SL最主要的服务器。每个模拟器模拟一个256*256平米的整块区域。当SL客户端浏览器满虚拟世界转悠时，实际上是在不同的模拟器间被倒手。模拟器的任务有：存储物体状态、土地状态、地形海拔图状态。模拟器还负责计算物体和土地的能见度，并把计算数据传送给客户端。模拟器还使用优先级队列传送图像数据。还有一种物理学模拟器专门掌管Hovak物理学例库[1]。公共谈话（Chat）和即时通讯（instant message）也由模拟器处理。全速运行时，模拟器可达每秒45帧，如果不能保持全速，它将在不减低帧速率的情况下尝试时间膨胀[2]，在Second Life中如果不能全速，则会以物体显示延迟为代价，而不会影响已显示物品的质量，这种效果也被叫做Lag。

　　模拟器两两之间以UDP网络连接进行通信，并由相邻的模拟器保持通信连接。

    要注意的是：在Second Life中，模拟器与客户端浏览器（Viewer）之间的区别与其他虚拟环境差异较大。模拟器负责运行物理引擎，碰撞检测，跟踪每一事物和用户化身Avitar的位置，将物品的位置发送给客户端，必要时将更新的数据发送给客户端（只有当发生碰撞或者方向和速度变化等情况下才会有这种更新）。而客户端负责处理本地物品的位置，获取速度等物理学信息，进行简单的物理学运算以跟踪何物向何处移动，不进行碰撞检测。

6、Other servers，其他服务器，其中包含若干规模较小的服务器。下面一一说明：

l         中央枢纽：在SL的官方网站上没有给出说明，但根据字面意思推断，应当与全局通讯、调度以及分布式运算有关。

l         代理数据库：掌管元数据与项目id（UUID）之间的映射。代理（Agent）一词在SL中特指与用户化身（Avatar）相对应的后台底层的唯一表示，在SL计算机系统中有唯一识别号，简称UUID，该号码与用户是唯一对应且持久存在的。其他物品也有UUID，但物品的UUID是在物品放置于虚拟世界中时临时生成的，不是持久的UUID。元数据是指在Second Life中不可分的数据，比如构成物体形状的基本单元（prim），或者一张纹理（texture）。一个物体可能由多个元数据组成，因此需要记录元数据与物体，也即是此处所称的项目之间的关系，而代理数据库就承担此责任。同时，任何物体都有唯一拥有者，记录物体的拥有者，也是代理数据库的任务。

l         中心数据库：官方文档描述该服务器存储谁拥有什么，用于记录账单，而实际上远不止这么简单，但囿于目前所能取得的资料，很少有对其详细的叙述。

l         搜索数据库：中心数据库的副本，用于搜索。可以断定，为了提高搜索效率，此数据库一定保有大量索引。而中心数据库为了保证数据写入和修改的效率，使用的索引肯定是比较少的。

l         地图服务器：使用OpenGL绘制全局地图。Second Life客户端也是使用OpenGL绘制的，此外普通网页上的SL地图使用的是Google的地图API。

l         RPC服务器： XML RPC（远程过程调用）服务器。其作用包含：开发者需要的，不通过客户端浏览器来操作Second Life的API，可将XMLRPC服务器代码翻译为in-world请求，与空间数据库和中心数据库通讯。

SecondLife用户登录验证步骤解析

我们不妨通过分析登录验证的步骤，来看看这些服务器是如何进行互相通信的。流程可参见文后图示。

1.        客户端对用户服务器发出安全信息校验和（Checnsum）请求，端口号：12036。

2.        客户端对登录服务器发出登录请求：

a)       通过HTTP打包发送XML RPC进行登录；

b)       Web服务器（多数情况下是Apache）与SQL数据库通话，获得用户信息，连接模拟器所需信息（比如IP地址）并生成连接；

c)       用户帐号名称，MD5口令，客户端版本，登录地址请求。

3.        登录服务器从数据库获得授权证书。

4.        登录服务器与网格中的模拟器对话：

a)      决定哪个模拟器负责该客户端；

b)      请求会话开始；

c)      网格返回与客户端通讯的UDP端口号 12035，13000-13050

5.        SIM响应登录服务器，告知用户是否允许登录到模拟器。

6.        登录服务器响应客户端：

a)       返回的信息有，用户id，会话id，安全会话id，模拟器IP，模拟器端口号，全局坐标，用户仓库信息等；

b)       大部分id都是UUID（比如用户id，会话id，安全会话id）；

c)       用户id是唯一的，并且是永久的。

7.        客户端与模拟器握手，并发送用户id和会话id。

8.        客户端与用户服务器握手：

a)       发送出席信息，以便收到组及时消息（Group IM）；

b)       给用户授予组权限；

c)       用户服务器验证模拟器会话信息（在数据库的Presence-Agent表中）。

结语

　　以上是对SecondLife架构的一个简要介绍，目前国内已经出现了类似SecondLife的在线虚拟游戏／社区，希望本文能够为大家提供一些启示，同时也期待国内的架构师们出来分享自己的经验与心得。

说明：本文部分内容译自SecondLife官方wiki。

--------------------------------------------------------------------------------

[1]简单地说物理学模拟器负责物理学相关的运算，比如重力加速度的效果，不同物体的空间占位关系等。Hovak是服务器端系统（grid）的代号，即将发布的是Hovak4。

[2]物理学名词，来自相对论。时间并不是永远以我们感受到的当前这种速度进行的，它也会发生变化；一般和速度有关。速度越快，越接近于光速，时间就会越慢

   DEM 的目的和特点

　　2.进入 90 年代以后，世界格局发生了根本的变化。反映在制造业，就是全球化趋势日益明显。

　　3.动态多变的市场要求企业的业务过程有较好的柔性，能根据环境的变化及时调整其业务过程(业务过程重组， BPR )。在业务过程重组的同时，现有的信息系统也必须随之调整。这样才能在不同的层次支持业务过程的重组，使之真正能起到应有的作用。然而，现有的 ERP 软件(如 SAP/R3 、 Oracle 等)的柔性较差，还不能很好满足这一要求。僵硬的信息系统与动态多变的市场、频繁的 BPR 将成为今后的一对重要矛盾。为了解决这个矛盾，荷兰 BaaN 公司提出了下一代 ERP ，即动态企业建模( Dynamic Enterpreise Modelling,DEM )的思想，并已将其付诸实现。

　　4.DEM 在如下几个关键方面区别于通常的 ERP ：

• DEM 支持连续的业务过程改进
• DEM 支持软件结构的重组
• DEM 能进行高质量的运行
• DEM 允许客户选择自己的界面和工作平台，并能很方便地与其他工作平台集成。

   DEM 的目的和特点

　　1. DEM 的目的是让用户用自己熟悉的方式，根据其公司内部和外界环境的变化，最快、最好地建立公司的业务控制模型、业务功能模型和业务过程模型，或对它们进行调 整，节约时间、消除浪费、降低成本和提高效率，以期在无法预测的持续、快速变化的竞争环境中求得生存和发展。

　　2. DEM 是一种革命性的软件设计方法，其本质特征是通过使用动态的管理模型来建立一个新的信息系统。每个模型都是动态的，因为它允许而且便于企业规划和记录其发展 和演变历程，因此支持业务过程的连续优化。在 DEM 中，主要体现了两个思想：一是在生成某公司的特定模型时，充分利用最好的实例知识和实践经验，表现在企业参考模型的使用；二是在动态公司中，公司的信息系 统能够适应公司环境等的快速变化，表现在 DEM 工具 -- 企业建模工具的使用。

　　3. DEM 的三个主要优点是：

• 速度快
  体现在简短、紧凑的 ORGWARE 软件中企业建模工具的使用，通过使用预定义业务模型来减小该过程的难度。
• 柔性高 　　　　　　　 　　 　　 DEM 的 软件结构可以不费时不费力地随着企业业务过程的变化而相应改变。上述两方面的优点通过企业建模工具和应用软件的充分集成得以实现，这也使得企业建模过程中许多工作可以自动完成。
• 质量好
  DEM 提高了企业建模的质量，因为它使用了一种简单的方式使其中很复杂的功能可视化。

   DEM 的内容

1. BAAN IV ORGWARE
   DEM是一个概念、一种方法，而BAAN IV ORGWARE则是实现DEM的工具，是陈述DEM的关键。BAAN IV ORGWARE由四个部分组成，即：
   • 企业建模工具 它使公司可以用图形描述业务模型的组织结构、功能特点以及业务过程的先后顺序。
   • 企业参考模型 这些模型为自动化、电子、项目工程等领域内的企业，提供了建立本企业模型的参考。
   • 企业模型性能管理工具 这是ORGWARE 性能管理工具，包括一套应用 BAAN IV ORGWARE 所有模块的预定义性能指标。简单地说，这就是评价模块。
   • 实施模块
     在DEM概念框架内，BAAN 通过三个预定义模型的连续赋值来实现，每个模型表示结构的不同方面，而它们组合起来就表示了整个企业。这三个模型是:
     1. 业务功能模型 应用DEM的第一步是给业务功能模型赋值，在一个分级的功能树中，业务过程被描述为"黑箱"，这里，黑箱定义了在不考虑具体怎样做的情况下，在这个阶段应当做些什么，功能模型的主要目的有：
        • 建立知识库(专家系统)，即为了管理咨询而记录"最好实例"业务知识(企业参考模型)。
        • 指导管理人员和咨询人员之间的对话(信息交流)。
        • 在相关业务分析基础上，开始业务过程的选择和建模。
     2. 业务过程模型
        业务过程模型规定在BAAN功能基础上怎样实现业务功能的目标，这是在过程的最低层次上建模，实际上是一个范例变换过程。于是在与主要的用户讨论具体过程时，就可以在适当的时间和地方显示适当的相应功能模块。业务过程模型的主要目的有：
        • 通过过程的划分来描述业务功能是怎样实现的。
        • 用过程来作为解释BAAN功能的理想工具，但其中最重要的是BAAN能为用户做些什么。
        • 过程是生成目标用户环境(END-USER ENVIRONMENT)的一个起点。
     3. 业务组织模型
        业务组织模型根据分工、业务单元和部门来描述组织结构，关键问题之一是组织中作用的 识别。这里，作用指在过程执行中按惯例分配给某一个特定的人或工作组 的行为或任务。模型的另一个特点是可以规定模型中不同组成部分之间的级别和功能关系。
2. DEM结构及其三个模型之间的关系
   • DEM结构示意图
     DEM的结构大致分为三个层次，即：核心功能层Ⅰ、过程管理层Ⅱ和组织管理层Ⅲ。对不同的企业而言，虽然其中Ⅱ、Ⅲ是一样的，但是Ⅰ并不一样。
   • DEM三个模型之间的关系
     DEM 中的三个模型是业务控制模型、业务功能模型和业务过程模型。当把某个参考模型作为一个PROJECT模型的基础时，必须使用自顶向下的方法来研究和重新评 价参考模型，并且从业务控制模型开始，因为业务控制模型对理解模型的整个结构是非常重要的。业务控制模型由多层框图构成，表示了功能和这些功能间的流向。 当业务控制模型的结构清楚后，就应当从头来分析业务功能模型，以确定应当使用哪些功能和业务功能选择和变化形式。业务控制模型和业务功能模型之间的关系是 一对一关系。对业务控制模型中每个主要功能和其中的重要功能，在企业建模的业务功能模型中，都有一个完全相同的业务主要功能和重要业务功能。在业务控制模 型和业务过程模型之间也存在一个类似上面一对一的参照。
   • 企业模型的建立
     在BAAN IV ORGWARE 的企业建模中有一个目录目标企业模块，它是专门为初次应用该套软件建模的企业而开发的，它是一种面向里程碑的方法，它指导用户完成BAAN方案的选择、实施和优化。
     目标企业把企业的建模过程大致分为3 个大阶段，以及8个小阶段（对应8个里程碑）。

简介：
SAP公司是ERP思想的倡导者，成立于1972年，总部设在德国南部的沃尔道夫市。SAP的主打产品R/3是用于分布 式客户机/服务器环境的标准ERP软件，主要功能模块包括：销售和分销、物料管理、生产计划、质量管理、工厂维修、人力资源、工业方案、办公室和通信、项 目系统、资产管理、控制、财务会计。R/3适用的服务器平台是：Novell、Netware、NT Server、OS400、Unix ，适用的数据库平台是：IBM DB2、Informix、MS SQL Server、Oracle ，支持的生产经营类型是：按定单生产、批量生产、合同生产、离散型、复杂设计生产、按库存生产、流程型，其用户主要分布在航空航天、汽车、化工、消费品、 电器设备、电子、食品饮料等行业。

点评：
R/3的功能涵盖了企业管理业务的各个方面，这些功能模块服务于各个不同的企业管理 领域。在每个管理领域，R/3又提供进一步细分的单一功能子模块，例如财务会计模块包括总账、应收账、应付账、财务控制、金融投资、报表合并、基金管理等 子模块。SAP所提供的是一个有效的标准而又全面的ERP软件，同时软件模块化结构保证了数据单独处理的特殊方案需求。
目前，排名世界500 强的企业，有一半以上使用的是SAP 的软件产品。因R/3的功能比较丰富，各模块之的关联性非常强，所以不仅价格偏高，而且实施难度也高于其他同类软件。R/3适用于那些管理基础较好经营规 模较大的企业，普通企业选择R/3时，要充分考虑软件适用性和价格因素。

高度集成的Oracle

简介：
Oracle公司是全球最大的应用软件供应商，成立于1977年，总部设在美国加州。Oracle主打管理软件产品 Oracle Applications R11i是目前全面集成的电子商务套件之一，能够使企业经营的各个方面全面自动化。Oracle企业管理软件的主要功能模块包括：销售定单管理系统、工程 数据管理、物料清单管理、主生产计划、物料需求计划、能力需求管理、车间生产管理、库存管理、采购管理、成本管理、财务管理、人力资源管理、预警系统。 Oracle适用的服务器平台是：DEC Open VMS、 NT、 Unix、 Windows 95/98，数据库平台是：Oracle，支持的生产经营类型是：按定单生产、批量生产、流程式生产、合同生产、离散型制造、复杂设计生产、混合型生产、 按定单设计、按库存生产，其用户主要分布在：航空航天、汽车、化工、消费品、电器设备、电子、食品饮料行业。

点评：
Oracle凭借“世界领先的数据库供应商”这一优势地位，建立起构架在自身数据之上的企业管理软件，其核心优势就在于它的集成性和完整性。用户完全可以 从Oracle公司获得任何所需要的企业管理应用功能，这些功能集成在一个技术体系中，而如果用户想从其它软件供应商处获得Oracle所提供的完整功 能，很可能需要从多家供应商分别购买不同的产品，这些系统分属于不同供应商的技术体系，由不同的顾问予以实施，影响了各个系统之间的协同性。对于集成性要 求较高的企业，Oracle无疑是理想的选择。但企业如果对开放性要求较高，Oracle显然无法胜任。

适宜“大批量生产”的JDE

简介：
J.D.Edwards公司于1977年在美国科罗拉多州丹福市创立，JDE系统是其提供的一套用于企业商务解决方案的软件产 品。JDE系统的模块包含制造业、分销业、财务、人力资源管理，其中制造业部分由产品数据管理、厂房设备维修、车间控制、主生产计划、物料需求计划、能力 需求计划等模块所组成；分销业部分由预测、需求计划、库存管理、销售定单处理、销售分析、采购定单处理、分销资源计划、仓库管理、电子数据交换（EDI） 模块所组成；财务部分由总分类账和基础财务、财务模式、预算和分配、应收账、应付账、现金账、多国通货账、固定资产等模块组成。
JDE适用的 服务器平台有：NT、OS/400、Unix、Digital VMS，适用的数据库平台是：IBM DB2、MS SQL Server、Oracle，支持的生产经营类型是：按定单装配、批量生产、按定单设计、合同生产、离散型、按定单制造、按库存生产、混合型生产、连续 型、大批量生产。用户主要分布在汽车、化工、消费品、电器设备、电子、食品饮料、工业品、金属加工、制药业等行业。

点评：
JDE最早是适用于制造业的MRPII系统，后来发展成为适用于制造业、金融、分销、建筑、能源、化工、房地产及公用事业方面的商务软件。虽然JDE的用 户遍及世界35个国家和地区，销售额也一直高居世界ERP软件供应商排名前五位，但JDE曾经一度被淡忘，因为它所采用的技术构架和编程技术没有多层客户 机/服务器和面向对象编程那么热烈地被人们谈论。
JDE在系统稳定性和运行速度上有优异表现，特别适用于大量生产型的工业企业，而且实施总成本不高。JDE是完全基于IBM AS／400小型机开发的，在其他通用系统上的运行效果不理想。目前JDE也在向其他平台扩展。

实现“动态企业建模”的Baan

简介：
BAAN是一个为项目型、流程型以及离散型产业供应链提供ERP系统和咨询服务的公司。BAAN的软件家族产品支持企业一系列 的业务过程，其中包括：制造、财务、分销、服务和维护业务。此外，BAAN公司还提供了Orgware——一套组织工具和软件工具，它能帮助企业减少实施 时间和成本，并能帮助企业实现对系统的不断改进。BAAN ERP 适用的服务器平台是：NT、 OS/400、 Unix、 Windows 95/98、 IBM S390，适用的数据库平台是：IBM DB2、Informix、MS SQL Server、Oracle，支持的生产类型是按定单设计、复杂设计生产，用户主要分布在航空航天、汽车、化工、工业制造等行业。

点评：
BAAN通过Orgware系统件作为企业建模工具，以保证企业灵活运用软件，它强大的功能能满足企业现在的实际需求，也能满足企业将来的需求。 Orgware把公司本身的业务处理流程作为输入，以标准的企业模型为参考，很快地配置系统来满足企业的需要和特殊要求。这样，企业的BAAN应用系统的 模型就会快速地顺利地被确定下来。
业务流程重组（BPR）不利往往是影响ERP实施的重要因素，BAAN的动态建模思想和技术不仅有利于保障 企业成功实施ERP系统，而且便于企业今后依据管理需要重新构建业务框架。业务流程重组有困难或者预计将来业务流程会发生改变的企业，选择BANN会有利 于成功实施运用ERP系统。

为用户量体裁衣的SSA-BPCS

简介：
SSA成立于1981年，其总部设在美国芝加哥。SSA主要向用户提供的BPCS（Business Planningand ControI System商业计划与控制系统）套件包括财务、分销、制造三大部分，能满足企业在这三个管理领域的大部分需要。BPCS适用的服务器平台是： OS/400、Unix，适用的数据库平台是：Informix、Oracle，支持的生产类型是：按定单生产、按库存生产、批量生产、连续型、混合型、 离散型，用户主要分布在汽车、化工、消费品、离散型、电器设备、电子、食品饮料、机器制造、金属加工、制药等行业。

点评：
SSA的BPCS系统的设计具有巧妙的功能和极大的使用弹性，各模块均包含许多用户自定义参数设计功能，可将系统加以裁剪组合，以符合用户特殊需求。
和BAAN一样，SSA为用户设计了快速实施系统的方案，以减少实施的时间成本和风险成本。由于BPCS强大的自定义功能，使实施BPCS的用户无需放 弃原来的工作模版，而是根据用户的实际工作情况来裁剪组合系统，以便短时间内上线运用。“我们的软件是为快速实施所设计”、“我们保持着极短的时间--效 益期”成为SSA打动用户的独特卖点。
对于客户化设置要求较多，或者对于实施时间要求较高的企业，采用SSA的BPCS会是一个不错的选择。

实现客户价值的SYMIX-SyteLine

简介：
Symix成立于1979年，是在微机服务器上开发MRPII软件的第一家软件公司。Symix 提供的软件产品SyteLine套件包含的主要功能模块是：总账、应收款系统、应付款系统、订单管理、采购管理、库存管理、资产管理、预算管理、成本管 理、生产计划。适用的服务器平台是：NT，Unix，适用的数据库是：Progress、Oracle，支持的生产类型：按定单生产、按库存生产、离散型 生产的企业。用户主要分布在汽车制造、电子电器、机械制造、金属加工等行业。

点评：
以客户为中心的商业模式这几年越来越受到 重视，CRM（customer relationship management 客户关系管理）软件因此运应而生，逐步成为企业信息化建设的焦点。虽然CRM这一思想并非Symix确切地提出，但是Symix却将“以客户为中心”的生 产经营理念最大程度地融合到软件中。
大多数CRM软件关注的是以客户为中心的营销服务工作，而Symix的CSRP（Customer Synchronized Resource Planning客户同步资源计划）系统更能以客户为导向，系统地组合企业各项生产经营资源，因此Symix自称CSRP是超越ERP的新型管理思想和软 件系统。对于外部市场环境变化较快，或者完全根据客户需求生产的企业，选择Symix能较好地实现客户需求拢动式生产。

构建虚拟工厂的QAD－MFG／PRO

简介：
QAD公司于1979年在美国加州的卡宾特瑞创立，其软件产品MFG／PRO系统包含分销、制造、财务三大类别36个主要功能模 块。适用的服务器平台是：NT、Unix，适用的数据库平台是：Progress、Oracle，支持的生产类型是：离散型、连续型、成批生产、备货生 产、按订单生产和重复生产，用户主要分布在电子工业、汽车制造、医药工业和消费品工业等行业。

点评：
以戴尔和阿迪达斯为代表 的虚拟工厂经营模式，在以信息技术为主的新经济时代有着特殊的经营优势。QAD的供应链管理系统就是用来帮助建立虚拟工厂的，这个“工厂”将涉及的不同研 发者、供应者、装配者、包装者和批发者组织起来，使它们与客户要求保持一致，然后工厂在产品上标以统一商标并获得利润。QAD 集成的分布式MFG／PRO系统能运行于虚拟工厂的整个经营管理过程，以便使“工厂”将其客户与他们自己很好地结合起来，然后再与供应商，以及供应商的供 应商联系在一起。MFG／PRO系统可以设置成一台机器多个数据库、多台机器单数据库、一台机器分开的数据库、多台机器分散的数据库，这种灵活的数据库配 置，可以实现任意数目的用户机同时存取任意数目的数据库服务器，以确保虚拟工厂在不同地区不同信息环境下协同运作。

简便实用的四班—Fourth Shift

简介：
FOURTH SHIFT（四班）公司成立于1982年，总部位于美国明尼阿波利斯市。Fourth Shift软件包含40多个管理模块，覆盖生产、采购、销售、客户服务等集成子系统。适用的服务器平台是：Novell Netware、NT、Windows 95/98，适用的数据库平台是：MS SQL Server，支持的生产类型主要是离散型、按单生产，也可用于流程式连续生产型企业，用户主要分布在日用消费品、电子电器、计算机行业。

点评：
Fourth Shift是一套适于中小制造企业应用的软件系统，功能虽然不如SAP的软件丰富，但基本符合中小企业在生产管理、物流管理、财务管理等方面的需求，而且具有简便实用、成本低廉、实施期短（一般3—6个月完成实施）等特点。
虽然Fourth Shift在世界的管理软件销售排名不是很靠前，但在中国及其它亚太地区的市场表现不俗，这与Fourth Shift符合这些地区大部分企业的实际需求，以及Fourth Shift一直以来在产品和服务本地化方面所做的努力不无关系。
目前Fourth Shift的财务会计系统已经通过中国财政机构符合中国会计管理制度的评审。中小制造企业特别是离散型制造业在选择企业管理软件时，Fourth Shift可以作为首要考虑对象。

兼容并蓄的CA—MANMAN／X

简介：
CA（Computer Associates）公司是以开发大型机软件起家的软件产品公司。由美籍华人王嘉廉于1976年创立，总部设在美国纽约长岛。
CA的产品家族非常庞大，MANMAN／X是其提供的一个完整的制造业管理系统。该系统由制造、工程、财务、销售与售后服务、系统工具五大部分组成，其 中每一部分又由各功能模块构成，例如：制造部分中包含了基础资料、库存管理、计划（MPS，MRP，CRP）管理、采购管理、车间控制和成本会计部分。
MANMAN／X不受工作平台或操作系统环境的限制，适用于Oracle、INGRES等各种关系型数据库并附带专有数据库系统。

点评：
CA软件最大的特点在于兼容并蓄的通用性和开放性。由于开放、模块化结构，MANMAN／X完全独立于计算机软／硬件环境，允许选择能最好工作的平台， 适用的数据平台也非常广泛。同时系统能适应用户各种生产经营类型要求，包含了各种制造方法单独的或任何组合的应用，可以满足用户的许多特定需求。 MANMAN／X提供的修改菜单和屏幕，以及自动生成应用程序的客户化开发工具，使用户具备了对迅速变化的市场和管理需求作相应调整的能力。
与Oracle 一样，CA提供给企业的是一个全面而完整的管理解决方案，企业办公及经营管理所涉及的软件产品，几乎都能从CA的软件家族中找到。与Oracle不同的 是，CA具有软件产品领域的广泛性和软件本身的开放性。CA兼容并蓄的风格不仅体现在软件产品上，而且体现在企业经营上。
在中国，CA正在走 本地化的资本和文化融合之路，目前已经和包括联想、安易在内的许多计算机软硬件厂商合作，共同开拓本地市场。由于CA兼容并蓄的风格，使企业选择CA不仅 选择了一个开放的软件系统，而且选择了全方位的系统支持和持续发展的保障。有资料称CA是世界第二大独立软件供应商，但在企业管理软件领域，目前CA的表 现与SAP、Oracle等“大腕”级软件供应商相比还有差距。

原作者:崔启亮
 
外包是发包方和接包方互相信任、高度协作的共同行为。为了顺利实施外包，对于发包方，要求企业具有一定的技术水 平、项目管理水平、人力资源和沟通控制能力。对于接包方，要求企业具有一定的成本、质量控制能力，具有国际市场开拓能力（包括业务能力、交流能力、接包渠 道和商业信誉等）。为了是外包服务形成产业化，还要求形成良好的政策环境和市场环境等。

下面以软件项目外包为例，从发包方和接包方的角度，讨论实施外包的关键因素。

1、项目需求

项目需求是项目规划和正确实施的根本，在外包项目实施过程中，如果客户经常改变需求或提出新需求，常常使项目延期或超出预算，对于合作双方都会受到商誉和经济上的损失。

通常发包方根据外包的项目特点，进行项目外包分析，提出项目需求报告。接包方在实施项目之前应该深入了解和挖掘客户需求，对某些不明确的需求与发包方讨论，对于项目实施过程中的需求变更，规定处理办法，并达成一致，形成项目的最终需求。

在需求分析阶段，接包方首先对发包方的需求认真分析，然后通过业务建模、会谈、问卷、需求会议等方式收集客户完整需求，形成文档，然后经过客户讨论、客户审查、文档修订等多次反复的过程。

2、项目计划

在项目实施之前，通常发包方提出项目实施计划的草稿。项目计划的内容应该完整、可行，对于项目流程、工作量、资源配置和项目里程碑等需要双方接受达成一致。

接包方要及时全面分析计划的内容，要详细地跟本企业的计划进行比对和审核，从而了解外包商对整个项目的流程、内容、估计的工作量和资源的安排是否与项目本身的要求吻合。明显的差异都需要及时澄清并建立共识。

发包方根据接包方对项目计划草稿的建议认真分析和深入讨论，进行必要的修改和补充，形成双方都接受的最终项目实施计划。

3、质量控制

软件外包的质量指软件产品满足用户需求的程度，包括功能需求、性能需求、稳定性、安全性和技术先进性需求、支持和服务需求等。达到客户的质量要求是外包业务的基本要求。

以软件开发项目为例，接包方质量控制的常用方法如下：
通过多次反复、多方参与的评审控制需求和设计的质量。
在编码之前，制定代码规范，并强制执行，以便保证代码的规范性。
通过严格的、完整的测试流程保证编码质量。
需求分析、方案、系统设计、测试计划、实施计划等必须进行内部评审，通过内部评审后指定双方人员共同审查。
必须制定全面的测试计划和质量保证实施过程并通过审查。
系统交付使用前，要经历单元测试、集成测试、系统测试和用户测试、验收测试等质量检验过程。
制定实施和维护计划以及实施和维护操作规程，记录操作过程，及时请发包方确认。

4、进度控制

进度影响双方的成本，可能影响发包方的业务，进度还可能影响产品质量。
接包方应该按照项目计划的进度实施项目，及时定期汇报实际实施的进度。对项目实施过程中影响进度的因素综合分析，及时与发包方交流，提出解决办法。发包方要对接包方的进度进行监控。

软件外包项目实施进度控制的常用方法如下：
通过科学估算，考虑资源配置情况，共同制定合理的双方认可的进度计划。
细分任务，制定更加精细的里程碑，并按里程碑进行验收和考核。
建立常规的进度报告制度，以便及时掌握项目进度。
采用严格的流程来控制需求变更。
进度计划中，将一些比较大的工作拆细，以便设立更多的里程碑。

5、风险控制

风险管理（Risk Management）是指经济单位对可能遇到的风险进行预测、识别、评估、分析并在此基础上有效地处置风险，以最低成本实现最大安全保障的科学管理方法。
发包方要根据外包项目的特点和要求，制定切实可行的计划，选择合适的接包方，并且密切监控项目的实施过程。
接包方一定要对整个项目足够了解，其中包括项目需求、工作范围、实现方法和预期经济利益的来源。对于已经完成的部分，要有一套合理的评估方法。

发包方可以通过下列方式来控制风险：
通过考察企业实力、资格认证和服务经验严格选择接包方。
通过严密的法律条款、严格的合同审核来保障知识产权和商业机密。
通过严格的过程的过程控制来控制外包业务的质量和进度。

接包方可以通过下列方式来控制风险：
进行严格的需求管理和控制，充分挖掘客户需求。
严格规范合同起草、谈判、审查和签署，在合同条文中明确规定外包服务过程的责、权、利、知识产权和商业机密保护。

执行规范的项目管理和控制，严格控制质量和进度。
通过有效的人力资源管理来稳定队伍、建立后备队伍和提升团队的技术能力和综合素质。
建立和保持畅通的沟通渠道。

6、交流与沟通

实施外包项目是发包方和接包方互相配合、共同合作的过程。要保障外包业务的顺利进行，必须建立有效的沟通渠道。