内容


使用 XML

一种轻量级的 XML 客户机

利用 SOAP、XSLT 以及其他开放源代码工具箱

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 使用 XML

敬请期待该系列的后续内容。

此内容是该系列的一部分:使用 XML

敬请期待该系列的后续内容。

在过去的十年中,我在电子商务项目上花了相当多的精力。最开始是所谓的电子数据交换(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 事务受益的:

  • 电子化目录可以让顾客看到更加全面的产品,因此能够节约很多金钱。比如说,商家允许顾客购买比较便宜但是知名度较低的产品。那么前提条件就是供货商必须提供电子化的产品目录,并经常进行更新。
  • 零售商可以关闭大量仓库(这样能从库存和不动产两方面节约成本),让供货商直接把货送到最终用户手里。这种方式称为直接配送(direct shipping)。然而,这样做使得订单的数量急剧增加(因为不是发一张订单把100件货物运送到仓库里,而是有一百张订单,每张只定购一件货物,并且要发送到不同的地点),因此对这样的步骤进行自动化处理是非常有意义的。
  • 实时的送货信息可以赢得新的客户,因此是强大的竞争筹码。不过这样做可能要求从多个不同的系统获取信息,比如说公司自己的数据仓库和运输商的跟踪系统。这样的目标只有完全自动化之后才能实时完成。
  • 银行对于任何业务来说都是非常基本的组成部分,因此如果能将结算表直接下载到计费程序包中将会十分有意义。

两种选择

大多数 B2B 项目都是由大的公司发起的;大公司拥有最多的事务,因此也会为自动化付最多的钱。然而,因为大公司的业务伙伴多为小型或者中型的公司,因此必须找到与不同规模的伙伴建立接口的方法。

集成的解决方案大致分为两类:要么是提供某种数据输入系统(Web 站点,或专用的客户机),让合作伙伴键入所有的数据,要么提供一种简单的解决方案,使供应商与之集成。

第一种方法(即提供数据输入系统)是最流行的,原因是它构建于熟悉的技术之上。实际上,一个简单的 Web 站点就能达到目的了,您也可以使用构建在线商店的工具来构建它。这种方法造价低,易于快速部署。然而,至少由于下面三个原因,这种方法并不是理想的解决方案:

  1. 增加了合作伙伴的负担。大多数公司都有计费程序包(如 QuickBooks 或者 Peachtree),用于保存业务记录。让他们将相同的数据重新输入到另外一个系统中没有多大的意义。很少有人喜欢把一件事情做两遍,而且通常如果这样的话,价格也是要重新谈的。
  2. 速度慢。合作伙伴们会迅速更新他们自己的计费程序包,但是要等到当天或者一星期内稍微空闲时才会更新在线系统,这会使他们损失一些钱。
  3. 容易产生错误。录入过程中很容易出错,盲目地把数据从一个系统拷贝到另一个系统中就更容易出错。

简而言之,数据输入系统打消了 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,但是所有的系统都具有将数据导出到多种不同格式的功能。两种最流行的格式是用逗号分割的数据格式(comma separated values,CSV)以及定长字段格式(fixed-length fields)。如果软件包不明确地提供导出功能,那么可以考虑与 Microsoft Office 集成。在大多数情况下,都可以通过 CSV 文件实现导出。

为了将这些文件导出成 XML,您可以使用 XML Import(XI),这也是我前不久在这个专栏中开发的项目。您也许还记得,XI 用正则表达式对文本文档进行处理,并将其导入到 XML 中。

那么导出又怎么样? <xsl:output method="text"/> 对于实际应用来说太有限了。更好的解决方案是向 XI 中加入文本生成器。这个文本生成器用一种特殊的 XML 词汇表来描述文本文档。我这里只定义了三种标签:

  • flat:root 这是文本文档的根节点
  • flat:field 表示一个文本字段
  • flat:br 表示当前系统的行结束字符(在 UNIX 下是 \n ,Windows 下是 \n\r )

flat:field 允许有以下的属性:

  • width 表示字段的字符宽度;文本将会被截断或者填补,以适应这一宽度。
  • align 表示文本应该是左对齐还是右对齐。
  • padding 设置用于填补的字符。

您可以在 flat:root 元素上通过 default-widthdefault-aligndefault-padding 属性来设置上面这些属性的缺省值。

为了从 XI 中调用这个文本生成器,您需要将输出方法设置为 xi:flat ,比如 <xsl:output method="xi:flat"/> 。这个文本生成器(以及 使用它的XI 用户界面的更新包)是可以下载的。

在我做 XI 的时候,我将正则表达式处理器抽象了出来,这样它就不只局限于某个 JDK 了。这样做带来的一个小小的好处是,XI 现在可以运行在 JDK 1.3 上。

结束语

本文标志着“使用 XML”专栏中一个新项目的开始。其目的是在现有的 XI 引擎上编写 XML 客户机。请抽出您宝贵的时间,在 使用 XML 论坛上与大家分享一下对这个项目的看法(可以单击文章顶部或底部的 讨论来访问论坛)。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=XML
ArticleID=21928
ArticleTitle=使用 XML: 一种轻量级的 XML 客户机
publish-date=10012003