Web服务设计师，第2部分：动态电子商务模式

申请免费试用、咨询电话：400-8352-114

Web服务设计师，第2部分：动态电子商务模式

Dan Gisolfi (gisolfi@us.ibm.com)

解决方案设计师，IBM jStart Emerging Technologies

2001 年 4 月

每一种新兴的技术必须要穿越创新和接受之间的鸿沟。Web 服务的技术采用生命周期也是如此。然而，这项技术却很适合决策者的不同对象。他们是谁？什么会激发他们？基于动态电子商务这种现象，这篇文章探讨了 Web 服务就市场的各个部分给商业实体提供的一种价值取向。

技术上任何合理的投资都需要有商业理由。无论这个理由表现为一种新的收入渠道，还是有效地改进了日常商业的运作，最终决定是否采用这项技术的人，一定要确定的就是这项投资绝对符合价值取向。

不同于近年来的其它新生技术（Java、XML、普及计算），Web 服务的发展并不只取决于 IT 决策者。这项技术的采用高度依赖于商业实体在其所在行业中的角色及其收入模式。由于这个原因，line-of-business (LOB) 的执行者就会在很大程度上影响采用新技术的速度和方式。

为实现 Web 服务，软件设计师不得不向他们的上级证实 Web 服务模式商业原理。因而，我从两个方面开始这篇文章，试着解释为什么商业需要 Web 服务以及它是如何影响商业目标的。

可能的商业角色

在 Web 服务的面向服务体系 (SOA) 中，有三个截然不同的角色：提供者、请求者和中介者。如果您是一个软件工程师，应该很清楚这个问题，任何给定的子系统或进程，都可被设计用来作为请求者或提供者或兼任两者。然而，从一个商业执行者的高度来看这些可能的参与节点，去了解与每一个节点相关的潜在商业模式是非常必要的。

我们再来从一般的 IT 角度去看，任何 Web 服务 -- 可通过 Web 获得的软件资源组件 -- 可以是其它分布式软件组件服务的请求者，可能是本地的，也可能是远程的。在这种情况下，软件设计师可以决定把 Web 服务和这个角色联系起来，这样可以减少操作和维护应用程序的开支，或者提高选择给定的商业进程的可用实现的灵活性。即使所有这些可实现，还是存在问题：商业何时决定认同请求者、提供者或中介者角色？此外，可能认同多个这样的角色吗？

虽然存在三个 SOA 参与节点，但事实上，一个公司有五个可能的商业节点以供选择。让我们单独看看每一个：

服务请求者：对于认同这个 SOA 角色的商业，必须找出他们的商业行为和请求者行为之间的共性。有两个明显的商业行为，它们允许商业从实现服务请求者的角色中获利：

内容集合是一种行为，商业实体能够在其中与各种内容提供者相互影响，处理或再生（用顾客期望的表现形式）这种内容。这种商业实体的示例可能是任何因特网入口或者信息服务提供者。

服务集合是一种行为，商业实体能够在其中与各种服务提供者相互影响，重新树立品牌、充当东道主，或者为顾客提供复合型服务。这种商业实体的示例就像 OnStar (www.onstar.com) 一样的机动入口。

服务提供者：对于认同这个 SOA 角色的商业，必须把自己视为正在执行某种程度的电子服务。无论服务被定义为处理数据，还是实现特殊任务的行为，商业实体必须相信，它是作为一种职业或者商业为其它的商业实体提供服务。由于几乎任何东西都可以是服务，所以很难完整地列出应用商业的清单。然而，我们可以提供一些简单的示例：

独立软件提供者是潜在服务提供者的最好示例。他们普遍拥有并维护软件资产，这些软件资产能够执行一个或多个任务。这些软件资产可以作为服务集合使用，或者分解成明显独立的软件服务资源。

经过验证和大众化，能够适应一整套不同应用方案的商业程序很可能成为一个好的服务提供者。例如，如果一个银行认为它的贷款处理业务是足够强大的资产，可以公开向社会提供，而且它也愿意将其作为一种商业服务，那么，这个银行就可以把自己视为贷款处理服务提供者。

注册处：如果一个商业实体的业务是收集和整理其它商业的数据，然后将这些数据卖给某些商业，那就可以恰当地称其为注册处，也是某种形式的 SOA 中介者。通常情况下，一个注册处会收集像商业名称、描述和联系信息的数据。在 UDDI 术语中，这个 SOA 角色经常被称为白页。

中介者：建立在注册处概念的基础之上，商业实体也能够认同中介者的意见，在 UDDI 术语中通常被称为黄页。中介者经常通过提供智能搜索能力和商业分级或分类数据来扩展注册处的价值取向。

集合者／门户：就是那些提供中介者功能并具有描述实际策略、进行商业处理和绑定描述能力的商业实体，能够把自己标识为绿页。

采用理由

这些商业角色在决定与给定的角色进行联合并采用技术之前，必须还要为商业提供一些附加值。为了达到这一点，有两类因素能够证明采用 Web 服务技术是正确的。第一类因素不总是和最终金钱价值有关，第二类因素则取决于收入。

非收入理由

非收入理由说明了一些采用动机，这些动机对于商业的成长和生存很重要，但不会轻易地或不必要地使用特定的金钱价值做信用。例如：

上市所需的时间。

通过通信提高运作效率，并降低运作成本。

向关系密切的商业伙伴显露内在过程，压缩供应链。

通过第一个上市或者成为实际标准充分利用网络影响。

提高创新速度。

更大胆地向新领域渗透。

收入理由

收入理由允许商业接触新客户，扩展现有的伙伴关系或者建立新的伙伴关系，并且为新的交货渠道提供现有的供应方式。这类采用动机可使潜在的服务提供者尝到甜头。虽然下面的可能是不尽完整的列表，但是我所在的组一直在努力地补充新增加的内容。当然，我欢迎来自读者的任何意见。

对于服务提供者，这里有五个收入模式：事务处理、成员资格／签署、租借／许可、商业伙伴关系和 注册。

事务处理模式指的是点击付款或者使用付费模式。它是所有模式中最基本的。一旦两个贸易伙伴（一个服务请求者和一个服务提供者）之间存在了商业关系，那么提供者需要确定如何获得使用服务的同意条款。一个可行的方法是 pay-as-you-go 方法。这里，每笔交易的收费通过使用类似信用卡之类的付费工具来实现。现在对于 Web 服务提供者，可以通过他们提供的服务界面来使用这种收入方法，但是这一点必须在设计时就被考虑进去。建立使用条款的另一个可能方法是 out-of-band 关系。简言之，就是商业关系条款要在使用服务之前达成一致。既然电子合同的技术尚未成熟，那么必须依赖使用服务之前建立的商业关系。使用这种方法，服务提供者只需要审查服务的使用并定期付款。无论哪一种方法，这两个贸易伙伴必须建立一个双边服务付费协议。

成员资格或者签署模式指的是一种收入模式，这种模式适用于带有特殊使用条款的已建立的用户帐户。使用者可以定期进行使用注册（不限量）或者按量注册。服务提供者可以创建成员资格级别，这样可以满足特殊级别用户的特定要求。类似于事务处理模式，服务提供者必须决定服务界面是否处理管理收入模式方面的问题，或者是否能够通过 out-of-band 关系来管理收入。

租借或者许可模式指的是一种收入模式，这种模式在大的商业伙伴中比较普遍，他们需要大量地使用服务并期望更加合体的协议。这里，服务提供者可能根据交易量收费，或可能根据服务请求者内部的请求“组件”（席位）数量收费。在本例中，out-of-band 关系就是一个给定的假设。

商业伙伴模式是一个新概念。虽然在 2000 年 .com 为之所做的宣传提供了足够的证明说明这个模式是必需的，我们仍必须为这个模式提供一个示例。本质上，这个模式指的是在服务交换、等同体或甚至请求者总收入的一部分的基础上，通过 out-of-band 或者基于提前使用的系统，来建立相关条款。

注册模式指的是一种收入模式，这种模式可以更容易地应用于 UDDI 门户或者绿页商业。这里，基于 pay-to-be-seen 概念的收集收入概念是可行的。前提是服务提供者希望被发布，他们愿意支付注册费用。

显然，只要服务提供者提供一个合理的商业概念，收入和非收入这两类都可为构建一个采用 Web 服务技术的商业案例提供充分的理由。

假设采用

这里所说的收入模式和采用理由的种类都比较普遍，对于任何市场部分都是适用的。在尝试提供一个示例时，我要求读者考虑图像转换的范围，以及 Sharpe Images (SI) 的假设商业实体和它的图像转换产品 -- Convert-It。SI 最近失去了对一家大保险公司的投标，那家公司正在寻找把它需要的全部图片和文档转化为电子资料。SI 的产品定位很好，而且在所有的竞争产品中最具灵活性。然而，Convert-It 是一个可安装的产品，不作为软件服务提供。SI 具有长远目光的商业主管意识到如果他们想要赢得商机，就需要满足资源电子化需求。他们决定做自己产品的主人，为顾客提供基于工程规模的租借业务。这个建议不仅让 SI 赢得了这个项目，而且它也给用户提供了基于 pay-as-you-go 的一个新的交货渠道。

总结

由于商业寻求与动态电子商务技术的结合，那么他们必须能够把商业与特定的 SOA 角色关联起来。在大多数示例中，他们还需要从商业的角度，为采用这种技术提供充分的理由。在本文中，我们声明了商业的五个不同的 SOA 角色，并提供了两类采用这种技术的商业原因。在下一期文章中，我将会讨论动态电子商务的本质。

参考资料

通过点击文章顶部或者底部的讨论，加入这篇文章的论坛。

阅读我这个系列的第一个专栏Web 服务设计师，第 1 部分：动态电子商务介绍。

请阅读Web 服务体系概览。

请查看动态电子商务的 real world adoption scenarios。

请回顾扩展标记语言。

请了解简单对象访问协议。

请阅读 Web 服务描述语言。

请访问它的主页，了解关于通用描述、发现和集成的更多信息。

请看一下 XML 协议工作组的成员。

请从 alphWorks 下载 IBM 的 WSDL 工具包。

请从 alphWorks 下载 IBM 的 Web 服务工具包。

关于作者

浏览： Web服务设计师，第1部分

Web服务设计师，第3部分

Web服务设计师，第4部分

Web服务设计师，第5部分

Web服务设计师，第6部分