北京火龙果软件工程技术中心 |
摘要 自从以某种通信模式将计算机连接在一起成为可能以后，文件传输就成了世界上最为常用的技术之一。过去，各种形式和规模的公司都极大程度地依赖此技术来在不同的 IT 系统之间交换基于文件的信息。尽管面向消息的中间件日渐重要，面向服务的架构也充满希望，但现代企业中的数据交换还是使用传输文件的简单过程。最近的政府法规，如 HIPAA 和 Sarbanes-Oxley，都提倡所有流程文档化、可审核并且可追查，包括并入或利用了 FTP 的业务流程。因此，企业在其策略中加入增强的文件传输功能作为整体集成策略的一部分，变得越来越重要了。 本文讨论如何在 BEA WebLogic Platform 中启用受管文件传输功能，以实现企业对企业 (B2B) 集成，同时讨论处理大文件以进行转换时涉及的一些问题。 介绍 几乎是从开始使用计算机以来，企业就已经使用文件传输了。这一简单的概念形成了许多公司的 IT 实施的基石。文件传输是指为使文件从一个应用程序传递到另一应用程序而提供的技术，其中另一应用程序可能在相同的计算平台上运行，也可能在完全不同的平台上运行。通常使用的逻辑是：业务应用程序被包含其所处理的数据的文件驱动，所以一种将业务的两个部分连接起来的方法就是交换（接收应用程序可以处理的）文件数据。 传统的文件传输一般采用批处理形式实现。信息被收集到一个应用程序/位置/系统中，然后被传递到另一个可能是远程的应用进行处理。例如，在工资处理系统中，从公司内的各个部门和区域收集考勤表信息，分批处理成数据文件，然后传送到企业大型主机。公司工资应用程序在此接收并处理这些数据文件，安排工资发放并生成工资条信息。这种机制实现了非常基本的应用程序和系统集成。但是，它有很大的局限性。其主要原因在于文件传输技术产生时，大多数使用都是以批操作形式进行的。按照美国证券交易委员会（SEC） Sarbanes-Oxley 法案的新要求，提倡所有流程文档化、可审核并且可追查，包括并入或利用了 FTP 的业务流程。因此，企业在其策略中加入受管文件传输功能作为整体集成策略不可缺少的一部分，变得越来越重要了。 扩展 SOA 直到最近，对于将现有技术应用到 SOA 世界相关的难题，只有一个标准应对方案 — 使用现有的 Web 服务增强工具中的一种在现有系统上创建新接口。典型的 SOA 架构类似图 1 所示，在此架构中，服务提供商提供一个广为人知的接口，人们使用 SOAP 或 REST 消息传递方式调用服务。
图 1. 使用 Web 服务的 SOA 但是，通常由于以下两个原因之一，这种 SOA 架构并不是始终可行或理想的：
当考虑现有的传输协议，特别是它们支持的业务流程时，我们同样面临着相似的情形。在实际应用中，许多协议仍然基于批处理，即使使用 FTP 或电子邮件分发非 XML 文档（如 Excel 文件）也是如此。与打破整个组织不同，SOA 实施必须无缝地适应和集成 — 而不必强制更改相关业务流程。在此基础上，我们将讨论 WebLogic Platform 如何帮助在现有的基于批处理的文件传输机制中并入基于 SOA 的受管文件传输功能。 用例：基于文件传输的 SOA 我们来虚构一个业务场景，从中创建基于样本文件传输的 SOA，并探讨如何在 WebLogic Platform 中启用基于文件传输的 SOA 解决方案。本示例将展示 WebLogic Platform 为实施基于文件传输的 SOA 解决方案提供的功能。有时我们会特意作一些简化，以便于理解现实示例中会如何处理。
图 2. GlobalTx Inc. 基于 SOA 的受管文件传输实施（单击图像查看全屏快照） 以 GlobalTx Inc.为例，它是美国有名的经纪公司之一，是向交易伙伴提供操作支持和交易服务的领先供应商。其传统的基于纸张和电话的系统无法满足规模需求。因此，公司决定实施基于 SOA 的 B2B 集成项目，使交易伙伴能直接向订单管理器系统（OMS）提交订单。项目的目标之一是支持包含这些订单的文件通过FTP进行安全传输，这些订单都根据 FIX（财务信息交换）规范编码。其它构想的功能包括自动文件处理，处理大文件以进行转换，以及通过版本控制功能实现有效的文件管理，防止数据重复或丢失。图 2 提供了如何为 GlobalTx 实施基于 SOA 的受管文件传输功能的快照。在以下各节中，我们将再次参考此图，了解如何通过部署基于 SOA 的受管文件传输功能，使 GlobalTx 的需求在 WebLogic Platform 中成为可能。 启用受管文件传输 在构建 WebLogic Platform 应用时，Java 控件可提供简便的方法来并入资源访问和封装业务逻辑。控件的实质是轻量的元数据驱动组件模型。有关控件用法的更多信息，请参阅文档。WebLogic Workshop 提供许多内置控件，您可通过右下角的“数据板”获取。文件控件是我们将讨论的集成控件之一。可通过文档中描述的几个简单步骤创建文件控件。但此文件控件提供的基本文件传输功能本身并不能满足 GlobalTx 提出的企业级的基于 SOA 的 B2B 集成要求。 要使文件传输在当今的业务环境中具有价值，必须具备以下服务质量和灵活性：
本文的其余部分将逐个讨论这些要求，并了解 GlobalTx 如何使用 WebLogic Platform 提供的功能来实施自己的基于 SOA 的受管文件传输解决方案。我们将详细说明构建 WebLogic Platform 应用程序所需的步骤，该应用程序同时利用能满足要求的 WebLogic Integration（如文件控件、文件事件生成器、定时服务和消息转换）和 WebLogic Portal 功能（如内容管理）。我们将介绍 WebLogic Platform 提供的一种称为Format Builder的特殊工具的使用，用它来定义从非 XML 到 XML 的转换映射。唯一要使用的第三方组件是用于安全文件传输的可构建为自定义 Java 控件的组件。 安全性 在 B2B 集成中，交易伙伴向 GlobalTx 发送的文件必须不会在路由时被截取或更改。在接收端，安全的文件传输意味着您可以信任传入文件的内容并允许内部应用程序自动处理这些文件。虽然 WebLogic Platform 不对安全文件传输提供内置支持，但您可以使用第三方 Java 客户端方便地创建自定义 FTP 控件，以提供 WLI流程项目可以安全使用的FTP。 我们来探讨一下如何使用 AppGate's MindTerm 创建自定义 FTP 控件。MindTerm 很可能是目前最流行的以纯 Java 编写实现 SSH1 和 SSH2 协议的客户端。请注意，与其它许多仅供评估的 API 不同，如果超过 100 个不同的用户需要使用 MindTerm，则必须购买商业许可证（有限商业使用许可证）。下文将概述在 WebLogic Workshop 内启用 MindTerm 的过程。 首先，要将 mindterm.jar 添加到 Workshop 应用程序的库文夹中，并按照图 3 的描述创建自定义 Java 控件：
图 3. 将 mindterm.jar 添加到 WebLogic Workshop 中的库文件夹（单击图像查看全屏快照） 下面介绍用来连接到远程服务器（在此启用 SSH 并有效配置了 SFTP）的代码的 API 快照。请注意，MindTerm 支持基于主机、基于密钥和基于密码的身份验证。在本文中，我们将使用基于密码的身份验证。基于密码和基于密钥的身份验证之间的配置相似，前者似乎是两者中较小的一部分。首先，创建一个传输对象，该对象将一个 socket 实例等传送到远程机器。此类实现 SSH2 协议栈的传输层。密钥交换算法和主机密钥类型的初始协议通过以下语句处理：
与服务器的通信从以下语句开始：
身份验证者是支持多个身份验证模块的对象，如可作为模块加入此对象的基于密码的身份验证和基于密钥的身份验证。以下是一个基于密码的身份验证模块的示例：
密码存储库是 WebLogic Integration OA&M 控制台内提供的实例，可用来根据别名存储密码。以下是一种特定于 WebLogic 的从密码存储库提取密码的方法，与已知别名对应：
此示例演示如何为提取的密码创建基于密码的身份验证模块并将其添加到用户身份验证对象：
此对象执行 SSH2 协议栈的用户身份验证层：
根据以上语句，一旦身份验证成功，将获取 ssh2connection 对象。且 sshTrans 对象内将设置连接，用于连接层，如下所示：
此处的客户端实例对象用于从远程机器检索与文件相关的信息（以及实际的文件）：
首先，为远程位置表示的目录取得文件句柄，用来获取与该目录中的文件相关的信息（从而搜索特定文件）。文件属性对象表示这样一种必然：
<file name> 表示从以上检索到的文件属性对象获取的相关单个文件。在获取文件句柄的同时，此处还提到了要对文件执行的操作：
随后，检索到文件并按如下所示加入到输出流（位于本地系统）。此语句中定义了表示该文件的文件句柄：
一旦获得文件，客户端和传输对象将断开连接：
这些示例形成了为交易伙伴与 GlobalTx 的 OMS 之间提供安全文件传输（如图 2 所示）的基础解决方案。稍后我们将深入研究定时处理和转换等其它功能。 文件处理自动化 在上一节我们了解了交易伙伴如何将文件安全地传输到 GlobalTx 的 OMS 中的文件夹。本节则集中介绍如何自动处理这些文件。WebLogic Platform 支持以下两种自动处理文件的机制，即事件处理和调度。 事件处理 事件处理包含在特定系统事件发生时启动特定操作的步骤。在 GlobalTx 一例中，包含订单的 FIX 文件到达文件夹将成为触发进一步处理的系统事件。WebLogic Platform 提供可用于此目的的文件事件生成器。我们可在 GlobalTx 的 OMS 中设置文件事件生成器，以对文件夹中文件的到达进行轮询并触发相应的文件事件，如图 4 所示。
图 4. 事件处理和调度 被触发后，可配置文件事件生成器，将内容（或对文件夹位置的引用）以二进制对象或 XML 的形式发布到“消息代理”（Message Broker）通道。在本例中，我们将包含文件位置详细信息的 XML 消息发布到“消息代理”通道，从而使文件控件可在随后处理该文件。文件事件生成器可按此处描述的几个简单步骤进行配置。它通过允许定义通道规则提供高度的灵活性，这些规则包括指定轮询间隔、轮询文件位置（作为本地目录或远程 FTP 服务器）和文件匹配模式，以及执行读后操作和文件归档等。 调度 调度与事件处理密切相关。调度支持为文件传输实施提供可观的附加价值。使用调度工具，我们就可能在特定时间点定期触发文件处理。我们可以安排 GlobalTx 的 OMS 每隔一个小时左右收取一次文件进行处理，而不是在文件到达时进行处理，如图 4 所示。进行此设置后，就不必记住需要执行的操作，然后发出命令来执行。 WebLogic Platform 提供可与文件控件一起使用的定时服务，以支持定期处理要传输的文件。此定时服务以定时事件生成器的形式提供，在用户指定的时间创建事件。当定时事件生成器检测到指定时间已过时，它会向“消息代理”通道发布消息。创建定时事件生成器的步骤与创建文件生成器的步骤相似；其主要不同之处在于可定义的通道规则。有关为定时事件生成器定义通道规则的各种选项的详细信息，请参阅此处。一旦“消息代理”通道配置了事件生成器，我们就可以定义一个订阅该通道上的事件的业务流程。图 5 演示如何使业务流程 LocalFileValidationProcess 订阅与定时事件 /sftpPrefix/sftp/sftpTimerChannel 相关联的“消息代理”通道。
图 5. 订阅“消息代理”通道（单击图像查看全屏快照） 使用从此通道获得的信息，业务流程现在可以按要求使用文件控件来处理文件。有关如何定义和使用文件控件的详细信息，请参阅文档。 文件转换 如果文件传输像在 GlobalTx 用例中一样作为集成方法使用，则向目标系统提供的信息的格式必须是所设计的系统处理格式。由于交易伙伴可能会发送按 FIX 规范编码的文件，GlobalTx 的 OMS 将需要一个转换引擎来将订单转换成进一步处理所需的格式。如图 4 所示，可通过上一节所讨论的自动处理文件的机制中的任何一种，在收到“消息代理”通道中发布的消息时调用此引擎。此操作很重要，因为将来新的交易伙伴很可能因 IT 系统和应用完全不同而使用不同的格式。因此，现代的文件传输需要有转换功能，使信息在发送或者在接收之前即已作“消息处理”，如图 6 所示。此转换应该使用易于使用的工具以达到无缝和高效文件传输效果。
图 6. 文件传输中的消息转换 WebLogic Platform 使用易于使用的 Format Builder 工具解决此需求。有关如何有效使用 Format Builder 来定义 MFL 定义的详细信息，请参阅 Workshop 文档。我们可以使用此工具来定义消息转换规则，将交易伙伴发送的 FIX 转换成 GlobalTx 的 OMS 能理解的标准 XML 格式。这可通过使用定界符表示消息结构并将此数据映射到所需输出 XML 格式的节点来完成。您可以使用 Format Builder 工具附带的 Format Tester 程序立即验证定义的映射。图 7 演示 Format Tester 如何按 Format Builder 中的定义将非 XML 文件消息转换为相应的 XML 表示法。
图 7. 使用 Format Tester 验证消息转换（单击图像查看全屏快照） 一旦映射，这些定义将存储在 MFL（Message Formatting Language，消息格式语言）文件中。MFL 文件与 XML 模式 (XSD) 非常相似；唯一的差别在于前者定义的是自定义格式，而非 XSD 定义的 XML 格式。WebLogic Integration 遵循 MFL 定义将原始数据输入进行轮换，然后根据基于消息的应用将数据映射到 Java 对象。图 8 演示非 XML 原始数据如何映射到从 MFL 定义创建的 JavaBean 对象。
图 8. 将非 XML 数据映射到 JavaBean 对象（单击图像查看全屏快照） 为以上映射所生成的代码片段如下： public void clientRequest(com.bea.data.RawData x0)throws Exception //#START: CODE GENERATED - PROTECTED SECTION - // You can safely add code above this comment in this method. // input transform parameter assignment this.fixObj = fix.FIXMLMflObject.newInstance(x0); //#END: CODE GENERATED - PROTECTED SECTION - // You can safely add code below this comment in this method. #// 以上示例演示如何使用 WebLogic Platform 工具使非 XML 格式的文件的转换成为一项普通的任务。 处理超大文件 发送基于文件的订单的交易伙伴可能会向 GlobalTx 的 OMS 发送超大文件。这些文件通常可能大于 100 MB。使用传统方法来处理在单批中发送的超大文档文件可能会严重损坏系统。这是因为 XML 转换需要使用大量内存，而由于这些文件超大，内存会迅速耗尽。 WebLogic Platform 使用文件控件在文件系统中方便地读取、写入或追加文件。对于包含大量单个记录的超大文件，有一种方法是使用文件控件将文件分割成使用模式的单个记录。有关如何应用此设计模式的详细信息，请参阅此处。 此外，使用文件控件处理文档还可以优化性能。下面是使用 WebLogic Platform 文件控件处理超大文件的特点和优点。
端到端文件管理 文件管理是文件传输在如 GlobalTx 所需的关键任务、实时的环境中得以采用的另一重要方面。由于在实际 B2B 应用场景中的使用超出了企业范围，因而可从单个控制点看到整个企业内以及企业外的所有传输活动就成了一项基本要求。图 2 显示 GlobalTx 如何使用 WebLogic Portal 的基于文件系统的内容储存库来管理交易伙伴发送和接收的文件和相关元数据。它提供诸如版本控制、文件夹管理、登入/登出和元数据管理等高级语义。 元数据包括有如时间戳、内容实体大小这样的系统属性（虚拟内容存储库用这些属性来管理基于文件的内容）。还可能包括如交易伙伴信息（文件发送者）、已接收数据的转换信息以及传输后处理的状态等这样的应用程序属性。所有这些都可以通过基于文件系统的内容储存库来方便地管理。如果文件传输作为触发批处理业务流程的大量信息流入使用，那么该文件及其相关的元数据应该可以从业务流程进行访问。在 WebLogic Platform 中，由内容储存库管理的所有文件均可使用业务流程内的内容管理 API 来访问。有关详细信息，请参阅 CM API 的 javadoc 文档。 整合 我们已了解了 GlobalTx 如何使用 WebLogic Platform 构建一个全面的基于 SOA 的受管文件传输解决方案。下表对一些要求和助力于该方案的相应组件进行总结。
总结 现在，几乎每个公司都和 GlobalTx 一样不同程度地使用文件传输。这些传输通常是整个 IT 操作中的重要部分。尽管基于消息的企业应用集成 (EAI) 为集成需求提供了灵活而粒度化的解决方案，企业还是不宜尝试一次性地跨越到百分之百的基于消息的实施，而是适合（并且慎重地）先在“混合”的环境下运行数月甚至数年。最低风险的方法是将部分操作逐步移到基于消息的集成形式，逐项替换文件传输活动。事实上，有些文件传输活动可能要永久保留。有些情况下，文件传输是达成理想效果的最佳途径。 因此，企业内部及外部集成策略的关键问题是如何使基于文件的活动与基于消息的活动交互操作。答案是拥有一种将文件映射到消息或将消息映射到文件的功能。使用这样的工具，就可以使应用程序在“支持消息”的同时能被处理文件接口的应用程序调用。映射引擎可将文件分割成单个的消息（例如，与文件中的特定记录对应），这些消息随后可用来驱动支持消息的应用程序。反过来，映射引擎重新组合消息，使基于文件的应用程序可以接收响应。我们已了解如何应用 BEA WebLogic Platform 的受管文件传输功能成功满足 GlobalTx 的需求。 资源
原文出处:http://dev2dev.bea.com/pub/a/2006/02/managed-file-transfer.html |
版权所有：UML软件工程组织