网易邮箱接收ibm的邮件_在IBM Integration Bus中发送和接收带有大型附件的SOAP消息

网易邮箱接收ibm的邮件

在IBM Integration Bus中实现内部缓冲区和字符串处理结构的数据类型可能会限制可以在单个消息中处理的数据大小。 IBM Integration Bus有两个主要的数据大小限制。首先，它对比特流中的位置索引有2 Gb的限制。其次，它对内部数据缓冲区的大小限制为4 Gb。本教程演示了如何使用MTOM和MIME解析器发送和接收具有较大附件的SOAP消息。

2 Gb限制

解析器接口使用带符号的int数据类型来记录位流中的位置。带符号的int类型具有2 Gb的限制。通过扩展，解析器接口无法访问比特流中超过2 Gb标记的任何点。

4 Gb限制

第二个限制是在数据结构中，用于存储表示消息逻辑模型中的解析树数据的数据缓冲区。此结构使用unsigned int数据类型表示内部缓冲区的大小以及此缓冲区中的任何位置信息。无符号int数据类型的限制为4 Gb。

首先，由于输入位流的大小限制为2 Gb，因此似乎无法使用数据缓冲区中可用的附加2 Gb。但是，CHARACTER数据存储在解析树中的地方，它以UCS-2（UTF-16变体）表示。此代码页是双字节代码页。因此，单字节代码页中的每个单个字符（例如ASCII或UTF-8）由消息树中的两个字符表示。例如，考虑在解析树中表示为单个CHARACTER元素的整个2 Gb输入流。

同样，您可以使用扩展SQL（ESQL），Java，C或.NET接口直接在树中创建元素。在这些情况下，如果不通过使用缓冲区扩展Swift耗尽系统上可用的内存就很难实现元素创建。但是，从理论上讲，您可以直接使用大于2 Gb的数据缓冲区创建元素。但是，4-Gb限制仍然有效。

流程设计限制的后果

这些限制的最明显结果是，由一个输入节点的一次调用读取的单个输入消息的最大大小限制为2 Gb。同样，由于CHARACTER数据在消息树中扩展，因此消息树中单个元素的最大大小为2 Gb字符。

此外，某些类型的处理（例如需要对Base64编码数据或十六进制编码数据进行处理）可能会导致在树中存储输出所需的空间大于原始源数据。例如，如果处理需要对UTF-8数据进行hexBinary编码，则解析树中需要四倍的空间。与输入数据相比，每个单个字节表示为2个字节，其中包含十六进制表示。然后，将这2个字节中的每个字节存储为2字节UCS-2字符。这些因素将经过这种类型的处理的元素的大小限制为1 Gb输入数据。

在某些情况下，使用流传输（例如FileInput节点或TCP / IP节点）可以将整个大消息拆分为几个较小的记录。通过使用此技术，可以处理大于2 Gb的输入消息。但是，消息流的单次调用永远不会呈现超过2 Gb的数据。

在其他情况下，运输选择受到限制。并非IBM Integration Bus中的所有传输都支持流的概念。在这种情况下，仔细使用消息树并了解如何存储和扩展数据可以提高消息流可以处理的最大消息大小。例如，二进制大对象（BLOB）数据不会在树中扩展为UCS-2。如果消息的某些部分可以表示为二进制内容，则在整个处理过程中确保将此数据视为二进制可以处理更大的消息。

用例概述

考虑到IBM Integration Bus可以集成的各种后端系统，某些集成方法存在局限性。具体地说，这些限制是指使用Web服务发送和接收大文件的能力。使用HTTP或Web服务传输大文件不是最有效的方法。但是，有时这种集成方法是唯一可用的方法。

您可以使用Web服务调用从几种方法中选择发送和接收文件的方法：

直接在CDATA标记内的SOAP请求中发送二进制数据。
在SOAP请求中发送Base64编码的文件。
将SOAP与附件一起使用。
使用消息传输优化机制（MTOM）。

有关使用Web服务的不同方法和文件传输的信息，请参阅WebSphere Message Broker V6.1中的文件处理。对于本教程中的用例，后端服务支持MTOM。下一节说明如何使用MTOM发送和接收文件，同时绕过IBM Integration Bus中文件大小的内部限制。

通过将HTTP节点与MIME解析器结合使用来实现MTOM

在典型情况下，IBM Integration Bus中的SOAP请求节点在以下条件下支持MTOM：

在WS-Extensions选项卡上启用了MTOM。
在前面的输入或转换节点中，Validation属性设置为Content和Value 。
消息树的SOAP.Attachments部分中没有子级。
输出消息中存在的元素在模式中定义为base64Binary。

在不受IBM Integration Bus中树中元素大小的限制的情况下，此解决方案在处理时间和内存消耗方面可能会很昂贵。验证巨大的SOAP消息可能会产生很大一部分费用。此外，通过使用Base64编码或十六进制编码对数据进行编码的成本随消息的大小而增加。这样做的代价可能是验证巨大的SOAP消息，以及需要在SOAP请求节点之前将文件编码为Base64。

解决此限制的方法可以在处理时间和内存消耗方面提供更有效的解决方案。此解决方案避免了在将文件发送到Web服务之前验证SOAP请求并将文件编码为Base64。

以下各节说明如何使用HTTP节点和MIME解析器发送和接收大文件。在此示例中，同一服务在请求消息中需要一个文件，并在响应中返回该文件。

发送文件

将HTTP节点与MIME解析器一起使用，可以绕过IBM Integration Bus中的文件大小限制。本质上，MTOM消息是线路上的多部分消息。消息的第一部分是SOAP信封，它通过标识符（ID）引用文件。消息的第二部分是由ID标识的文件。

清单1显示了在线上的MTOM消息的示例。

清单1.在线上的MTOM消息

Content-Type: multipart/related; boundary= dwMIMEBoundry
;
type="application/xop+xml"; start="<soap@ibm.com>";
start-info="text/xml"; charset=UTF-8
u
--dwMIMEBoundary
content-type: application/xop+xml; charset=UTF-8; type="text/xml";
content-transfer-encoding: binary
content-id:<soap@ibm.com><?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header/><soapenv:Body><Request><input><fileName></fileName><file><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include"href="cid:thefile@ibm.com"/></file></input></Request></soapenv:Body>
</soapenv:Envelope>
--dwMIMEBoundary
content-type: text/plain
content-transfer-encoding: binary
content-id:<thefile@ibm.com>... binary data goes here ...

如前所述，MTOM和MIME解析器可以帮助绕过大小限制。

图1显示了使用MIME实现MTOM的子流的一部分。

图1.实现MTOM的子流程

构建MIME消息发生在BuildRequest ESQL Compute节点中。清单2显示了此节点的实现。在此代码中，文件位于Compute节点之前的环境中。该代码分为三个部分。每个部分对应于MTOM消息的一部分：

第1部分定义了开始部分的边界以及所需的任何HTTP标头，例如Web服务的URL。
第2节创建SOAP请求消息并定义消息的“开始”部分。
第3节使用与SOAP信封中定义的内容ID相同的内容ID定义消息的文件部分。

清单2.节点实现

------------------------------------------Section 1--------------------------------------------
DECLARE MIMEBoundary CHAR 'dwMIMEBoundary';
DECLARE url char '';
SET OutputLocalEnvironment = InputLocalEnvironment;
SET OutputLocalEnvironment.Destination.HTTP.RequestURL ='theWebService.com';
SET OutputRoot.Properties.ContentType = 'multipart/form-data; boundary=' || '"'|| MIMEBoundary||'"';
SET OutputRoot.HTTPRequestHeader."X-Original-HTTP-URL" ='theWebService.com';
SET OutputRoot.HTTPRequestHeader."Content-Type" = 'multipart/related; type="application/xop+xml"; start="<soapenv@ibm.com>"; start-info="text/xml"; boundary=' || '"'|| MIMEBoundary||'"';
SET OutputRoot.HTTPRequestHeader."SOAPAction"='';
SET OutputRoot.HTTPRequestHeader."MIME-Version"='1.0';
CREATE FIELD OutputRoot.MIME TYPE Name;
DECLARE mm REFERENCE TO OutputRoot.MIME;
CREATE LASTCHILD OF mm TYPE Name NAME 'Parts';
CREATE LASTCHILD OF mm.Parts TYPE Name NAME 'Part';------------------------------------------Section 2--------------------------------------------
Creating the Soap Request message in the environment in order to cast as BLOB later.
CREATE LASTCHILD OF Environment.Variables DOMAIN 'XMLNSC' NAME 'XMLNSC';DECLARE soapenv NAMESPACE 'http://schemas.xmlsoap.org/soap/envelope/';
DECLARE xop NAMESPACE 'http://www.w3.org/2004/08/xop/include';
CREATE FIELD Environment.Variables.XMLNSC.soapenv:Envelope.soapenv:Body;
SET Environment.Variables.XMLNSC.soapenv:Envelope.soapenv:Body.ns:Request.input.fileName='theFilename';
SET Environment.Variables.XMLNSC.soapenv:Envelope.soapenv:Body.ns:Request.input.file.xop:Include.(XMLNSC.Attribute)href='cid:thefile@ibm.com';
DECLARE soapEnv BLOB ;
SET  soapEnv = CAST (ASBITSTREAM( Environment.Variables.XMLNSC) AS BLOB CCSID 1208);------Doing first part of the message which contains the soap envelope-------------DECLARE Part1 REFERENCE TO mm.Parts.Part[1];
CREATE FIELD Part1."Content-Type" TYPE NameValue VALUE 'application/xop+xml; charset=UTF-8; type="text/xml"';
CREATE FIELD Part1."Content-ID" TYPE NameValue VALUE '<soapenv@ibm.com>';
CREATE LASTCHILD OF Part1 TYPE Name NAME 'Data';
CREATE LASTCHILD OF Part1.Data DOMAIN('BLOB') PARSE(soapEnv);------------------------------------------Section 3------------------------------------------------
Adding file in the second part of the messageCREATE LASTCHILD OF mm.Parts TYPE Name NAME 'Part';
DECLARE refPart REFERENCE TO mm.Parts;
DECLARE Part2 REFERENCE TO refPart;
MOVE Part2 TO refPart.Part[2];
CREATE FIELD Part2."Content-Disposition" TYPE NameValue VALUE 'attachment; name='||'"file"; filename='||'"thefile.zip"';
CREATE FIELD Part2."Content-Type" TYPE NameValue VALUE 'application/octet-stream';
CREATE FIELD Part2."Content-Transfer-Encoding" TYPE NameValue VALUE 'binary'; CREATE FIELD Part2."Content-ID" TYPE NameValue VALUE '<thefile@ibm.com>';
CREATE LASTCHILD OF Part2 TYPE Name NAME 'Data';
CREATE LASTCHILD OF Part2.Data DOMAIN('BLOB') PARSE(Environment.Variables.file);

接收文件

当从SOAP调用响应接收文件时，文件大小限制也适用。要绕过大小限制，请使用带有HTTP节点的MIME解析器以通过MTOM接收大文件。

为确保后端服务通过使用多部分消息和MTOM进行响应，服务请求必须为多部分消息。但是，后端服务必须支持MTOM。

图2显示了使用MIME实现MTOM的子流的一部分。

图2.实现MTOM的子流程

在TransSoapToBlob计算节点中，将SOAP请求消息构建为多部分消息。在清单3中，SOAP消息位于Compute节点之前的环境变量中。

清单3. TransSoapToBlob计算节点实现

DECLARE soapString CHAR;SET soapString= Environment.Variables.SoapString;SET Environment.MIMEBoundary = 'MIMEBoundary';SET OutputLocalEnvironment = InputLocalEnvironment;SET OutputLocalEnvironment.Destination.HTTP.RequestURL ='theservice.com';SET OutputRoot.Properties.ContentType = 'multipart/form-data; boundary='
|| '"'|| Environment.MIMEBoundary||'"';SET OutputRoot.HTTPRequestHeader."X-Original-HTTP-URL"='theservice.com';SET OutputRoot.HTTPRequestHeader."Content-Type" = 'multipart/related;type="application/xop+xml"; start="<rootpart@ibm.com>";start-info="text/xml"; boundary='
|| '"'|| Environment.MIMEBoundary||'"';SET OutputRoot.HTTPRequestHeader."SOAPAction"='';SET OutputRoot.HTTPRequestHeader."MIME-Version"='1.0'; CREATE FIELD OutputRoot.MIME TYPE Name;DECLARE mm REFERENCE TO OutputRoot.MIME;CREATE LASTCHILD OF mm TYPE Name NAME 'Parts';CREATE LASTCHILD OF mm.Parts TYPE Name NAME 'Part';DECLARE soapEnv BLOB ; SET soapEnv = CAST (soapString AS BLOB CCSID 1208); DECLARE Part1 REFERENCE TO mm .Parts.Part[1];CREATE FIELD Part1."Content-Type" TYPE NameValue VALUE
'application/xop+xml; charset=UTF-8; type="text/xml"';CREATE FIELD Part1."Content-ID" TYPE NameValue VALUE'<rootpart@ibm.com>';CREATE LASTCHILD OF Part1 TYPE Name NAME 'Data';CREATE LASTCHILD OF Part1.Data DOMAIN('BLOB') PARSE(soapEnv);

显示的流的第二个节点是HTTP调用。确保“响应消息解析”的解析器设置为MIME，如图3所示。

图3.响应消息解析设置

如果服务返回有效响应，则它由两部分组成。消息的第一部分是SOAP响应。消息的第二部分是文件。

第二个Compute节点，SaveFileAndExtractResponse，将在线上发送的SOAP响应作为BLOB并将文件保存在环境中。清单4显示了实现它的代码。

清单4. SaveFileAndExtractResponse计算节点实现

SET OutputRoot.BLOB.BLOB = InputRoot.MIME.Parts.Part[1].Data.BLOB.BLOB;Set Environment.Variables.File =
InputRoot.MIME.Parts.Part[2].Data.BLOB.BLOB;

流的此分支中的最后一个节点是ResetContentDescriptor节点，该节点将BLOB（SOAP响应）解析为XMLNSC。

结论

本教程说明了如何最大化消息流可以处理的消息大小。您学习了如何使用MIME解析器来确保树的二进制部分不会不必要地扩展为字符数据。处理此大小的消息需要在承载IBM Integration Bus运行时的系统上提供大量内存。通常，将此规模的消息视为流数据。但是，在无法采用这种方法的情况下，请使用本教程中介绍的技术，通过使用MIME解析器从Web服务发送和接收大文件。当您这样做时，请遵守IBM Integration Bus中可用数据结构的限制。

翻译自: https://www.ibm.com/developerworks/websphere/library/techarticles/1601_crighton-trs/1601_crighton.html

网易邮箱接收ibm的邮件