现代企业被淹没在信息的海洋中。虽然拥有日益增长的信息量，但是大多数企业几乎不能从中挖掘出那怕一小部分的非常有价值的信息。
这是因为信息分散在众多具有不同格式和接口的系统中--系统之间互不关联，所包含的不同内容之间互不相通。企业信息就位于其中。集成（EII）问题：企业需要一种能够轻松访问特定商业实体信息的能力，譬如从各种分散的信息源中获取像顾客或者是订单这样的信息。
EII问题并不新鲜--数据库领域已经为此奋斗了二十多年。但是目前的商业趋势迫切地需要一个新解决方案的产生。幸运的是，我们当前的各种新技术最终带来这种解决方案。本文关注于为什么会需要这样，以及BEA的 Liquid Data for WebLogic 是如何利用这些技术来提供一个商业上的EII解决方案的。
一个集成方案的例子：
想象一个拥有无线和宽带两个部门的大型长途通讯商。每个部门都有自己的订单管理系统和客户支持系统。同时，该通讯商也有一个中央CRM系统，以维护顾客购买历史和产品推销信息。仔细观察该提供商的IT环境，也许会看出下面这个混合后端系统的端倪。
无线部门：
订单管理系统：将Oracle用作RDBMS的SAP ERP
客户支持系统：将Oracle用作RDBMS的Clarify
宽带部门：
订单管理系统：将Sybase用作RDBMS的PeopleSoft ERP
客户支持系统：将SQL Server用作RDBMS的自开发系统
Corporate CRM System:
联合CRM系统：
Siebel使用DB2作为RDBMS。
正如我们所知道的，与消费者相关的信息分布在五个不同的信息系统中。（在实际情况中，一个企业使用的应用系统总数目可能接近10--100）这些系统可能是由于不同的独立软件供应商开发的或供应的，而且这些系统彼此间可能是没有联系的。
有些系统允许直接访问数据库，而其他的只允许通过它们的商业级API来访问。商家希望通过各种不同渠道让消费者随时他们的帐目信息，以此来改善他们的消费者响应和运转效率。这些渠道包括电话树系统，实时电话客户支持代表，在购物出口处的客户服务台，以及自服务Web门户。
商家同时也希望通过向四种渠道中添加推荐特性来增加销售额。为此，商家希望建立全方位、360度的"消费者单一视图"，它可以被所有渠道共享。为了实现这个刻不容缓的目标，视图的数据必须直接从商家的操作系统中获得。这就是EII问题的一个很明显的实例
当前的EII"解决方案"
为了解决这个问题，应用程序开发者在工程上面临三个基本挑战。
元数据的挑战：用来描述包含在不同后端系统中信息的元数据，以各种形式被捕获，包括RDBMS目录，WSDL文件，应用视图（J2EE-CA 适配器的）以及XML Schema。
数据访问API的挑战：包含在不同后端系统中的信息必须使用合适的协议来访问。这些协议有JDBC/SQL、ODBC/SQL、OCI/SQL ( Oracle 数据库)、SOAP和JCA等。
数据模型的挑战：从给定后端系统中返回的数据基本格式取决于该系统的本性。可能的格式包括关系行集、Java对象和XML文档。
表1列出了四个解决当前EII问题的常见方法，并简要分析了它们各自的优缺点。但是上述四个方法没有一个能提供完整的EII解决方案。
Liquid Data：基于XML的EII解决方案
2002年11月，BEA推出了Liquid Data for WebLogic。Liquid Data提供了对来自异种数据源的数据的实时访问和集中，并增强了前台应用的可见度。这里的"实时"是指使用可获得的最新信息。Liquid Data与数据仓库不同，它通过直接集成和访问企业各种运营系统中的数据来提供对企业当前状态的访问，而数据仓库存储的是特定企业数据预先集成的拷贝，这些数据通常是几天或几周以前的。Liquid Data把重心放在数据的可见度或者集成的读取访问上。BEA的WebLogic Integration为需要更新支持的应用补充了Liquid Data，它的目标是那些通常需要同时快速访问一个或几个商业实体集成视图的前台应用。我们对客户全面的观点就是一个经典的前台应用。
Liquid Data采用了一个XML数据集成方案，从而区别于过去的EII方案。它结合了EAI以及关系数据集成方案的很多优点，并且摈弃了它们的弱点。Liquid Data提供了基于标准的企业数据的XML视图--这些企业数据源要么以虚拟XML文档的形式予以表现出来，要么以一个采用XML参数并生成XML结果的函数集的形式表现出来。W3C XML Schema标准正是这种企业数据模型，并且W3C XML Query（XQuery）草案标准是一种说明性语言，指定了集成重用视图和对分布在企业各处数据的查询。XQuery函数模型化了其作用的数据源。采用EAI风格的适配器来"XML化（XML-ify）"封装的应用程序，这些应用程序是不能提供这样的XML API的。Liquid Data使用XML而不用普通的数据表形式使得其能够更好地适用于处理来自复杂数据源的信息；使用XML而不用专有EAI对象模型，使Liquid Data能与那些支持基于标准的XML和WEB 服务API的应用系统能够更好的交互。
|
方案
|
优点
|
缺点
|
| 自定义编码 |
明确地服务于初始目的 |
创建和维护的成本过高
代码跨部门的重用性太低 |
| ETL and 数据仓库 |
支持对超大型历史数据集的深度分析 |
|
| 企业应用集成（EAI） |
后端系统的适配器体系结构
支持面向流程的集成（即应用编排） |
高维护成本
数据远非实时
查询只限于那些预先选择好用于归档的数据
项目周期通常很长
|
| 关系数据集成 |
支持对多个RDBMS表的SQL查询
支持可查询视图 |
不能自动集成非关系数据，比如来自Web服务和打包应用的数据
可能偏向解决方案供应商的RDBMS |
目前可用的EII解决方案
Liquid Data的体系结构
图1描述了Liquid Data的体系结构。底部是各种支持即装即用的数据源。Liquid Data本身支持JDBC/SQL源（Oracle、DB2、Sybase、SQLServer和PointBase）、Web服务（简单的RPC风格和复杂的文档风格）、XML数据文件、使用BEA WebLogic Integration适配器的打包或遗留应用（SAP ，PeopleSoft等）的应用视图。
Liquid Data自动自建JDBC/SQL源的关系目录，并生成它们内容的默认XML视图。在Web服务中，Liquid Data则自动自建它们的WSDL描述。
除了这些数据源，Liquid Data还支持自定义的Java函数，以便开发者能为那些本身不支持Liquid Data的数据源编写XML插件。数据视图（稍后再讨论）如果定义了的话，也能用作Liquid Data数据源。
图1顶部显示的应用调用了包括数据视图在内的数据查询。Liquid Data的主要组件及其功能如下所示。
系统管理员：为Liquid Data服务器配置数据源。
数据架构师：懂相关业务实体和数据源的内容专家。为感兴趣的业务实体定义一层或几层可重用的集成视图，并在视图顶部定义已存储的查询。
应用程序开发人员：从应用程序代码中调用存储的参数化查询。
对系统管理员来说，Liquid Data扩展了BEA WebLogic服务器基于Web的控制台。对于数据架构师来说，Liquid Data为图形化定义数据视图和存储的查询提供了一个工具，即DataView Builder。
Liquid Data集中于参数化的存储查询，因为它们在保护企业的运行数据存储不受特殊查询流量影响的同时，还提供了一种简化应用程序开发人员工作的方法。
对应用程序开发人员来说，Liquid Data为调用存储查询提供了一个EJB API、一个JSP标签库API和一个Web服务API。
图1的中间是一个分布式的查询执行引擎。该引擎通过调用底层数据源，进行必要的数据转换和计算，并将集成的XML结果返回给应用程序来处理XML查询。该引擎还支持缓存方式。当在指定的时间内再次访问同样的查询或视图（采用同样的参数）时，数据架构师可以规定缓存给定的查询结果，以便重用。图中没有指出但是非常重要的一点是Liquid Data支持存储查询、数据视图和基础数据源的安全策略。Liquid Data服务器能够作为J2EE应用部署在BEA Weblogic服务器集群上。
XQuery:Liquid Data的秘密武器
Liquid Data使用的XQuery获得了业内广泛的支持，并成为定义企业数据源集成视图的说明性语言。这里我们给出的例子，简要地说明了XML如何将多个数据源中的数据缝合在一起。XQuery语言在www.w3.org/TR/xquer上有详细的介绍。Liquid Data中XQuery的用法在 http://edocs.bea.com/liquiddata/docs10/index.html.有介绍。Liquid Data中最常的XQuery表达式是FLWR，它类似于SQL中的SELECT-FROM-WHERE查询。FLWR表达式包含以下几个部分：
生成一个或者更多的值序列，并将这些值绑定到查询变量的FOR子句。XQuery中的FOR子句类似于SQL中的FROM子句。
将临时变量绑定到表达式结果上的LET子句。LET子句很类似于一些提供商的SQL方言中所规定的临时视图。
包含布尔值谓词的WHERE子句。其中布尔值谓词用来限制FOR子句的变量绑定。XQuery中的WHERE子句和SQL中的WHERE子句相似。
指定了查询所需的XML输出的RETURN子句。XQuery RETURN子句与SQL中的SELECT子句大致类似，不过它可以指定的结构远比SQL中的丰富。
再考虑一下我们最初的EII方案。假定我们想得到无线部门某一客户的合同信息以及宽带部门的产品定单信息。列表1显示了如何利用XQuery 完成这一工作。最上面的FOR子句为每一位无线客户绑定了一个变量。随后的LET子句连接了客户的名和姓，以便进行格式化输出。WHERE子句过滤出ID与查询参数匹配的客户。最后，大型的RETURN子句将来自无线部门数据库以及一个嵌套查询的结果的客户数据指定为查询的输出。该嵌套查询从无线部门的数据库中读取定单数据。它的WHERE子句保证只查询那些感兴趣的顾客订单，而RETURN子句则检索所期望的订单信息。列表2展示了这种查询输出的一个例子。
DataView Builder的用户界面
为了将数据架构师手工编写XQuery视图和存储查询的需要降到最低，Liquid Data引入了一个名为DataView Builder的工具。DataView Builder支持查询设计和XQuery构建的图示、拖放、和基于映射的方法。图2显示了一个设计视图的例子，其中输入数据源被映射到目标数据视图，以便用图形化的方法构建一个XQuery查询。DataView Builder还提供一个测试视图窗口，在这个窗口中可以检查、运行并手动调整（可选）查询。
可编程的API：
Liquid Data提供了三个能让应用程序开发人员用来从应用程序内部调用Liquid Data查询的API。它们是：
EJB API：它提供了一个到Liquid Data服务器的无状态会话Bean（Stateless Session Bean ，SLSB）接口。它是一个类似JDBC的接口，具有很多方法，可根据Liquid Data服务器所知道的集成企业数据执行存储查询（标准的）或特殊查询，这些查询可以带查询参数，也可以不带查询参数。
JSP标签库：针对JSP和门户开发人员来说，Liquid Data在它的SLSB接口之上提供一个JSP标签库外观。每个SLSB方法在标签库中都有一个副本。
Web服务接口：开发人员可以要求Liquid Data将存储查询转换为Web服务。每个存储查询都生成一个相应的WSDL文件。和Web服务进行会话的所有应用程序都能通过这个API利用Liquid Data服务。
其他特性：
Liquid Data的特性太多了，这里不能一一而述。想了解更多详情，建议您浏览http://edocs.bea.com/liquiddata/docs10/index.html 上的在线文档，并下载、试用该产品。但我们将在这里将着重强调一些关键的附加特性。
图1 Liquid Data体系结构
图2 DataView Builder--设计视图窗口
管理控制台
为了进行系统管理，Liquid Data扩充了WebLogic服务器现有的管理控制台。新增的控制台功能包括：
管理基本的Liquid Data服务器设置。
配置新的Liquid Data数据源。
配置Liquid Data缓存子系统。
为数据源和数据视图定义Liquid Data的安全策略。
监视Liquid Data服务器的活动。
安全性
Liquid Data支持安全策略，并且支持存储查询的访问控制列表（ACL）。Liquid Data中用户和工作组的概念和BEA WebLogic服务器中的相同。对于特殊查询，Liquid Data同样支持数据源级的访问控制列表。
资源库（repository）
为了管理EII资源，Liquid Data使用了一个轻型的、基于服务器的资源库来存储源和目标XML模式、存储查询、WSDL文件，以及自定义函数的代码和元数据等。此资源库基于文件并提供了一个简单的文件夹概念。
产品组合
Liquid Data是整个BEA平台系列的一个有机组成部分，可以和任何现有的BEA产品组合使用。有趣的BEA产品组合包括：
Liquid Data+ WebLogic Potral：Liquid Data对企业数据进行集成和集中，而Potral则处理Web的表现和个性化。
Liquid Data+ WebLogic Integration Adaptor：这使得Liquid Data能够集成打包应用中的数据以及关系和Web服务数据。
Liquid Data+ WebLogic Integration：，Liquid Data为工作流提供一个集成的企业数据视图，而工作流程支持对数据进行操作（比如更新）。
Liquid Data+ WebLogic Workshop：Liquid Data为基于Web服务的应用提供了集成的企业数据视图。
小结
本文简要介绍了BEA Liquid Data for WebLogic的技术特性。它为解决企业的信息集成问题带来了一种崭新的、面向XML的方案。它为企业的异种数据源提供了一个基于虚拟XML文档的视图，并且利用一个基于XQuery的说明性范例创建企业关键业务实体的集成视图，并在这些视图的基础上定义存储查询。
参考
列表 1: XQuery Example
<CUSTOMERPROFILE>
{
for in document("WIRELESS-DIVISION")/db/CUSTOMER
let := xf:concat(/FIRST_NAME," ",/LAST_NAME)
where /CUSTOMER_ID eq #
return
<CUSTOMER>
<CUSTID>{ xf:data(/CUSTOMER_ID) }</CUSTID>
<FULL_NAME>{ }</FULL_NAME>
<ADDRESS>{ xf:data(/STREET_ADDRESS1) }</ADDRESS>
<CITY>{ xf:data(/CITY) }</CITY>
<STATE>{ xf:data(/STATE) }</STATE>
<ZIP>{ xf:data(/ZIPCODE) }</ZIP>
<PHONE>{ xf:data(/TELEPHONE_NUMBER) }</PHONE>
{
for in document("BROADBAND-DIVISION")/db/CUSTOMER_ORDER
where (/CUSTOMER_ID eq /CUSTOMER_ID)
return
<ORDER>
<ORDER_DATE>{ xf:data(/ORDER_DATE) }</ORDER_DATE>
<TOTAL_ORDER_AMT>{ xf:data(/TOTAL_ORDER_AMOUNT)
}</TOTAL_ORDER_AMT>
<ORDERID>{ xf:data(/ORDER_ID)
}</ORDERID>
<SHIP_METHOD>{
xf:data(/SHIP_METHOD) }</SHIP_METHOD>
</ORDER>
}
</CUSTOMER>
}
</CUSTOMERPROFILE>
列表 2: Sample XQuery Output
<CUSTOMERPROFILE>
<CUSTOMER>
<CUSTID>CUSTOMER_1</CUSTID>
<FULL_NAME>JOHN_1 KAY_1</FULL_NAME>
<ADDRESS>NORTH FIRST STREET</ADDRESS>
<CITY>SAN JOSE</CITY>
<STATE>TX</STATE>
<ZIP>93151</ZIP>
<PHONE>4081231234</PHONE>
<ORDER>
<ORDER_DATE>2002-04-09</ORDER_DATE>
<TOTAL_ORDER_AMT>1000.00</TOTAL_ORDER_AMT>
<ORDERID>ORDER_ID_1_0</ORDERID>
<SHIP_METHOD>AIR</SHIP_METHOD>
</ORDER>
<ORDER>
<ORDER_DATE>2002-04-09</ORDER_DATE>
<TOTAL_ORDER_AMT>1500.00</TOTAL_ORDER_AMT>
<ORDERID>ORDER_ID_1_1</ORDERID>
<SHIP_METHOD>AIR</SHIP_METHOD>
</ORDER>
</CUSTOMER>
</CUSTOMERPROFILE>
| 作者简介 |
|
NITIN MANGTANI是BEA Liquid Data技术经理。他主要负责Liquid Data产品的相关工作。 |
|
