XMLFoundation

• 下载源文件 - 1.09 Mb

 

  

 

XML生成对象的必要性

获取标记为XML的数据需要应用程序层工具来轻松高效地处理XML数据。最简单的方法是将XML解析为DOM树，然后遍历树以收集应用程序/对象变量所需的数据。这种方法会产生大量的“简单”源代码，用于将数据从XML移到结构化对象中，这在实现时间和长期维护方面都是一种糟糕的方法。

或者，OO方法将此过程泛化为可重用功能，从而使对象可以直接序列化到XML和从XML反序列化。沿此思路已发布了许多实现。（ASP，Visual Basic，更多VB，Java，更多Java，IBM Java，Perl，Python，Delphi，PHP）。（+约30个其他）很明显，所有语言的软件开发人员都有类似的需求。他们必须：

1. 编写自己的对象-XML工具，
2. 找到现成的生产级框架，或者
3. 使用最原始的方法并聘请一支维护程序员团队。

如果您的应用程序不使用XML

这个基础仍然是一个优秀工具，可以确保性能、可移植性和简化开发。该基础包含各种通用的实用类（列表、堆栈、哈希、树、排序、字符串、文件结构、异常、压缩、加密、uuencode +更多），它们都具有可移植性、注释文档、优化且易于使用。例如，字符串类设计用于轻松使用XML字符串，但可用于任何应用程序。 FiveLoaves是一个广泛使用XMLFoundation的应用程序示例，但其1.0版本不处理XML。如果（最有可能的是当）FiveLoaves需要任何XML支持时，这将是一个简单的增强，一个自然的进步——而不是事后补救。

旧瓶装新酒：老问题 - 新数据格式

“从数据生成对象”不是一个新概念。程序员多年来一直在这样做，甚至在它们被称为对象之前。曾经有一段时间，行业尝试了对象数据库，因为它们使应用程序的构建工作变得更加简单。对象数据库是个好主意，但对于大量信息来说并不实用——因为性能就是可用性。数据库保持快速和关系型，而对象数据库则像其他从未被广泛接受的“酷”技术一样走向衰落。程序员添加了大量的简单逻辑，将数据从列-行输出移到可用的内存结构（对象）中。基本上，程序员是在手工编写对象数据库无法快速完成的任务。各种工具和开发框架可供所有语言的开发人员使用。这些工具简化了将行/列数据移到应用程序层所需结构（对象）中的繁琐任务。

原生组件对象支持

CORBA和COM对象与其他开发语言中的所有其他对象一样，面临着相同的问题。该框架支持这两种分布式对象体系结构。添加到每个对象的原生XML访问器开启了全新的开发技术维度。您选择的对象技术成为互操作性的次要问题，因为无论您选择哪种技术，您都有一个直接XML的备用接口。

对速度的需求

XML优美易读的冗长是有代价的。比较这两种协议显示了用不同方式标记的相同信息。

123456789112345678921234567893123456789412345678  Measure
.........0.........0.........0.........0........ 
<Name>Brian</Name><EmployeeID>11260</EmployeeID>  XML
Brian,11260                                       Comma Separated
##Brian##                                         Packed Binary 
123456789112345678921234567893123456789412345678 
.........0.........0.........0.........0........ 

您可以看到标记在红色中的所有标记，这些标记被添加到蓝色的两块数据中。数据为10个字节，但可以表示为少于7个字节。

标记类型	消息大小
XML	48字节
位置逗号分隔	11字节。
打包二进制	9字节。（##是名称长度，##是打包的员工ID）

通常，与使用其他对象传输协议相比，使用XML需要更多的空间。这意味着：

1. 数据组装花费了更长的时间。
2. 由于发送的数据量更大，传输到您那里花费了更长的时间。
3. 处理更多信息将花费更长的时间。

时间是相对的，但却是技术的中心。较低层的时间在较高层会被指数级放大。我们今天看到的较高层将在未来的进步中被埋没，直到永远。1984年有人看了较高层，说“640k足够任何人用了”，奠定了基础，建筑开始了。到1992年，基础已经被重建。“新科技”在那时是。所以更合适的问题是“你明天想在哪里？”莫扎特粉丝看科技广告可能能理解。我们今天称之为宽带的东西，明天我们将称之为瓶颈。这只是时间问题。

实现响应：随处可用。

由于“对象到/从XML”是一项非常通用的任务，因此实现用途几乎是无穷无尽的。该框架旨在尽可能多的环境中工作。

应用程序通用：XML用于对象数据传输是格式良好的。这对于实时信息服务器和/或客户端/服务器（又名：B2C）实现以及B2B来说都效果很好。在B2B集成中，DTD验证在入站XML文档进入对象创建的应用程序层之前就已经完成。在像B2B这样的情况下，当您确实想根据DTD验证XML时，这作为预备步骤完成，而不是在对象因子化中完成。有许多优秀的验证XML解析器可免费获得。UBT使用Xerces解析器来执行这些“高级”任务。（Xerces的历史）

性能：应用程序技术要求中的最低公分母是满足最苛刻实现的性能要求。这个理想影响了框架各个层面的许多设计决策，从算法选择到内存管理。尤其对于XML来说，对理想内存使用的关注变得更加重要。单个“额外”或“临时”数据副本的最终结果将是一个由于软件设计而内存需求加倍的服务器。

大小：越小越好，但在嵌入式系统中，小通常是首要要求。XMLFoundation是“紧凑”的代码。考虑FiveLoaves，该应用程序广泛使用了该基础，几乎所有的实用程序和算法都得到了利用，并且它编译成一个350kb的可执行文件（软盘容量的四分之一 - 未压缩）。许多Internet应用程序通过Internet连接进行安装或更新，对它们而言，额外的大小意味着用户或客户等待时间的增加。在互联网时代，服务最好的公司往往是技术最好的公司。

国际化：UBT将发布一个基于IBM的ICU的Unicode实现，这与Java VM用于提供Unicode支持的（免费）库相同。它将作为一个单独的库构建，这样所有非亚洲/阿拉伯语的实现就无需承担翻译和双倍内存消耗的开销。

可移植性

真正的可移植性需要考虑许多因素，该框架的目的是在不损害性能的情况下解决所有这些问题。

Java应用程序更容易跨硬件平台移植，因为只需要管理一个构建。在Java的范围内，可移植性还包括对现有开发技术（如CORBA、JavaScript和JSP）的支持。并非所有应用程序服务器技术都一样。EJB可能不会加载本地库，但它们的容器可能会，如果它们被实现为这样做的话。在某些实现中，Bean可能间接“使用”具有本地实现的Java对象。

C++已经发展了大约15年，现在几乎到处都有支持。它肯定到处都有Java，因为JVM是用C/C++编写的。一些C++编译器对C++的后期新增功能（如模板）的支持仍然较弱。因此，C++框架严格分为两层。较低一层是空的。模板类不被框架使用，而是被应用程序使用，因此它们的包含是可选的。如果您的编译器不支持模板，请不要使用模板类。“ObjectsFromXML”示例随框架一起提供，展示了两种方法。

C++的移植比Java复杂。由于C++编译为直接的机器二进制码，因此必须在您想支持的每个目标系统上通过编译器来处理源代码。因此，对于C++用户来说，在考虑可移植性时：不使用STL。不使用命名空间。系统包含已最小化，仅包含标准的“K&R C”包含。不使用iostream。该框架已在多种平台上使用，包括：HPUX、AIX、SunOS、3.1/95/98/ME/NT/2K、Linux，甚至专有系统。它已与许多编译器进行了验证，包括：CC5.0、Xlc、gcc(2.95 & 3.0)、IntelC++5.0、 KAIc++4.0f、ForteC++(6.2 & 7)和Visual C++6.sp5。

与Java一样，C++用户还必须考虑对应用程序/对象技术（如CORBA和COM）的支持。该框架附带了一个示例，该示例已移植到IONA/Orbix、BEA/WLE-ObjectBroker和Inprise/Borland Visibroker（位于CORBA示例中）。

坚实的基础

这些源代码是UBT完成的几个大型客户企业级项目的基石。它也是FiveLoaves、DesignerXSL、DesignerXML、TransactXML以及我们自己几个内部项目的基石。自1998年1月以来，它一直在全职开发中。像列表这样的几个基本实用程序可以追溯到1992年——它们在多年的许多软件项目中都经过了试验和测试。

对象的XML来源在哪里？

该框架的目的是为XML提供对象序列化。XML的来源可以是另一个对象的当前状态、磁盘文件或内存缓冲区。许多产品（如Oracle和SQL Server）开始支持XML作为描述它们所包含数据的一种方式，这些产品将提供可接受的“动态XML”来源来分配您对象的状态。您还可以使用XML服务器，如UBT的TransactXML Server或任何其他能够生成格式良好的XML文档的服务器或应用程序。其中一个示例程序“ObjectsFromXML”演示了如何使用来自UBT的TransactXML Server创建的磁盘文件或动态XML文档的交替数据源。