电子商务集成模式

一、数据库复制（DatabaseReplication）

数 据库复制可能是目前最流行的企业应用集成模式。数据库复制包括对两个或两个以上数据库数据拷贝的管理，数据库复制经常会导致数据冗余。作为一个公司，采用 数据库复制的模式，是有很多理由的。许多公司对分布在几个不同物理区域的相同数据，执行操作、请求多拷贝等，呈现分布式。数据库复制也是一种进行数据恢复 的方法。在许多公司中，通常存在着第二个活跃的辅数据库用于数据恢复的目的。当主数据库受损，需要进行恢复时，通常就用到第二个辅数据库。这也同样适用于 “高可靠性”的系统。

数据库复制通常可被划分为两种类型：同步复制和异步复制。

同步复制（SynchronousReplication）

同步复制表示源数据库和目标数据库之间保持绝对的一致性的。它的主要目标是确保数据库间数据的实时一致性。在实际操作中，为了确保数据的绝对一致性，需要使用一些事务处理技术。图1描述了在数据库复制中事务处理监视器的使用。

图1：使用事务处理监视器进行同步复制

事务必须满足大家都所知的ACID属性，即原子性（Atomic），一致性（Consistent），隔离性（Isolated），和持久性（Durable）

• 原子性：一个事务要么被全部执行，要么完全不执行。当事务中断时，它执行的部分结果要被取消。
• 一致性：事务组件或对象被从一种有效的状态改变到另一种有效的状态。
• 隔离性：一个未完成的事务不能在其提交前把结果暴露给其它的事务。
• 持久性：一旦事务提交（完成）后，事务的操作结果永不丢失，且与后续的故障无关。

使 用事务协议表示跨数据库的数据代理操作必须是作为一个单一的工作单元被完成的。对数据库A离散数据 的更改，必须同时在数据库B上实现。如果对数据库A的数据更改操作是成功的，但对数据库B的数据操作是不成功的，那么，对数据库A的更改必须被“回滚”， 两个系统都恢复到前一个一致性状态。如前面所述，在两个系统中事务处理是通过事务处理监视器（transaction processing monitor (TPM) ）完成的。如，CICS (IBM)或Tuxedo (BEA)。

异步复制（Asynchronous Replication）

异 步复制，对执行时间的要求就相对要比较松一些。对所有系统的时间要求是“在同步中”，或者，一致性是一个可以观察的时间度量。这并不表示维持事务完整性的 要求降低了。它依然要求事务是最小的工作单元。异步消息队列产品，如MQ Series ，经常被用来维持事务语法作为复制处理中的一部分。它们通过事务队列的使用来完成复制。事务队列确保只有当源数据库把数据包插入队列，数据包离开队列提交 到目标数据源时，数据处理过程才算是被完成。

二、单步应用集成（Single-Step Application Integration，（SSAI））

单 步应用集成模式是对异步数据库复制模式的扩展。不是把注意力放在两个数据库的数据的一致性上，SSAI模式集成不同应用中的数据，从一个上下文移到另一个 上下文。通过把源消息的数据语法翻译，重新格式化数据元到新的目标消息中。所谓“单步”是因为它需要一个中介把源消息映射到目标消息中。典型地，它是异步 复制技术的一个扩展，它使用消息队列中间件，如MQ Series。它一般使用不太复杂的FTP，以批处理的方式实现。在这种模式中，它并非简单地为了数据的一致性，把数据从点A移到点B。源数据和目标数据 是相似的，如果并非总是一样，那也不是什么问题，因为SSAI模式的重点不在这里。它的重点不是数据的一致性，而是应用数据集成。图2描述了一个SSAI 模式的例子，消息A被直接地转换到消息B。

图2：单步应用集成

SSAI代理执行单步转换包括：翻译，重新格式化，智能地映射数据的规则的应用。不管怎样，整个“事务”从本质上看，还是“点——点”的。虽然企业多应用的集成可以被看作是一系列点到点的集成，但是，这是会有局限性的，需要更灵活和更复杂的模式。

三、多步应用集成（Multi-Step Application Integration，(MSAI)）

多 步应用集成(MSAI) 模式是对SSAI模式的扩展。MSAI可以完成“ n (源)——m (目标)”应用的集成。它是一种多对多的集成模式，提供一种SSAI不能做到的序列逻辑处理（sequential logical processing）。换一种方式讲，在此模式中，处理过程是依照次序的，所应用的规则则是布尔逻辑。如同单步模式，MSAI也需要一个代理进行不同应 用间的数据转换。它通常构建于一个基于异步事件的系统之上，典型地，通过消息队列中间件的使用来实现。基于异步事件的处理方法创建比较松散的联结。虽然每 个系统在物理上是独立的，逻辑上则存在依赖关系。换句话说，所谓的依赖存在于应用事件中，这些应用事件能够用转换和数据集成规则来表示。来自于一个应用中 的数据能够驱使另外一个应用中消息的恢复或处理。

图3描绘了一个最简单的多步集成例子，包含3个应用，来自应用A的消息和一个来自应用B的消息组合在一起，来自应用B的消息则为了目标应用C已被重新格式化。来自应用A的数据元是关键因素，它导致了对来自应用B 的消息的请求。

图3：多步应用集成

图3 中，account_id数据元，来自于Customer_Order消息，是一个关键数据元，它驱动了对一个Customer_Billing消息的请 求。来自两个消息中的数据元被组合，并根据相应的数据转换规则，被重新转换，并发送一个Shipping_Order消息给Shipping & Distribution System.。即使在这样一个例子中，你也能看出Customer_Billing消息是怎样对Customer_Order消息产生逻辑依赖性的。最 后的Shipping_Order消息同时依赖于Customer_Order和Customer_Billing消息数据元。

当然，你可以看到许多包含很多复杂变量的多步集成处理例子。MSAI模式是一种可扩展的，具有很大灵活性的模式，它支持复杂的应用集成。

四、代理应用（Brokering Application）

在 电子商务的集成过程中，通常不仅仅是对数据的集成，更多的，则是对商业逻辑的集成。代理应用模式，通过对中间应用逻辑的使用，把两个或两个以上的应用集成 在一起。它表示客户应用代码中包含了代理交互的逻辑。客户代理应用作为一种中介，处理来自于不同应用的请求。如图4所示。

图4：代理应用

这种处理模式特别适合于下面提到的几种情况。

需要复用逻辑的应用（Applications Need to Reuse Logic）

当 两个或更多的应用需要共享或重用公共的商业逻辑时，代理应用模式的使用就非常有效。例如，如果应用A包含了一个特定计算的商业逻辑，另外的应用能够使用这 样的计算逻辑，你就能书写一段中间客户代码来访问来自应用A的逻辑，这个中间代理应用就扮演了应用A 的一个代理服务器的角色。

被复杂逻辑相连的应用（Applications Linked by Complex Logic）

有 时候，即使使用前面所描述的多步应用集成模式，也不能描述出绑定多个应用的逻辑。例如，MSAI能够通过序列逻辑处理联结一些应用，但是它不能处理一些非 常复杂的逻辑，如，一个卡车公司的卡车调度算法。这就要求客户逻辑必须作为一种服务，其它的应用能参与或直接接受指挥。

通过用户界面而被集成统一的应用（Applications Unified Through User Interface）

虽然这里所说的都是针对服务器——服务器集成的中间件代码，但是我们也要知道，这并不仅仅局限于此。图5显示了两个或两个以上的应用怎样通过一个公共用户界面被集成在一起。这是一种重要的客户端代理应用的使用。用户界面并不是必须为一个图形用户界面，虽然通常是这样的。

图5：用户界面驱动的集成

这种模式通常被应用于两层客户/服务器实现的IT 结构中。在这种模式的实现中，相连的客户端应用是一个胖客户，用来访问多数据库或应用。

代理应用模式被广泛地应用，即使它要求书写一部分的客户逻辑，这是因为有许多问题只能通过这种模式被解决。这导致了对某些技术使用的必要性，如应用服务器等。

五、应用—应用B2B集成（Application-to-Application B2Bi）

应用—应用B2Bi,，它的集成范围超越了EAI，即超出公司的范围。下面我们将介绍四种B2B集成模式，当然它们不一定是占主导地位的模式。应用——应用模式是对EAI的逻辑扩展。

应用—应用B2Bi，通常包括企业实体直接把他们的应用联结到合作伙伴或客户的应用上。如图6所示。这种类型的集成，通常是作为针对客户的货物或服务的一个供应链的一部分而被实现的。

图6：应用——应用B2Bi

这张图并非表示每个应用都是完全公开的。仅仅应用数据的一个子集是对外的。对外的应用消息，作为供应链的一部分，与合作伙伴或客户相联。

那 么这种模式，和企业内部的应用集成有什么根本区别呢？在企业内部应用集成中，可以使用多步应用集成或代理应用模式。但是这种应用—应用模式，则包括了与外 部企业实体的集成，而不仅仅是应用的集成，这是与EAI集成的根本差异所在。这种模式中，应用程序是进入一个企业实体的直接入口点。该模式也要求使用一个 公共网络，如，因特网或一个第三方网络。这种对企业内部集成的扩展，意味着要重点解决一系列问题。

安全（Security）

由于外部网络的使用、外部实体的协作，需要加强安全管理。在合作伙伴之间必须建立信任层次，就是说，要实现一些安全措施，包括认证、鉴别、认可和数据加密传输等等。

联合控制（Federated Control）

联合控制表示每个伙伴实体能独立地在自己的集成环境中控制数据成分，同时又能有效地参与公共集成环境。

系统管理（Systems Management）

最后，需要很好地管理整个集成系统。为了长期的成功合作，在合作伙伴间签署服务协议是非常重要的。就是说每个参与者要确保应用系统的可靠性和可操作性。

六、 数据交换B2Bi（Data Exchange B2Bi）

应用—应用B2Bi模式的局限性在于实现起来比较复杂。它需要每一个参与者直接地处理各个应用的自然数据，这就使它的B2B交互模型的可扩展性比较差。因此，需要一种可扩展的B2Bi模型，使参与者能自由地交换数据，并且尽量不影响各自应用系统的基本结构。

数 据交换B2Bi模式能使B2B交换以一种公共的数据交换格式进行。这是目前B2B商务世界中被广泛使用的模式。数据交换B2Bi是非常有效的，因为它的概 念非常简单，并且已被应用了很长时间。产生于二十世纪六十年代的电子数据交换（Electronic Data Interchange (EDI)），就是最早的数据交换B2Bi模式，它是目前因特网上B2B的先驱。

基于XML的B2B将会逐渐兴起，也将会极大地促进基于因特网的B2B模式。如图7所示，基于XML的数据包，通过一个数据交换服务，在两个企业实体间被传输交换。

服务的主要职责是准备数据包，把数据包放在一个安全信封中。B2B服务支持安全标准，如MIME， X.509，和S/Key等。它也负责通过一个标准，对数据进行路由。大多数B2B服务提供许多传输选项，如，HTTPS，FTP，和TCP/IP Sockets等。不管怎样，如果检查一下，你会发现目前许多B2Bi交换依旧是通过一个HTTPS管道传输XML文档的。

图7：数据交换B2Bi.

这种集成模式，基本上依旧是点——点的。电子商务企业间的交互是静态的。有许多贸易标准正在出现，用于定义传输的文档内容，使之成为公共业务流程。

七、B2B流程集成（B2B Process Integration）

一个点——点数据交换模式，管理的是静态交互，这是它的局限性所在。

B2B 流程集成模式，则弥补了数据交换B2Bi模式的缺陷，它引入了企业流程集成服务（Business Process Integration (BPI) services）机制。如同数据交换B2Bi模式允许参与者动态地通过XML文档管理数据交换，B2B 流程集成模式也能这样工作。因此，能处理具有更多、更复杂关系的贸易伙伴间的流程集成。

B2B 流程集成模式的实现可以分为两类：封闭式流程B2Bi（Closed Process B2Bi）或开放式流程B2Bi （Open Process B2Bi）。由于它们都把注意点放在流程上，所以可把它们归为B2B流程集成模式。

封闭的流程B2Bi（Closed Process B2Bi）

封闭的流程B2Bi 可运用于一个管理着内部流程的组织，对外的关键流程仅仅通过数据交换实现。每个使用BPI 的组织，可以在企业内部监测企业流程活动的状态。相关的企业活动是通过数据交换来发布给合作伙伴的。

图8中，公司A 和公司 B都已在企业内部实现BPI，但都选择不直接把流程活动直接暴露给外面。因此，两个公司间的流程没有受到管理。两个公司内受到管理的一系列业务流程，通过一个已公布的业务事件的公共，而被连结在一起。

图8：封闭的流程B2Bi.

开放的处理B2Bi（Open Process B2Bi）

开 放的流程B2Bi为多B2B公司实体间共享流程创造了可能性。两个公司间的流程可以由两个公司同时管理。这就要求BPI产品由两个公司实体来实现。公司内 部的流程依旧可以作为公司的私有流程而被管理，并且限制它们只能在公司内部是可见的。由两个公司共享的外部B2B流程可以作为公共流程而被管理。产生的结 果可以用图9来表示。

图9：开放流程B2Bi

开放流程B2Bi 需要BPI解决方案能够细分公共流程和私有流程的管理。