ESB技术搜集-04

http://www.blogjava.net/flyingbug/archive/2005/11/21/20836.html

 

Message Transformation及其相关模式

 

通常，通过消息系统集成的应用很少有同样的消息格式。比如说，一个帐务系统同一个CRM系统对客户对象是有着不同的概念的。基于这个，一个系统可能将消息存储在关系表中，另一个可能存储在文件中。集成已存在的系统通常意味着我们没有修改系统以便使他们更好的一起工作的自由。然而，集成方案不得不协调和解决各种系统之间的不同。Message Translator模式提供了一个通用的解决方案。这里解释几种特定的Message Translator。

 

Message Transformation包含以下几种模式：

l         Envelope Wrapper

l         Content Enricher

l         Content Filter

l         Claim Check

l         Normalizer

l         Canonical Data Model

 

大多数消息系统放置特定的需求在消息头的格式和内容中。我们包装有效数据到一个Envelope Wrapper中以适应消息基础设施的需求。如果消息需要穿过不同的消息基础设施，可以结合多个Envelope Wrapper。

如果原始系统不能提供目标系统需要的数据域，可以使用一个Content Enricher。它可以查找缺少的信息并从已有数据中计算出它。Content Filter正好相反，它从消息中删除不需要的数据。Claim Check也从消息中删除数据，但是它将存储他们以便以后取回。Normalizer将多个不同格式的消息翻译成统一格式。

 

消除依赖

 

消息转换在集成中是一个很深的话题。Message Channels和Message Routers可以通过消除应用必须知道另外一个应用的位置的需求从而解除应用间的基本依赖。

一个应用可以发送一个消息到Message Channel而不必担心谁来取出消息。然而消息格式增加了另外一种依赖。如果一个应用不得不将消息格式化成另外一个应用的数据格式，通过Message Channel解耦的说法就像一个幻想。接收系统的任何改变或切换到另外一个接收系统都需要对发送应用进行改变。Message Translators可以帮助除去这种依赖。

 

元数据管理

 

将消息从一个消息格式转换到另一个格式需要操作元数据 － 描述数据格式的数据。

元数据在两个并行系统之间的集成中扮演着非常重要的角色。一个处理实际的消息数据，另外一个处理元数据。许多用于处理消息数据的模式也同样可以管理元数据。比如说，Channel Adapter不仅可以从一个系统中移进和移出消息，还可以从一个外部应用中获取元数据，并将其加载到一个元数据仓库中。使用这个仓库，集成开发者可以定义应用元数据与Canonical Data Model.之间的转换。

 

 

元数据集成

 

http://www.blogjava.net/images/blogjava_net/flyingbug/2501/o_MT1.JPG

举例来说，上面的图描述了两个需要交换客户信息的应用的集成。每个系统的客户数据的定义稍有不同。从A到B的消息需要转换一下才能被B接收。如果Channel Adapters可以抽取元数据的话，创建一个转换将非常简单。然后这个元数据可以被放入一个仓库，大大的简化了Message Translator的配置和验证。元数据可以被存储成不同的格式。通常XML消息使用XSD格式。其他EAI工具实现所有元数据格式，但是允许管理员导入或导出到其他格式。

 

消息系统外的数据转换

 

这些转换模式组成的很多原则可以被应用于非消息集成。比如说，File Transfer可以执行系统间的转换工作。类似的，Remote Procedure Invocation必须使请求使用要调用的service的格式，即使应用本身的格式可能不同。典型的，需要调用程序来执行转换。一些最成熟的转换引擎组成了ETL工具，比如Informatica或者DataMirror。这些工具一般都一次转换大量的数据，而不是转换单个消息。

Message System应专注于几种基本的Message Translator模式。而不应该关心实体间结构转换的细节（不同的数据模型之间的转换，比如ER模型不支持多对多关系而其他的支持这种）。关于这个主题最老也使最相关的书是Kent的《Data and Reality》。