基于XML的电子商务集成系统的研究与实现

第第#页足W3C颁布的XML标准，比如所有的标签必须是一对的形式出现等等。内容有效是指如果在XML文档中声明要遵守一定的语义，那么这个XML文档必须满足一定的规范，这些规范通常在一个单独的文件里定义。这些文件定义了XML文档的格式，出现的元素，属性的类型等。目前常用的XML文档定义语言有DTD、XDR和XMLSchema。其中XDR(XML-DataReducedLanguage)是由XML-Data草案派生出来的一个分支，主要在Microsoft公司的产品如Biztalk、SQLServer、Office2000等中使用。而DTD和XMLSchema是由相应行业协会制定、颁布并被广泛使用的XML文档定义语言。DTD(DocumentTypeDefinition)出现较早，是在SGML中供不同的使用者创建自己的文档标记的一种文档描述语言，它的作用包括定义内容模式、限制范围、属性的数据类型等。DTD已应用多年，在技术人员中积累了丰富的使用经验，所有的SGML工具和许多XML工具都支持DTD。目前，DTD仍然是使用最多的文档定义手段。另一方面，DTD本身存在一定的缺陷。DTD本身采用特殊的语法而不是通常的标记语言的形式，它不支持名字空间(Namespace),仅提供了非常有限的数据类型，不能表达元素中字符数据的数据类型。另外，DTD扩展机制有限，而且不便使用。针对DTD的问题以及将来的应用需要，W3C在1998年提出指定XMLSchema规范的需求(Requirement)，并与2001年5月正式颁布XMLSchema的推荐标准[4][5][6。]该标准分为三部分，即Part0:Prime、Part1:Structure和Part2:Data，分别描述了XMLSchema的总体概念、文档语法以及数据类型的定义。与DTD相比，XMLSchema有以下区别与优点：首先，DTD有自己特殊的书写语法，而XMLSchema的语法采用XML的格式，一份XMLSchema文档本身即是XML文档，可以使用通用的XMLParser来解析，无需另行编写解析器；XMLSchema支持名字空间(Namespace)，使得一个XML文件可以有多个对应的Schema，而使用DTD的话，一个XML文档只能对应一个DTD；・DTD只能将字符数据定义为字符串，而XMLSchema对字符数据支持多种数据类型，可以将字符串定义为整型、浮点数、布尔等多种简单数据类型；・XMLSchema中的数据类型可以随意扩充，可以对简单数据类型进行约束，或者创建自定义数据类型。但是，XMLSchema的缺点是，由于采用XML的语法，在定义一些比较简单的数据结构时表达不如DTD简练。尽管如此，XMLSchema正在逐步取代DTD，成为目前XML文档定义的标准。下面是一个简单的例子：一个简单的XML文档如下：＜书本＞＜名称＞天涯明月刀＜/名称＞＜作者＞古龙＜/作者＞＜/书本＞用DTD定义如下：V!ELEMENT书本（名称，作者）〉V!ELEMENT名称（#PCDATA）＞[ELEMENT作者（#PCDATA）＞那么用Schema形式如何定义呢？见下面的代码：elementname='书本'type='书本类型'/＞VcomplexTypename='书本类型'＞elementname='名称'type='string'/＞elementname='作者'type='string'/＞/complexType＞例2-2DTDandXMLSchema从这个例子可以看出，Schema的定义形式是XML文档，而DTD是一些特殊的标记，相对于DTD来说，Schema在今后的发展中将会有更大的空间。在XECI中，XMLSchema或者DTD非常重要，因为企业间交互的表单和消息都是XML文档的格式，交易的商业流程也是用XML文档描述，还有其它的一些描述文件也是XML文档。对每种文档，我们可以用XMLSchema定义它们的格式，企业在生成表单比如订货单时，可以根据这些Schema构造相应的XML文档，不符合Schema的就认为是无效文档。那么当客户想了解企业的文件格式时只需要去下载这些Schema就可以了，这样就达到了数据格式的统一。XMLQueryXMLQuery，通常缩写为XQuery⑺，是一种已经以这样或那样的方式存在几年的规范。XMLQuery工作组在1999年9月正式成立，任务是创建一种灵活的查询语言来从XML文档中抽取数据。最新的工作草案对实现这个目标大有帮助。XQuery构建在XPath规范之上。事实上，XQuery的一些特性已公认为是非常基本的，以致于它们已被合并入XPath2.0规范中，而且这个规范目前为W3C的XMLQuery和XSL工作组共同拥有。这是个好消息，因为它意味着样式表作者们将很快就能利用像序列、量化和更强有力的类型控制这样的特性。同样，已将条件表达式和迭代器添加到了XPath语言中，而在以前它们是XSL语言的一部分。这样就可以在样式表中编写更清晰的代码，并且为样式表创建者带来较少的麻烦。XECI采用了大量的XML文档，这样企业就需要经常对这些文档进行检索，查找它们所需要的数据。XQuery非常适合包含叙述流和量化数据的文档。例如，包含手术期间外科医生操作的描述医疗记录文档。因此使用XQuery将会大大的

缩短数据处理时间，从而提高整个商业交易的效率。XECI框架XML作为一种结构化的数据表示方法，通过定义好的标记语言，避免了信息的丢失和处理上的困难，对新一代的Internet应用有着重要意义。在这一节我们将提出XECI的框架，这个框架是以XML为数据的中间形式和工作对象的电子商务集成技术框架。下面的几个小节将描述XECI的协议层次和功能模块。2.2.1XECI协议层次电子商务集成的本质是在一定的业务合作协议下，通过Internet的传输通道，实现双方或多方之间的消息流，以达成合作的目的。因此在XECI里，企业间的交易过程实际上是遵守一定的协议进行交互的过程。下图是XECI的协议层次图：商务集成企业内部应用

应用集成层

商业流程层

安全层商务集成XECI通信（SOAP）底层通信（HTTP）图2-1XECI协议层次图如图所示，根据XECI协议的功能，我们可以分成三层：底层通信层；商务集成层；企业应用集成。•底层通信层：XECI考虑的是Internet上的电子商务，底层数据的传输主要是通过HTTP连接。其它一些标准、框架比如ebXML也采用了SMTP协议，从技术上讲，这和HTTP是类似的，因此XECI主要是基于HTTP的。•商务集成层：商务集成层主要的作用是按照一定的商业流程处理企业间的电子交易，包括三个子层：XECI通信层、安全层和商业流程层。XECI通信层：XECI通信层的功能也是数据的通信，与底层通信层不同，这一层处理处理的数据是在XECI中定义的有固定格式的XML文档，包括订单请求、返回结果等。这些数据有固定但可能是比较复杂的格式，比如数据结构，数据类型等，用一般的协议（比如HTTP等）不易描述。我们使用的是SOAP协议,SOAP定义了一套编码规则，可以比较方便的描述简单的数据。最重要的是，SOAP可以方便的和HTTP绑定，从而可以与上层比较好的结合在一起。安全层：该层确保系统间消息传递的保密性、完整性、安全性，防止窃取、冒名篡改。商业流程层：在这一层，我们定义了一些商业流程，也就是商业交易的规则，并且按照这些商业流程控制交易的执行。•企业应用集成：第一章我们讲过，传统的C/S结构不适合商业流程复杂的B2B电子商务，该层的任务就是对企业内部的复杂环境进行整合，配合商务集成层完成复杂的交易。该层包括应用集成和企业应用服务两个子层。应用集成：该层负责管理企业内部应用。尽管企业内部的环境是多样的，但是经过该层的调度，它们将对上层提供统一的服务接口,这样对于上层来说,只需要了解接口的输入和输出,而不用关心具体的应用.企业内部应用：该层主要是完成数据操作的中间件等内部应用,它们读取或者修改数据库,并将结果以XML的格式返回。XECI功能模块前面介绍的是XECI的协议层，协议层主要是根据商业交互和数据传输的流程划分的。在这一节里，我们根据XECI各部分的功能不同划分为四大模块，分别是数据集成模块、应用集成模块、注册库模块和安全模块。在这四个模块中，数据集成模块负责企业间数据的交换；应用集成模块负责企业内部应用的整合，这两个模块是XECI最主要的两个功能模块。注册库和安全模块则为XECI提供辅助功能和安全保护，它们的重要性虽然不及前者，但是对于一个完善的电子商务集成系统还是不可或缺的。下面我们将分别介绍。1）数据集成模块随着IT业的发展，特别是Internet的发展，信息量正以指数的速度递增。对于企业来说，信息是它们的财富，能否获取更多的信息成为企业是否成功的一个重要因素。然而这些企业或组织又都面临着一个相同的问题，那就是大量格式多样，并且是分散的数据，这其中包括各类数据库、知识库、文件系统、电子图书以及电子邮件等等。在20年前，企业的数据大都保存在一台主机里，数据格式比较简单，数据的访问和交换也不那么频繁，问题还不是那么明显。而如今，企业间进行交易，经常需要访问和交换数据，我们都知道，一个企业经常采用不同的数据库，比如Oracle、DB2、SQLServer或者XML数据库；出于不同的目的，企业也经常使用不同的系统，包括Windows、UNIX和LINUX。这些差异给企业的数据互访，商业往来带来极大的障碍。数据集成的研究内容就是如何消除这些障碍，通过统一企业间的数据交互格式，提高企业的效率。那么如何使企业间的数据达到统一呢？在XECI里是通过“统一用户词典”和“统一商业流程”来完成的。统一用户词典命名问题经常会给企业带来很多的麻烦［8］，主要是因为同一词汇在不同企业可能会有不同的含义，或者在表示的内容上不一致。举个例子，比如“足球”这个词，对于新浪网这些门户网站它所代表的意义主要是一类体育新闻，那么在描述“足球”时，根据我们所关心的内容就是：＜足球＞＜类别＞体育新闻＜/类别＞＜来源＞新浪网＜/来源＞＜/足球＞而对于阿迪达斯来说，足球是一类体育用品，它的内容完全不同，请看：＜足球＞＜类别＞体育用品＜/类别＞＜规格＞飞火流星＜/规格＞＜厂商＞阿迪达斯＜/厂商＞＜/足球＞如果两个企业之间存在商业往来，那么由于对这些词汇的理解和定义不同，势必给它们的交易带来障碍。那么如何才能解决这些问题呢？我们的做法是统一用户词典，在XECI中，对于一些关键词汇（比如Transaction，BusinessProcess等），我们用XMLSchema或者DTD对其含义和内容进行定义，并以WebService的形式保存在注册库中（具体是如何保存，我们将在以后介绍）。所谓的"WebService"，它是指由企业发布的完成其特别商务需求的在线应用服务，其它公司或应用软件能够通过Internet来访问并使用这项在线服务。这样做有几点好处：对其它企业，用户词典都是公开的（对一些涉及企业机密的文件，我们可以通过一定的安全策略加以控制）用户可以方便的修改统一商业流程所谓商业流程(BusinessProcess)［9］,是指企业中不同角色为实现经营目标而进行的一系列相互衔接、自动进行的商业事务(BusinessTransaction)的集合，说得简单点就是企业交互的业务流程，有些地方也称为工作流(Workflow)。电子商务集成的商业流程与一般的商业流程有所不同［10］，前者考虑的是所有的企业，重点放在企业间的交互上，要求具有普适性；后者主要考虑的是某个企业的内部业务，相比较而言会片面些。因此前者比较松散和灵活，而后者耦合度高。目前在商业流程方面，有一些权威机构制定的标准，比如BPMI(BusinessProcessManagementInitiative)组织提出的BPML，全称是BusinessProcessModelingLanguage。BPML定义了一种商业流程建模语言，它能够表达跨越多个应用、多个企业部门和多个业务伙伴的商业流程，并在企业与企业间电子商务应用起到关键作用。RosettaNet主要解决的是供应链的问题，它的核心是PIP(PartnerInterfaceProcesses)，PIP是企业流程说明，企业可以利用PIP来架构企业本身和其它企业伙伴间的电子化流程。其它还有一些关于商业流程的标准比如cXML,ebXML等等，虽然具体内容有所不同，通过学习这些标准，我们可以总结出一个完整的商业流程应该包括以下内容：一组活动及它们之间的联系•流程启动和终止条件活动执行者相关的应用程序活动要求的参数及结果格式本文在商业流程的设计上主要参考了BPML和ebXML，一则因为商业流程涉及企业交易流程，本人对此不是非常熟悉；而且要设计一套完善的商业流程描述语言也绝非易事(ebXML由OASIS，UN/CEFACT，NIST,W3C制定，期间参与者包括IBM等大公司)。因此，本文提出的商业流程主要是为本文的整体框架设计的。2)应用集成模块应用集成指的是企业内部应用程序的集成［11］，企业内部是一个异构的环境。一个典型的企业内部网络包括大型主机、UNIX工作站和PC机，各种机器所采用的操作系统和网络通信协议也是千差万别的。在这样的异构环境下，实现信息和软件资源的共享，从而实现企业间交互的自动化。所谓交互自动化是指企业不需要知道对方企业内部的构造，对它来说，对方内部的环境的改变不会影响企业间的交互过程。实现应用系统集成和即插即用的一个关键是标准规范和相应的支持软件。近几年国际上研究较多，出现了一些规范和产品。目前，几种主流的分布式对象的标准和具体化模型主要有：OMG组织的CORBA、Microsoft的OLE/COM（DCOM）、CILabs的OpenDoc等。其中CORBA和OLE/COM（DCOM）是两个主要的标准规范。与一般的应用集成系统不同，在XECI里，企业对商业流程的处理是内部应用之间协作的过程。它更加注重的是应用之间的逻辑过程，如果采用传统的CORBA等不利于商业逻辑的描述，因此，我们提出了一种基于服务的电子商务集成框架（ServicebasedE-businessIntegrationFrame，以下简称为SEAIF[12]）。在SEAIF中，我们把企业内部的每个应用看成一个Web服务，通过服务互操作描述语言（SIML）用XML的格式把它们的逻辑关系，协作过程描述出来。下面是SEAIF的协议框架图：服务互操作描述语言（SIML）简单对象访问协议（SOAP）可扩展标识语言（XML）公共网络协议（HTTP，TCP/TP等）图2-2SEAIF协议框架采用SEAIF集成电子商务应用有以下优点：与CORBA相比，SEAIF集成框架是轻量级、可扩展及灵活的。SEAIF很容易实现Web应用、企业应用程序及应用程序组件的集成。SEAIF采用SOAP消息作为通信机制，与传统的RPC调用相比，SOAP由于采用XML表达消息内容，因此SOAP调用是开放自描述的，SOAP调用有诸如调用灵活性好、平台中立、技术中立、容易穿过防火墙及轻量级等优点。由于SEAIF将计算单元抽象地描述为服务，从而使服务的描述、服务的实现及服务之间的通信协议相分离，所以SEAIF易于与现有的ebXML、Rosettanet及CORBA等技术集成。由于采用XML技术集成电子商务应用，SEAIF比传统的DOT技术更适合于在技术上和策略上使用公共接口定义语言通信体系结构困难的企业。3）注册库模块一个企业如果想和另外的企业进行商务过程，它必须要知道对方提供的服务，而这个企业本身也要公布自己提供的服务。如何使企业可以方便地找到这些服务信息呢？一个解决该问题的办法是在公司的每个网站上放置一个Web服务的描述文件。这样，至少那些依靠已经注册的URL来工作的网络爬虫程序能够发现并为它们建立索引。可是通过这种方法来定位Web服务的方法完全依赖爬虫程序的能力。这种分布式的机制是可扩展的，但它缺少一种机制来保证服务描述格式的一致性，也不能便捷的跟踪不断发生的变化。在XECI中，企业信息和企业的服务信息保存在注册库中。所谓注册库，是一个第三方的服务中心，企业要使用注册库，首先需要先注册成为它的成员。关于服务的注册有两个比较有影响的标准，一个是UDDI,另一个是WSDL。UDDI提供了一套注册的标准框架和协议，而WSDL是一种WebService描述语言，主要用来描述企业服务。很多企业使用，研究机构实现的注册库的实现都采用了UDDI和WSDL，因此为了符合国内外的标准，XECI也主要是参考了这两个协议，下面是关于UDDI和WSDL的介绍。UDDI和WSDLUDDI[13是—套基于Web的、分布式的、为Web服务提供的信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的Web服务注册，使得别的企业能够发现的访问协议的实现标准。Web服务是下一代的WWW，它允许在Web站点上放置可编程的元素，使得能进行基于Web的分布式计算和处理。UDDI商业注册中心的创建目的就是为促进企业的Web服务的发展及为企业发现适当的Web服务。UDDI提供了一种基于分布式的商业注册中心的方法，该商业注册中心维护了一个企业和企业提供的Web服务的全球目录，而且其中的信息描述格式是基于通用的XML格式的。UDDI计划的核心组件是UDDI商业注册，它使用一个XML文档来描述企业及其提供的Web服务。从概念上来说，UDDI商业注册所提供的信息包含三个部分："白页(WhitePage)"，包括了地址，联系方法，和已知的企业标识；"黄页(Yellowpage)"，包括了基于标准分类法的行业类别；"绿页(GreenPage)"，则包括了关于该企业所提供的Web服务的技术信息，其形式可能是一些指向文件或是URL的指针，而这些文件或URL是为服务发现机制服务的。所有的UDDI商业注册信息存储在UDDI商业注册中心中。WSDL—“Web服务描述语言”(WebServicesDescriptionLanguage)就是描述XMLWeb服务的标准XML格式，WSDL由Ariba、Intel、IBM和微软等开发商提出。它用一种和具体语言无关的抽象方式定义了给定Web服务收发的有关操作和消息。WSDL将Web服务描述为一组对消息进行操作的网络端点。一个WSDL服务描述包含对一组操作和消息的一个抽象定义，绑定到这些操作和消息的一个具体协议，和这个绑定的一个网络端点规范。UDDI数据类型在UDDI注册中心有4种主要的数据类型：businessEntity、businessService、bindingTemplate和tModel。businessEntity提供关于商家的信息，可以包含一个或多个businessService。这个商家是服务提供者。Web服务的技术和业务描述在businessService和其bindingTemplate中被定义。每个bindingTemplate包含一个对一个或多个tModel的引用。tModel被用于定义服务的技术规范。WSDL文档类型为帮助在UDDI注册中心发布和查找WSDL服务描述，WSDL文档被分为两种类型：服务接口(serviceinterface)和服务实现(serviceimplementations)服务接口由WSDL文档来描述，这种文档包含服务接口的types、import、message、portType和binding等元素。服务接口包含将用于实现一个或多个服务的WSDL服务定义。它是Web服务的抽象定义，并被用于描述某种特定类型的服务。通过使用一个import元素，一个服务接口文档可以引用另一个服务接口文档。例如，一个仅包含message和portType元素的服务接口可以被另一个仅包含此portType的绑定的服务接口引用。WSDL服务实现文档将包含import和service元素。服务实现文档包含实现一个服务接口的服务的描述。import元素中至少会有一个将包含对WSDL服务接口文档的引用。一个服务实现文档可以包含对多个服务接口文档的引用。WSDL服务实现文档中的import元素包含两个属性。namespace的属性值是一个与服务接口文档中的targetNamespace相匹配的URLOlocation属性是一个用于引用包含完整的服务接口定义的WSDL文档的URL。port元素的binding属性包含对服务接口文档中的某个特定绑定的引用XECI注册库的实现在这里，我们提供了一种基于分布式的注册中心的方法，该注册中心维护了一个企业的信息和企业提供的Web服务的目录，而且其中的信息描述格式是基于通用的XML格式的。它主要提供对外的服务接口，和注册商务流程的功能。XECI的注册服务由两部分组成：注册库和注册客户端。注册库由可信第三方管理，存放企业提供的服务接口，共享数据以及商务流程；注册客户端为企业提供注册的接口。注册库物理位置上可以是集中的，也可以是分散的。集中式的优点是所有信息存储在一个地方，便于管理，缺点是对注册服务器的访问量会很大，带来的后果就是服务器负载过重；对于分散的注册库需要提供分布式的管理，这样就可以把负载分配到各个节点，但是由此也带来了节点间的协调问题。XECI的注册库采用的集中式的管理。注册客户端是XECI为企业用户提供的注册工具，企业可以通过客户端提供的注册接口完成注册，或者通过关键字查找企业提供的服务，进而获悉企业提供服务的接口。注册客户端与注册库的通信采用SOAP(SimpleObjectAccessProtocol)协议，SOAP是个轻量级的协议，用XML的格式书写，比较适合分布式环境下的数据通信，关于SOAP，我们将在后面提到。4)安全模块安全对于电子商务系统非常重要，在电子商务集成技术中，设计到多方之间的数据通信和业务流程，安全更为重要。而且还提出了新的要求，就是灵活性和互操作性。XECI中传递的主要是XML数据，XML是一个开放的标准，因此XML的安全更应该引起企业的注意。关于XML的安全有很多标准，比如XML加密（Xenc）[14、XML签名（X-SIG）、XML加密管理规范（XKMS）、XML访问控制标记语言（XACML）和安全声明标记语言（XAML）等等。我们主要考虑两个问题，一种是XML的签名，另一种是XML数据的加密，XML签名和XML加密结合在一起，可以确保数据发送和接收的一致性。下面我们讲分别分析这两个问题。XML的数字签名XML数字签名的目的是实现Internet上数据交换的完整性、确认性和不可抵赖性。OASIS（标准和互用性集团）已经有计划为电子商务交易和终端用户安全信息开发一种基于XML的规范，即安全服务标记语言（S2ML,SecurityServicesMarkupLanguage），一种在XML文件中定义用户认证、授权、权利和侧面信息的方法，为在网络安全解决方案中使用XML向工业标准又迈进了一步。数字签名技术并不是新鲜的话题，但是关于如何利用好数字签名却似乎总是有无穷无尽的讨论。新的应用对异构环境中互操作性和可扩展性的要求，使得数字签名问题变得复杂化。人们对电子化处理传统事务的需求高涨，复杂的事务处理过程伴随着复杂的文档。数字签名可能是对整个文档进行，也可能只是对文档中的某一部分进行，对复杂文档签名是一个值得研究的问题。在网络环境中，文档之间相互联系，给人们带来了方便，也带来了处理的复杂性。一个文档不一定是一个文件，可能是一组文件组成，文件之间用超链接关联。签名和被签名的数据甚至不在一个文档中，不在一台主机中。在事务处理过程中文档也在变化之中，而且签名会有多种方式，如共同签名、认可、公证等。比如在B2B的一次交易中，会有多次协商、更改过程，而且涉及到多方的关系。多媒体的广泛应用，使信息的表示多样化。不仅有一般的文本数据，或纯粹的一种数据，而且有可能使多种数据的混合。如图像和描述图像的数据混合，程序代码和对象实体等。所有这些复杂应用对数字签名提出了更高的要求，用现有的技术很难满足这些需求。XML的出现和广泛应用使这一切变为可能。我们可以将XML签名应用到任意数据内容。那些应用到相同XML文档中数据的签名称为封装或被封装的签名，而那些数据在签名元素外部的签名称为分离签名。下面是一个简单分离签名的实例。[s01]〈SignatureId="MyFirstSignature"xmlns="/2000/09/xmldsig#">[s02]<SignedInfo>[s03]<CanonicalizationMethodAlgorithm="/TR/2001/REC-xml-c14n-20010315"/>[s04]<SignatureMethodAlgorithm="/2000/09/xmldsig#dsa-sha1"/>[s05]〈ReferenceURI="/TR/2000/REC-xhtml1-20000126/">[s06]〈Transforms〉[s07]〈TransformAlgorithm="/TR/2001/REC-xml-c14n-20010315"/>[s08]〈/Transforms〉[s09]<DigestMethodAlgorithm="/2000/09/xmldsig#sha1"/>[s10]<DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>[s11]〈/Reference〉[s12]〈/SignedInfo>[s13]<SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>[s14]〈KeyInfo>[s15a]〈KeyValue〉[s15b]〈DSAKeyValue>[s15c]^'...〈^'"'...〈©'"'...〈"'"'...〈/丫〉[s15d]〈/DSAKeyValue>[s15e]〈/KeyValue〉[s16]〈/KeyInfo>[s17]〈/Signature〉例2-3XML签名实例实际签名的信息是位于s02行和s12行之间，即SignedInfo元素。在签名的部分中包含用于计算SignatureValue元素的算法的引用，而那个元素本身位于签名部分之外（在sl3行上）。s04行上的SignatureMethod引用的是将规范的SignedInfo转换成SignatureValue所用的算法。它是密钥相关的算法和摘要算法（在这里是DSA和SHA-1）的组合，可能还具有象填充这样的操作°KeyInfo元素（在这里位于sl4行和sl6行之间—该元素是可选的）指出用来验证签名的密钥。XML的加密[15]象其它任何文档一样，可以将XML文档整篇加密，然后安全地发送给一个或多个接收方。例如，这是SSL或TLS的常见功能，但是更令人感兴趣的是如何对同一文档的不同部分进行不同处理的情况。XML的一个有价值的好处是可以将一整篇XML作为一个操作发送，然后在本地保存，从而减少了网络通信量。但是，这就带来了一个问题：如何控制对不同元素组的授权查看。商家可能需要知道客户的名称和地址，但是，无需知道任何正在使用的信用卡的各种详细信息，就像银行不需要知道购买货物的详细信息一样。可能需要防止研究人员看到有关个人医疗记录的详细信息，而管理人员可能正好需要那些详细信息，但是应该防止他们查看医疗历史；而医生或护士可能需要医疗详细信息和一些（但不是全部）个人资料。密码术现在所做的远远不止隐藏信息。消息摘要确定文本完整性，数字签名支持发送方认证，相关的机制用于确保任何一方日后无法拒绝有效事务。这些都是远程交易必不可少的元素，现在，用于处理整个文档的机制开发得相当好。有了一般的加密，对XML文档整体进行数字化签名不是问题。然而，当需要对文档的不同部分（可能由不同的人）签名，以及需要与选择性的方法一起来这样做时，就会出现困难。也许不可能或者不值得强制不同部分的加密工作由特定人员按特定顺序进行，然而成功地处理文档的不同部分将取决于是否知道这点。此外，由于数字签名断言已经使用了特定专用密钥来认证，所以要小心签名人是以纯文本形式查看文档项的，这可能意味着对由于其它原因而加密的部分内容进行了解密。在另一种情况下，作为更大集合中的一部分，可能对已经加密过的数据进行进一步加密。在牵涉单一XML文档（可能由一些不同的应用程序和不同的用户处理在工作流序列中使用的Web表单或一系列数据）的事务集中考虑的不同可能性越多，就越可能看到巨大的潜在复杂性。还有其它问题。XML语言的强项之一是，搜索是明确的，无二义性的：DTD或Schema提供了相关语法的信息。如果将包括标记在内的文档的一部分作为整体加密，就会丧失搜索与那些标记相关的数据的能力。此外，如果标记本身被加密，那么一旦泄漏，它们将被利用对采用的密码术进行纯文本攻击。我们一般采用EncryptedData元素来表示XML中加密的数据，该元素与EncryptedKey元素一起用来将加密密钥从发起方传送到已知的接收方。要加密的数据可以是任意数据、XML文档、XML元素或XML元素内容；加密数据的结果是一个包含或引用密码数据的XML加密元素。当加密元素或元素内容时，EncryptedData元素替换XML文档加密版本中的该元素或内容。当加密的是任意数据时，EncryptedData元素可能成为新XML文档的根，或者可能成为一个子代元素。当加密整个XML文档时，EncryptedData元素可能成为新文档的根。此外，EncryptedData不能是另一个EncryptedData元素的父代或子代元素，但是实际加密的数据可以是包括现有EncryptedData或EncryptedKey元素的任何内容。下面是XML加密的一个例子:1.显示JohnSmith的银行帐户、5000美元限额、卡号和有效期的的信息<?xmlversion='1.0'?><PaymentInfoxmlns='/paymentv2'><Name>JohnSmith<Name/><CreditCardLimit='5,000'Currency='USD'><Number>4019244502775567</Number><Issuer>BankoftheInternet</Issuer><Expiration>04/02</Expiration></CreditCard></PaymentInfo>例2-4XML加密实例2.除名称之外全部被加密的加密文档<?xmlversion='1.0'?><PaymentInfoxmlns='/paymentv2'><Name>JohnSmith<Name/><EncryptedDataType='/2001/04/xmlenc#Element'xmlns='/2001/04/xmlenc#'><CipherData><CipherValue>A23B45C56</CipherValue></CipherData></EncryptedData></PaymentInfo>例2-5XML加密结果1但是，在其它情况下，可能只需要隐藏一些敏感内容（可能来自商家或其它第三方）例3演示了这点。（请注意，显示了与加密内容相关的标记名。）只隐藏了信用卡号的加密文档<?xmlversion='1.0'?><PaymentInfoxmlns='/paymentv2'><Name>JohnSmith<Name/><CreditCardLimit='5,000'Currency='USD'><Number><EncryptedDataxmlns='/2001/04/xmlenc#'Type='/2001/04/xmlenc#Content<CipherData><CipherValue>A23B45C56</CipherValue></CipherData></EncryptedData></Number><Issuer>BankoftheInternet</Issuer><Expiration>04/02</Expiration></CreditCard></PaymentInfo>例2-6XML加密结果2可能还有必要加密文档中的所有信息，例4演示了这点。隐藏了全部内容的加密文档<?xmlversion='1.0'?><EncryptedDataxmlns='/2001/04/xmlenc#'Type='/in-notes/iana/assignments/media-types/text/xml'><CipherData><CipherValue>A23B45C56</CipherValue></CipherData></EncryptedData>例2-7XML加密结果3CipherData可以圭寸装，也可以引用原始加密数据。在第一种情况下，CipherValue元素的内容显示原始数据，而在第二种情况，使用CipherReference元素，这包括了一个指向加密数据位置的URI。2.2.3XECI实例在这一节里，我们将通过一个实例认识XECI的工作过程，一方面对XECI的协议层次有个直观的认识，另一方面也对它的四个功能模块有深刻的了解。该实例是电脑零售商向硬件厂商发送硬盘订购的交易过程，通过这个过程可以对上述XECI框架各个环节和细节进行说明。订购的过程分为三步，查询”硬盘”价钱、查询库存、发送订单。各模块的准备该例中，电脑零售商和硬件厂商分别以客户和生产者的身份出现。作为客户，电脑零售商是交易的发起者，由它发送请求；硬件厂商是服务提供者，它接受客户的请求，并对请求进行处理。在交易前，各模块首先要有一些技术性的准备：1.数据集成前面我们说过，不同企业对词汇的理解不同，因此要首先统一用户词典。本例中，虽然客户与生产者都是电脑行业，但也有可能对各零件包含的内容有不同的认识。比如电脑零售商更加关心零件的价格，而硬件厂商更注重零件的规格等。这里，零件由硬件厂商定义，以”硬盘”为例，在硬件厂商端的定义如下：HardDisk.xml＜硬盘＞＜厂商〉IBMv/厂商〉＜型号＞蓝亚＜/型号＞＜容量＞18Gv/容量〉＜速度＞10000转＜/速度＞＜其它说明〉SCSI接口，2M缓存，三年质保＜/其它说明〉＜/硬盘＞另外，硬件厂商还定义了不同的商业流程，比如查询价格、查询库存、订购等等。下面是关于订购流程的定义（关于此例的Schema见附录1）：OrderProcess.xml<Packagename="Ordering"><business-transactionname="AvailabilityBT"><requesttype="AvailabilityRequest"/><responsetype="AvailabilityResponse"status="success"/></business-transaction><business-transactionname="QuoteBT"timeToPerform=""timeUnit="days"><requesttype="QuoteRequest"/><responsetype="Quote"status="success"/></business-transaction><business-transactionname="OrderBT"isNonRepudiationRequired="true"><requesttype="Order"/><responsetype="OrderConfirmation"status="success"/><responsetype="OrderDenied"status="failure"/></business-transaction><business-transactionname="ShippingNotice"isSecureTransportRequired="false"><requesttype="ShippingNotice"/></business-transaction><business-transactionname="PaymentNoticeBT"><requesttype="PaymentNotice"/><responsetype="PaymentResponse"status="success"/></business-transaction><binary-collaborationname="AvailabilityCollaboration"initiator="buy"responder="sell"><business-transaction-activityname="AvailabilityBT"from="buy"to="sell"/><collaboration-activityname="QuoteOrder"type="QuoteOrderCollaboration"from="buy"to="sell"/><startto="AvailabilityBT"/><transitionfrom="AvailabilityBT"to="QuoteOrder"/><successfrom="QuoteOrder"guard="success"/><failurefrom="QuoteOrder"guard="failure"/></binary-collaboration><binary-collaborationname="QuoteOrderCollaboration"initiator="buy"responder="sell"><business-transaction-activityname="QuoteBT"from="buy"to="sell"/><collaboration-activityname="OrderIt"type="OrderCollaboration"from="buy"to="sell"/><startto="QuoteBT"/><transitionfrom="QuoteBT"to="OrderIt"/><successfrom="OrderIt"guard="success"/><failurefrom="OrderIt"guard="failure"/></binary-collaboration><binary-collaborationname="OrderCollaboration"initiator="buy"responder="sell"timeToPerform=""timeUnit="days"><business-transaction-activityname="OrderBT"from="buy"to="sell"/><business-transaction-activityname="ShippingNotice"from="sell"to="buy"/><business-transaction-activityname="PaymentNotice"from="buy"to="sell"/><startto="OrderBT"/><transitionfrom="OrderBT"guard="OrderConfirmation"to="ShippingNotice"/><transitionfrom="ShippingNotice"to="PaymentNotice"/><transitionfrom="PaymentNotice"to="PaymentResponse"/><successfrom="PaymentResponse"/><failurefrom="OrderBT"condition="failure"/></binary-collaboration><multi-party-collaborationname="BuySell"><business-partnername="buyer"><performsservice="AvailabilityCollaboration"role="buy"/></business-partner><business-partnername="seller"><performsservice="AvailabilityCollaboration"role="sell"/></business-partner></multi-party-collaboration></Package>例2-8BusinessProcessforOrder对于”硬盘”的定义和订购流程的定义将存储在注册库中并且对外公开，电脑零售商可以去注册库查询，获取相关信息。2.应用集成硬件厂商除了要定义一些重要词汇和商业流程外，它还要定义内部各部门应用程序的工作流程，下面是查询库存的工作流程（关于此例子的Schema见附录2）：Repertory.xml<ApplicationCollaborationProfileid="N01"name="Repertory"><ApplicationCollaborationInfourl="http://localhost:8080/soap/servlet/rpcrouter">vPartner>电脑零售商v/Partner><IP>01</IP><Port>8080</Port><RPCRouter>http://localhost:8080/soap/servlet/rpcrouter</RPCRouter></ApplicationCollaborationInfo><App-Collaboration><App-transactionname="AvailabilityRequest"method="getRepertory"><Parameters><ParameterFrom="AvailabilityRequest"name="ItemID"location="ListItems/ListItem/ItemID"/></Parameters><Return>String</Return><ResponseMessage><to>AvailabilityResponse</to><Location>error</Location></ResponseMessage></App-transaction></App-Collaboration><Functions><Functionname="getRepertory"type="sa.class"urnid="urn:xbirep"><Parameters><Parametername="ItemID"type="String"></Parameter></Parameters><Return>int</Return><Type>responder</Type></Function></Functions></ApplicationCollaborationProfile>例2-9查询库存的工作流程在这个例子中，说明了调用应用程序的位置(属性url)、接收的请求(AvailabilityRequest)、处理此请求的方法(getRepertory)以及需要的参数，并在后面对getRepertory这个方法进行了描述(包含在元素Functions里)。3.注册库除了硬件厂商对词汇的定义和商业流程外，注册库里还保存了硬件厂商的资料和提供服务的信息，包括服务入口，需要的参数等等。

系统的运行下图是系统的运行流程图财务部门库存部门图2-3系统工作流程图系统经过六个步骤完成电脑零售商和硬件厂商的交易：硬件厂商将本企业资料，提供的Web服务，商业流程等提交给注册库，完成注册；电脑零售商从注册库下载“硬盘”的定义、订购流程的描述，找到服务入口，准备开始与硬件厂商通信；电脑零售商遵循硬件厂商的订购流程生成一定格式的硬盘订单，发送给对方。硬盘的订购由三个事务组成：查询硬盘价格、查询硬盘库存、递交订单；硬件厂商接收到订单后，数据集成模块完成此定单的解析，并按照OrderProcess.xml的描述控制交易的进行。根据OrderProcess.xml，首先找到整个流程的入口，也就是查询硬盘价格，因此它将该事务的请求交给应用集成模块。5．应用集成模块根据把查询硬盘价格的任务派发给财务部门，经过后台应用程序的数据操作，返回处理结果（以XML的格式）。应用集成模块将此结果整理后返回给上层。6．数据集成模块接着把第二个事务交给应用集成模块，经过类似5的处理，把库存部门的处理结果返回给数据集成模块。7．在完成了全部三个事务后，数据集成模块把最终结果交由安全模块进行签名和加密，并把加密后的结果传给电脑零售商。在这个例子里，电脑零售商需要知道的只是硬件厂商对“硬盘”的定义、订购的流程和服务入口，它不必知道要和硬件厂商的哪些部门打交道；而对于硬件厂商，内部应用的变动不会导致系统大的改动，它所要修改的只是一些关于应用程序url、调用方面和传递参数的配置，有很强的灵活性。XECI分析与比较XECI在很多方面采用XML相关技术，包括消息格式、数据格式、流程的描述等等，这也是近几年电子商务集成研究的一个趋势。然而，采用XML技术并不是XECI唯一的优点，XECI实现的是一个灵活的电子商务集成系统，它分层设计了交互协议，层与层之间提供接口，可以很好的结合在一起。其实，基于XML的电子商务集成已经不是什么新鲜的概念了，早在几年前,OASIS（结构化信息标准促进组织）和UN/CEFACT（联合国贸易辅助和电子商务中心）就已经开始了ebXML的研究，到现在已经吸引了众多大公司的注意，并且参与到标准的制定中来。这也是XECI在很多方面借鉴了ebXML标准的原因。但是，ebXML也绝非一个完美的标准，首先，ebXML是一项提议，其面向的范围是世界上每一家公司（这样说可以有些夸张，但在ebXML技术规范里确实是这样说得），这样就是的ebXML的规范非常复杂，很多规范甚至不适合某类行业的企业；第二，ebXML没有对企业应用集成做相应的规定，这是它的另一个不足。所以，我们在这里提出XECI并不是一项无意义的重复劳动，在XECI里，加入了应用集成的模块，弥补了ebXML的不足。而且XECI框架不复杂，对小企业来说可能是一个更好的选择。下面我们从系统的可扩展性、开放性、灵活性和可靠性几个方面分析XECI的特点，并和其它的系统或者框架进行比较。•可扩展性在经济全球化，信息传递速度加快的情况下，业务环境的变化也相应加快，这使得业务协作的规则处于一种经常性的改动中。这就要求电子商务系统具有良好的可扩展性，这种扩展性并不是指依靠对将来的预测而留下接口或空间，而是在变化发生时，只要付出最小的代价就可以适应变化。一般Web上的电子商务系统缺乏这种可扩展性，由于系统和后台负责数据操作的应用之间没有一个统一的接口，经常会因为后台数据库改变，或者交易步骤的更改而对程序进行大的修改。相信有Web系统开发经验的人都会有相似的经历。对XECI而言，有一个应用集成模块对企业内部的应用程序进行管理，如果企业内部应用发生了变化，比如增加了新的应用，或者参数改变，可以通过修改描述应用程序的xml文件而适应新的环境，程序本身不需要做大的改动；同样的，通过修改商业流程可以很容易的改变企业间的交互过程。这是基于xml的电子商务集成系统最吸引人的地方，Internet上的企业是多种多样的，要让这些企业接收一个系统，这个系统首先必须是实施起来很方便的。基于xml的电子商务系统比如ebXML和Biztalk都因此而占据了市场。开放性开放性也可以理解为互操作性。既然有相互间的数据交换和协作，就必然需要共同的语言，这种语言势必在一定范围内是开放的，比如同一行业内的开放性，业务伙伴间的开放性。实现开放性的方法是标准化工作，遵守相同的标准，实现互通于协作。这一点对于采用xml技术的XECI来说是勿庸置疑的，xml本身就是一种开放式的语言，采用xml作为企业间交互的数据格式，不需要进行数据转化就可以直接读取。XECI还提供了注册库，允许企业对外公布其对一些重要的而且有争议的词汇的定义，这样同行业的企业很容易达成统一。灵活性灵活性是指企业能通过Internet迅速与合作伙伴建立连接，快速的依靠信息交互技术实现业务往来。灵活性要求节省成本，像EDI那种需要架构专用网的系统价格过于昂贵，不适合Internet上的中小企业。一方面，XECI利用Internet的网络，通过Internet作为信息交换平台，避免了EDI在物理连接上的紧耦合性，有利于连接的快速建立。另一方面，前面我们也讲过，XECI不同于一般的C/S结构，它对企业内部应用进行集成，实现了企业各部门之间的协作。这一点是XECI与其它一些基于xml的集成系统，比如ebXML的不同之处。在对应用集成时，XECI用xml描述应用逻辑，并通过RPC调用应用程序，而不是分布对象技术，这是因为分布对象技术意味着在程序代码层次的连接，存在系统的兼容性、可维护性差的弱点。可靠性XECI建议采用xml签名和加密技术，一方面可以保证通信的安全，另一方面，也比较适合Internet的实际情况，即不易采用大型的安全认证体系，这样会使通信量过大，影响系统效率。本章小结在这一章里，我们详细的介绍了XECI系统及相关技术。XML作为一种结构化的数据表示方法，通过定义好的标记语言，避免了信息的丢失和处理上的困难。对新一代的Internet应用有着重要的意义。因此，我们提出了以XML作为数据的中间形式和工作对象的电子商务集成技术框架。XECI设计了分层的协议，并按功能划分为四个模块：底层通信模块、数据集成模块、应用集成模块和安全模块。本章对四个模块做了详细的分析，并通过一个实例介绍了四个模块的工作过程。最后是XECI系统的分析，以及和其它系统，特别是Web上的电子商务系统和ebXML做了几个方面的比较。第三章XDI的设计与实现前一章所讲的主要是XECI的系统框架和功能模块，具体的实施还需要有一个运作的平台，所以在这一章里我们主要介绍这样的一个系统平台一XDI。XDI系统设计XDI(XMLbasedDataIntegration)是按照XECI技术框架设计的一个系统原型，它为系统的实施设计了一套辅助开发工具和软件包。XDI主要考虑到了以下几个问题:•数据和消息的传输webservice的发布与查找企业内部任务的分配等等模型框架图1显示了XDI的系统框架。XDI由四个主要部分组成：通信层、文档解析层、企业应用层和注册服务层。通信层负责数据和消息的封装和传输，通信层位于整个框架的最底层，理论上它可以采用不同的协议，而且为了是系统更具有通用性，它也应该采用不同的协议，比如HTTP、FTP、SMTP等。在XDI中，通信层我们采用SOAP(simpleobjectaccessprotocol)协议，SOAP是一个轻量级的协议，SOAP以XML形式提供了一个简单、轻量的用于在分散或分布环境中交换结构化和类型化信息的机制。之所以采用SOAP协议，是因为SOAP可以与各种应用层协议，如HTTP、SMTP等结合，完成消息的传输。而且SOAP消息结构简单，但是又有一定的出错处理，比较适合传输结构化的数据，这与XDI的应用背景是相符的。目前有比较多的电子商务集成系统采用SOAP，比如ebxml、UDDI等等。

图3-1XDI框架文档解析层是XDI的核心层次，它的任务是解析、整合企业间传输的XDC(XDIDescriptiondoCument)文档，协调企业应用层的活动。XDC是XML格式的文档，它描述了商业过程中请求的内容和返回结果。在企业应用层里，针对不同的商业请求有不同的企业应用程序专门处理，可以按不同的部门分为财务应用、库存应用等。企业应用接收XML格式的请求，在将不同数据库的数据转换成XML文档格式后，作为结果返回。企业应用之间的合作由ApplicationIntegrationServer协调完成。除了上述三层，XDI还包含注册服务层。我们都知道，Internet上资源非常丰富，也正是由于这一点，给资源的查找带来了不便。如果有一个地方可以让各企业发布信息和服务内容，那么企业间就可以方便的交流了。注册服务层的作用正是这样，通过注册客户端，企业可以进行服务的发布与查找。注册中心作为一个可信的第三方存储和管理企业的信息。面几节将详细介绍文档解析层、企业应用层和注册服务层。文档解析层文档解析层之所以成为XDI的核心层次，是因为在XDI里，企业间传输的数据都要经过文档解析层的整合；并且文档解析层还控制着商业流程的完成。图3-2显示了文档解析层的内部结构，在文档解析层内部处理的是XDC文档，它用来描述商业请求和返回数据；Controller的任务是控制商业流程的执行。文档解析层的处理过程如下：首先，文档解析层接收SOAP格式的商业请求，把XDC文档从SOAP消息体中取出；然后，对XDC文档进行解析。不同的企业对商业请求有不同的处理流程,比如一次订单请求可能包括查询库存、查询价格、购买等几个事务，我们用XML文档描述每个商业流程。Controller从XML文档读入商业流程,按照商业流程将一次商业请求分成几个事务，交给企业应用层完成；企业应用层处理后返回XML文档，Controller根据商业流程，或者继续交给企业应用层处理，或者将结果整合成XDC格式，装入SOAP消息体,返回最后结果。图3-2文档解析层企业应用层企业应用层的主要任务是处理文档解析层发送过来的请求，最终结果以XML格式返回给文档解析层。在这一层里，AIS(ApplicationIntegrationServer)起到调度内部应用程序的作用。企业内部应用程序都必须在AIS里注册，受AIS统一支配，AIS管理一个应用程序目录，不同的上层请求由不同的应用程序处理。可以根据需要，增加或卸载企业内部应用程序。我们都知道，一个分布式的应用程序，或者各部门的应用程序可以运行在一台机器上，也可以运行在不同机器，不同平台上。比如，财务部门可以运行在UNIX上，数据库采用Oracle；库存部门可以运行在Windows平台上，数据库用SQLServer。那么在AIS与应用程序通信时就会遇到跨平台的情况。XML的平台无关性很好的解决了这一问题。在XDI中，应用程序作为HTTPServerApplication运行在后台；AIS通过应用程序的URL向其发送HTTP请求，请求内容为XML格式。应用程序接到请求进行后台操作，比如读数据库，或者调用其它Server程序；然后将结果整理成XML格式返回给AIS。注册服务层在这一层，XDI为企业提供了注册客户端。通过客户端，企业可以在注册中心发布企业信息和服务信息。注册中心是一个可信第三方，统一管理企业的资料。企业可以通过客户端提供的接口向注册中心发送请求，查询其它客户的信息。XDI按照UDDI(UniversalDescription,DiscoveryandIntegration)标准设计注册客户端和注册中心。通过UDDI注册，使得企业能够把自身的描述、服务描述以及服务访问方式的描述公开发布。已注册的企业能够被潜在的交易市场或采购商所搜索到，同时，对于合作伙伴之间集成也能更为动态和方便地实施。目前参与了UDDI的组织来自很多的行业，同时都是这些行业的核心力量，比如IBM、Microsoft和HP。XDCXDI使用XML作为数据传输格式，克服了Internet上不同平台、不同数据库系统间数据交换的困难。我们知道，不同企业间，系统与系统之间，往往因为平台不同，数据库不同造成信息流通的困难。而XML是一个平台无关的语言，以XML作为异构系统之间的交流媒介，不必担心看不懂对方的资料格式；而且，XML在数据存储和表示上是分开的，这样在交互过程中，我们可以把重点放在业务流程上。这就是XDI采用XML的原因。XDI提供了XDC(XDIDescriptiondoCument)对企业间传输的数据进行整合。XDC是XML格式的文档，有两种格式，分别是XDC:Request和XDC:Response。XDC:Request描述了企业的请求信息，XDC:Response描述了对请求的处理结果。下面我们通过一个例子来看XDI是如何通过XDC完成B2B商务集成的。假设有两个企业A(购买方)与B(销售方)，A要查询B的某件商品的价格，比如一本书《ComputerNetwork》。它首先使用注册客户端，查询B发布的服务信息，按照B公司的名字关键字，A可以查询到B提供的所有服务。经过查询，A得知要查询价格，需要向B发送getPrice的命令，命令参数为书名。然后A构造如下的查询请求：<?xmlversion="1.0"?><XDC><RequestRequestID="2a0d77ee-ed00-0000-0080-8a5f12f2f907"><head><RequestDesc>querythepriceof"ComputerNetwork"</RequestDesc><Requesterurl="">A</Requester><RequestTime>200206101735</RequestTime></head><RequestDetailname="getPrice"><RequestDetailDesc>querythepriceof"ComputerNetwork"</RequestDetailDesc><Parameterscount="1"><ParameterSeqNo="1"><Name>BookName</Name><DataType>String</DataType><Value>ComputerNetwork</Value></Parameter></Parameters></RequestDetail></Request></XDC>例3-1XDCRequest在上面的XDC文档中，属性RequestID唯一标示了A的请求，由程序自动生成。vXDC:Head>描述了请求的属性，包括简介、请求者信息、时间等。<描述了请求调用的命令，包括命令的简介、传递的参数等。A将查询请求封装在SOAP消息里，通过HTTP请求发送给B。B收到请求后，从SOAP消息里解析出XDC文档，然后由文档解析层的Controller按照查询价格的商业流程控制交易的进行。由于查询价格只有一个事务，因此它只需将此事务交给AIS。AIS根据其管理的应用程序目录，调用后台程序处理查询价格的事务。后台程序将处理结果以XML格式表示，结果如下：vResponse><Price>45.00¥v/Price></Response>AIS将结果返回给Controller，Controller将结果整合成XDC文档，内容如下：<?xmlversion="1.0"?><XDC><ResponseResponseID="f32c7fee-ed00-0000-0080-8a5f12f2f907"><head><ResponseDesc>thepriceof"ComputerNetwork"</Response><ResponseTime>200206101737</ResponseTime></head><body><ErrInfoErrCode="0"><ErrDesc>thereisnoerror</ErrDesc></ErrInfo><ResultsCount="1"><ResultSeqNo="1"><Name>Price</Name><DataType>String</DataType>vValue>45.00¥v/Value></Result></Results></body></Response></XDC>例3-2XDCResponse在<XDC:Response>文档中，属性ResponselD唯一标示了返回给B的处理结果，由程序自动生成。vXDC:Head>描述了返回结果的属性，包括简介、时间等。<XDC:Body>描述了结果的内容和出错信息，如果有错误，属性ErrCode将为“1”,XML元素vErrDesc>描述了错误信息；如果没有错误，ErrCode为“0”。<XDC:Result>为结果的内容。然后，Controller将XDC文档封装成SOAP消息，返回给B。XDI系统实现XDI由Java编写，Java有很强的可移植性，所谓“Writeonce，runeverywhere”，这对可能会使用不同平台和操作系统的企业是最好不过了。XDI在XML文档处理方面使用了一些已经非常成熟的Java类库，比如提供DOM类型接口的XMLParser类库；对于消息的传递和应用程序的调用，XDI采用的是SOAP协议和SOAPRPC(RemoteProcedureCall)。在注册库的实现上，XDI使用的是IBM公布的免费开发包UDDI4J。下面我们先看一下这些关键技术。3.2.1关键技术DOMXDI需要经常解析XML文档，因此XML的处理速度将会影响到系统的运行效率。DOM(DocumentObjectModel)是W3C制定并颁布的一套XMLParserAPI接口规范［16］，它与平台和语言是无关的，因而可以用各种语言在各种平台上实现。DOM定义了XML文件在内存中的逻辑结构(即为文档)，提供了访问、存取XML文件的方法。利用DOM规范，可以实现DOM文档和XML之间的相互转换，遍历、操作相应DOM文档的内容。DOM规范目前共有三层，其中Level1与Level2分别于1998年和2000年被正式确定为W3C推荐标准，Level3的标准正在指定中。DOM的每一层都是对前一层的扩充，例如Level2增加了Level1中没有的事件机制、文档抽象视(AbstractView)、对象树的遍历(Traversal)、文档中的块(Range)、风格页(GenericStylesheets)、层叠式风格页(CascadingStyleSheets)等，而Level3中对事件机制做了进一步的扩充和完善。DOM的中心思想是将一份XML文档以“树”的数据结构来表示，在处理XML文档时，DOM首先把文档读入内存，然后把文档表示为节点(Node)对象树［⑺口8】，节点对象不但表示了文档中的XML元素而且代表了在一个文档之内的其他所有内容，从最顶端的文档元素自身到单独的内容要素，比如属性、注释以及数据等等都包括在内。每一个节点都有其专门的接口，这些接口对应于节点所代表的XML内容，但这些接口其实在本质上也是节点。除了DOM，还有一个XML文档解析包一SAX(SimpleAPIforXML)。SAX也提供了一套XMLParserAPI接口，与DOM不同，SAX提供的访问模式是一种顺序模式［也，这是一种快速读写XML数据的方式。当使用SAX分析器对XML文档进行分析时，会触发一系列事件，并激活相应的事件处理函数，应用程序通过这些事件处理函数实现对XML文档的访问，因而SAX接口也被称作事件驱动接口。DOM和SAX各有优点和缺点，两者在很多方面(如时间性能、空间性能、接口复杂度、功能等)都存在互补的关系。DOM的思路自然而直观，易于理解便于编程。但另一方面，DOM运行速度较慢，解析整个文档时至少需要扫描整个文档两遍，当处理大型文档时对于内存的开销也很大。与DOM相比，虽然SAX的事件驱动模型不如DOM的树状模型直观自然，但SAX显得更“轻便”运行更快，对资源的要求较低。XDI采用DOM是出于两方面的考虑：一方面，对XML的树形结构表示很容易理解，处理起来也比较方便；另一方面，由于目前XDI处理的文档都不大,因此使用DOM速度会比较快。XDI使用的DOM是由A开发并免费下载的Xerces，Xerces提供了一套完整的类库，非常适合学习和研究使用。SOAP与RPCSOAP[20][21]（SimpleObjectAccessProtoco1）以XML形式提供了一个简单、轻量的用于在分散或分布环境中交换结构化和类型化信息的机制。SOAP本身并没有定义任何应用程序语义，如编程模型或特定语义的实现；实际上它通过提供一个有标准组件的包模型和在模块中编码数据的机制，定义了一个简单的表示应用程序语义的机制。这使SOAP能够被用于从消息传递到RPC的各种系统。SOAP包括三个部分SOAP封装结构定义了一个整体框架用来表示消息中包含什么内容，谁来处理这些内容以及这些内容是可选的或是必需的。SOAP编码规则定义了用以交换应用程序定义的数据类型的实例的一系列机制。SOAPRPC表示定义了一个用来表示远程过程调用和应答的协定。这三个部分在功能上是相交的，特别的，封装和编码规则是在不同的名域中定义的，这种模块性的定义方法增加了简单性。SOAP主要是提供了一套编码规则，