毕业设计外文资料翻译-用于XML处理的Java的性能分析

毕业设计外文资料翻译学院：专业班级：学生姓名：学号：指导教师：外文出处：(外文)BrunoTrevizanDeOliveira.ISBN:978-0-9853483-3-52013SDIWC附件：1.外文资料翻译译文；2.外文原文指导教师评语：该同学的英文专业资料术语翻译较准确，体现了一定的专业英语水平。翻译材料能与原文保持一致，能正确表达出原文意思。翻译字、词数满足要求。翻译材料语句较通顺，翻译材料的格式符合要求。该同学较好的完成了外文文献翻译工作。签名：2015年10月14日

外文资料翻译译文用于XML处理的Java的性能分析BrunoOliveira

1引言可扩展标记语言（可扩展标记语言）由于其结构简单，在许多应用中被广泛用于数据表示，因此可用于保证数据的可移植性。数据交换系统之间的异构性高，便于信息的交流和共享，它是平台独立的，这使得它的多数应用中很有吸引力美国与XML格式有其他语言补充这种格式的应用领域，如XSD，XSLT或XQuery。目前，XML格式用于几种发展软件类型，包括网页、Web服务、网络应用，完全基于XML的数据库访问和修改操作，一旦影响到XML文件的操作是必不可少的于任何增加的数据量，通过这些操作的复杂性，并在较短的时间内需要处理的。再加上这不断增长的数据，XML文档可以达到大数R兆（甚至千兆字节），限制和调节用于处理XML数据的应用有吸引力的开发技术。还加上了可移植性的概念编程语言提供了一组允许的操作的结构化文档的接口，根据该格式。由于其便携性，Java和XML中常用的应用发展。本论文的主要研究重点是对应用编程语言进行语言处理的各种分析模型和API（应用编程接口）进行了研究，并对其进行了分析和研究提供刷新基准可用表示模型，确定哪些是最适合的访问和大型XML文档的转换。我们也将主要优势识别IED的每个表示模型，始终保持性能因素考虑。下一节（2）检查一些内存和流表示模型，识别文档如何处理根据每一个分析模型。3节和4的API，有些回忆的API和功能流。第5节比较内存为基础的API的性能和内存消耗下一步，在6节中，我们比较了先前研究的最佳API的改性效果，终止了该论文的7节。2内存和流表示模型由于它的复杂性和重要性，分析过程是最关键的操作，在XML处理，直接处理时间和内存消耗。一些研究[有蜜蜂用目标来测试和改进表示模型和API的处理。然而，有些人并没有把重点放在Java编程和其他人是过时的。这是主要由各种更新和执行环境的改善造成的，特别是在Java虚拟机的影响，我们知道，在操作运行和有效性。在处理XML文档的过程分四个阶段进行阐述：分析被认为是在性能上，迈出了关键的一步，访问、修改和系列化，其性能是方向通过解析模型直接影响。作为性能最关键的因素，分析其角色的转换，在转换成字符格式，主要涉及不是一种编程语言理解，词法分析，这是一个过程，识别XML元素，例如开始节点，结束节点或字符，应用世界范围内定义的正则表达式B联盟（W3C）。分析阶段的最后一步是对文档进行语法分析，如果文档符合一个XML文档的构造规则，就要检查它，在分析过程中，该接口实现了对数据的访问和修改操作。2.1基于内存的表示模型大多数基于内存的API在数据处理中使用一个通用的模型，其中的XML文档完全以树的形式存储在多个节点上，从一个单一的节点上降下树的根。这种模式允许使用不同的方法来定位和操作包含在节点中的数据。对于每一个搜索，或者其他类型的操作，它是必要的由根元素继续在结构层次结构中的处理，以访问剩余的数据（图1）。由于所有的信息都在内存中可用，我们可以在运行时遍历图1.内存树表示的例子树DOM的秩序，改变节点的定位在一个非常简单和容易的方法执行数据转换。考虑到其存储结构表示，这些API，方便应用发展，提供一个广泛的搜索方法，让您可以轻松地执行树的组成节点上的操作，然而，内存为基础的蜜蜂消耗，平均四至五时间比文件大小更大。例如，一个20MB的文件的需求，根据不同的表示模型，为约100兆字节是存储在内存中，这可能是处理大文件的问题。2.2流媒体模式基于流媒体的应用程序使用最少的内存资源对文档进行顺序扫描，通常，这种类型的API使用了XML文档的深度（嵌套元素的数目）和最大在XML元素中存储的数据。这两个都是比内存为基础的分析树方法的大小总是小于。然后，文档的一小部分提取序列uentially不需要加载整个文档的结构。通常，解析器读取XML文档，它将调用一个特定的方法来处理它的对象。图2介绍了ESAX（XML处理简单的API）的XML处理模型，这是类似于其他的基于流的API。图2.SAX解析模型该分析器被配置为输入源，它与一组确定的内容管理方法相关联，例如，该文件的开头或结束，以及数据的元素可能包含在分析步骤期间发生的错误。程序运行时，通过内容管理方法捕获的事件triggersare。每次解析器检测XML的重要组成部分外触发以适当的方法读取相应的数据块。基于流媒体的API更适合处理大数据文件，因为，在理论上，他们可以处理无限大小的文件。3基于记忆的API为了得到一个基于内存的XML处理的API的概述，我们进行了一项具体的研究，以确定哪些API更有效的内存管理，这是更快的惯性导航与制导我们涵盖了以下的API：DOM，XOM，ojxqi，VTD，JDOM，DOM4J和Xerces2，包括在JAXP包，DOMAPI是一个类的集合，一组Java方法，内存中的XML处理允许一个结构类似图1。在一些情况下，DOMAPI的基础是新的API构建，修改它的一些特征，服务于特定目的的要求。例如，JDOMAPI允许JavaXML文档的操作通过一个树结构表示，因此类似于DOM。然而，这个应用程序已经开发了专门为Java语言，使它亩更直观的一个典型的Java程序员。例如，没有文本类，因为Java编程语言提供它自己的类（字符串类）。JDOM利用Java功能苏用相同的名称、反射、弱引用和使用集合，如列表和迭代器的方法创建方法。JDOMAPI不同于DOMAPI使用类而不是国米面，简化了API，但限制了灵活性。对于他的部分，dom4j是一个开源的基于DOM、JDOMAPI的概念，使用接口和抽象类的方法，具有广泛的U集合类的硒。dom4j是比JDOM更完整的解决方案，更加重了接口的使用，增加了一点复杂性增加成本更大的灵活性。受DOM和JDOM，XOMAPI被设计为是最好的两个世界。在哈罗德的演讲，XOM归类为一个易于使用的API，快速和简单的。公司利用现有的Java一个机制（如JDOM），揭示了一个更受限制的API，不允许畸形文件创建，迫使验证通过继承。在这样的一些缺点概述ESJDOM的提出，即认为这不因为有几种方式完成相同的任务（一个喜欢读书的孩子元），由于在Java的使用一些空白约定（如设置方法不总是返回空白）。另一个缺点是，指的是使用对象表示的文档的元素，产生小的内存开销。在此外，还提供了比较与使用接口而不是导致更复杂的API类dom4j。简要的介绍，我们可以说，dom4j是一个API基于DOM（和扩展），一个DXOMAPI以简化XML处理的主要目标对DOM的原则。JDOMdom4j和XOM已被专门开发的Java语言的优势，不像其他R的API（如DOM），这是在多种编程语言通用开发。XQuery是从XML文档中提取数据，允许一个高级代码创作中提取数据的一种语言，类似于关系数据库的SQL语言发生了什么。T他的语言的需要，应该把XQuery语言产生命令的API的原生支持。ojxqi（OracleJavaXQueryAPI）是一个API提出的Oracle这是纳入在XQuery语言支持库，简化了XML转换通过一个简单的语言的使用，这是非常相似的建筑语言。Oracle支持XQuery两个不同的层次：数据库和中间层。第一个应用于数据库环境和源二运行查询，而不是数据库。因此，它是可以编译的几个条款允许XQuery执行，从而导致一系列新的结果。数据从ojxqiAPI是完全在内存处理，允许为DOM对象的创作表现新台币的数据。最后，分析了API，表示一个对象树结构的XML数据，命名为Xerces2，包括一套解析器使用DOM和SAX的数据模型。我们测试的DOM实现，自然遵循相同的准则，作为先前的API的架构。另一方面，VTD（虚拟令牌描述符）API使用不同的方法，有前提对象的创建是低性能的主要因素。VTDAPI实现了基于整数数组结构来表示数据在内存中创建对象，消除我的成本NG的提取过程中，通过对64位整数数组的使用（VTD记录）。VTD是二进制格式，指定如何分配令牌（识别码）在非萃取法。概念解析“萃取”意味着XML文本保持完整的记忆而令牌代表独家使用范围和大小的位（字符串的内容不复制）。过程与其他提取的XML处理模型进行对比的方法（如DOM和SAX），分配内存块的文档内容分配，直接操纵数据。此操作只能在分析过程完成之后才能进行，将文档大小作为数据访问性能的最大瓶颈。4基于流的API基于流媒体的不保存在内存中的文件的长期结构。这种类型的API读取数据作为一系列代表他们中的一种形式，对象的事件（如DOMAPI），使用一个小的内存中的一部分，以顺序处理文档。对象是与不同类型的事件相关联的，并且在内存中不保持太长，而不像基于内存的方法美国的JSR（Java规范请求）173定义了StreamingAPIforXML（StAX），允许在流模式的要素分析，并提取信息通过应用控制事件（拉模式），不同于SAXAPIJAXP的包，有一个经理，以事件作为解析器方便（推模型）。而StAXAPI允许你丢弃信息文件中的恰当的解析（调用nextevent法），SAX解析器提取所有元素即使你不需要他们。此外，StAX有两个不同的抽象层次的API集成：诅咒的API，这是一个较低的—级应用程序，专注于效率和简单的使用，这相当于一系列的事件，和基于迭代器的API，提供了一个更高层次的抽象允许流水线，并代表通过对象的事件。这个实现允许程序员问（peek()法）没有阅读活动。这是可能的，跳过的光标和事件的方法的输入。在这研究我们测试了被诅咒的API，因为这是最有效的方式来读取数据XML。此外，我们还测试了SAX和StAXAPI允许nodefactoryXOMimplementation.nodefactory解析XML文档作为流像SAX和StAX。SAX，StAX和XOM（流模式的实现）在解析过程完成后，允许访问数据。此功能允许内存消耗由于处理过的数据，而不再需要，可能会释放内存，从而保持内存的使用率低作为分析过程所得。表1总结了之前的所有API。表1.API分析汇总APIParsingModelJAXP:SaxStreamingevents:pushmodel.JAXP:StAXStreamingevents:pullmodel.JAXP:DOMMemory:treeobject.XOMMemory:treeobject.OJXQIMemory:treeobject.jDOMMemory:treeobject.dom4jMemory:treeobject.Xerces2Memory:treeobject.VTDMemory:arrayofintegers.为了测试每个接口的内存使用率和执行时间，我们使用了2个不同的文档的家庭：1）一个代表某个公司的销售订单（salesorderdetail），这是从微软的数据仓库的样品：冒险作品；2）其他的xmlgen工具旨在表现关于招标网站的信息产生的，从一个电子商务的典型应用。5API的性能分析表2介绍了文件的大小和用于每个API测试的性能。我们用大小不同的三个实例为每个文档类型，为了测试不仅规模在MEM理论表示，而且所用的时间分析每个文档。5.1基于内存的API研究包括在兆的内存消耗量（MB）-（图3），和执行时间在毫秒（ms）–（图4）所使用的每一个的基于内存的API。表2.用于测试的文档结果是基于一个算术平均数，导致从五个执行的每个文件（不考虑第一次执行的时间）的每个文件。结果表明在相对增益VTD与其他基于内存的API，无论是在内存使用方面或在运行时，说明VTD表示模型的数据比其他API表示优越得多。图3.在兆字节的存储器接口的内存消耗图4.基于内存的API的执行时间随着车辆外，没有其他的memorybasedAPI可以进行解析的最大文件与内存Java虚拟机的数量（SalesOrderDetail3-greenbarandAuctionWebSite3–orangebar）。值得注意的是，在解析DOM性能良好的时间与其他基于内存的API。虽然内存中的DOM文档的表达高于XOM和ojxqi表示。当大的XML文件，基于内存的方法是不可行的，由于固有的内存限制。5.2基于流媒体的API一旦基流减少内存消耗API，不代表在处理方面的一个关键点，我们只测试解析速度在毫秒每个API：SAX，StAX（被认为是T他基于指针的API）和埃克森美孚（流方法）（图5）为每个文件前面介绍的。图5.解析从API毫秒时间的流SAX和StAX的时间消耗是非常相似的，这是很容易预料的，因为主要的一点区别这两个API是解析器如何处理的事件进行处理。考虑到整个电子文档，结果是非常相似的，不过与拥有比其他流的API更低的性能。5.3两种API的比较分析在大多数情况下，内存为基础的API被广泛的应用，在大多数情况下，被处理的文件是足够小，以适应内存。然而，在内存可用性是有限的情况下，或大小在可处理的XML文件中，最适合的是基于流的API。项目的要求是最关键的，以确定最合适的API的类型。需要申请文件新的API的选择也是相当大的因素，一旦基于内存的API更适合这种类型的操作，而基于API是用于正向应用流阳离子。为了测试API文档转换性能考虑以下APIsalesorderdetail文件：SAX，StAX和VTD。为每个API开发了两个操作：−选择：手术选择的一组元素基于给定谓词，代表了唯一的数据访问。−差异：手术移除从第一个文档的所有元素，同第二文件，代表一个随机存取数据。选择操作，基于谓词，选择所有元素SalesOrderID已经价值43659，产生一个新的文件。如果一个元素，立即下面的差异操作检查他根文档节点，存在于一个文件，因此无论它和保持它如果他不存在，如果文件。差异的操作我们认为一个salesorderdetail观点为了产生一个空文件，所以我们可以广泛使用的算法和漠视的结果文件的大小，因为它会是空的。然而，VTD消耗大量内存。内存消耗可以为环境提供有限的能力的一个瓶颈。我们用一个新文件：2.9megabytsalesorderdetail0为了减少测试的执行时间。考虑到选择操作，StAX稍快，内存消耗低的优势相比，VTD。这增加了记忆我们年龄发生主要是由于重建整个结构的文件在内存中，这也意味着一个更高的执行时间的成本。只有在正确的表示的文件在内存中处理阶段开始。基于流的API没有这个过程，立即开始转变，获得更快的结果和更少的计算资源。对于差异化操作，基于内存的API比基于流媒体的更快。差分运算要求对每个元素进行一个验证过程，使用多个合作mparisons为了验证它是否存在文件。流的API需要执行大量的I/O（输入/输出）操作，因为它的每一个元素可能PR屁股整个文档（在最坏的情况）。在基于内存的API的情况下，因为这两个文件都充分代表在内存中，比较不必做任何我/输出，从而减少执行时间。由于不内存的限制，如果我们需要在同一时间的几个文件的工作，他们的大小更为限制，因为他们都需要在内存中进行处理。它也被发现，第一次运行的操作是慢于随后的运行。因此，我们进行了一项研究（表5）与Stax和VTD文件选择操作：定货讲解1下，为了salesorderdetail2和salesorderdetail3评价第一次运行的影响。第一次运行的影响，对车辆的重视，和执行速度大大增加的大小文件的增加，影响StAX和VTD之间的运行速度。表5.选择操作的时间以毫秒为单位（毫秒）6改性在API分析中出现的一个重要特征是，可以处理一个文档的元素，即插入、删除或更新信息。基于流的API是不足够的这种操作，因为他们在一个连续的过程文件，其中复杂的操作的实现没有明显的利益由于转换也不够完善但通过在文档元素的阶。在这种情况下，有必要执行多个输入/输出操作。基于内存的API，我们测试了DOM和VTD，主要是因为几乎所有其他API测试是基于DOM的模型以及它们之间的性能差异很不相关。汽车行驶记录仪的使用的更少的内存比DOM和执行文件在更少的时间分析。在DOM对象创建成本API是不同性能的主要因素。VTD免疫成本由于其我内在的表征结构。然而，操纵DOM树结构允许一个相当平凡的操作数据，由于添加或删除一个节点的树是由一个操纵P做的ointers节点之间。另一方面，微软需要重建VTD记录处理下次更新。我们建立了一个测试场景改变的拍卖网站文件的内容。的结构这样的文件包括以下要素：地区、类别、catgraph，人，open_auctions，和closed_auctions。这些元素中的每一个包含一组与信息有关的信息拍卖网站。试验更改数据，包括三个步骤：1）添加一个元素未知内容的nationalidnumber；2）重命名信用卡元CC；和改变每个人的性别元素含量，3）用以取代男性为男，女为F。在这两个接口，文件被加载到内存和扫描，以滚动的内容，每个人，在同一时间进行修改。执行所有转换后，文件写入到文件分别使用DOM变压器类和VTDxmlmodifier类。性能分析检测API四小的拍卖网站文件。每份文件以下几个人含：−auctionwebsite1–2550人−auctionwebsite2–7649人−auctionwebsite3–12750人−auctionwebsite4–20400人表6.每一个API的毫秒执行时间在表6中，我们可以看到每一个处理的文件的测试结果。请注意，对于大文件，我们必须增加虚拟机内存可用以处理它们。结果显示出明显的优势VTD数据插入和更新。在这种情况下，DOM对象的操作与使用VTD整数结构数组中没有优势。7结论结构化文档在不同类型领域的应用具有广泛的应用。在许多情况下，它是必要的过程文件的一个相当大的规模，在运行时是相关的和执行窗口显然是有限的。正如我们所看到的，有两种类型的XMLAPI：记忆API和基于流的API。存储器的XMLAPI保持长期生活在记忆的结构数据Y只有解析过程完成后的修改是允许的，而基于API的使用小内存流，内存的分配和释放不断，允许无限的过程有限大小的XML文件（在理论上）。一般而言，XML处理，dom4j，和DOM都是不错的选择，与他们之间的偏好Java特定特征或跨语言的兼容性决定的，取决于项目的要求。虽然XML转换不灵活，ojxqi是一个很好的选择当你需要性能良好的标准的修改。整数结构VTD数组被证明是最好的模式几乎所有的测试中。这是一个模型，消耗更少的内存（相比其他基于内存的API），处理时间是非常快的，即使他们的更新文件的能力，保持其STR结构在内存中，证明了是相对于其他基于内存的API远远优于（测试场景）。骨化醇的使用相比其他基于内存的API，API是比较复杂的，它是N建立主导API具有额外的努力。基于StAXAPI流，已被证明是具有更好的整体性能相比SAX和XOMAPI。这种API在内存中不保持长期的结构数据，所以没有在使用这种类型的接口的优点，当您需要执行一组的转换，在某种程度上改变的顺序的元素在XML层次。通常情况下，这种类型的API只用于为只是简单的修改了应用程序或使用XSLT语言。基于内存的API在内存中保持整个文档的结构，但是，在一些开销，但是，对于某些更新的文件结构，这种类型的API导致一些广告在基于流的API，因为这些需要执行增加I/O操作做相同的变化特点。使用基于内存的接口来操作一个文档是更方便和快捷的，由于基于流媒体的应用，我们需要经常使用临时缓冲区来保存内存中的信息。总之，我们可以得出这样的结论：选择从2种方法研究处理文件主要取决于项目的要求。2.外文原文PERFORMANCEANALYSISOFJAVAAPISFORXMLPROCESSINGBrunoOliveira1.INTRODUCTIONDuetothesimplicityofitshierarchicalstructure,XML(ExtensibleMarkupLanguage)iswidelyusedfordatarepresentationinmanyapplications.Asaresultofitsportability,XMLisusedtoensuredatainterchangingamongsystemswithhighheterogeneousnatures,facilitatingdatacommunicationandsharing,it’splatformindependent,whichmakesitquiteattractiveforthemajorityofapplications.AssociatedwiththeXMLformatthereareotherlanguagesthatcomplementtheapplicationareaofthisformat,suchasXSD,XSLTorXQuery.Currently,XMLformatisusedinthedevelopmentofseveraltypesofsoftware,includingwebpages,webservices,networkapplications,andfullybasedXMLdatabases.AccessandmodificationoperationsareessentialtoXMLfilesmanipulationoncetheyareaffectedbyanyincreasingamountofdata,bythecomplexityofthoseoperations,andbyshorterperiodsoftimeneededtoprocessthem.Coupledwiththisdatagrowing,XMLdocumentscanreachlargenumberofmegabytes(orevengigabytes),limitingandconditioningthetechnologyusedfordevelopmentofapplicationsappealingforXMLdataprocessing.Alsocoupledwiththeconceptofportability,JavaprogramminglanguageprovidesasetofinterfacesallowingforthemanipulationofstructureddocumentsaccordingtotheXMLformat.Duetotheirportability,JavaandXMLarecommonlyusedinapplicationdevelopment.ThemainfocusofthispaperwastoconductastudyofthevariousparsingmodelsandAPIs(ApplicationProgrammingInterface)forXMLprocessingusingJavaprogramminglanguage,withthepurposetosupplyarefreshbenchmarktotheavailablerepresentationmodels,identifyingwhichisthemostsuitableforaccessandtransformationoflargeXMLdocuments.Wealsoreferthemainadvantagesidentifiedforeachrepresentationmodel,alwayskeepingtheperformancefactorinmind.Thenextsection(2)examinessomememoryandstreamingrepresentationmodels,identifyinghowdocumentsareprocessedaccordingtoeachparsingmodel.Section3and4presentsomememory-basedAPIsandstreaming-basedAPIsandtheirfeatures.Section5comparesperformanceandmemoryconsumptionofmemory-basedAPIsandstreaming-basedAPIs.Next,insection6,wecomparemodificationperformanceofthebestAPIsstudiedpreviously,terminatingthepapersummarizingresultsinsection7.2.MEMORYandSTREAMINGREPRESENTATIONMODELSDuetoitscomplexityandimportance,theparsingprocessisthemostcriticaloperationinXMLprocessing,directlyconditioningprocessingtimeandmemoryconsumption.Severalstudies[1–6]havebeenconductedwiththegoaltotestandimproverepresentationmodelsandAPIsinXMLprocessing[7].However,someofthemdidnotfocusitscontextonJavaprogrammingandothersareoutdated.Thisismainlycausedbymiscellaneousupdatesandimprovementsintheexecutionenvironment,particularlyintheJavaVirtualMachine,whichaffects,asweknow,runtimeandeffectivenessoftheoperations.In[8]theprocessofhandlingXMLdocumentswasdescribedinfourphases:Parsingthatisconsideredacriticalstepinperformance,Access,ModificationandSerialization,whoseperformanceisdirectlyaffectedbytheparsingmodels.Asthemostcriticalfactorofperformance,parsingischaracterizedbytheconversionofcharacters,mainlyrelatedtotheconversionofcharactersintoaformatthataprogramminglanguageunderstands,lexicalanalysiswhichistheprocessthatidentifiesXMLelements,e.g.Startnode,endnodeorcharacters,applyingregularexpressionsdefinedbyWorldWideWebConsortium(W3C).Thelaststepoftheparsingphaseisthesyntacticanalysisofthedocument,whereitischeckedifthedocumentcomplieswiththerulesofconstructionofanXMLdocument.Finally,theAPIimplementsaccessandmodificationoperationsonthedataresultedfromtheparsingprocess.2.1Memory-basedrepresentationmodelsMostmemory-basedAPIsuseacommonmodelindataprocessing,whereXMLdocumentsareentirelystoredinmemoryinatreeformatwithmultiplenodes,descendingallfromasinglenoderepresentingtherootofthetree.Thiskindofschemaallowstheuseofdifferentmethodstolocateandmanipulatedatacontainedinsidethenodes.Foreachsearch,orotherkindofmanipulation,itisnecessarytostarttheprocessingbytherootelementcontinuinginthestructurehierarchytoaccesstheremainingdata(figure1).Sincealltheinformationisavailableinmemory,wecanFigure1.ExampleofaXMLmemorytreerepresentationtraversethetreeinrandomorder,changingthepositioningofthenodesandperformingdatatransformationsinaverysimpleandaccessibleway.Consideringitsmemorystructurerepresentation,theseAPIsfacilitateapplicationdevelopment,providingawiderangeofsearchmethodsthatallowyoutoeasilyperformoperationsontheconstituentnodesofthetree.Howevermemory-basedAPIsconsume,inaverage,fourtofivetimesmorememorythanthedocument’ssize.Forexample,a20megabytesdocumentneeds,dependingontherepresentationmodel,approximately100megabytesinordertobestoredinmemory,whichmayrepresentaprobleminprocessinglargedocuments.2.2Streaming-basedmodelsStreaming-basedAPIsperformasequentialscanofthedocumentusingminimummemoryresources.Typically,thistypeofAPIsusethedepthoftheXMLdocument(numberofnestedelements)andthemaximumdatastoredinXMLattributesonasingleXMLelement.Bothofthesearealwayssmallerthanthesizeofthememory-basedparsingtreeapproach.Then,asmallportionofthedocumentisextractedsequentiallywithouttheneedtoloadthewholedocumentstructure.Usually,theparserreadstheXMLdocumentcallingaspecificmethodforeachtypeofeventtoprocessitsobject.Figure2presentstheSAX(SimpleAPIforXMLProcessing)conceptualmodelforXMLprocessing,whichissimilartootherstreaming-basedAPIs.Figure2.SAXparsingmodelTheparserisconfiguredasaninputsource,whichisassociatedwithasetofcontentmanagementmethodsthatidentify,forexample,thebeginningortheendofthedocumentandelementsofdatathatmightcontainerrorsthatoccurredduringtheparsingstep.Whentheparserruns,eventtriggersarecapturedbycontentmanagementmethods.EachtimetheparserdetectsanimportantpartoftheXMLdocumentittriggerstheappropriatemethodinordertoreadtherespectivedatablock.Streaming-basedAPIsaremoresuitableforprocessinglargeXMLdocuments,because,intheory,theycanprocessdocumentsofinfinitesize.3.MEMORY-BASEDAPISInordertogetamemory-basedAPIoverviewforXMLprocessinginJava,weconductedaspecificstudytodeterminewhichAPIsaremoreefficientinmemorymanagementandwhichisfasterinXMLprocessing.WecoveredthefollowingAPIs:DOM,XOM,OJXQI,VTD,JDOM,dom4jandXerces2,IncludedinJAXPpackage,DOMAPIisacollectionofclassesthathasasetofJavamethodsthatallowsXMLprocessinginmemorywithastructuresimilartofigure1.Inseveralcases,theDOMAPIisthebasisfortheconstructionofnewAPIsthatrevisesomeofitscharacteristics,withtheaimofservingspecificrequirements.Forinstance,theJDOMAPIallowsthemanipulationofXMLdocumentswithJavaviaatreestructurerepresentation,thusbeingsimilartoDOM.However,thisAPIhasbeendevelopedspecificallyforJavalanguage,makingitmuchmoreintuitiveforatypicalJavaprogrammer.Forexample,thereisnoTextclass[9],sinceJavaprogramminglanguageprovidesitsownclass(Stringclass).JDOMtakesadvantageofJavafeaturessuchas:creatingmethodswiththesamename,reflection,weakreferences,andtheuseofcollectionssuchasListandIterator[10].JDOMAPIdiffersfromDOMAPIintheuseofclassesinsteadofinterfaces,simplifyingtheAPIbutlimitingflexibility.Forhispart,thedom4jisanopen-sourceAPIbasedonDOMandJDOMconcepts,usinganinterfaceandabstractbaseclassapproach,withextensiveuseoftheCollectionclasses.dom4jisamorecompletesolutionthanJDOM,whichgivesmoreemphasistotheuseoftheinterfaces,addingmoreflexibilityatthecostofalittleaddedcomplexity[11,12].InspiredbyDOMandJDOM,theXOMAPIwasdesignedtobethebestofbothworlds.InHarold’spresentation[13],XOMisclassifiedasaneasytouseAPI,fastandsimple.XOMmakesuseofexistingJavamechanisms(likeJDOM),revealingafarmorerestrictedAPIthatdoesnotallowcreationofmalformeddocuments,forcingvalidationsthroughtheuseofinheritance.InsuchoverviewsomedisadvantagesofJDOMwerepresented,namelytheonethatconsidersitinconsistentsincethereareseveralwaystoaccomplishthesametasks(likereadingachildelement)andduetosomegapsintheuseofJavaconvention(e.g.setmethodsnotalwaysreturnvoid).Anotherdisadvantagelisted,referstoelementsofanXMLdocumentthatarerepresentedusingobjects,whichproducessmallmemoryoverheads.Inaddition,acomparisonisalsoprovidedwiththedom4jthatusesinterfacesinsteadofclassesresultinginamorecomplexAPI.Briefly,wecansaythatdom4jisanAPIbasedonDOM(andextended),andtheXOMAPIbasedontheprinciplesofDOMwiththemaingoalofsimplifyingXMLprocessing.JDOM,dom4jandXOMhavetheadvantageofbeingspecificallydevelopedfortheJavalanguage,unlikeotherAPIs(likeDOM),whichweredevelopedinagenericwayforseveralprogramminglanguages[11].XQueryisalanguageforextractingdatafromanXMLdocumentthatallowsthecreationofahighlevelcodeforextractionofdata,similartowhathappenswithSQLlanguageforrelationaldatabases.ThislanguagewillrequirenativesupportfromtheAPIthatshouldinterpretcommandsproducedfromXQuerylanguage.OJXQI(OracleJavaXQueryAPI)isanAPIproposedbyOraclewhichisincorporatedintoitsdatabasewithsupportforXQuerylanguage,simplifyingXMLtransformationsthroughtheuseofasimplelanguage,whichisverysimilarinconstructiontoSQLlanguage.OraclesupportsXQueryintwodifferentlevels:databaseandmidtier.Thefirstoneappliesqueriesinthedatabaseenvironmentandthesecondonerunqueriesonsources,whicharenotdatabases.Thus,itispossibletocompileseveralclausesallowingXQueryexecution,andconsequentlyleadtoanewsetofresults.DatafromOJXQIAPIisentirelyprocessedinmemory,allowingthecreationofDOMobjectsinordertorepresentthedata.ThelastAPIthatwasanalyzed,representingXMLdatainanobjecttreestructure,isnamedXerces2,andconsistsinasetofparsersthatuseDOMandSAXdatamodels.WetestedtheDOMimplementation,whichnaturallyfollowsthesameguidelinesintermsofarchitectureasthepreviousAPIspresented.Ontheotherhand,VTD(VirtualTokenDescriptor)APIusesadifferentapproach,havingthepremisethatthecreationofobjectsisthemainfactoroflowperformance.VTDAPIimplementsarraysofintegersbasedstructuretorepresentdatainmemory,eliminatingthecostofobjectcreationresultingfromtheextractionprocess,throughtheuseofarraysof64-bitintegers(VTDrecords).VTDisabinaryformatthatspecifieshowtoassigntokens(identificationcodes)inanon-extractivemethod.Theconceptofparsing"non-extractively"[14]meansthatXMLtextremainsintactinmemorywhilethetokensarerepresentedexclusivelybyusingrangesandsizesinbits(thecontentsofthestringisnotcopied)[8].TheprocesscontrastswiththemethodusedbyotherextractiveXMLprocessingmodels(suchasDOMandSAX),whichallocateblocksofmemoryfordocumentcontentsallocation,manipulatingdatadirectly.ThismanipulationcanonlybeperformedaftertheparsingprocesshasfinishedwithdocumentsizeasthelargestbottleneckinXMLdataaccessperformance.4.STREAMING-BASEDAPISStreaming-basedAPIsdonotmaintainlong-livedstructuresofdocumentsinmemory.ThistypeofAPIsreaddataasaseriesofeventsrepresentingtheminaformofobjects(likeDOMAPI),usingasmallportionofmemorytoprocessthedocumentinasequentialway.Objectsareassociatedwithdifferenttypesofeventsandarenotmaintainedtoolonginmemoryunliketheapproachofmemory-basedAPIs.TheJSR(JavaSpecificationRequest)173definesStreamingAPIforXML(StAX),thatallowparsingelementsinstreamingmode,andtheextractionofinformationthrougheventscontrolledbytheapplication(pullmodel),differingfromSAXAPIofJAXPpackage,thathasamanagerthattakeseventsasconvenienceoftheparser(pushmodel).WhileStAXAPIallowsyoutodiscardinformationinthedocument’sparsingasappropriate(invokingthenextEventmethod),SAXparserextractsallelementsevenifyoudon’tneedthem.Inaddition,StAXhastwointegratedAPIswithdifferentlevelsofabstraction:thecursed-basedAPI,whichisalower-levelAPI,focusedonefficiencyandsimplicityofuse,thatworkslikeastreamofevents,andtheiteratorbasedAPIthatoffersahigherlevelofabstractionallowingpipelining,andrepresentingtheeventsthroughobjects.Thisimplementationallowstheprogrammertoask(peek()method)withoutreadingtheevent.ItispossibletoskiptheinputofboththeCursorandEventapproaches.Inthisstudywetestedcursed-basedAPIbecauseisthemostefficientwaytoreadXMLdata[15].InadditiontoSAXandStAX,wealsotestedXOMAPIwithNodeFactoryimplementation.NodeFactoryallowsparsingtheXMLdocumentasStreaminglikeSAXandStAX.SAX,StAXandXOM(streamingmodeimplementation)allowaccesstodatabeforetheparsingprocessiscompleted.Thisfeatureallowsmemoryconsumptiontoremainlowbecauseprocesseddata,andnolongerinneed,mightbereleasedfrommemory,thuskeepingmemoryusagelowastheparsingprocessproceeds.Table1summarizesallAPIsdescribedbefore.Table1.APIsanalysissummaryAPIParsingModelJAXP:SaxStreamingevents:pushmodel.JAXP:StAXStreamingevents:pullmodel.JAXP:DOMMemory:treeobject.XOMMemory:treeobject.OJXQIMemory:treeobject.jDOMMemory:treeobject.dom4jMemory:treeobject.Xerces2Memory:treeobject.VTDMemory:arrayofintegers.InordertotestmemoryusageandexecutiontimeforeachAPI,weusedtwodifferentfamiliesofXMLdocuments:1)onerepresentingsalesordersofaparticularcompany(SalesOrderDetail),whichwastakenfromtheMicrosoftDataWarehousesamples:AdventureWorks;2)anothergeneratedbyxmlgentoolwhichaimstorepresentinformationaboutabiddingwebsite,fromane-commercetypicalApplication.5.PERFORMANCEANALYSESOFAPISTable2presentsthesizeofthedocumentsandthepropertiesusedontestsforeachAPI.Weusedthreeinstancesofdifferentsizesforeachdocumenttypeinordertotestnotonlythesizeofin-memoryrepresentation,butalsotheelapsedtimeofparsingeachdocument.5.1Memory-basedAPIsThestudyconsistedinmeasurementsofmemoryconsumptioninmegabytes(MB)-(figure3),andexecutiontimeinmilliseconds(ms)–(figure4)usedbyeachmemory-basedAPI.Table2.DocumentsusedontestsResultsarebasedonanarithmeticaverageresultedfromfiveexecutionsforeachAPIforeachdocument(withoutconsideringthetimeofthefirstexecution).TheresultsshowsthegainofVTDinrelationtoothermemory-basedAPIs,eitherintermsofmemoryusageoratruntime,showingthatVTDrepresentationmodelofdataismuchsuperiorthanotherAPIsrepresentation.Figure3.MemoryconsumptioninmegabytesofmemorybasedAPIsFigure4.Executiontimeinmillisecondsofmemory-basedAPIsWiththeexceptionofVTD,noothermemorybasedAPIwasabletoperformtheparsingofthebiggestdocumentswiththeamountofmemoryavailableonJavaVirtualMachine(SalesOrderDetail3-greenbarandAuctionWebSite3–orangebar).NoteworthyisthegoodperformanceinparsingtimeofDOMinrelationtoothermemory-basedAPIs.AlthoughtherepresentationofaDOMdocumentinmemoryishigherthantheXOMandOJXQIrepresentation.WhenlargeXMLfilesareused,thememory-basedapproachisnotfeasibleduetoinherentmemorylimitations.5.2Streaming-basedAPIsOncememoryconsumptionofstreaming-basedAPIsisreduced,notrepresentingacriticalpointintermsofprocessing,weonlytestedparsingspeedinmillisecondsforeachAPI:SAX,StAX(wasdeemedthecursor-basedAPI)andXOM(streaming-basedapproach)(Fig5)foreachofthedocumentspresentedearlier.Figure5.Parsingtimeinmillisecondsfromstreaming-basedAPIsSAXandStAXareverysimilarintimeconsumption,whichiseasilyexpected,sincethemainpointthatdistinguishesthesetwoAPIsishowtheparserhandlestheeventsprocessed.Consideringtheentiredocument,theresultsarequitesimilar,neverthelessXOMhasamuchlowerperformancecomparedtootherstreaming-basedAPIs.5.3ComparativeanalysisoftwotypesofAPIsMemory-basedAPIsarewidelyusedduetothefactthat,inmostcases,documentsbeingprocessedaresmallenoughtofitinmemory.However,incaseswherememoryavailabilityislimited,orthesizeoftheXMLdocumenttobeprocessedislarge,streaming-basedAPIsarethemostsuitable.ProjectrequirementsarecrucialtodeterminethemostsuitabletypeofAPIused.TheneedtoapplydocumenttransformationisalsoaconsiderablefactorforAPIselection,oncememory-basedAPIsaremuchmoresuitableforthistypeofoperation,whilestreaming-basedAPIsaremoreusedforforward-onlyapplications.InordertotestAPIperformanceindocumenttransformationsweconsideredSalesOrderDetaildocumentsforthefollowingAPIs:SAX,StAXandVTD.TwooperationsweredevelopedforeachAPI:−Selection:anoperationthatselectsasetofelementsbasedonagivenpredicate,representingforward-onlyacc