在过去的十年中，我在电子商务项目上花了相当多的精力。最开始是所谓的电子数据交换（Electronic Data Interchange，EDI）技术，然后是在线商店，现在我正在研究XML 和 Web 服务。我所见证到的最显著的变化，不是 技术，而是 人们的期望。
十年之前，一个电子商务项目就是一项重点任务。我指的是 Internet 广泛应用之前的情况，那时的项目使用的是所谓的 增值网络（比如X.25，或者 X.400）、特定的文件格式（比如 X12 和 UN/EDIFACT 之类的 EDI 格式），以及非常专用的软件。因为有如此之多的定制组件，毫无疑问，这样的项目一定是造价高昂，进度缓慢，并且实施困难。
现在，随着技术的不断成熟，人们的期望也逐渐发生了变化。几乎每一个人都可以访问廉价的网络（Internet），更少的文件格式（如 HTML和 XML）保证了世界范围内的兼容性，并且有充足的廉价软件，帮助你创建与部署 Web 应用程序。那么人们也会很自然地期望电子商务项目能变得轻松、快速和廉价。
对于在线商店而言，大体上是这种情况。夫妻店逐渐转移到了 Yahoo! Store 或者 eBay上，而稍大一些的业务则会购买成套解决方案，比如IBM WebSphere Commerce（参阅 ）。
只有在 B2B 领域，即在业务伙伴之间建立直接联系方面，人们的期望依然不能得到满足。这样的项目依旧相当昂贵，并且很难成功。在本次 使用 XML专栏的全新系列文章中，我打算介绍我近年来取得的一些经验，并着重提出一些有前景的解决方案。
背景知识典型的 B2B 项目与典型的在线商店项目之间最主要的区别在于，B2B 项目需要两端都进行集成。在线商店是一种交互式的软件，购买者只需要点击鼠标，就能够完成购买过程。在整个过程中，他必须通过填写表单，向商家提供很多信息，包括姓名、地址、送货要求等等。这种方式能够成功的原因就在于：一个商店往往有很多客户，而每一名客户通常不会经常来购物。
在大多数 B2B的环境中，事务的发生频率更高（通常某家公司在一天之内给供应商发送的订单有几打），因此您需要使事务尽可能的自动化。比如说，我们的软件不应该再让客户填写表单，或者是点击选项，而是要根据本地数据库自动做出决定。自动化可以使处理过程变成流水线，从而减少工作量（一名员工能做比以前更多的工作），并且降低出错的风险（录入错误是经常发生的）。我们面临的挑战就是，用低廉且有效的方式实现这样的自动化。
下面仅举出少量例子，用于说明业务是如何从电子化 B2B 事务受益的：
- 电子化目录可以让顾客看到更加全面的产品，因此能够节约很多金钱。比如说，商家允许顾客购买比较便宜但是知名度较低的产品。那么前提条件就是供货商必须提供电子化的产品目录，并经常进行更新。
- 零售商可以关闭大量仓库（这样能从库存和不动产两方面节约成本），让供货商直接把货送到最终用户手里。这种方式称为直接配送（directshipping）。然而，这样做使得订单的数量急剧增加（因为不是发一张订单把100件货物运送到仓库里，而是有一百张订单，每张只定购一件货物，并且要发送到不同的地点），因此对这样的步骤进行自动化处理是非常有意义的。
- 实时的送货信息可以赢得新的客户，因此是强大的竞争筹码。不过这样做可能要求从多个不同的系统获取信息，比如说公司自己的数据仓库和运输商的跟踪系统。这样的目标只有完全自动化之后才能实时完成。
- 银行对于任何业务来说都是非常基本的组成部分，因此如果能将结算表直接下载到计费程序包中将会十分有意义。
两种选择大多数 B2B项目都是由大的公司发起的；大公司拥有最多的事务，因此也会为自动化付最多的钱。然而，因为大公司的业务伙伴多为小型或者中型的公司，因此必须找到与不同规模的伙伴建立接口的方法。
集成的解决方案大致分为两类：要么是提供某种数据输入系统（Web 站点，或专用的客户机），让合作伙伴键入所有的数据，要么提供一种简单的解决方案，使供应商与之集成。
第一种方法（即提供数据输入系统）是最流行的，原因是它构建于熟悉的技术之上。实际上，一个简单的 Web 站点就能达到目的了，您也可以使用构建在线商店的工具来构建它。这种方法造价低，易于快速部署。然而，至少由于下面三个原因，这种方法并不是理想的解决方案：
- 增加了合作伙伴的负担。大多数公司都有计费程序包（如 QuickBooks 或者 Peachtree），用于保存业务记录。让他们将相同的数据重新输入到另外一个系统中没有多大的意义。很少有人喜欢把一件事情做两遍，而且通常如果这样的话，价格也是要重新谈的。
- 速度慢。合作伙伴们会迅速更新他们自己的计费程序包，但是要等到当天或者一星期内稍微空闲时才会更新在线系统，这会使他们损失一些钱。
- 容易产生错误。录入过程中很容易出错，盲目地把数据从一个系统拷贝到另一个系统中就更容易出错。
简而言之，数据输入系统打消了 B2B 电子化联系所带来的大多数好处：它影响了价格、降低了速度、还可能带来更多错误。
一种更值得推荐的解决方案是利用计费程序包的数据库，这个数据库中已经保存了事务的一个副本。通过与计费程序包集成，我们就可能获得相应的信息，使得很多业务变成自动化。然而，中小规模的公司几乎都没有能进行这种集成的专家，因此需要较大的合作伙伴为其提供帮助。
项目笔记与现实情况这样的项目中，最有意思的地方就是不同规模公司之间文化上的差异。这一点集中体现在他们使用的工具上。大公司有专门的 IT 职员，可以投资开发定制构建的软件。而小一点儿的公司大多购买现成的软件包，他们的IT 职员也只局限于网络管理员。大公司还倾向于遵守严格的过程，小公司则更加灵活，因此也喜欢选择不那么严格的软件包。
带着这些想法，我开始对XML 产生兴趣。1997年，XML/EDI Group 承诺开发新的方法，让 XML为中小型企业提供 B2B 解决方案。
我前面说过，现实情况是B2B项目在某种程度上依然是痛苦和昂贵的。与计费程序包接口也不是轻而易举的事情。不过有了开放源代码项目的帮助，您是可以成功的。根据最近这些年的经验，我撰写了这一系列的文章。
保持简单性尽管与计费程序包集成是最有吸引力的解决方案，但是这对于IT人员来说不是非常受欢迎的，大家都认为这种方法即困难又昂贵。人们知道这需要一台集成服务器，比如IBM 的 Branch Transformation Toolkit for WebSphere，还要需要相当多的顾问，才能让它运转起来。集成对于大公司来说是很好的方案，但是在稍小一些的合作伙伴那里几乎是不可行的。
规模较小的合作伙伴需要的是折衷的解决方案。它们需要比集成服务器简单，比数据输入系统费力少的工具。XML客户机就是这样的折衷方案。所谓 XML客户机是一种简单的工具，可以用 尽可能自动化的方式准备XML 消息。然后，您可以将这些消息转发给集成服务器。
与众不同的就是这六个字： 尽可能自动化（as automatically as possible）。服务器的设计是为了提供 24/7的可用性，可以在无人值守的情况下处理成千上万的事务。它提供的功能包括高级日志、用户与应用程序分区、（可能还有）群集。如果您每小时有几千个事务，选用服务器会很适合；否则就太过了。
根据我的经验，即便每天只有几百个事务，或者更少些（有时比这还 少得多），进行自动化处理也是值得的。但是您必须选择正确的工具。对于容量低的系统来说，如果能够降低费用，那么让用户启动并监视事务也是非常合理的要求。而且，XML客户机是尽可能自动化的，但是期望用户能提供足够完整的信息也是完全合理的。
这样的 XML 客户机与集成服务器处于完全不同的阵营。我的经验是，XML 客户机是对集成服务器的 补充，而不构成 竞争。
需求分析那么在什么地方可以找到这样的 XML 客户机呢？很不幸，据我所知，这方面还没有成套解决方案。倒是有几个很好的工具可以用，但是您既然已经要自己开发了，为什么不利用开放源代码的组件（比如XSL 处理器和 SOAP 库）来构建您自己的 XML 客户机呢？
XML 客户机的规范包括：
- 消息准备：根据标准计费程序包导出的数据准备XML 消息。反之亦然。这一部分是 XML 客户机的核心：XML可以从计费程序包导出的数据中生成 XML消息。反过来，它也可以将 XML 消息反馈给计费程序包。
- 服务器接口：通过标准的 XML 协议，如 SOAP，向（从）集成服务器发送（接收）消息。因此，XML 客户机是集成服务器的补偿。它设计用于那些不需要集成服务器的所有功能的合作伙伴。
- 易于使用：如果用户对非定制软件比较熟悉的话，就应该觉得 XML 客户机也很熟悉。XML 客户机的用户界面很像电子邮件客户端的界面。
- 可提供大量的用户信息：B2B 电子商务对大多数用户来说都是很新的东西，因此他们需要建立对这类系统的信任。根据我的经验，最好的办法就是给他们提供大量的信息。
- 好的日志系统：电子商务关系不受地理位置的限制，这一点几乎大家都认可。因此您需要好的日志系统，这样才能帮助远程的用户使用系统。
规范中有一条我故意没有说出来，即：在将消息发往服务器之前对其进行编辑的能力。之所以会产生这种需求，是因为大多数计费程序包在设计时都没有考虑到电子商务。它们可能并没有把需要的信息都存储起来，或者无法把所有需要的信息都导出来（根据我的经验，低价软件包比高端的开放性更差）。
如果数据缺失，那么什么方案都不顶用了。最现实的选择是从计费程序包中获取尽可能多的数据，并要求用户澄清这些数据。这对于高端的集成服务器来说几乎是不可接受的，但是对XML 客户机却很实用。
理想的 XML 客户机还应该包括 XML 编辑器，但是我不想在这个专栏中介绍了。我相信在不久的将来，我将会把开放源代码的 XForm 组件加入这个项目，但是在撰写本文的时候，唯一好用的编辑器依然是商用产品。由于我不想把这个专栏文章变成对某个特定产品的介绍，因此我打算把编辑器这部分当作练习留给读者。
对 XI 做一些改变您应该如何准备 XML 消息呢？并不是所有的计费程序包都能识别 XML，但是所有的系统都具有将数据导出到多种不同格式的功能。两种最流行的格式是用逗号分割的数据格式（commaseparated values，CSV）以及定长字段格式（fixed-length fields）。如果软件包不明确地提供导出功能，那么可以考虑与Microsoft Office 集成。在大多数情况下，都可以通过 CSV 文件实现导出。
为了将这些文件导出成 XML，您可以使用 XML Import（XI），这也是我前不久在这个专栏中开发的项目。您也许还记得，XI用正则表达式对文本文档进行处理，并将其导入到 XML 中。
那么导出又怎么样？ <xsl utput method="text"/> 对于实际应用来说太有限了。更好的解决方案是向XI 中加入文本生成器。这个文本生成器用一种特殊的 XML 词汇表来描述文本文档。我这里只定义了三种标签：
- flat:root 这是文本文档的根节点
- flat:field 表示一个文本字段
- flat:br 表示当前系统的行结束字符（在 UNIX 下是 \n ，Windows下是 \n\r )
flat:field 允许有以下的属性：
- width 表示字段的字符宽度；文本将会被截断或者填补，以适应这一宽度。
- align 表示文本应该是左对齐还是右对齐。
- padding 设置用于填补的字符。
您可以在 flat:root 元素上通过 default-width 、 default-align 和 default-padding 属性来设置上面这些属性的缺省值。
为了从 XI 中调用这个文本生成器，您需要将输出方法设置为 xi:flat ，比如 <xslutput method="xi:flat"/> 。这个文本生成器（以及 使用它的XI 用户界面的更新包）是可以下载的。
在我做 XI 的时候，我将正则表达式处理器抽象了出来，这样它就不只局限于某个 JDK 了。这样做带来的一个小小的好处是，XI 现在可以运行在JDK 1.3 上。
结束语本文标志着“使用 XML”专栏中一个新项目的开始。其目的是在现有的 XI 引擎上编写 XML 客户机。请抽出您宝贵的时间，在 使用 XML论坛上与大家分享一下对这个项目的看法（可以单击文章顶部或底部的 讨论来访问论坛）。 |
