大头随笔（四） :: 梦想风暴

来源: BlogBus 原始链接: http://blogbus.com:80/blogbus/blog/diary.php?diaryid=227677 存档链接: https://web.archive.org/web/20041028142526id_/http://blogbus.com:80/blogbus/blog/diary.php?diaryid=227677

梦想风暴 一个小程序员的信口开河 <<<大头随笔（三） | 主页 | 惊天逆转>>> 大头随笔（四） 2004-06-18 最初接触 XML 是在大学里，因为其名字与 HTML 的相似性，于是我就顺水推舟地认为 XML 也是用来做网页的。找到网上的名著《无废话 XML 》，用 IE 打开了其第一个例子，颇感奇怪地发现其结果和我想像的并不一致，基本上就是源代码重现（当然，有细微的差别，节点是可以伸缩的，就像树型控件一样。不过，当时我没发现）。实在看不出这个 XML 有什么用，于是大学里对 XML 的探索也就基本上到此为止了。 后来看过的一些东西都在说 XML 有多强大，有神奇，一直觉得很难理解，不就是和 HTML 一样的一堆标签吗？要说比 HTML 强，无非是它的标签可以自定义，哪里看出它强大神奇了。 很凑巧，工作后的第一个项目用到了 SOAP ，而要了解 SOAP ，首先要了解的就是 XML 。于是，我开始了新一次学习 XML 的历程。如果说这次学习 XML 是项目所迫，那倒是有一个优点，那就是学习 XML 有了真正的应用环境。之所以，自己以前对 XML 有一些误解，完全是因为自己的知之甚少加上没有应用环境造成的（由此可见，学习一样新技术，应用是多重要了 ^_^ ）。 这次的教材我选择的还是那本《无废话 XML 》。与最初接触 XML 时不同，这次我完全没有把 XML 看成一种做网页的语言，而是看成一种数据的记录方式。为什么？因为我们项目中关键的通信协议是 SOAP 来定义的，而 SOAP 就是用 XML 来定义的。所以，我知道了 XML 可以用作数据记录和传输。其实说起来 XML 的基本语法确实很简单，简单到一个由标签组成的语言，居然本身几乎没有定义任何标签。 有了应用环境， XML 学习起来还是很快的，基本上，一个上午就可以把那些基本语法浏览一遍。与在课堂上学习不同，在项目中学习一些东西，有个很大的缺点，就是不那么系统。和一个好朋友曾经就此交流过，因为他和我说，自己好像工作了这么长时间没有什么长进，而事实上，他的水平比起念书的时候提高了很多，就是因为知识的不系统，使他觉得自己长进不大。 回头接着说。要想把 XML 结合到自己的程序中，要做的第一项工作就是解析 XML ，从 XML 中提取自己需要的内容。这里的解析可不只是解析文本文件，也可能是网络中传过来的文本流。现在流行的解析方法主要有两种： SAX （ Simple API for XML ）和 DOM （ Document Object Model ）。 学过编译原理的人都还记得词法分析吧！一般就是读源程序，然后，根据读进来的字节分析个字节在这里出现是否合理，比如当前词法分析器认为自己正在处理的是一个浮点数，结果又冒出一个小数点来，它一下子就懵了，只好提示用户，自己看不懂。这种根据前面处理结果结合新来的东西得出新的处理结果的过程，做学问的人称之为有限状态机。词法分析完了就是语法分析了，同样的字组成的句子可不是谁都能理解的，词法分析器干的就是看看源程序说的是不是“行话”。 说过这些东西，再来说解析 XML 可能会好懂一些。 SAX 相当于读一点解析一点，可以认为是词法分析和语法分析在一个过程中进行了。需要自己做的实际上相当于是一个语法分析的过程。在 Java 中实现这个过程，一般就是自己实现一个 Handler 类，这个类要继承自一个 Handler 的基类，把其中的几个方法改写成自己想要的东西。之所以说， SAX 是和词法分析过程紧密联系在一起，从其 API 的方法定义中就可以看出来，它的接口更多的是代表词法的字符串、字符数组等等。可能到这里还体现的不是很明显。那就先来看看 DOM ，对比一下就知道了。 DOM 和 SAX 最大的不同，在于它并急于让用户参与到解析过程中，自己先慢慢地把所有内容解析了，在内存中形成一棵树。这所以 XML 可以形成一棵树，因为它的标签可以层层嵌套，看起来，里面的节点就像外面节点的“孩子”一样，而学过数据结构的人就可以看出，只要把节点和叶子对应，这和树是一样的。在编程实现上，与 SAX 很明显的一点不同在于，前面说到的那个 Handler 类需要在开始正式的解析之前需要设置到解析器（ parser ）中，然后再行解析，这就使得这个 Handler 可以参与到 XML 的解析过程中。而 DOM 完全不必理会这些，解析过程进行去吧！给我解析的结果就可以了。从 API 上可以看出它与解析过程无关，它的 API 中更多的是 Document 、 Node 、 Element 之类已经上升到逻辑高度一级的东西。 从这些解释中可以看出， DOM 逻辑性更强一些，但它很吃亏的一点在于它需要在内存中形成一棵树，于是不可避免的要比 SAX 浪费更多的内存。 不管怎么样，解析 XML 都是一件费时费力的事。用 XML 作承载的协议，比如 SOAP ，虽然有种种诸如跨平台等等的优点，但处理起来一般简单定义的协议浪费掉更多的时间。所以，对于用 XML 作承载的协议，不要对其处理效率报有很高的期望。 上面几次提到 SOAP ，这里就不妨在说上几句。 SOAP 这两年很火，我在做这个项目之前，也是只闻其名，不见其实，于是对它产生了一种莫名的崇敬。 SOAP 究竟是什么呢？ Simple Object Access Protocol ――简单对象访问协议。如果拿来 SOAP 规范看，保证很多人和我当初一样，看不了几页就眼发花、头发晕。其实， SOAP 之所以敢称简单，依我看，它是因为自己几乎什么新东西都没有造成的。协议的数据格式完全是用 XML 来定义的，传输协议可以使用 HTTP 或是 SMTP ，不过，据说 HTTP 用的多一些，因为一般的防火墙对 HTTP 是不设防的。协议内容有了，传输有了，还要什么？所以，我说它自己几乎什么都没有。要说符合 SOAP 的 XML 文件和一般的 XML 有什么区别的话，那就是 SOAP 里要求分为头和体两部分，具体头和体内容，那就是自己的问题了。项目开发到后期，我们自己就利用 SOAP 定义了一套自己的协议。另外， SOAP 消息后面还可以携带多媒体附件，比如文本、图像，也就是利用 SOAP 消息可以传输很多东西，当然这相当于对 XML 做了一些扩展。 既然说到了 SOAP ，就顺便说一下 Web Service 吧！ 关注一下这几年的报道，就会发现 Web Service 是上镜率极高的词。抛开其推广者和媒体的溢美之词和诸多美好构想。作为开发人员，我们关注更多的是其实现一级的东西。 Web Service 其实就是一个以 SOAP 作为其实现协议来实现的一种服务。也就是说，一方发起一个 SOAP 消息，另一方（也就是提供服务的一方）得到消息，进行处理，然后，将处理结果生成一个 SOAP 消息发回去。具体实现什么，还是上面的那句话，那就是自己的问题了。 如果是用 Java 来实现 Web Service ，那可以到 Sun 的网站上找来 JWSDP （ Java Web Service Developer Pack ）。 Sun 还提供了相应的教程，找几个例子试一下，会觉得自己也加入了比较前沿的一族。如果用 C# ，可能更简单。以前在做毕设的时候，有个同学就是用 C# 来实现一个 Web Service ，当时，我还对此一无所知。只见他托托点点，写了几行代码，一个 Web Service 的例程就完成了，羡慕得不得了。 不过，话说回来。 SOAP 和 Web Service 并不只有我上面说的那么点东西，还是有很多的东西要去学，去了解的。像 Web Service 中非常重要的服务发布、查找等等就被我忽略不计了。之所以这种方式表达，完全是因为自己对这些很重要的东西了解不多，不敢胡说，更重要的是因为不想让它们看起来那么神秘。 SOAP 和 Web Service 曾经是在我心目中地位极高，虽然现在我对它们了解也并不多，但理解一些原理就不再觉得它们神秘，于是它们俩都被拉下了我心目中的神坛。我是在只对 XML 基本语法有了解的情况下去接触它们的，由此可见，其难度并不是很大。反过来看，它们的简单也正说明了其设计者水平的高超，简单的设计才是好的设计。 几乎是走马观花般的说了一遍， XML 相关的东西可决不只这么一点点。本来很想把自己了解的东西一一“炫耀”一番，可我实在不想让一篇小品文成为一部小说，只好就此收住了。 dreamhead 发表于 2004-06-18 22:57 引用Trackback(0) | 编辑 Comments 发表评论 最近更新 Hello Velocity之后 Hello Velocity 对象的生命 高手的煽动 XML与堆栈 Meta的乐趣 奴隶社会与共产主义 返回值和异常 梦想归来 自其不变而观之