ProtoBuf、XML相关技术与Web服务架构

XML主要是一种数据描述方法，相关技术有3个：Schema、XSL和XLL

DTD（Document Type Definittion，文档类型定义）与Schema：对文档格式进行定义的语言，就相当于数据库中需要定义数据模式一样。其中DTD是从SGML继承下来，Schema是专门为XML文档格式而设计的。

CSS和XSL（eXtensible Stylesheet Language）:由于XML是内容和格式分离的语言，所以需要定义显示格式。其中CSS是随HTML的出现而出现的，是一种极其简单的样式语言；XSL是专门为XML设计样式语言，它被定义为一套元素集的XML语法规范，该语法用来将XML文件转换为HTML或者其他格式的文档。

Xpath、Xpointer与xllink:都用于扩展Web上的链接。XLink与HTML中的<a>标记的功能很类似；Xpath是一门语言，用于把XML文档作为带有各种结构点的树来查看。使用Xpath可以定位XML文档的任意节点。XML中，链接分为两部分，即Xlink和Xpointer.Xlink是XML的链接语言，用于描述一个文档如何链接到另外一个文档，Xpointer是XML语言的指针，用于定义如何寻址一个文档的各个组成部分。

XML名字空间：当多个文档创建DTD或者Schema时，需要某种方式来确定每个定义的起源。Namespace的使用可以有效防止名字冲突

XML查询语句：XQL(XML Query Language)和XML-QL是两种比较有影响力的查询语言，它们是对XSL的一种自然的补充，并在XSL的基础上提供了刷选操作、布尔操作和对节点集合进行索引，并为查询，定位等提供了单一的语法形式。

RDF(Resource Description Framework):一种用于描述Web资源的标记语言。RDF是一个处理元数据的XML（标准通用标记语言的子集）应用，所谓元数据，就是“描述数据的数据”或者“描述信息的信息”。也许这样解释元数据有些令人难以理解，举个简单的例子，书的内容是书的数据，而作者的名字、出版社的地址或版权信息就是书的元数据。数据和元数据的划分不是绝对的，有些数据既可以作为数据处理，也可以作为元数据处理，例如可以将作者的名字作为数据而不是元数据处理。RDF是用于编译、交换、和重新使用结构化元数据的W3C指令的XML应用程序，它能使软件更容易理解Web站点的内容，可以发现Web站点上的资源。

DOM（Document Object Model）、SAX（simple API for XML）和XML解析器（分为验证和非验证）

Web服务架构

W3C将服务定义为：“服务提供者完成一组工作，为服务使用者交付所需的最终结果”。Web Service是描述一系列操作的接口，它使用标准的、规范的XML描述接口。

Web服务模型，服务提供者（使用WSDL）对Web服务进行详细、准确、规范的描述，并发布到服务组册中心

Web服务使用SOAP（Simple Object Access Protocol，简单对象访问协议）作为消息的传送标准。在此之上是WSDL(网络服务描述语言,Web Services Description Language)

我妈可以将SOAP理解为：HTTP+XML+RPC

WSDL定义了可被机器识别的SDK（软件开发工具包）文档，可以理解为Web服务的SDK标准，或者Web服务的接口定义。既要描述是做什么的，还要描述如何使用他们提供的服务。

面向服务的架构（Service-Oriented Architecture，SOA）

W3C将SOA定义为“一种应用程序架构，在这种架构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程”

Web服务实现SOA

在采用Web服务作为SOA的实现技术时，该系统至少分为6个层次：底层传输层、服务通信协议层、服务描述层、服务层、业务流程层和服务注册层。

服务通信协议层的主要功能是描述并定义服务之间进行消息传递所需的技术标准，常用的是SOAP协议，还有新出现的REST（Representional State Transfer，表述性状态转移）协议

服务描述，描述服务的接口与消息交换方式，，相关的标准是WSDL

服务层，将遗留的系统进行包装，并通过发布的WSDL接口描述被定为和调用

业务流程层，支持服务发现，服务调用和点到点的服务调用，并将业务流程从Web服务的底层调用抽象出来，相关的标准是WS-BPEL(Web Service-Business Process Execution Language，Web 服务业务流程执行语言)。

服务注册层，是使服务提供者能够通过WSDL发布服务定义，并支持服务请求者查找所需的服务信息，相关标准是UDDI

企业服务总线（Enterprise Service Bus，ESB）

使用ESB，可以在不改变现有基础结构的情况下让几代技术实现互操作，在几乎不更改代码的情况下以一种无缝的非入侵方式使企业已有的系统具有全新的服务接口，并能在部署环境中支持任何标准。并且，不同的应用程序可以同时使用同一服务，在应用程序或者数据发生变化时无需改动服务代码。

ESB架构中每个构件对标准强有力的支持，这些构件是通信、连接、转换、可移植和安全。

 

关于 ProtoBuf 的一些思考

官方文档以及网上很多文章提到 ProtoBuf 可类比 XML 或 JSON。

那么 ProtoBuf 是否就等同于 XML 和 JSON 呢，它们是否具有完全相同的应用场景呢？

个人认为如果要将 ProtoBuf、XML、JSON 三者放到一起去比较，应该区分两个维度。一个是数据结构化，一个是数据序列化。这里的数据结构化主要面向开发或业务层面，数据序列化面向通信或存储层面，当然数据序列化也需要“结构”和“格式”，所以这两者之间的区别主要在于面向领域和场景不同，一般要求和侧重点也会有所不同。数据结构化侧重人类可读性甚至有时会强调语义表达能力，而数据序列化侧重效率和压缩。

从这两个维度，我们可以做出下面的一些思考。

XML 作为一种扩展标记语言，JSON 作为源于 JS 的数据格式，都具有数据结构化的能力。

例如 XML 可以衍生出 HTML （虽然 HTML 早于 XML，但从概念上讲，HTML 只是预定义标签的 XML），HTML 的作用是标记和表达万维网中资源的结构，以便浏览器更好的展示万维网资源，同时也要尽可能保证其人类可读以便开发人员进行编辑，这就是面向业务或开发层面的数据结构化。

再如 XML 还可衍生出 RDF/RDFS，进一步表达语义网中资源的关系和语义，同样它强调数据结构化的能力和人类可读。

JSON 也是同理，在很多场合更多的是体现了数据结构化的能力，例如作为交互接口的数据结构的表达。在 MongoDB 中采用 JSON 作为查询语句，也是在发挥其数据结构化的能力。

当然，JSON、XML 同样也可以直接被用来数据序列化，实际上很多时候它们也是这么被使用的，例如直接采用 JSON、XML 进行网络通信传输，此时 JSON、XML 就成了一种序列化格式，它发挥了数据序列化的能力。但是经常这么被使用，不代表这么做就是合理。实际将 JSON、XML 直接作用数据序列化通常并不是最优选择，因为它们在速度、效率、空间上并不是最优。换句话说它们更适合数据结构化而非数据序列化。

扯完 XML 和 JSON，我们来看看 ProtoBuf，同样的 ProtoBuf 也具有数据结构化的能力，其实也就是上面介绍的 message 定义。我们能够在 .proto 文件中，通过 message、import、内嵌 message 等语法来实现数据结构化，但是很容易能够看出，ProtoBuf 在数据结构化方面和 XML、JSON 相差较大，人类可读性较差，不适合上面提到的 XML、JSON 的一些应用场景。

但是如果从数据序列化的角度你会发现 ProtoBuf 有着明显的优势，效率、速度、空间几乎全面占优，看完后面的 ProtoBuf 编码的文章，你更会了解 ProtoBuf 是如何极尽所能的压榨每一寸空间和性能，而其中的编码原理正是 ProtoBuf 的关键所在，message 的表达能力并不是 ProtoBuf 最关键的重点。所以可以看出 ProtoBuf 重点侧重于数据序列化 而非 数据结构化。

最终对这些个人思考做一些小小的总结：

1. XML、JSON、ProtoBuf 都具有数据结构化和数据序列化的能力
2. XML、JSON 更注重数据结构化，关注人类可读性和语义表达能力。ProtoBuf 更注重数据序列化，关注效率、空间、速度，人类可读性差，语义表达能力不足（为保证极致的效率，会舍弃一部分元信息）
3. ProtoBuf 的应用场景更为明确，XML、JSON 的应用场景更为丰富。