八、消息转换

8.1 引言

元数据管理

要把消息从一种格式转换为另一种格式，则需要解决好元数据问题，所谓元数据是指用于描述实际数据格式的数据。如果从一个应用向另一个应用发送了一个消息，告诉我们ID号为123的客户从加利福尼亚的 San Francisco搬到了北卡罗来纳州的Raleigh，相关的元数据则是:该地址修改消息使用了一个数字类型的客户 ID字段，并且把客户的姓和名分别存储在两个不超过40字符的文本字段中。

8.2 信封包装器

如果已有的系统对消息格式有特定的需求，如要求有消息首部字段，或者要求加密，这样的系统如何参与消息传递交换?

当信封到达目标时再解开消息使用信封包装器，把应用数据包装在符合消息传递基础设施要求的信封中，当信封到达目标时再解开消息。

包装和解包消息的过程包括5步：

1. 消息源采用原始格式发布一个消息。这个格式是由应用本身的性质所决定，不符合消息传递基础设施的要求。
2. 包装器把原始消息转换为符合消息传递系统要求的消息格式。这一过程可能包括增加消息首部字段，加密消息，增加安全凭证等。
3. 消息传递系统传送符合要求的消息。
4. 结果消息传输给解包器。解包器逆向撤销包装器所作的修改。这一过程可能包括删除消息首部字段，解密消息，或验证消息凭证。
5. 消息接收者接收到一个“明文”消息。

信封既要封装消息首部，也要封装消息体(或有效载荷)。我们可以把消息首部看作是写在信件信封外面的信息:消息传递系统使用这些信息来路由和跟踪消息。信件的内容是有效载荷或消息体一在消息到达目标前，消息传递基础设施(在一定的限制条件下)不太关注消息体。

包装器一般要在原始消息中添加信息。例如，邮政系统在发送内部消息前，必须查看其邮政编码。为此，包装器集成了内容扩充器的部分功能。但是，包装器不会扩充实际的信息内容，而只是增加路由、跟踪和处理消息所需的信息。这些信息可以实时地创建 (如创建唯一的消息 ID，或者增加时间戳)，也可以从基础设施中提取(如从安全上下文中提取)，或者是那些原本包含在原始消息体中但被包装器划分到消息首部中的数据(如原始消息中包含的键字段)。最后这种情况有时也被称为提升 (promotion)，因为特定的字段从隐藏的消息体中“提升”到完全可见的消息首部中。

通常情况下，多个包装器和解包器会链接在一起(见下面的邮递系统示例)，在此利用了分层的协议模型。由此，消息的有效载荷中可能包含着新的信封，这个信封则进一步封装了消息首部和有效载荷(如下图所示)。

8.3 内容扩充器

如果消息的创建者无法提供所需的所有数据项，如何与其他系统通信?

• 选择A：
  • 缺点1：需要修改预约系统的内部结构
  • 缺点2：即使预约系统是可定制的，也要认识到，我们对系统所做的修改建立在另一个系统的特定需求上
• 选择B：
  • 缺点：在一个松耦合系统中，我们不希望让一个系统指示另一个系统应该怎么做，而应该发送一个事件消息，让其他系统自己决定如何操作。另外，这个解决方案把预约系统与客户关怀系统更紧密地耦合起来，因为预约系统现在需要知道从哪里获得缺少的数据。这就会把预约系统与财会系统和客户关怀系统绑在一起。由于这样会导致脆弱的集成解决方案，因此这种耦合是不可取的。
• 选择C：
  • 需要修改客户关怀系统的逻辑

使用一种特殊的转换器(即内容扩充器)访问外部数据源，以便在消息中增加缺少的信息。

内容扩充器使用输入消息中的信息《如键字段)从外部数据源中获取数据。当内容扩充器从数据源获得所需的数据后，就把它们附加到消息中。来自输入消息的原始信息可能添加到结果消息中，也可能不再需要，这取决于接收应用的特定需求。

由内容扩充器注入的附加信息必须保存在系统中的某个位置。这些新数据一般从以下：

1. 计算：内容扩充器可以计算出缺少的信息
2. 环境：内容扩充器从操作环境中获取额外的数据。最常见的是时间戳。
3. 其他系统：包括数据库、文件、LDAP目录、应用或手工输入。

内容扩充器往往用于解析包含在消息中的引用。为了减小消息的大小，并使消息易于管理，我们一般只传递对象的引用，而不是传递包含所有数据元素的完整对象。这些引用通常采用键或唯一ID 的形式。当系统要处理消息时，必须根据包含在原始消息中的对象引用提取出所需的数据项。

8.4 内容过滤器

处理一个很大的消息时，如果只对其中的少量数据项感兴趣，应该如何简化?

为什么我们想从消息中删除有价值的数据元素?一个常见的原因是为了安全。从一个服务请求数据的应用可能无权查看应答消息中包含的所有数据元素。

删除数据元素的另一个原因是为了简化消息处理和降低网络通信量。在许多实际应用显然，我们应该根据第三方制定的消良的处理是从接收到来自业务伙伴的消息开始的。

使用内容过滤器从消息中删除不重要的数据项，只留下重要的数据项。

内容过滤器不但要能删除数据元素，还要能简化消息的结构。

多个内容过滤器可以实现为一个静态的分解器(见“分解器”)，从而把一个复杂的消息分解为多个独立的消息，每个消息对应原来大消息中的一个部分(如下图所示)。

8.5 声明标签

在不损害信息内容的前提条件下，怎样减少跨系统发送的消息的数据量?

把消息中的数据存储在一个持久存储库中，并把声明标签传递给后续组件这些组件可以使用声明标签重新获得所存储的信息。

声明标签模式包括以下步骤:

1. 带有数据的消息到达。
2. 托运行李(Check Luggage)组件为信息产生唯一的键。该键可以作为后续的声明标签。
3. 托运行李组件从消息中取出数据，并把数据存储在一个持久的存储库中，如文件或数据存储库。它把键与所存储的数据相关联。
4. 从消息中删除持久存储的数据，并在消息中增加声明标签5.其他组件可以使用内容扩充器，根据声明标签取得数据。

1）选择键

如何为数据选择合适的键?可行的方法包括:

1. 消息体中可能已经包含有业务键，如客户ID，可以把它作为键
2. 消息中可能包含一个消息 D，可以用于将数据存储库中的数据与消息相关联
3. 可以生成一个唯一的ID

重用已有的业务键看起来是最简单的方法。如果必须去掉客户的一些详细信息，以后可以再通过客户 ID 引用这些信息。当把这个键传递给其他组件时，首先要确定是否有必要让这些组件清楚该键是一个客户 ID，而不只是一个抽象键。把键表示为抽象键有一个好处，这样一来可以采用相同的方法处理所有键，而且可以建立一个通用的机制，根据抽象键从数据存储库获取数据。

虽然可以方便地使用消息 ID 作为键，但是一般不应该这样做。如果使用消息 ID 作为获取数据的键，会使同一个数据元素有二义性，进而引发冲突。例如，假设要把声明标签引用传递给另一个消息。为这个新消息指派了新的唯一ID，不过这样一来，我们就不能使用这个新的ID从数据存储库中获取数据了。使用消息ID作为键只适用于一定的范围，即只限于在一个消息范围内访问数据。因此，通常更好的做法是指派一个新的元素存储键，而避免这种不好的“元素重用”。

数据可能只是在数据存储库中临时存储。如何从数据存储库中删除无用的数据?为此，可以修改从数据存储库中获取数据的语义，从而在读取数据时将其删除。采用这种方法，数据只能获取一次，从安全的角度考虑，这样做是非常适合的。但是，这样无法使多个组件访问相同的数据。为此，可以为数据附加一个到期日期，并定义一个垃圾收集进程，让它周期性地删除所有到期的数据。还有第三种方法，就是根本不删除任何数据。这是因为我们使用的业务系统(如财会系统)就是一个数据存储库，它必须把所有的数据都保留在系统中。

2）使用声明标签隐藏信息

根据外部系统拥有的键，对外部系统所能采取的行动加以限制。这样能避免外部系统恶意地向系统发送消息。当外部系统尝试使用错误的键获取消息中的数据时，内容扩充器会堵住包含非法键(或者键已经到期，或者已被使用) 的消息。

3）使用带声明标签的过程管理器

如果要与多个外部系统交互，过程管理器可以提供声明标签的功能。当有消息到达时，过程管理器会创建过程实例(有时也被称为任务或作业)。它允许为每个独立的过程实例关联额外的数据。实际上，此时过程引警就相当于数据存储库，存储了消息中的数据。过程管理器在向外部系统发送消息时，只会发送与该系统相关的数据，消息中不必包含原始消息中的所有信息，因为其他信息会存储在过程的数据库中。当过程管理器接收到外部系统返回的响应消息时，它会把新数据与已经保存在过程实例中的数据合并。

8.6 规范器

如何处理语义上等价但是格式不同的消息?

业务模型与每个参与者达成的协议中包括这样一条:要尽可能减少对系统基础设施的改变。因此，聚合器要能处理以各种数据格式到达的信息，包括EDI(电子数据交换)记录、逗号分隔的文件或通过电子邮件传送的XML文档或Excel表单。

当与大量的参与者打交道时，有一个重要的问题，这就是修改的速度如何。每个参与者不但喜欢采用不同的数据格式，而且格式还会随时间改变。另外，新的参与者会不断加入进来，而其他的参与者也可能随时退出。即使某个特定的参与者每隔两年才会改变一次数据的格式，但是同时面对几十个参与者时，数据的格式每个月、甚至每周都会发生改变把这些改变与处理的其他部分尽可能隔离是非常重要的，只有这样才能避免改变对整个系统造成的“涟漪效应”

为了使系统的剩余部分与各种输入消息格式相隔离，必须把输入消息转换为一种公共的格式。由于输入消息有不同的类型，因此每种消息数据格式要有一个不同的消息转换器。为了达到这个目的，最简单的方法是使用一组数据类型通道，每个通道对应一个消息类型。然后再把各个数据类型通道连接到不同的消息转换器。采用这种方法的缺点是，大量的消息格式被转化为同样多的消息通道。

使用规范器，通过一个定制的消息转换器来路由各种消息类型，使结果消息与一种公共消息格式匹配。

1）检测消息格式

XML：根据根元素的名字识别出正确的类型

文件：根据文件名、文件名后缀、文件夹结构

8.7 规范数据模型

当集成的应用使用不同数据格式时，如何把它们的相互依赖减到最少?

设计一种规范数据模型，使之独立于所有特定的应用。要求每个应用能产生和消费使用这种公共格式的消息。

1）转换的选择

1. 修改应用的内部数据格式
2. 在应用的内部实现消息传递映射器
3. 使用外部消息转换器

2）双重转换

使用规范数据模型会给消息流增加一定程度的开销。每个消息都要经历两次转换，而不是一次转换:一次是从源应用的格式转换为公共格式，另一次是从公共格式转换为目标应用的格式。因此，使用规范数据模型有时也被称为双重转换

3）设计规范数据模型

定义规范数据模型通常是克服应用之间语义不一致性的第一步

4）数据格式的依赖性

在应用之间存在者不同层次的依赖性。消息通道的使用在应用之间提供了公共的传输层，消除了应用中各个传输协议之间的依赖。消息路由器可以提供位置独立性，因而发送方的应用不必依赖接收方应用的位置。通过使用公共数据表示，如XML，可以消除对任何应用特定数据类型的赖。最后，规范数据模型可以克服对应用所使用的数据格式和语义的依赖。