jboss esb_与JBoss ESB和LegStar的大型机集成

jboss esb

介绍

在Dobbs博士于2008年10月发行的 《 您的下一代语言是COBOL吗？ ，Michael Swaine提到“每年都会编写数十亿行新的COBOL代码”，以证明遗留大型机应用程序的持续大小和强度。 难怪在这种情况下，将大型机应用程序与分布式系统（尤其是基于Java的系统）集成仍然是一个重要的主题。

大型机集成是该领域在过去几年中积累了大量经验的领域。 一个教训是，艰难的方法是紧密耦合是不好的。 对于所有集成系统当然都是如此，但是对于大型机应用程序，技术差距更大：一方面是COBOL，CICS / IMS，TSO，另一方面是Java，J2EE，Eclipse。 在具有非常不同的生命周期的应用程序，开发人员的思维方式，工具等之间创建过多的依赖关系会导致系统脆弱且不稳定。

大型机集成厂商很早就采用了面向服务的体系结构（SOA），从而导致了第一代以SOA为灵感的大型机集成解决方案。 从将COBOL绑定到XML和SOAP消息传递直接在大型机上运行的意义上讲，这些解决方案中的大多数都是以大型机为中心的。

大型IT社区最近采用了企业集成模式 ，并且企业服务总线（ESB）成为了SOA基础架构的选择，这为大型机集成创造了新的架构机会。 在本文中，我们提倡以ESB为中心的大型机集成视图，并介绍用于JBoss ESB的LegStar，这是一种实现这种架构的开源解决方案。

以主机为中心的第一代集成正在显示其局限性和成本

Michael Swaine提到COBOL语言本身正在发展以支持XML，并且CICS之类的系统现在提供SOAP支持。 除了IBM之外，还有很多供应商提供大型机上的XML和SOAP堆栈的COBOL绑定。 几年来，专门研究遗留集成系统的分析人员一直偏爱这种以大型机为中心的方法，以与本地运行在大型机上的XML和SOAP集成。

因为当时没有本机大型机SOAP堆栈，所以大多数以大型机为中心的集成供应商都被迫开发自制SOAP堆栈。 有些人甚至开发自己的XML解析器。

但是，自那时以来，SOA和Web服务发展Swift。 几年前，提供基本的XML处理和SOAP 1.1就足以声明服务导向。 从那时起，客户对SOA的期望和认识不断发展，并采用了诸如WS- *的新标准。 结果，自制SOAP堆栈的维护成本Swift增长。

大型机开发人员缺少开源提供的大型社区和资源池。 结果，几个大型机SOAP堆栈尚未提供SOAP 1.2或WS-Addressing，这是许多WS- *规范的先决条件。 相比之下，Apache的最新Axis2版本下载了20 Mb，其中包括59个库，这些库涵盖SAAJ（SOAP 1.1和SOAP 1.2），XML Schema，WSDL 1.1和WSDL 2.0，WS-Addressing，Fastinfoset，WS-MetadataExchange，MTOM， WS-Policy等。

此外，诸如RESTful Web服务之类的新技术也在不断涌现。 在Google，Yahoo和Amazon的支持下，这种类型的体系结构变得越来越流行，并且JSR 311（用于RESTful Web服务的Java API）的采用为其可信度做出了贡献。 JSON作为XML的轻量级替代品也获得了发展。 例如，Axis2现在支持JSON。 在不久的将来，将大型机应用程序与RESTful Web服务和JSON支持集成在一起可能成为需求，这将给已经很长的积压工作增加更多的内容。 除了基本的Web服务功能之外，对于编排或脚本语言的要求已经出现，这给以大型机为中心的开发团队带来了更大的压力。

以大型机为中心的解决方案不仅在功能方面落后，而且在出现SOAP时常常会匆忙做出糟糕的设计决策。

例如，以大型机为中心的解决方案通常将绑定，消息传递和传输层紧密结合在一起。 另一方面，开源社区做出了重要的决定，即将语言绑定（例如Java到XML绑定）与传输和消息传递完全分开。 在Java世界中，用于XML绑定的JSR 222 Java体系结构（JAXB）通常独立于任何Web服务技术来实现。 您可以将其与SOAP或RESTful Web服务一起使用。 同样，消息传递和传输通常清楚地分开，因此除了传统的HTTP / HTTPS之外，还可以通过JMS或TCP套接字传送SOAP消息。 结果，以大型机为中心的解决方案很难适应不断变化的SOA环境。

还设计了以大型机为中心的集成解决方案，将大型机作为IT基础架构的中心。 分布式应用程序被视为外围设备。 这导致了大型机集成的不对称性愿景，其中唯一的需求，或者至少最重要的需求是这些外围应用程序消耗大型机资源。 随着分布式应用程序重要性的增长，大型机应用程序无法再保持孤立状态。 许多以大型机为中心的集成供应商最近都意识到了这一威胁，并开始提供出站功能，但是很少一家公司进行了基本的大修，以支持对大型机应用程序在IT基础架构中的作用更加平衡的看法。 SOAP客户端功能通常非常弱，并且在大型机上受到限制，从而严重限制了对分布式服务的出站访问。

最后，以主机为中心的集成的一个重要方面是成本。 在大型机上，软件许可和维护费用昂贵。 开源还没有渗透到那个世界，而且可能永远也不会渗透。 另外，XML和SOAP处理是CPU密集型活动。 尽管IBM采取了一些措施来缓解这一事实，但大型机上的CPU成本仍然相对较高。

总而言之，以大型机为中心的集成厂商要赶上最新的Web服务标准，响应新的要求并适应大型机应用程序不断变化的角色以及开源软件所普及的新成本结构，变得越来越困难。

下一代以ESB为中心的大型机集成

在开源世界中，企业服务总线（ESB）已成为支持SOA的最佳基础架构。 他们为许多传输，注册表服务，复杂的消息转换，业务流程等提供支持。 从某种意义上讲，它们涵盖了先前由企业应用程序集成（EAI）专有平台拥有的基础。

以ESB为中心的大型机集成解决方案通过在ESB体系结构上进行构建来利用这些优势。 例如，将COBOL绑定到Java或XML被视为ESB中的任何转换活动。 与大型机交换消息使用ESB标准传输或建立在现有的基础上。 大型机应用程序不了解ESB，因此也可以与另一个大型机交换数据。

ESB是开源市场中非常活跃的部分，与大型机相比，年轻的开发人员社区对其了解得更好。 ESB受益于大型开放源代码社区，并直接面临新兴技术挑战，例如BPM，动态语言和RESTful Web服务。 BPM和BPEL仍然是以大型机为中心的集成解决方案所面临的挑战，在ESB上可广泛使用。 通过以ESB为中心的集成，大型机交互可以轻松地参与复杂的业务流程。

与以大型机为中心的同类产品一样，以ESB为中心的大型机集成工具具有设计时和运行时功能。 需要设计时工具才能将COBOL映射到开放世界的复杂类型。 不同之处在于，以ESB为中心的设计时工具会生成专门针对ESB的工件。 一旦部署到该ESB中，这些工件将把大型机数据流转换成开放世界对象。 转换作为ESB内部任务进行，并受益于ESB的多线程可伸缩体系结构。

以ESB为中心的大型机集成还受益于开放世界中当今可用的大量XML优化技术，这些技术可减少内存占用以及XML相关活动的CPU消耗。 可以说，分布式平台上的CPU已经比大型机便宜，但最重要的是，复杂的工具（例如探查器）已在Java领域广泛使用，在大型机上已经不那么普遍了。 以ESB为中心的解决方案可以更好地监视和控制CPU或内存消耗，从而进一步降低了整体集成成本。

在以ESB为中心的解决方案中，生成的工件与可以在ESB中部署的任何内容（Java，XML，jars）一致。 这意味着可以使用开放世界中丰富的管理工具（源代码控制，构建控制，依赖项管理，持续集成...）来管理这些工件，并且可以对它们进行单元测试，检测和保护。 集成工件是开发工件，对此非常敏感。 它们通常是高容量交易系统的关键部分，并且可以访问敏感数据。 在以ESB为中心的解决方案中，他们可以被视为开发生态系统的一等公民。

ESB还提供了比以主机为中心的SOAP堆栈更好的绝缘级别。 为了说明这一点，请考虑以下用例：大型机代码需要使用分布式平台上大型机外部提供的服务。 随着分布式环境的功能越来越丰富，并且在IT产品组合中扮演着越来越重要的角色，参考数据和流程源自分布式环境越来越普遍。 在这种情况下，大型机上的其余进程需要访问这些分布式功能。 在以大型机为中心的集成解决方案中，COBOL程序必须发出SOAP请求。 另一方面，使用以ESB为中心的集成解决方案，COBOL程序不了解特定消息，甚至不知道它正在与分布式平台通信。 它只是将大型机数据放入WebSphere MQ队列或HTTP有效负载中。 目标服务和协议的知识保存在ESB中，这正是ESB的角色。 以ESB为中心的解决方案可提供更高水平的去耦，这是集成系统最需要的质量。

LegStar和JBoss ESB，以ESB为中心的大型机集成解决方案

LegStar for JBoss ESB是一种开源大型机集成技术，它是最早专门针对ESB作为集成平台的公司之一。 在本文中，我们演示了如何使用LegStar利用Redhat JBoss ESB（一种开源ESB）来使大型机COBOL程序访问外部环境。 组合的体系结构使用同步或异步消息传递，并且所涉及的主机技术最少，可以有效地将主机程序与分布式进程分离。

用例

我们将向COBOL使用者公开一个Java对象（一个普通的旧Java对象或POJO）。

用于JBoss ESB的LegStar还可以涵盖更为经典的用例，在这种用例中，COBOL程序向Java使用者开放，但是当COBOL代码需要充当客户端时，尤其是在松散耦合至关重要时，存在一些独特的挑战。

用于JBoss ESB的LegStar还允许COBOL代码使用ESB服务和Web服务。 我们选择使用POJO来简化事情。

建筑

在大型机方面，我们将COBOL作为开发语言，将WebSphere MQ作为传输机制。

在服务器端，我们使用免费的开放源代码技术： JBoss ESB和LegStar 。

部署的架构如下所示：

关于这种体系结构选择，有几件事值得一提：

WebSphere MQ与JBoss ESB之间传输原始数据

另外，您可以使用HTTP与ESB进行对话，但是WebSphere MQ在大型机上非常普遍，并且比HTTP提供了对异步消息传递的更好支持。 COBOL代码可以在CICS或IMS中作为批处理程序在TSO中运行。 WebSphere MQ API可用于任何这些环境以及更多环境。

COBOL程序将原始大型机数据放入WebSphere MQ消息中。 此内容未在大型机上翻译。 这意味着JBoss ESB将接收原始大型机数据。 这样做有两个优点：

• 大型机上的CPU消耗更少（无数据转换）
• 大型机不需要知道它正在与非大型机平台通信

第二点在去耦方面特别重要。

尽管该架构图显示了z / OS上的单个WebSphere MQ Manager，但是在分布式平台上可能还会有一个。 为了简单起见，我们并没有代表那位额外的经理，也是因为这并非严格必要。

从ESB角度来看，我们使用JBoss ESB随附的标准Listener。 这是一种高性能的多线程侦听器，能够支持来自大型机的大量传入，并发请求。

在大型机端，客户端代码同步或异步交互

使用标准WebSphere MQ API，COBOL客户端代码可以自由地等待响应，或者在发布请求后返回。 异步消息传递模式是使用WebSphere MQ标准触发机制实现的，其中另一个COBOL程序可以处理回复。

异步是可取的，因为它在系统之间建立了较少的依赖性。 这种类型的交换模式也非常适合ESB模型。

JBoss ESB服务是COBOL客户端程序和POJO之间的代理。

JBoss ESB支持各种传输，并提供了我们在这里利用的通用管道概念。

JMS网关是标准的JBoss ESB侦听器，它监视WebSphere MQ队列并在收到消息时触发一系列操作。 JBoss附带了一些现成的操作，例如我们在这里使用的Object Invoker或JMS路由器。

LegStar在进行设计时会生成用于编组/解组原始大型机数据所需的转换操作，如下一节所述。 LegStar产生的工件是JBoss ESB特有的，并已对其进行了优化。

在某种程度上，ESB代理服务使COBOL客户端免受可能影响目标POJO的更改的影响。 首先，更改POJO位置或程序包名称不会影响COBOL客户端。 您也可以在不影响客户端的情况下向POJO添加新属性。 当然，更深远的更改（例如删除属性或更改类型）仍然会影响COBOL代码。

一步步

在这里，我们描述了开发人员为POJO创建ESB服务代理所遵循的主要步骤。 用于JBoss ESB的LegStar带有Eclipse插件，可简化该过程。 另外，可以使用与ant脚本相同的工具，但是我们选择了Eclipse方式，因为它更友好。

完整的Eclipse项目可在此处获得 。

目标Java对象（PO​​JO）

出于本文的目的，我们使用普通旧Java对象（PO​​JO），但它也可以是JBoss ESB服务或非ESB Web服务。

但是，这不仅是任何Java对象，我们希望Java类公开一个粗粒度的方法，该方法将单个复杂对象作为输入，生成单个对象作为输出，并在出现问题时引发异常。 此行为与远程外观模式有关 。 在此模式的上下文中，输入和输出对象称为数据传输对象 。 在本文的其余部分中，我们将此类对象称为数据对象。

此处显示了唯一方法。 表示请求的输入数据对象称为JVMQueryRequest。 它包含环境变量名称的集合。 输出数据对象JVMQueryReply将包含所请求的环境变量的值的集合以及一些特定于语言环境的值。

public class JVMQuery {

    public JVMQueryReply queryJvm(JVMQueryRequest request) throws JVMQueryException {

        List
   
   
    
     envVarValues = new ArrayList 
    
    
     
     ();
     
     
        try {
     
     
            for (String envVarName : request.getEnvVarNames()) {
     
     
                if (envVarName == null) {
     
     
                    throw new JVMQueryException("Invalid variable name");
     
     
                }
     
     
                String value = System.getenv(envVarName);
     
     
                if (value == null) {
     
     
                    envVarValues.add("Not found");
     
     
                } else {
     
     
                    envVarValues.add(value);
     
     
                }
     
     
            }
     
     
        } catch (SecurityException e) {
     
     
            throw new JVMQueryException(e);
     
     
        }
     
     

     
     
        JVMQueryReply reply = new JVMQueryReply();
     
     
        reply.setEnvVarValues(envVarValues);
     
     
        Locale locale = Locale.getDefault();
     
     
        reply.setCountry(locale.getDisplayCountry());
     
     
        reply.setLanguage(locale.getDisplayLanguage());
     
     
        reply.setFormattedDate(
     
     
                DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.FULL,
     
     
                        locale).format(new Date()));
     
     
        reply.setCurrencySymbol(Currency.getInstance(locale).getSymbol());
     
     
        return reply;
     
     
    }
     
     

     
     
}
     
     

    
    
   
   

将Java数据对象映射到COBOL结构

当原始大型机数据到达ESB时，必须采取措施将该数据编组为Java数据对象。 这就是LegStar发挥作用的地方。 LegStar提供了设计时工具，可将COBOL结构映射到XML Schema和Java。 它还提供了运行时绑定框架，以执行原始大型机数据的封送/拆封。

LegStar附带了一组Eclipse插件，使用户可以选择Java对象并请求自动映射到COBOL结构：

结果是带有特殊COBOL注释的XML模式。 以下是Eclipse标准XML模式编辑器提供的一些映射JVMQueryReply数据对象所产生的元素描述：

您可能会注意到某些COBOL属性具有默认值。 例如，字符串的默认大小为32。这是因为COBOL仅支持固定大小的字符串。 同样，COBOL不支持无界数组。 您可以在XML Schema编辑器中轻松更改默认值。

生成COBOL绑定类

LegStar COBOL绑定类是Java类，用于将原始大型机数据编组/解编为Java数据对象。

在Eclipse中，插件从XML模式中提取复杂类型。 然后，它允许您选择要为其生成绑定类的复杂类型。 在以下示例中，我们选择输入和输出类型：

LegStar COBOL绑定机制建立在Java到XML绑定框架（称为JAXB或JSR 222）的基础上 。 绑定过程将生成带有附加COBOL注释的JAXB类。 如果打开一个生成的JAXB类，您将看到Java对象中的每个属性如何保存一个COBOL注释：

生成JBoss ESB操作和示例配置

最后一步将产生一组工件，以帮助部署和测试JBoss ESB代理服务。 在Eclipse中，我们选择WebSphere MQ生成选项，并指定目标JBoss ESB服务应部署到的位置：

LegStar会生成示例JBoss ESB配置文件，以及完整的动作处理管道，以供测试。 它还会生成COBOL客户端示例代码，可用于调用JBoss ESB服务并快速启动自己的开发。

结论

用于JBoss ESB的LegStar是下一代以ESB为中心的大型机集成解决方案的示例。

这是这种新型体系结构的特征的摘要：

• 它确实是双向的，大型机代码根据情况充当服务器或客户端。
• 大型机COBOL程序有效地松散地耦合到分布式服务。 在所示的示例中，COBOL程序使用无处不在的WebSphere MQ队列名称来寻址目标服务。 就COBOL程序而言，目标服务可以位于另一个大型机上，可以用Java，PHP来实现，就此而言，可以在Web上的任何地方进行。 ESB知道在何处实施服务，或者至少知道如何向其转发请求。
• ESB负责将大型机代码与目标服务特质隔离。 在技​​术日新月异的世界中，当目标服务更改时，修改COBOL程序的需求将减少。
• 大型机程序可以轻松地参与复杂的工作流程。 JBoss jBPM或Active Endpoints ActiveBPEL可以代替大型机程序作为活动参与者来提供流程工作流和服务编排，而不是本文中所示的简单操作流程。
• 使用诸如XML Schema，JAXB，JAX-WS，JMS或HTTP之类的开放式标准技术，可以确保大型社区能够保持它们的生命力。 这与当前以大型机为中心的SOAP堆栈集（形成于黑匣子，专有且发展缓慢）中的一些鲜明对比形成了鲜明对比。
• 所产生的所有工件都是开放世界友好的：Java代码，XML Schema，XML配置文件等。这使得可以使用功能强大的工具来管理集成产品，该工具现已在Java社区中广泛使用。
• 减少了主机上的占地面积。 在我们的方案中，大型机上根本没有外国技术。 一个COBOL编译器和WebSphere MQ就足够了（或者，可以使用HTTP）。 所有CPU密集型活动（例如转换和XML处理）都发生在大型机上，而这些主机在CPU便宜的平台上。

COBOL和大型机应用程序将存在很长一段时间。 许多这样的应用程序非常有效地实现了它们的目的。 同时，开放世界应用程序的规模和关键性也在不断增长，其中SOA和ESB是基本构建块。 在这种情况下，以ESB为中心的大型机集成带来了值得考虑的独特优势。

关于作者

费迪·穆萨兰	是LegSem的首席执行官，在大型机应用程序和集成技术方面拥有20多年的经验
马克·利特尔	在Redhat担任JBoss部门的SOA技术开发经理和标准总监

翻译自: https://www.infoq.com/articles/legacy-integration/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

jboss esb