BEA WebLogic Integration8.1简介--统一集成环境

企业应用集成现在是企业IT策略的核心，但是由于某种原因，其成本的投入和所获得的效益现在还不能令人满意：现在典型的IT组织结构都将应用程序的开发和集成隔离开来。

BEA WebLogic Integration 8.1将应用程序的开发和集成技术合并为一个统一的平台，在二者之间构建了一座桥梁。它利用BEA WebLogic Server作为底层部署环境，使用Web服务集成公司内外的分布式系统，采用BEA WebLogic Workshop简化面向服务的应用程序开发（SODA，services-orinted development of applications）。

SODA要求IT职员在构建应用程序时就对应用程序的集成进行设计，从而最小化事后集成的负担。根据Gartner统计，SODA可以将集成的费用降低30%甚至更多。同时使用面向服务的体系结构（SOA，service-oriented architecture）和SODA，IT职员可以构建一个良好的基础平台，它会有益于将单个模块搭建成更灵活的系统。BEA相信"集成"是一项重大的创新，这将有助于降低Global 2000中集成项目的成本并提高其成效。

根据面向服务的设计，WebLogic Integration 8.1会在现有的集成方法之间架设一座桥梁，来弥补它们间的差异（见图1a和图1b）。仔细研究一下集成和应用之间的差异就会清楚地发现，这些环境需要进行统一，原因有两个。首先，所有的集成项目都需要IT部门编写代码以弥补各种专有集成方案间不可避免的差异，或者实现核心业务特有的业务逻辑。其次，大部分应用都需要集成，即使只和数据库进行集成也是如此。如果大家都不认为访问数据库是一项挑战，那是因为经过最近十年的发展，SQL和JDBC的标准和使用技术已经使得数据库的集成成为开发过程中很自然的一部分。

第二种差异来自于集成建模工具和集成部署环境之间的差距，这需要沟通才能解决。传统业务流程管理（BPM）工具的目标是业务分析人员，帮助他们勾画出一幅高级的集成架构图。但是实现这幅架构图要求施工人员必须具专有集成和部署环境的专业知识，必然会增加人力成本。为了优化使用这些资源，我们的研究结果表明集成环境必须具备以下条件：

•  业务分析人员能够和IT群组的应用开发人员进行交流，并且集成专家们能够按照业务流程模型的需要进行沟通。

•  给IT职员配备一些工具，让他们无需低级的编码和过多的细节就可以实现和绑定业务流程。
第三种差异在于在IT快速发展的历史过程中所逐渐积累起来的各种不同层次的集成技术之间的不同。早期的EAI项目着重于解决连通性以及数据转换、适配器、消息代理（message brokering）以及二进制格式间的转换等问题。遍布整个企业的后端系统具有专有特性，其解决方案很难进行维护和改进。近期的EAI产品将BPM置于专有的解决方案之上，通过交换二进制消息来捕获并自动化正在执行的事务的语义。随着B2B逐渐向基于标准的集成发展，它开始使用XML来进行业务流程建模。随着公共流程的出现并被业务合作伙伴共享，自动化逐渐成为人们关注的焦点。但是，层次的增加使得集成的问题更多。

为优化企业集成，BEA已经证明松散耦合的集成比传统的紧密耦合更容易维护；而且异步通信对于实施和保护业务操作都非常关键；粗粒度的通信可以最大化松散耦合系统之间高成本通信的效率。企业人员需要知"谁可以访问什么内容"，这将使安全服务以及用户和贸易伙伴管理成为任何集成项目的必要需求。 统一集成框架。

新版本的BEA WebLogic Integration被设计用来在现有裂痕之间建立一道桥梁。BEA WebLogic Integration的统一框架根据三种开发和集成情况将所有的应用程序开发和集成中共同的操作结合起来：

•  最底层是面向对象的J2EE企业开发人员，他们创建业务对象并编写必需的系统级代码。

•  上面一层是业务应用开发人员，他们非常接近于一线的业务，使用J2EE开发人员所创建的对象和组件，并将其装配到业务应用程序中，来增加应用程序的逻辑和用户界面。

•  最上层是业务分析人员，他们对业务流程进行建模，定义业务主操作的路由，以及XML业务文  档在松散耦合系统中的转换。 为了在这些层次之间建立一个连续的开发过程，BEA认为每个用户都需要处于正确的抽象层次上。在J2EE之上需要一层抽象，以便让应用程序的开发人员和系统集成专家--也就是WebLogic Integration的目标用户--能够不需要面向对象和J2EE的知识就可以实现业务流程。根据业务流程逻辑，在更高一层上还需要一层抽象，以便允许业务分析人员能和需求充分进行沟通，确认IT实现，并在系统运行时按照业务的要求监控整个系统的行为。

统一集成平台的组件

BEA WebLogic Integration是在WebLogic Server之上搭建的，它利用了一种可以充分使用WebLogic Workshop框架的体系结构；还提供了一些高层的抽象，以简化应用程序在J2EE平台上的开发和集成。WebLogic Workshop框架在一个统一的开发和集成环境中提供了构建和集成应用程序需要的所有组件（从业务流程到应用的集成）。

WebLogic Workshop控件

WebLogic Integration充分利用了WebLogic Workshop的运行时框架，通过高级控件提供对资源的访问，从而提高开发者的生产率。这种体系结构在程序逻辑开发和事件驱动编程的基础上提供了一种统一的编程模型。该平台替应用程序开发者和集成专家对J2EE API和后端资源的底层技术细节进行了抽象。例如，考虑一个发送JMS消息的情况。在J2EE编码层，发送JMS消息需要50到80行代码，因为J2EE API为用户提供了访问所有JMS参数和程序接口的方法。

在WebLogic Workshop框架中，你可以使用一个JMS控件，它将这80行代码封装到一个高级的组件中。使用该组件，在一些应用逻辑中你只需要编写一行简单的Java代码就可以发送一条JMS消息，或者进入业务流程模型中的一个简单步骤。虽然这种方法为了易用性而牺牲了一些灵活性，但是BEA相信这种方法对80%的应用都是适合的。即使不适用于即装即用（out-of-the-box），开发人员依然可以访问J2EE API（见图2）。

BEA WebLogic Integration会提供大量的即装即用控件，从后端被打包的应用程序（Packaged Application）和J2EE资源到B2B网络和用户，资源覆盖范围非常广泛。

WebLogic Workshop IDE

新版本的WebLogic Workshop IDE开拓了一片新天地，其目标用户并非J2EE专家，而是应用程序的开发人员。BEA认识到应用程序开发人员需要一种高级工具，以便允许他们无需J2EE的专业知识就可以提高生产率。这使得WebLogic Workshop IDE和其他统一的IDE环境不同，后者通常都是炫耀自己的IDE组件，但是其实依然需要有J2EE专家在背后支持。

利用J2EE的一个高级接口和合适的WebLogic Integration组件，使用一个工具就可以实现集成开发和集成环境。这样你就可以建模业务流程，定义转换，构建Web服务，编写应用逻辑，定义基于Web的接口和Web Pageflow，并构建流程门户（入口）。

WebLogic Workshop IDE可以简化自定义控件的构建，使应用程序开发者、集成专家以及ISV创建自己的控件，并对平台进行扩展。实际上，使用WebLogic Workshop IDE人工创建的任何内容都可以自动成为一个控件，并能在整个业务流程中重用。

应用集成体系结构

既然已经定义好了体系结构，就让我们来了解一下本产品是如何支持传统的组件集成的：连通性、消息代理、BPM、数据转换。

连通性

BEA的连通性策略是基于一个尽可能开放的标准而制定的。虽然从何处访问专有接口是一个必不可少的因素，但是BEA的体系结构设计能够确保这些遗留系统中低级的专有特性不会在整个体系结构中扩散，而是被限定到后端系统中，并被包装成类似于J2EE CA或Web服务的标准的接口。这样，所有的资源对于最终用户来说都和业务服务类似。

WebLogic Integration可以连接三种主要资源：

•  遗留系统（Legacy System）和打包的应用程序（Packaged Application）：一组基于J2EE CA的适配器集用来和后端系统进行集成，包括所有的主要业务应用。该平台支持诸如FIX、SWIFT、HIPAA和HL7之类的垂直网络和格式。另外，它还支持使用适配器开发工具包（Adapter Development Kit）来开发基于J2EE CA的自定义适配器。这些适配器通过应用程序视图控件提供给WebLogic Workshop IDE。要配置一个应用程序视图控件，应用程序专家可以使用WebLogic配置工具来配置适配器，并定义相关的高级业务操作和事件。

•  J2EE资源：包括一个访问所有J2EE资源（例如JMS、EJB、数据库(JDBC)以及J2EE CA）的控件集。

•  B2B和EDI：通过Web服务、RosettaNet和ebXML以及一些更普通的协议（例如email，HTTP和FTP），使用控件来提供对防火墙之外的资源的访问。

业务流程管理（BPM）

WebLogic Integration BPM允许用户对跨越多个内部系统、外部资源和用户的业务流程进行建模，并执行这些业务流程。从BPM的视角来看，企业是一组业务服务的集合，这些服务可以通过控件进行访问，并能能对业务流程进行建模。WebLogic Integration既支持同步通信，也支持异步通信；既支持有状态的过程，也支持无状态的过程。

Weblogic的业务流程引擎通过保留连续编写Java代码的能力，提供了很大的灵活性（见图3）。编写几行Java程序是完成一项任务（例如在一组包含价格信息的XML文档中判断最低价格）最有效的方法。WebLogic的解决方案是将业务流程中采用了一个称为"查找最低价格"的粗粒度步骤，然后让应用程序开发人员开发出最好的实现方法。
 
消息代理

WebLogic Integration消息代理为业务流程提供了一种基于通道的"发布和订阅"通信机制，这使得业务流程可以利用一个业务-命名范例以松散耦合的匿名方式进行通信。例如，每当一个新订单消息被发布到通道中时，都会激活一个订单路由过程，该过程会预定"New Order Entered"通道。

借助于IDE，开发人员可以定义通道的命名层次，并为每个业务流程指定发布和订阅所使用的通道。过滤器（利用XQuery定义的）允许根据消息的内容对订阅重新进行定义。使用前面的例子，一个业务流程可以使用一个过滤器来只订阅那些发布到"New Order Entered"通道中的价格超过$10,000的订单。

消息代理支持可从外部资源向通道发布事件的事件发生器。WebLogic Integration为JMS、文件、email和定时事件都提供了事件发生器。适配器可以从打包的应用程序向通道中发布事件。
数据转换

WebLogic Integration提供了一些组件和工具来支持三种主要的数据转换：二进制到XML，XML到XML，以及XML到二进制。该平台将数据转换组件打包成控件，将其作为可以在多个流程和集成方案间重用的资源，例如从RosettaNet到OAG（开放应用组）格式的数据转换。新的数据转换特性对于从XML到XML的数据转换使用XQuery。XQuery是W3C标准流程中最后阶段的XML标准。

一直以来，XML到XML的数据转换都是使用XSLT，但是XSLT从来都不是为实现这种功能而设计的。XSLT本来用于处理半结构化数据和基于文档的转换：采用XML，应用XSLT，并将XML转化为可以向终端用户或设备显示的内容。XSLT是一种递归的、基于模式匹配的、声明式语言--这是最难理解的三个概念。而且，XSLT转换定义的是如何执行数据转换，而不是执行什么操作，由于它被绑定在用户代码中，所以限定了XSLT处理器的优化。

虽然WebLogic Intefration完全支持XSLT，但是新的版本引入了一个新的XQuery处理器和一些工具，以简化并加速数据转化的过程。XQuery很像用于XML的SQL，这对于早已熟悉SQL的应用程序开发人员来说显得很亲切。而且，BEA初步的性能测试表明，由于XQuery定义的是做什么，而不是如何做，因此XQuery转换比XSLT转换更容易优化（见图4）。
 

系统管理

Weblogic Integration提供了一个统一的、基于Web的管理控制台，它可以解决如下的问题：

•  工作流管理和监视

•  任务或工作列表管理

•  贸易伙伴管理

•  消息路由管理

•  事件和适配器配置

•  安全性和归档管理

尽管系统假设集成环境主要是通过WebLogic Integration管理控制台进行管理的，但是它还是提供了JMX接口来支持第三方的管理工具。

WebLogic Integration通过维护两个逻辑数据库存储，将运行时的管理和离线分析隔离开来。在线管理数据库包括有关集成引擎、业务流程状态和消息历史的运行时数据。该数据库是为提高性能而设计的。为了具有良好的伸缩性并能尽快地获取数据，该数据库的数据都是按照最优化的格式进行维护的。根据可配置的归档策略，这个在线数据库可以周期性地归档到离线数据库存储中。

结论

BEA WebLogic Integration通过提供一个统一的体系结构缩短了开发和集成之间、IT职员和业务用户之间以及EAI和B2B之间的差距。它通过统一所有用户所需的开发技巧集，降低了学习的难度。在此前的将各个在技术上孤立的集成环境桥接起来的过程中，WebLogic Integration本身就是一架桥梁，它可以降低开发成本，充分利用开发者的组织才能和知识结构，并提高生产率。