![关闭 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
电子商务模式是一组已被证实的、可重用的资源，它有助于加速电子商务解决方案的开发过程。1999 年，IBM® 在网上公布了电子商务模式。从那时起，许多人就开始研究这些模式——最著名的是 Jonathan Adams et al。（详见 参考资料）。他给出了一个概念框架，业务分析家和系统架构师可以使用这个框架来确定适合他们需求的各种模式。本文中的方法使用了这个概念框架。
在本文中，我们使用了许多不同的模式，所有这些都可在 IBM Web 站点的 IBM 电子商务模式上找到。对于那些还没有出现在 Web 站点上的模式，我们提供了参考资料。在某些情况下，我们找不到合适的模式。对于这种情况，我们介绍将来可能成为模式的潜在的新类型的设计：
- 业务流程复合模式允许人工启动一个需要协作和监控的业务流程。
- 页面聚合应用程序和运行时模式是一个访问集成模式，这种模式提供了一种结构使得可以通过自定义的公共接口来访问多个 Web 应用程序。
- 被管理的协作运行时模式，允许用户通过一种预定义的方式来合作。
本文使用了在概述文章（详见按需业务流程的生命周期，第 1 部分）中描述的定制加工处理系统作为基础说明了在创建有效的体系结构过程中电子商务模式的使用方法。
该指南包括如下几步：
- 规划高级业务描述
- 设计解决方案概要图表
- 识别业务模式
- 识别集成模式
- 识别复合模式
- 识别应用程序模式
- 将程序包集成到解决方案
- 识别运行时模式
- 设计产品
OTMPS 允许用户初始化订单提交过程。用户能将有效的并且配置好的订单通过使用制造业的术语翻译成一个材料单（Bill of Materials，BOM），然后将它们提交到生产车间去实现。在正常的情况下，用户提交的定单需要经过多步来为其分组、确认和配置，以及作为 BOM 和其它的说明提交到生产过程中去。这个过程中也可能有例外情况出现，例如处理无效订单、解决系统异常，以及其它的问题。这需要人工解决，例如允许处理无效的订单，以及由系统管理员来解决工作流程中的系统异常问题。
在同 OTMPS 持有者协商的基础上，分析专家指出了 OTMPS 的高级需求，这已在概述文章（详见参考资料）中列出。我们将这些需求提炼如下：
- 当系统发现问题时，应当启动一个用于解决问题的新工作流程实例——管理对等协作的工作流程。
对于额外的细节和特定的用例，请参阅按需业务流程的生命周期，第 1 部分。
您可以通过将业务描述中的文本转化为图示的方法生成一个解决方案概要图表。我们在用例分析（详见参考资料）的过程中完成了这项工作。我们使用不同的用例来生成解决方案概要图表，如图 1 所示。
图 1. 应用于 OTMPS 的解决方案概要图表
Executive Dashboard 允许持有者通过查看来自于不同系统的聚合信息来监视业务运作。这就是信息聚合（Information Aggregation）模式。
操作员可以：
- 建立订单
- 查看订单状态
- 取消订单
- 更改交易规则
管理员可以：
- 启动定制的流程
- 停止定制的流程
- 将定制的流程挂起
- 中断后继续定制的流程
这些操作包括指导用户与后端系统（预定处理系统）进行交互，并指定一个自服务（Self-Service）的业务模式。OTMPS 分别通知操作者、管理员、用户任何在操作上的、系统中的，以及交易过程中出现的问题，然后管理相应问题的解决方案工作流程，其中包括对等协作。这些交互说明了协作业务模式。
OTMPS 需要一个供给链来向供应商发送购买订单来对订单及其实现进行进一步的处理。这种交互在企业之间进行，并说明了扩展的企业业务模式。
使用单一的签名来访问不同的应用程序这种功能的实现需要得到所有用户的共识。为了实现这种功能，您需要访问集成模式（这是可选的）。
从图 1的解决方案概要图表中可以明显地看出，流程集成模式（应用程序集成模式的子集）可以使得 OTMPS 链接到：
- 业务度量应用程序
- 通知处理器
- 规则管理应用程序
- 供应商的系统
- 用于生产的应用程序
- 通过业务度量应用程序链接到其它系统
业务度量应用程序集合了从 OTMPS 及其它的系统发出的处理信息。也就是说，您需要数据集成模式（另一个应用程序集成模式的子集）。
注意：通常，数据集成模式被认为是一种受限制的模式，也就是说，仅仅当应用程序通过读取其它应用程序的数据源来组合数据的时候，数据集成模式才可用。但是，消息队列或一系列输入参数也可以作为数据源。因此，当其它的应用程序通过使用过程集成模式将数据装入目标应用程序时，数据集成模式也是可用的。
至此为止识别过的模式，在图 2中予以总结。我们还没有找到适应于 OTMPS 需要的复合模式。最初，似乎我们可以使用 Portal 复合模式（详见 参考材料）。然而，经过对相应的应用程序模式的进一步研究，我们发现它并没有满足需要。例如，OTMPS 需要有能被管理的对等协作，这是 Portal 复合模式所不支持的。同样，个人交付和通用应用程序模式也都是强制性的，但我们并不需要。
图 2. 不存在适合于 OTMPS 的复合模式
由于您只关注包含后端集成的 Web 通道，所以直接集成的单通道是 Order Entry、Rules Management，以及 Administration Console/Monitor 应用程序宜采用的模式。
一旦收到通知，您就应当密切关注职员、管理员或持有者的行为，并允许他们调换工作。换句话说，您需要通知处理器的支持，它不仅用来向用户通报，而且也管理相应的对等工作流程。因此，宜采用受管理的协作模式。
只要您对聚集的业务过程的读取访问感兴趣，就需要用户信息访问应用程序模式（详见 参考资料）。到目前为止，还不需要用户存储结果的本机副本或者执行对源程序的修改（例如，OTMPS）。因此，用稳定的基本 类型就可以了。
您需要集成不同的供应者以及替换供应者，只要他们的信息格式兼容就无需更改 OTMPS。换句话说，您需要按照 1：N 的比例来设计提交给大多数设备的请求。Exposed Broker 模式（详见参考资料）的路由器变量是最能符合这些需求的。
您需要一种共识使得不同类的人能够使用单点登录对不同的应用程序进行访问。换句话说，您需要表示性的安全服务。单点登录应用程序模式已经提供了这种安全服务。您可以通过使用直接集成单通道（Directly Integrated Single Channel，DISC）应用程序模式（一种自服务的应用程序模式）中的变量来实现表示性的服务。应用这种模式的主要驱动程序提供了对后端应用程序以及 Web 应用程序中的数据进行实时访问的功能，它以“后端应用程序和数据”作为主键。但是您可以使用它通过单一的 Web 应用程序来访问多个 Web 应用程序，这样就提供了一个公共的表示层。下面是关于 IBM Redbook 的图 4-8 中所涉及到的变量的参考资料 使用 IBM WebSphere®Portal V5 的 Portal 复合模式。不幸的是，把变量并入最初的 DISC 应用程序模式中是暂时的，并且它仍旧作为直接集成单通道应用程序模式。在本文中，我们把这个变量看作页面聚合应用程序模式（如图 3 所示），它仅代表 Web 应用程序的集合，也就是不包括自服务模式。
图 3. 页面聚合应用程序模式
直接联结的应用程序模式可以用来记录 OTMPS 和 Business Metric 应用程序之间，OTMPS 同供应商的 OTMPS 和 Rules Management 应用程序之间，以及 Business Metric 应用程序同其它系统之间的交互过程。
OTMPS 本质上是一个工作流程应用程序，它按顺序经过不同的检查点，同生产应用程序进行交互，并最终向生产车间发送 BOM。您也希望 OTMPS 能够适应业务策略和流程中的变化。换句话说，您对工作流程的性能，以及 Broker 或 Router 模式的灵活性提出要求。因此，应用管理流程应用程序模式是非常理想的。由于定制过程在本质上是串行的，所以您应当使用串行处理模式而不是并行处理模式（详见参考资料）来将 OTMPS 集成到生产应用程序中去。
直接联结的应用程序模式可以用来将通知处理器与 OTMPS 集成起来。
由于 Business Metric 应用程序只是聚集了那些来自于不同数据源的数据，所以用 Population 应用程序模式（详见参考资料）就可以实现了。
图 4总结所有 OTMPS 所需的应用程序模式。
图 4. 电子商务模式设计的解决方案
您可以使用公共事件体系结构（Common Event Infrastructure，CEI）（详见参考资料）来聚集 OTMPS 及其它的系统发出的流程事件。CEI 提供了数据集成：Population 应用程序模式，并且通过使用流程集成：直接联结的应用程序模式来支持集成。CEI 没有提供直接访问数据库的事件，但它提供了 API 用来查询数据库。换句话说，它可以被视为一种数据服务。因此，图 4 中展示的模式设计依然有效。
无需使用不同种类的应用程序服务器，也就是说，您的应用程序将运行在同类的应用程序服务器上。这样，对于 SSO，您可以使用同类应用程序服务器运行时模式，如图 5 所示。
图 5. 访问集成::单点登录::同类应用程序服务器
对于页面聚合模式而言，您可以使用直接集成单通道中的运行变量 1 来实现，如图 6 所示，在 Application Server 节点被 Portal Server 节点替换的地方。
图 6. 访问集成::页面聚合::页面聚合运行时模式
在这种情况下，您不能直接访问数据源，但是用户信息访问运行时模式（详见参考资料），如图 7 所示，仍旧是适用的，因为您可以把 CEI 看作数据源。
图 7. 只读的信息访问::在内部网络中的 BI 应用程序
鉴于电脑黑客的攻击能力不断加强，如图 8 所示的运行时变种 1 是适合于直接集成单通道应用程序模式的一种值得推荐的模式。
图 8. 自服务::直接集成单通道::运行时变种 1
在管理协作模式方面唯一一种类型是电子商务模式一书（详见参考资料）中介绍的应用程序模式。因此，我们引入并使用了一个潜在的新模式——管理协作运行时模式。
管理协作运行时模式，如图 9 所示，允许 Web 客户端之间可以进行同步或异步的合作，也就是说，接收端不必通过预定义的方式连到协作服务器上。它通过处理从预定义的工作流程中得到的请求并由接收端存储随后的修复响应来实现了这个功能。
图 9. 管理协作运行时模式
协作服务器在处理工作流程同客户端的交互过程中起了重要的作用。它为使用流程数据信息的实际用户设计了工作流程信息接收器（例如，用户、管理员、组织、任务等等）。它也将负责存储客户端的工作流程信息并允许他们查看并回复那些信息。一旦收到回复，服务器就会将它传递到工作流程中并删除原始的信息。
工作流管理负责管理已安排好的工作流程的执行过程。它将维护工作流程的状态直到执行完毕，也负责将接收到的信息映射到工作流程的实例中去。
如果您想将不同的组件用于服务，那么 Simple Service Bus 模式（详见参考资料）是最适合的，如图 10 所示。
图 10. 直接联结::Simple Service Bus 模式
串行流程运行时模式（详见参考资料），如图 11 所示，允许 OTMPS 以串行的方式与不同的应用程序交互。这个交互由流程管理员管理。
图 11. 串行流程运行时模式
您需要一个与用来集成不同供应者的公开路由器应用程序模式进行通信的运行时模式。它应当支持 1：N 的设计规划，并支持转换成用于访问现有系统的协议。公开路由器运行时模式（图 12）或公开企业服务总线（ESB）模式（图 13）能够满足那种需求（详见参考资料）。如果您想建立一个 SOA 解决方案，那么公开的 ESB 模式对于您来说是个较好的选择，它提供了一套底层功能使得能够成功集成 SOA（详见参考资料）中的服务。
图 12. Exposed Broker:: Router 模式
图 13. Exposed ESB 网关复合模式
您应当巩固各种运行时模式。混合运行时模式，如图 14 所示，给出了完整合理的运行结构的描述。注意 Simple Service Bus 和 CEI 模式均是 ESB 模式的一部分。同样地，流程管理器和工作流管理器已经并入了单独的流程管理节点，因为流程管理也有管理工作流的能力。
图 14. 混合运行时模式
您可以为不同的产品配置设计运行时模式。例如，您可以为 WebSphere Business Integration Server Foundation 或 WebSphere MQ Workflow（详见参考资料）设计流程管理。您也可以有选择的为 WebSphere Business Integration Message Broker 或 WebSphere Business Integration Server Foundation 等等（详见参考资料）设计 ESB。这个选择取决于很多因素，例如：
- 产品性能
- 价格
- 现有技术
- 发展前景
- 产业指导
对于流程管理，您可以使用 WebSphere Business Integration Server Foundation（详见图 15）中的流程控制，因为它是基于开放式标准的 J2EE 及 Web 服务业务流程执行语言（Business Process Execution Language for Web Services，BPEL4WS）。同样地，对于 Portal Server，您可以使用 WebSphere Portal Express，因为它具有所有必要的特点。有时，现有的产品不能满足需求，所以只好决定是仅实现需求中的部分内容，还是设计一个精简的解决方案。考虑到产品的灵活性，您也许希望协作服务器同流程管理之间实现松耦合，但是在 WebSphere Business Integration Server Foundation 产品中它们是紧耦合的。而且，WebSphere Business Integration Server Foundation 中缺省的协作应用程序 Business Portal 内部嵌有协作流程。所以我们决定采用它，因为它的局限性很小，而且有很大的潜在选择余地，也就是说，试着使协作服务器及相应的工作流程更加具体化。
图 15. 适合 OTMPS 的产品设计
基于对 OTMPS 的研究，我们发现了一种新的设计模式——业务流程模式，经过进一步的确认后它可能成为一种复合模式。图 16 展示了用业务流程模式以及电子商务模式实现的用例。
图 16. 业务流程复合模式
（潜在的）业务流程复合模式
这种模式允许人工初始化业务流程，它集成了不同的应用程序和服务器，并且能够与人进行交互完成他的请求。同时，也可以监控业务和流程的整个过程。
业务流程复合模式包括：
- 自服务交易模式使得客户可以更便利地同业务流程进行交互。一些操作诸如预定的提交、需求的提交或新建帐户都可以通过使用这种模式完成。此外，它也可以帮助系统管理员管理业务流程。
- 协作交易模式有助于实现下列交互：
- 客户同操作员
- 操作员之间
- 客户或操作员同业务流程之间
- 信息聚合业务模式提供了对业务流程中的数据进行只读的访问。您可以随时使用它将流程数据转换成业务的标准。
- 应用程序集成模式集成了自服务、协作、扩展的企业、以及信息聚合业务模式。您也可以使用它们来集成附带有应用程序或系统支持的业务流程。例如，将 OTMPS 与生产系统集成起来。
业务流程复合模式可选择地包括：
- 扩展的企业交易模式：这种模式同业务伙伴的应用程序进行交互（例如，在 OTMPS 与供应商的预定提交的应用程序之间提供交互能力）。
- 访问集成模式：这种模式提供了接口、SOS 功能，以及使客户可以进行个性化设计的功能。
电子商务模式对于建立符合业务需求的有效体系结构是非常有帮助的。但是从模式的种类以及可能的产品设计方面考虑，使用这些模式都是有益的。本文中我们已经给出了如何选择并应用不同的模式和产品来建立适合于 OTMPS 的系统体系结构的方法。您也可以将这种体系结构应用于包含类似的业务及 IT 需求的系统中。
对 Jonathan Adams 和 Dr. George Galambos 对本文提出的批评和建议表示感谢。
-
第 1 部分：为您的按需业务流程构建基础
-
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
- 阅读这个系列中的概述文章按需业务流程的生命周期，第 1 部分：为您的按需业务流程构建基础"（developerWorks，2004 年 10 月）。
- IBM 电子商务模式提供了一些有价值的信息关于各种可重用的电子商务模式，它有助于加快 Web 应用程序的开发速度。
- 可以在 Jonathan Adams、Srinivas Koushik、Guru Vasudeva 和 George Galambos 编写的 电子商务模式：重用策略 一书中找到更多的有关 电子商务模式的内容（IBM 发布，2001，ISBN 1-931182-02-7）。
- 阅读下面的 Redbook 来获取更多的关于 SOA、Web 服务及其需求的信息：
- 模式：过程设计及工作流程中的串行和并行处理， IBM Redbook SG24-6306-00
- 模式：企业之间及企业内部的高层交涉，IBM Redbook SG24-6075-00
- 模式：通过企业服务总线实现 SOA，IBM Redbook SG24-6346-00
- 模式：自定义设计 Domino 和 WebSphere 的集成过程，IBM Redbook SG24-6903-00
- 模式：SOA 和 Web 服务，IBM Redbook SG24-6303-00
- 通过使用 IBM WebSphere Portal Server 来实现访问集成模式，IBM Redbook SG24-6267-00
- 通过使用 WebSphere Portal V5 来实现 Portal 复合模式，IBM Redbook SG24-6087-00
- 模式：用 DB2 信息集成器实现信息聚合以及数据集成, IBM Redbook SG24-7101-00
- 了解更多的关于公共事件体系结构的内容，IBM 的统一、兼容的格式化工具，应用于业务、系统以及网络中基于 Common Base Event（CBE）模式的事件。
- 想获取更多信息吗？developerWorks Web 服务和 SOA 专区有大量内容丰富的文章，以及关于如何开发 Web 服务应用程序的入门级、中级、高级教程。
- 访问 Developer Bookstore 来获得技术书籍的详细列表，包括大量的有关 Web 服务的主题。
Naveen Sachdeva 是 WebSphere 技术中心 IBM Application Integration Middleware 组的一名咨询软件工程师。他在大规模系统集成及分布式计算系统的设计与开发方面有10年以上的经验。 目前，他帮助 IBM 业务伙伴使用 IBM 产品进行技术功能实现和概念验证。他现在主要从事 SOA 工具技术以及 Model Driven Development 模型驱动开发。
German Goldszmidt 博士是 IBM Software Group 中的高级技术人员，主要研究按需求解决方案传输、定制和部署的集成平台的体系结构。他以前是 IBM T.J. Watson Research Center 的研究员，带领设计和实施了几项技术，包括 Oceano，这是最初的电子计算功能和 WebSphere 的负载平衡组件 Network Dispatcher 的原型。您可以通过 gsg@us.ibm.com 来联系他。
标签
使用 滑动条 调节标签的数量。
热门标签 显示了特定专区最受欢迎的标签（例如 Java technology，Linux，WebSphere）。
我的标签 显示了特定专区您标记的标签（例如 Java technology，Linux，WebSphere）。