2.1 消息表示需求分析

2.1.1 需求分析

首先要注意区分的是：仅从字面来看，会有人将“消息表示法”要解决的问题理解为前文所述的“流消息”与“XML消息”的问题，这是完全可以理解的。因为这样来定义“消息表示”的内涵也说得通，因此，这里要明确指出，本书中所说的消息表示法，主要是指程序员编写代码层面的“消息表示”，而“流消息”与“XML消息”的问题，则是指传输过程中的“消息格式”。本章主要介绍“流消息”的表示法。

除了代码层面的消息表示法以外，本章还会对传输层面（流化后）的消息结构作以介绍，但要指出的是：关于消息的传输格式（流化后的消息结构），其本身必须要和代码层面的消息表示如何转换为传输格式（即消息的流化）的问题一起讨论才能完全讲清楚。所以对消息传输格式来讲，更多的应该是讲如何生成该格式的动态问题，而不仅仅是讲如何表示这样一个静态问题。因此，仅通过本章内容，是无法完全阐述清楚的。然而，代码层面的消息表示，却是一个纯粹静态的表示方法问题，并且内容繁杂，确实需要单独讨论，这是本章的研究重点。对消息流化的问题，将在下一章讨论，到那时，读者应该会对流化后的消息结构有个更清晰的认识。

概念清楚以后，现在，让我们来分析一下消息表示法的需求。

总的来说，消息表示法的设计是为了满足这样的需求：如何将我们需要通过消息传递的信息（包括各种类型的数据以及远程调用的请求），在程序员编写代码的层面，合理、全面、有效地组织并表达出来？

其实，在第1章我们对那个原始消息实现方法进行分析时，也涉及了一些该方面的问题，但当时是对那种原始方法的初步分析，在每个层面，都还很不深入，也不全面。

所以，这里在介绍消息表示法之前，我们专门对消息表示的需求进行分析。笔者认为，一个设计全面的消息表示方法应该能满足以下需求。

· 需要有能力容纳各种数据类型及其组合。这应该包括了基本数据类型、二进制流、类（或结构）及由类（或结构）的实例（对象）组成的集合（数组或列表）。

· 需要有能力在一个消息体中包含多种远程调用请求及各自的参数列表。

· 需要有能力描述（或组合描述）巨大的数据量，包括二进制流。

· 需要有能力在各种平台上实现统一表示，包括Windows，UNIX/Linux，Macintosh等。

· 需要有能力容纳不同的消息版本，也就是说，消息表示的约定协议会允许改变（这一点更多是与消息发送/接收、处理有关）。

· 应该有能力在消息体中包含对本消息的发送、接收以及计算大小等方法接口。这里我们用了“应该”一词，而不是“需要”，是指虽然它初看起来并不像前几点那样是必需的，但其实，在后文中我们可以看到，将消息中各元素的发送/接收接口包含在消息表示体中，对统一、方便地实现消息通信与处理机制是至关重要的。

· 一个完整消息体可以是由多个合法代码单元组成的（即多个类或多个结构），而不一定必须是一个合法的代码单元。这里不是指一个代码单元（类）中嵌套了其他代码单元（类）的实例这种情况（关联关系），而是指多个无关联关系的代码单元在实例化之前就可以组合成一个完整消息。

需要注意的是，上面我们只提到了一个“设计全面”的消息需求分析，并没有提及合理性、优化性、灵活性、方便性等方面的要求，而这些，自然也是重要而且必须的，它们正是要在下文对消息表示法具体内容的阐述中体现出来的。

2.1.2 消息表示法的内容

总的来讲，本章介绍消息表示法所涉及的主要内容包括以下几个部分。

· 消息的总体结构。总体来说，消息是由哪几个大部分组成的以及如何组成的。

· 代码层面与传输层面的消息表示，以代码层面消息表示为主。

· 各消息组成部分的详细内容。

· 采用面向对象语言，示例消息表示法的实现。

下面我们会对这些内容逐一介绍。