内容


WebSphere Message Broker V6.1 中的消息建模和解析增强功能

Comments

引言

IBM® WebSphere® Message Broker 提供了一系列解析和编写消息格式的解析器。当将表示输入消息的位流转换为可由代理处理的内部形式时,将会调用解析器。每个解析器适合于称为消息域的特定消息分类(例如固定长度的二进制、分隔文本,或者 XML)。对于架构师、消息集设计人员和开发人员,本文将向您介绍如何使用 WebSphere Message Broker V6.1 中针对 XMLNSC 和 MRM 域的增强消息建模和解析功能。

什么是消息解析?

通常,WebSphere Message Broker 消息流接收具有已定义格式的消息,对其进行转换,并以不同的格式将其输出。下面的图 1 显示了一个示例,其中将 COBOL Person 数据结构转换为 XML Person 文档。每个 Person 消息包含 Name、Age 和 Height 字段:

图 1. 消息解析示例
消息解析示例
消息解析示例

COBOL Person 消息以输入位流的形式到达。在消息流能够处理和转换它之前,必须将其转换为逻辑消息树,这是反映消息逻辑结构的代理数据结构。无论您的转换逻辑是采用 Java 或 ESQL 来表达的,还是将其表示为图形映射,代理的所有处理节点均使用逻辑消息树。该示例应用了某个逻辑,此逻辑转换消息并创建新消息、输出逻辑消息树,然后逻辑消息树转换为将消息表示为 XML 文档的输出位流。

将位流转换为逻辑消息树(解析)以及将逻辑消息树转换回位流(序列化或编写)的代理组件称为解析器。解析器必须同时理解位流的物理格式及其逻辑结构才能创建逻辑消息树。在该示例中,您可以看到两个解析器,一个理解 COBOL 数据结构,另一个理解 XML。

只有解析器才需要理解消息的物理格式——逻辑消息树与消息位流的物理格式无关。这种物理格式与转换逻辑的分离是代理消息流的一个重要体系结构特征。

解析器在执行解析时可能使用也可能不使用某个模型。稍后您将在本文中看到使用模型的优点。

解析器的类型

显而易见,解析器必须理解它将解析和序列化的消息的格式。可以通过两种基本的方法编写解析器:

  • 编程方法——编写特定的解析器程序来解析每种消息格式。例如,如果您有五种不同的 COBOL 数据结构,您将编写五个特定于格式的解析器,并将格式信息硬编码到解析器程序代码中。当格式为固定的或者是自己定义的格式时,此方法非常有效,并具有促进特定格式的轻松优化的优点。缺点在于缺乏灵活性——您必须为每种新的格式编写新的解析器程序,并且如果格式更改,您就必须更改、重新编译、重新链接和重新部署解析器程序。
  • 描述方法——您将编写单个通用的模型驱动的解析器程序来解析所有格式,每种消息格式由各自的模型表示。有关格式的知识不在解析器中,而是在模型中,模型可由解析器在运行时直接访问,或者将其生成为解析器可调用的代码。模型驱动的解析是非常灵活的方法,因为更改和部署模型将更加容易,但是缺点在于,通用解析器的优化较为困难。

WebSphere Message Broker 同时使用编程和描述解析器,具体取决于涉及到的消息格式的性质。

为什么要对消息建模?

对消息建模的理由有很多。下面的理由适用于解析器在运行时对模型的使用:

  • 大多数消息不是自己定义的——通常,需要某个模型来解析消息位流。例如,C 或 COBOL 程序创建的消息只是二进制数据的流,在没有某些智能来进行解释的情况下毫无意义,这就是模型派上用场的地方。XML 则相反——它包含嵌入的结构信息,使得 XML 解析器无需使用模型即可解析任何 XML 文档。
  • 验证需要模型——如果您希望验证消息的结构是正确的,则需要某个模型。XML 解析器可以解析任何 XML 文档,但它仍然需要模型来执行验证。

下面的理由适用于在设计时对模型的使用:模型与解析器是否实际使用模型无关。

  • 加速转换开发——例如,从源消息到目标消息的图形映射在无模型的情况下是不可能实现的。如果您以这种方式转换 XML 文档,即使 XML 解析器在运行时选择不使用模型,您也需要模型。
  • 提供版本控制——当存储在集中的共享存储库中时,模型提供了跟踪消息的不同版本的理想方法。
  • 提供文档——模型提供了可在程序员、业务分析人员和集成专家之间共享的消息文档。

WebSphere Message Broker V6 中的解析、建模和域

将由消息流处理的每个消息必须与某个域关联。域确定了在解析和序列化该消息时使用的解析器。每个域适合于特定的消息分类,并且某些域支持多个不同的消息分类。输入消息的域通常在消息流的输入节点上指定,但是也可以由 MQRFH2 Header 或 JMS Header 指定。用于输出消息的域是在逻辑树中创建消息时指定的。为简单起见,域的解析器具有与域相同的名称——实际上,域和解析器表示同一个意思。

WebSphere Message Broker 提供了几个不同的域。您将为相关消息格式选择最适合的域。例如:

  • 对于不使用模型的 XML 文档的编程解析,存在一组通用的 XML 域:XML、XMLNS 和 XMLNSC。
  • MRM 域是最灵活的域。它具有模型驱动的通用解析器,可解析二进制消息、文本消息和 XML 文档。
  • 为 MIME 消息(SwA、RosettaNet 等等)和 SAP IDOC 结构提供了专门的域。
  • 当将消息视为不透明的、不进行解析或者只是进行路由时,可以使用 BLOB 域。

如果没有某个已提供的域适合于特定的消息格式,您可以编写自己的编程或描述解析器,以供您自己的用户定义的域使用。

WebSphere Message Broker V6 中的通用 XML 域

提供了一组不使用 XML 模型解析 XML 文档的域。由于 XML 是如此详细,不需要模型来解析 XML,并且可以编写解析器以编程方式解析 XML。

  • XML 域——处理 XML 文档的原始方式。它不支持 XML 命名空间,建议不要将其用于开发新的消息流。
  • XMLNS 域——为提供 XML 命名空间支持而添加的域。命名空间的使用改变了逻辑消息树的内容(但不改变形状),这就是创建新域而不是修改原始 XML 域的原因。XMLNS 和 XML 域均创建其形状与 XML 数据模型紧密一致的逻辑树,因此用于格式设置的空白得以保留,简单元素和属性的值包含在该树的单独子节点中。
  • XMLNSC 精简域——在 WebSphere Message Broker V6.0 中添加,用于减少在 XML 文档基础上创建的逻辑消息树占用的内存量。这种精简行为改变了逻辑消息树的形状,这就是创建新域的原因。缺省情况下,用于格式设置的空白被丢弃,简单元素和属性没有子节点。这样可以节省大量的内存。XMLNSC 域是第一个利用了称为解析器选项的功能的域。这些选项是一组作为节点属性公开的选项,这些属性在运行时传递给特定解析器,从而使解析器的行为可以在每个节点的基础上受到控制。

WebSphere Message Broker V6.0 中的 MRM 域

最灵活的域称为 MRM,它具有模型驱动的通用解析器。例如,MRM 解析器可以根据模型执行消息的运行时验证。

MRM 域支持对来自用 C、COBOL、PL/1 和其他语言编写的应用程序的二进制消息建模。这种支持包括能够直接在 C 头文件或 COBOL Copybook 的基础上创建消息模型。二进制消息的建模使用一种称为自定义有线格式(Custom Wire Format,CWF)的物理格式。

MRM 支持对带格式的文本消息建模,这些消息也许带有由标记确定或由特定分隔符分隔的字段,或者同时带有这两种格式。这包括诸如 SWIFT、EDIFACT、X12、HL7 和 FIX 等行业标准(作为扩展可用),以及诸如逗号分隔值(Comma Separated Values,CSV)等常用文本消息。文本消息的建模使用称为标记/分隔字符串格式(Tagged/Delimited String Format,TDS)的物理格式。

MRM 域支持对 XML 消息建模,包括利用了 XML 命名空间的 XML 消息。由于使用模型来解析 XML,它提供了超出通用 XML 域的额外功能。示例包括在逻辑消息树中创建具有正确数据类型的对象,以及根据模型验证 XML。XML 消息的建模使用一种称为 XML 有线格式(XML Wire Format,XML)的物理格式。解析 XML 时,MRM 的行为与诸如 XMLNSC 等“精简”域类似。

WebSphere Message Broker V6.0 中的 IDOC 域

在 WebSphere Message Broker V6.0 中,IDOC 域是建议用于解析从 WebSphere MQ Link for R/3 传递到代理的 SAP 应用程序链接支持(Application Link Enabling,ALE)文本 Idoc 的方法。但是,IDOC 域具有某些限制:

  • 它与映射节点不兼容,因为路径中插入了 MRM 元素(例如,Root.DD[1].MRM.xxx)。
  • 导入步骤同时需要使用 IA0F 实用工具程序对 C 头文件进行预处理(例如,删除 #define,填充至 1000 个字节)和后期处理(将消息名称改为大写)。IA0F Support Pac 包含一组工具,可帮助您在使用 IDOC 解析器时创建消息集。
  • File IDocs 不受支持。

在 WebSphere Message Broker V6.0 中创建和使用消息集

消息模型存在于称为消息集的容器中。创建和使用消息集时的典型事件序列如下:

  1. 创建一个消息集项目和消息集。
  2. 导入由 XML DTD、XML 模式、WSDL 类型、C 结构或 COBOL 结构描述的应用程序消息格式,从而创建和填充消息定义文件。然后您可以使用消息定义编辑器编辑消息的逻辑结构,以及物理格式注释。
  3. 或者,您可以创建空消息定义文件,并且仅使用编辑器创建逻辑结构和物理注释。
  4. 如果消息集中的消息模型将由 MRM 解析器在运行时使用,您必须将它们部署到代理。作为部署单元的是消息集。这可以通过将消息集添加到代理存档 (.bar) 文件来实现,从而导致将消息集生成为称为消息字典的精简形式。
  5. 如果消息集中的消息模型将由映射编辑器或 ESQL 编辑器引用,您必须设置消息流对象,以便它引用消息集项目。这是使用 File-Properties 菜单完成的。
  6. 如果消息集中的消息模型将由其他工具用于创建 Web 服务,您可以使用向导在消息集基础上生成 WSDL。

图 2 显示了将消息集部署到 WebSphere Message Broker V6.0 中的 Message Broker 运行时的事件序列。

图 2. 将消息集部署到 WebSphere Message Broker V6.0 中的运行时
将消息集部署到 WebSphere Message Broker V6.0 中的运行时
将消息集部署到 WebSphere Message Broker V6.0 中的运行时

WebSphere Message Broker V6.1 中的解析和建模增强功能

下面我们将描述 WebSphere Message Broker V6.1 中使用的解析器和域的增强功能。

两个重要的现有域得到了增强:

  • XMLNSC 域——现在使用新的内部高速解析器。与在 WebSphere Message Broker V6.0 中一样,可以在不使用模型的情况下使用 XMLNSC 域,但是还可以根据实际 XML 模式进行解析和验证,因此变成了模型驱动的域。
  • MRM 域——经过增强以增加可建模的非 XML 消息格式的数量,并使得建模更加容易。

WebSphere Message Broker V6.1 添加了两个新的模型驱动的域:

  • SOAP 域——用于 WebSphere Message Broker V6.1 中提供的新的 SOAP 节点。这些节点处理 SOAP XML、MIME 包装的 SOAP with Attachments 以及 MTOM,并提供了对 WS-Addressing 和 WS-Security 标准的支持。创建了规范树,由这个新的域拥有。
  • DataObject 域——用于新的 6.1 适配器节点。这些节点使用嵌入的 WebSphere 适配器直接与 EIS 系统连接。创建了一个树来表示适配器业务对象,该树由这个新的域拥有。

两个现有域正式被弃用:

  • XML 域——不再需要,因为可以改为使用 XMLNSC 或 XMLNS。
  • IDOC 域——功能有限。MRM 现在可以处理 SAP ALE 和 File IDocs,因此应该取代 IDOC 域。

在此例中,弃用意味着不再进行增强,并将在将来的 WMB 版本中撤消。

WebSphere Message Broker V6.1 中对消息集的更改

WebSphere Message Broker V6.1 中的工具包发生了一些重要更改,这些更改影响到如何将模型部署到消息代理运行时。在 WebSphere Message Broker V6.1 中,引入了一个称为“受支持的消息域”的新属性。当将消息集添加到某个 .bar 文件时,新的“受支持的消息域”属性将确定生成什么运行时模型并将其添加到 .bar。

对于 MRM 和 IDOC 域,在运行时将需要消息字典。因此将在消息集的基础上生成 .dictionary 文件并将其添加到 .bar 文件。这与 WebSphere Message Broker V6.0 的行为相同。

在运行时,XMLNSC 域在进行验证的情况下需要 XML 模式,DataObject 域需要 XML 模式,SOAP 域需要 XML 模式和 WSDL。对于这些域,将在每个消息定义文件的基础上生成 .xsd 文件。将 .xsd 文件压缩到单个 .xsdzip 文件中。然后将 .xsdzip 文件添加到 .bar 文件。此外,对于 SOAP,将把所有的 .wsdl 文件添加到 .xsdzip 文件。

因此,取决于受支持的域,消息集会导致生成 .dictionary 文件和/或 .xsdzip 文件,并将其添加到 .bar 文件。WebSphere Message Broker V6.1 中对消息集的更改:

图 3. 在 WebSphere Message Broker V6.1 中将消息集添加到 .bar 文件
在 WebSphere Message Broker V6.1 中将消息集添加到 .bar 文件
在 WebSphere Message Broker V6.1 中将消息集添加到 .bar 文件

如果消息集被标记为支持 XMLNSC 或 SOAP 或 DataObject 域,则在将消息集添加到 .bar 文件时,将会创建一个 .xsdzip 文件来包含所生成的 XML 模式和原始 WSDL 文件。此文件将在代理上解压缩,并根据消息集保存在代理的文件系统上。

当您指定消息流使用 XMLNSC 或 SOAP 或 DataObject 作为消息域时,您还必须提供消息集的名称。该域的解析器将相应地加载和使用 XML 模式或 WSDL。图 4 显示了在将消息集部署到 WebSphere Message Broker V6.1 中的 Message Broker 运行时时的新事件序列:

图 4. 将消息集部署到 WebSphere Message Broker V6.1 中的运行时
将消息集部署到 WebSphere Message Broker V6.1 中的运行时
将消息集部署到 WebSphere Message Broker V6.1 中的运行时

对 XMLNSC 域的增强

XMLNSC 域的操作方式已发生了若干重要的变化。对 XMLNSC 的增强使其成为大多数情况下建议用于 XML 解析的域。

新的内部高速解析器

IBM Research 开发了一个新的、更快的 XML 解析器。它直接取代了 IBM 的 Xerces 解析器的功能,因此 XMLNSC 域已切换为使用新的解析器,从而具有改进的性能。这个切换没有外部影响。在迁移到 WebSphere Message Broker V6.1 时,指定 XMLNSC 的 WebSphere Message Broker V6.0 消息流将一如既往地操作。请注意,仅对 XMLNSC 进行了此更改,而没有对继续使用 Xerces 的 XML、XMLNS 或 MRM XML 做出此更改。

XMLNSC 域的体系结构意味着它比其他 XML 域使用显著更少的 CPU。XMLNSC 在从 XML 文档构建消息树时也使用更少的内存。因此,如果性能对您的应用程序非常关键,则应该使用 XMLNSC 域。

根据 XML 模式进行的验证

MRM 解析器使用的验证逻辑并不完全遵守 W3C XML 模式规范。WebSphere Message Broker v6.1 中的 XMLNSC 解析器解决了此缺点,并提供与标准兼容的模式验证。

XMLNSC 验证的性能也在相当大的程度上胜过 MRM 验证,因为新的 XML 解析器的体系结构针对模型驱动的场景进行了优化。验证与 XML Schema 1.0 规范完全兼容。

XMLNSC 以两种模式之一进行操作。用于实现 WebSphere Message Broker V6.0 兼容性的缺省方式是以非验证模式操作。如果选择了验证,则它将在验证模式下操作,并预期为其提供一个消息集属性。

与 MRM 一样,是否要验证将由现有节点的 Validate 选项决定。如果 Validate 选项设置为 None,则不会对消息进行验证。如果 Validate 选项设置为 Content and value 或 Content,则将根据 XML 模式对消息进行验证。图 5 显示了如何启用验证以便根据 XML 模式进行解析和验证:

图 5. 启用 XMLNSC 域的验证
启用 XMLNSC 域的验证
启用 XMLNSC 域的验证

如果选择了验证,则还必须提供消息集的名称,该名称将用于定位代理的文件系统上的 XML 模式。(不需要 Message Type 属性,因为将使用文档中的根元素的名称。不需要 Message Format 属性,因为 XMLNSC 仅使用逻辑模型)。图 6 显示了如何在选择了验证时提供消息集属性:

图 6. 指定消息集属性以定位使用 XMLNSC 进行验证所需的 XML 模式
指定消息集属性以定位使用 XMLNSC 进行验证所需的 XML 模式
指定消息集属性以定位使用 XMLNSC 进行验证所需的 XML 模式

树中的正确数据类型

在 WebSphere Message Broker V6.0 中,XMLNSC 从不使用模型,因此必须假设它遇到的所有 XML 数据都是字符数据类型。此外,它在树中创建的所有语法元素都是 ESQL 数据类型 CHARACTER。在 6.1 中,如果 XMLNSC 以验证模式操作,则它将具有 XML 模式,因此知道 XML 数据的 XML 模式数据类型。这使得所构建的语法元素具有与 XML 模式数据类型匹配的数据类型,构建方式与 MRM 构建其树的方式相同。用于实现 WebSphere Message Broker V6.0 兼容性的缺省方式是构建仅具有 CHARACTER 数据类型的树。如果选择了名为 Build tree using XML Schema data types 的新选项,则会构建具有适当数据类型的树。这个新选项可以在 XMLNSC Parser Options 下面找到,并且仅在验证模式下才是启用的。图 7 显示了如何选择新选项 Build tree using XML Schema data types。

不透明解析

这是用于描述一个性能增强的术语,在该性能增强中,指定的 XML 元素并不完全进行解析,而是将其跳过,并将原始位流作为 Unicode 字符串插入树中。此功能在 WebSphere Message Broker V6.0 中可用,但是仅以有限的方式公开。在 WebSphere Message Broker V6.1 中,它通过名为 Opaque elements 的新选项完全公开,允许您指定希望不透明地解析的元素的 XPath。此新选项可在 XMLNSC Parser Options 下面找到,并且仅在非验证模式下启用,因为根据定义,验证涉及到完全展开所有元素。图 7 显示了如何在新选项 Opaque elements 中指定您希望不透明地解析的元素的 XPath:

图 7. XMLNSC Parser Options
XMLNSC Parser Options
XMLNSC Parser Options

对 XMLNSC 的增强使其成为大多数情况下建议用于 XML 解析的域。如果您需要创建更紧密地遵守 XML 信息集 (XPath) 的逻辑树,或者希望保留内联 DTD,则应该使用 XMLNS 域。仅当您有由 MRM CWF 或 TDS 解析的非 XML 数据,并且只希望将其呈现为 XML 而不做进一步的转换时,才应该将 MRM-XML 域用于新的消息流。XML 域已被正式弃用,不应该将其用于新的应用程序。

对 MRM 域的增强

MRM 域存在若干针对二进制和文本消息的改进。

固定长度数据的自动截断

如果 Message Broker V6.0 中的消息流创建了将写出为 CWF 或 TDS 固定长度字段的数据,或者该数据太长,则会引发异常。如果您希望避免该异常,则必须将数据截断以适应该字段,并且必须编写附加的逻辑代码来处理截断。此外,这必须使用硬编码的长度,因为没有 API 可用于访问模型以获得该长度。

在 WebSphere Message Broker V6.1 中,新的 CWF 和 TDS 选项可用于在写出数据之前截断过长的输出数据。它们适用于消息集中的所有消息定义文件中的所有固定长度的字段。这些新的 CWF 和 TDS 选项如图 8 和 9 所示:

图 8. 用于截断固定长度字符串的新的 CWF 消息集属性
用于截断固定长度字符串的新的 CWF 消息集属性
用于截断固定长度字符串的新的 CWF 消息集属性
图 9. 用于截断字符串的新的 TDS 消息集属性
用于截断字符串的新的 TDS 消息集属性
用于截断字符串的新的 TDS 消息集属性

TDS 标记中的十六进制数据

标记 (markup) 这个术语用于描述消息格式中不属于数据值的那些字符。TDS 分隔符、标记 (tag)/数据分隔符、组指示符、组终止符和重复元素分隔符全都是标记 (markup) 的示例。

在 WebSphere Message Broker V6.0 中,当 TDS 标记 (markup) 或 TDS 标记 (tag) 中使用了十六进制值时,将无法对消息建模。WebSphere Message Broker V6.1 中做出了以下增强:

  • TDS 标记除了更常见的文本字符以外,还可以包含十六进制值。用于指定单个十六进制值的语法为助记符 <0xNN>,其中 NN 为从 00 到 FF 的十六进制数字。这些数字表示一个 Unicode 字符,而不是输入消息的代码页中的一个字符。
  • TDS 标记现在可以包含 Unicode 字符和十六进制字符 <0xNN> 助记符。
  • TDS 数据模式现在可以包含十六进制值。这允许在解析时在正则表达式中使用十六进制值。十六进制值以 \xNN 的形式指定,其中 N 为从 0 到 F 的十六进制数字。

改进的 CSV 消息支持

逗号分隔值(Comma Separated Values,CSV)消息非常普遍,已有多个 TDS 版本支持它。为了使得对 CSV 消息的建模更加容易,WebSphere Message Broker V6.1 中的 TDS 经过了以下增强:

  • 提供了一个新的 TDS 消息集属性 Quote Character。这允许将开头和结尾引号字符用作转义机制。在解析时,引号导致将其中包括的所有字符视为数据,而不会潜在地将其视为标记,并且始终会在将数据添加到树之前删除引号。在输出时,任何包含 TDS Reserved Characters 消息集属性中指定的字符之一的数据字段将添加引号(这类似于 TDS Escape character 消息集属性的现有行为)。
  • 提供了一个新的 TDS 元素属性 Repeat Reference。这允许通过消息中的一个整数字段指示某个元素的重复次数。其工作方式与相同名称的现有 CWF 属性的工作方式相同。
  • 提供了一个名为 CSV 的新的 TDS Messaging Standard 设置,它将诸如 Data Element Separation、Quote Character、Reserved Characters 和 Delimiter 等 TDS 属性预设为适合 CSV 的值。
  • 提供了简单 CSV 消息的预构建 TDS 模型,可以使用 New Message Definition File From ... IBM Supplied Message 向导将其添加到消息集。

新的 TDS 消息集属性 Quote Character 和名为 CSV 的新的 TDS Messaging Standard 设置如图 10 所示:

图 10. 用于 CSV 消息建模的 TDS 增强
用于 CSV 消息建模的 TDS 增强
用于 CSV 消息建模的 TDS 增强

对包含文本和二进制数据的消息的建模改进

在 WebSphere Message Broker V6.0 中,大多数类型的数据仅由 CWF 处理,而标记仅由 TDS 处理。在 WebSphere Message Broker V6.1 中,TDS 已扩展到处理更广泛的二进制数据类型。这意味着 TDS 元素属性现在非常类似于 CWF 元素属性。此更改的关键是对现有的 TDS 元素属性 Physical Type 添加了更多功能。现有的设置 Characters 和 Messaging Standard Alternate 已重新命名为 Text 和 TLOG Specific。添加了新的通用设置 Null Terminated String、Length Encoded String 1、Length Encoded String 2、Packed Decimal、External Decimal、Integer、Float、Time Seconds、Time Milliseconds 和 Binary。这些新设置的行为与对应的 CWF 设置几乎一样。

WebSphere Message Broker V6.1 中添加了以下用于新的物理类型的新的 TDS 元素属性:

  • Length Units
  • Signed
  • Sign EBCDIC Custom Overpunched

这些新的 TDS 元素属性如图 11 所示:

图 11. 新的 TDS 元素属性
新的 TDS 元素属性
新的 TDS 元素属性

在 WebSphere Message Broker V6.1 中,某些 TDS 元素属性已得到了扩展。表 1 显示了对这些 TDS 元素属性的更新:

表 1. 已得到扩展的 TDS 元素属性
TDS 元素属性WebSphere Message Broker V6.0 设置WebSphere Message Broker V6.1 设置
Sign Orientation

None

Leading

Trailing

Leading Separate

Trailing Separate

Leading Overpunched

Trailing Overpunched

Encoding Null

NullPadFill

NullLogicalValue

NullLiteralValue

NullPadFill

NullLogicalValue

NullLiteralValue

NullLiteralFill

仅当您将 Physical Type 设置为 Text 或 External Decimal,并且已选择了 Signed 时,Sign Orientation 属性才会启用。

如果 Physical Type 为 Text,则 Sign Orientation 的唯一有效值为 Leading Separate 和 Trailing Separate。

如果 Physical Type 为 External Decimal 并且选择了 Sign EBCDIC Customer Overpunched,则 Sign Orientation 的唯一有效值为 Leading Overpunched 和 Trailing Overpunched。这些更新后的 TDS 元素属性如图 12 所示:

图 12. 更新后的 TDS 元素属性
新的 TDS 元素属性
新的 TDS 元素属性

在 WebSphere Message Broker V6.1 中,添加了新的 TDS 消息集属性以匹配对应的 CWF 属性。表 2 列出了这些新属性。

表 2. 新的 TDS 消息集属性
消息集属性设置WebSphere Message Broker V6.1 中的新消息集属性
消息标准用户定义的混合模式——针对混合的文本和二进制数据
数字设置

聚进十进制 (Packed Decimal) positive code

Derive sign from logical type

缺省字节顺序

缺省聚进十进制字节顺序

缺省浮点格式

Boolean 值表示

二进制 boolean true 值

二进制 boolean false 值

常规设置用于缺失元素的输出策略

这些新的 TDS 消息集属性如图 13 所示:

图 13. 新的 TDS 消息集属性
新的 TDS 消息集属性
新的 TDS 消息集属性

除了以下区别以外,这些 TDS 扩展使得 TDS 几乎与 CWF 不相上下:

  • TDS 不支持字节对齐规则。不存在与 CWF 元素属性 Byte Alignment、Leading Skip Count、Trailing Skip Count 对应的属性。
  • C 和 COBOL 导入程序并不始终完全填充 TDS 模型。这些导入程序设置逻辑属性和 CWF 物理格式属性,但是不设置 TDS 物理格式属性。

纯 COBOL 和 C 建模应该继续使用 CWF。

对 SAP 文本 IDocs 的支持

MRM TDS 现在具有解析 ALE 和 File IDocs 的所有功能。在 WebSphere Message Broker V6.1 中,建议使用 MRM TDS 解析从 WebSphere MQ Link for R/3 发送或导出到文件系统的 IDocs。IDOC 域已正式弃用。请注意,作为业务对象从新的 WebSphere Adapter for SAP 接收的 IDocs 应该由新的 DataObject 域处理。

用于对 SAP 文本 IDoc 建模的过程现在如下:

  • 使用 New Message Definition File From ... IBM Supplied Message 向导将 IDoc DC/DD 的预构建 TDS 模型导入消息集。存在用于 ALE 和 File 风格的预构建模型。这将创建名为 Text_IDoc 的 TDS 物理格式(如果还不存在的话)。
  • 确保您的 TDS 物理格式将 Messaging Standard 属性设置为 User Defined Text。
  • 使用 New Message Definition File From ... C 向导导入用户结构 C 头文件,并选择用于 ALE 或 File IDocs 的新选项。不需要任何预处理,因为 IA0F 实用工具的逻辑现已在该向导中。使用 MRM 多部分消息将用户结构链接到 DD。
  • 非常方便,C 导入程序创建的缺省 TDS 模型无需任何手动编辑即可正确地对用户结构建模,因为 IDoc 数据全都是固定长度的字符串。

图 14 显示了 New Message Definition File From ...C 向导,它允许您为 IDoc 选择预处理选项:

图 14. 对 SAP 文本 IDoc 的支持
对 SAP 文本 IDoc 的支持
对 SAP 文本 IDoc 的支持

结束语

本文描述了对 WebSphere Message Broker V6.1 中的消息建模和解析所做的增强。XMLNSC 域是建议用于解析和编写大多数应用程序的 XML 数据的域。XMLNSC 通过以下方式得到了增强:

  • XMLNSC 域现在使用高性能的 XML 解析器,这意味着它现在比其他 XML 域使用显著更少的 CPU。XMLNSC 在从 XML 文档构建消息树时也使用更少的内存。这为其提供了相对于 XMLNS 和 XML 解析器的显著性能改进。因此,如果性能对您的应用程序非常关键,则应该使用 XMLNSC 域。
  • XMLNSC 域已变为模型驱动的域,因为它现在可以根据实际 XML 模式进行解析和验证。XMLNSC 验证的性能也在相当大的程度上胜过 MRM 验证,因为新的高性能 XML 解析器的体系结构针对模型驱动的场景进行了优化。验证与 XML Schema 1.0 规范完全兼容。
  • XMLNSC 域在非验证模式下支持不透明解析。这降低了解析和编写消息的成本,并且可能改进消息流其他部分中的性能。

MRM 域通过以下方式得到了增强:

  • 自动截断固定长度的数据。
  • 可以在 TDS 标记 (markup)、标记 (tag) 和数据模式中包含十六进制值。
  • 对 CSV 消息的改进支持,包括 Quote Characte、Repeat Reference、新的 CSV Messaging Standard 设置、简单 CSV 消息的预构建 TDS 模型。
  • 对混合二进制和文本消息的支持。
  • 对 SAP 文本 IDoc 的支持。

相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=386167
ArticleTitle=WebSphere Message Broker V6.1 中的消息建模和解析增强功能
publish-date=05072009