在当今使用XML解决真正的商业问题

原著：Roger Oney
翻译、制作：iven　OICQ：1917460　
电子信箱：ivice@china.com
日期： 2000/11/6

我们听过太多天花乱坠的关于XML的事，但是许多的开发人员还不知道使用XML该从何处入手开始使用的也未完全探索过它的能力，更没有查找存在的标准提供给他们的所用的解决方案。这篇文章将通过讨论一个假想的案例来举例说明上述问题。

商业问题

　　XML的力量存在于它的“eXtensibility 可扩展性(译注：XML的全称是eXtensible Markup Language）”...但是这也能证明这是很多组织所难于克服的障碍。

　　在这个案例中，我们的电子商务网站是在两个不同的伙伴之间外包某种类型订单的履行业务。一个通常的情况是，这两者都想要订单是同一种XML格式，但两种格式就是有着非常大的不同。此外，伙伴B需要我们将XML订单文件放在FTP目录中的同时，伙伴A要求将XML直接发送到他们的服务器上。从那里，他们能获得数据。

所以就有如下三个挑战：

• 一、我们不得不自动发送订单数据到外部的服务器
• 二、我们不得不为每个伙伴准备不同的数据格式
• 三、并且，我们将使用不同的方法传送数据

这真的不好

　　不久就会有各种各样的系统被放置于这个任务中。解决方案 ，诸如BizTalk 、SOAP和SQL 2000会加进许多。BizTalk还不可用。SOAP也不会有什么帮助，而且，使用SOAP需要双方签订协议统一使用它。再有，SQL 2000会使我们很容易生成从订单数据库中生成XML.说这些系统会工作在一起只是对将来的承诺，而作为一个开发者，我们今天需要理解一些技巧。

　　尽管，我们并未准备好使用任何这些解决方案。在以某种方式设计我们的应用时，对我们感觉有能力地方的着手一试，还是值得的。

解决方案

　　这篇文章将讨论使用VB、SQL Server 7.0、XML和XSL（译注：XSL是可扩展样式表语言，全称是 eXtensible Stylesheet Language）建立一个健壮的和灵活的伙伴间订单处理系统以适应当前的需求，并且自身是可扩展的。

　　此处理过程包括以下三个独立的步骤。（为了演示的方便，所有步骤都包括在一个可执行文件中）

• 步骤一：建立内部的XML订单文档　在第一步中，系统从 SQL 服务器的数据中建立XML文档。内部XML文档位于内部发信信箱中。
• 步骤二：建立待发送的订单XML文档　对每一个在第一步中建立的内部的XML订单文档，将其与合作伙伴指定XSL表合并来建立待外送的订单文档。这个文档包括两个主要的部分，标题和数据包。标题包含发送数据包的所有信息。数据包则是跟据合作伙伴指定的规范格式化的XML数据。当第二步完成时，所有的待发送订单文档被储存在合作者输出目录。
• 步骤三：分发数据包　对每一个在合作者输出目录中的订单文件，系统读取标签中的发送方法和其对应的参数。它将数据包发给知道如何使用指定的方法分发XML文档的运行进程。当第三步完成，外送的文档被储存在合作者档案目录中。

　　这个系统的特性之一是往后加入一个新的合作伙伴到系统中只需做少量的工作。甚至，一个未来的伙伴需要我们发送一个CSV文件到其指定的电子邮件地址时，我们只要写一个XSL文件就可以解决大多数问题。同样容易的是，我们能够分发一个HTML报表，一个Excel电子表格或是一个纯文本的Email消息。

开始工作

　　这个处理程序是一个VB可执行文件，叫做PartnerOrderProcess.exe。在每一步，程序使用Filesystem 对象读取并移动XML文件。因此为了给应用程序足够的信息还需要完成这些任务，一个XML文件AppInit.xml 与exe文件在同一个目录中 ，文件中包括所有的不同种类文件的系统位置。这个例子应用程序中的设置如下：

（说明：虽然在本文包括的例子中这些目录位置是在AppInit.xml文件中直接给出的，但是还有其它几种方法。例如，你可以写一个简单的VB程序为你生成AppInit.xml文件。另一种增强的AppInit.xml还可包括无DSN的连接字符串。）

　　这个简单的应用程序覆盖两个例子。为了使之更吸引人和演示一些有趣的例子，第一个案例要求我们的处理程序发送订单文件到合作者指定的URL地址。但是我们打算从表单中以字符串变量的形式发送XML数据，并且通过HTTP协议监听回程信息。合作者将通过HTTP流格式返回XML数据。这例给出的例子代码利用了微软的XMLHttp对象来发送和监听回应。

　　第二个案例要求我们简单地复制为合作者准备的XML文件到不同的本地目录。这是很灵巧的，举例来说，你可能需要将文件放置在FTP目录中，或者是你想要从中动态地建立Web报表的目录。

第一步

　　处理程序使用SQL服务器数据库中的数据建立一般的内部XML订单文件。对于我们的例子，我们将从三张表中抽取数据，包括PartnerInfo、PartnerOrders和PartnerOrderItems。（一个SQL脚本包括在下载的例子中，因此你可以自己建立此数据库）。PartnerInfo储存了第二步中需要的合作伙伴指定的XSL文件的目录位置。PartnerOrders和PartnerOrderItem包含了所有的从Web站点生成的订单数据。你同样可容易地从现存的订单表中抽取数据，并且把他们和类似于PartnerInfo的表连结起来。

　　在步骤一中，处理程序简单的查找所有还没被处理的合作伙伴订单数据。它获取这些数据并建立我们内部的XML订单文档。这些文档包括一个所有数据超集，这些数据是我们可能需要传送给未来的合作伙伴的。这些文档都是一般化的并且遵循一个内部的标准，这是为了任何我们的系统可以理解如何读取这些文件。第一步完成以后，所有生成好的文档被保存在内部发件箱中。

　　内部XML订单文档的特性：

• 包含了合作伙伴指定的XSL文件的目录位置
• 遵循内部标准（可能的话最好是工业标准）
• 是订单数据的超集

　　让我们随着这段XML语句贯穿整个系统：

<OrderShipping_Details>
   <Name>John P Doe</Name>
   <Address1>Street Address1</Address1>
   <Address2>Apt 1</Address2>
   <Address3></Address3>
   <City>CityName</City>
   <State>ST</State>
   <PostalCode>88888</PostalCode>
   <Country>US</Country>
   <Phone>123?56?890</Phone>
   <ShipMethod>Standard Shipping</ShipMethod>
</OrderShipping_Details>

（注：这将是研究为了你们的产业而现存的标准的良好场所。检查大纲（Schema,译注：描述XML文件信息结构的文件，用来替代DTD的功能）或是DTD库（译注：DTD是文档类型声明，全称是Document Type Declaration）。这样你就不必做重复劳动了。）（ 译注：在国内还不可能有行业标准Schema）

步骤二

　　处理程序依次整理在发件箱中的内部订单，并载入 XML 数据。于是它使用 XML DOM（译注，DOM是文档对象模型，全称是Document Object Model）查询文档，并且查找到合作伙伴指定的XSL文件的位置。处理程序载入正确的XSL文件并且将它合并入内部的XML订单数据来建立待发送的订单XML文档。如果这儿出现任何错误，处理程序保存内部XML订单到内部订单出错目录中。如果没有错误发生，内部的XML订单文档则被保存到存档目录中，并且新的外送文档将存在于合作者的发件箱目录中。

外送订单XML文档的特性：

• 这个文件包含了处理程序为了分发订单到给定合作伙伴的所需知道的所有信息。它包括两个主要的元素：标签和数据包
• 标签包含一个分发的方法（例如："PostAsForm"，或是"FTP"）
• 标签包含任何所需的分发参数（例如："PostToURL"，或是"FTPassword"）
• 数据包是为了加工合作伙伴订单数据的一个容器元素
• 数据包是合作伙伴指定格式的数据
• 在此给出的应用程序，订单数据从我们内部XML格式转化为合作者指定的XML格式

　　在这一步中我们要解决的最大的问题是怎样将我们的数据转变成合作者指定的格式。在这个例子中合作伙伴A要求运送详细信息如下：

<SHIPTO>
   <SHIPTONAME>John Doe</SHIPTONAME>
   <ADDRESS1>Street Address1</ADDRESS1>
   <ADDRESS2>Apt 1</ADDRESS2>
   <CITY>CityName</CITY>
   <STATE>ST</STATE>
   <ZIP>88888</ZIP>
   <COUNTRY>US</COUNTRY>
   <SHIPPING_METHOD>ups_ground</SHIPPING_METHOD>
</SHIPTO>

伙伴B的要求是：

<OrderShippingDetails>
   <Address line="1">John Doe</Address>
   <Address line="2">Street Address1</Address>
   <Address line="3">Apt 1</Address>
   <Address line="4">CityName,ST 88888</Address>
   <Address line="5">US</Address>
</OrderShippingDetails>

<SHIPTO>
   <SHIPTONAME>
      <xsl:value-of select="OrderShipping_Details/Name"/>
   </SHIPTONAME>
   <ADDRESS1>
      <xsl:value-of select="OrderShipping_Details/Address1"/>
   </ADDRESS1>
   <ADDRESS2>
      <xsl:value-of select="OrderShipping_Details/Address2"/>
   </ADDRESS2>
   <CITY>
      <xsl:value-of select="OrderShipping_Details/City"/>
   </CITY>
   <STATE>
      <xsl:value-of select="OrderShipping_Details/State"/>
   </STATE>
   <ZIP>
      <xsl:value-of select="OrderShipping_Details/PostalCode"/>
   </ZIP>
   <COUNTRY>
      <xsl:value-of select="OrderShipping_Details/Country"/>
   </COUNTRY>
   <xsl:apply templates select="OrderShipping_Details/ShipMethod"/>
</SHIPTO>

还有转换我们的运送方法到合作者，我们调用这个模板：

<xsl:template match="ShipMethod">
   <xsl:element name="SHIPPING_METHOD">
   <xsl:choose>
      <xsl:when test=".[.='UPS Next Day Air Saver']">ups_next_day</xsl:when>
      <xsl:when test=".[.='Standard Shipping']">ups_ground</xsl:when>
      <xsl:when test=".[.='US Postal Service']">us_firstclass</xsl:when>
      <xsl:when test=".[.='Federal Express']">us_fedex_priority</xsl:when>
      <xsl:otherwise>UNKNOWN ?<xsl:value-of select="."/></xsl:otherwise>
   </xsl:choose>
   </xsl:element>
</xsl:template>

　　XSL文件是这个应用程序真正的心脏。在步骤一中，处理程序知道如何把我们的数据转入我们内部的XML订单文档。文档元素之一指示了XSL文件的目录位置。在此步骤中，处理程序整理此文件，并使用它来转换到数据包和标签。在步骤三中，此处理程序动态地使用这些在标签中的信息来发送数据包。

　　尽管，当前的系统要求支持发送订单给两个合作伙伴，我们能够简单的扩展这个应用程序支持多个伙伴。系统总是以同样的方式做步骤一和步骤二。我们可以简单地写一个XSL文件，这个文件将用来解决转换我们的数据时的细节问题。

步骤三

　　程序处理每一个外送文档。使用XML DOM，处理程序检索文档的标签元素，找到分发的方法和分发参数列表。处理程序也读取数据包并作为分离的XML文档储存在内存中（记住这是最终的合作伙伴订单XML）。

在我们的例子中，一个送往伙伴B的订单有着以下的标签：

<FSO_Label>
<XMLDelivery Method="POSTXMLASFORM">
   <Post2Url type="delivery_param">
      http://www.PartnerURL.asp/Orders/AcceptPost_ReturnXML.asp
   </Post2Url>
   <FrmVarName type="delivery_param">partner_xml</FrmVarName>
   <ResponseXPath type="delivery_param">
      /partner_salesorder_response/@error_code
   </ResponseXPath>
   <ResponseSuccessValue type="delivery_param">
      success
   </ResponseSuccessValue>
</XMLDelivery>
</FSO_Label>

　　在这个例子中，第二个标记，XMLDelivery，告诉系统那个方法应该被调用：
POSTXMLASFORM。记的吗，对于这个伙伴，我们通过HTTP以表单元素发送XML数据，　并且监听HTTP流的XML回应。因此，当调用此方法时，外送的XML必须指定几个参数。其中之一是处理程序将发送XML到哪个URL。我们在这儿也指定了合作伙伴要求使用的表单变量名。

　　由两个参数我们可以让处理程序动态的从合作伙伴“读取”XML回应，来得知他们是否成功的接收了我们的订单。第一个参数是XML中的路径，它指示了处理程序在哪儿查找合作伙伴的系统回应。第二是成功标志。在这个案例中当我们完成分发合作伙伴订单时，是简单的“success”。如下图所示：

　　我们的处理程序会发送订单XML到指定的URL，这意味什么呢？它会收到XML回应并且发送XML到一个运行进程，此进程将查找/partner_salesorder_response/@error_cod这个选定的节点值。如果此值恰好是ResponseSuccessValue参数，则处理程序知道整个交易成功并复制XML存档。如果他们不相符，意味着发送失败并且XML将被复制到出错目录中。

　　考虑到在如下的场景中，一个公司可能要处理几个合作伙伴的业务，所有的处理都需要不同的订单分发方法并且制定不同的参数。这是此种解决方案的力量才会变得明显。这个方案不仅使得一个程序处理各种分发方法，而且也使得此程序动态地决定“听”到什么来决定给定的交易是否成功。这个示例应用程序监听合作伙伴的回应。但是一样的规则也可扩展到与内部系统的通信。

将来的考虑

　　虽然这个示例应用程序具有完全的功能，这儿还是有许多值得改进的地方。这儿是一些立即引起注意的几点：

• 使用大纲或是DTD来验证合作伙伴的XML包是有效的
• 自动化处理在出错目录中的文件
• 检查SQL Server 2000在这个系统中的合适之处
• 建立一个SOAP类，通过SOAP来分发订单数据。当与内部其它的系统进行通信时，这很灵活使用XSLT来建立订单表单