消息交换总线技术是为了实现企业数据共享和应用集成，提供一种基于企业服务总线(ESB)的信息共享交换平台。该技术采用面向服务体系结构(SOA)的设计思想，以信息共享为目标，具有松散耦合的特点，实现了"集中式管理、分布式运行"的工作模式。通过设计标准的适配器组件，实现各种数据库和应用系统之间的数据共享与交换，能有效实现企业中信息共享，并具有良好的可扩展性和可靠性。
Oracle的OSB总线包括ESB（Enterprise Service Bus）和 WSM（Web Service Management）两大部分，是ORACLE公司的消息交换总线产品。ESB包括MOM, ORBs, RPCs, WebServices功能的新型、综合类型中间件，通过配置集成；WSM包括服务管理，消息跟踪两个部分。使用OSB可以很容易的将企业已有的对外功能集成进来，并且能够集成和开发出来新的功能。
ESB服务总线的核心功能在前面很多文档里面有已经介绍过，在这里再做简单总结：
服务代理和位置透明
ESB的一个重要功能，即将遗留系统或外部接口或服务能力接入到ESB，通过ESB再包一层后形成统一的服务目录朝外部发布，起到服务中介和原始无法位置透明的作用。最简单的服务代理就是仅仅只做服务路由转发，其它啥都不做，因此在OSB消息流绘制最简单的就是重要的pipeline是空的，仅仅只有业务服务和代理服务。
协议转换和遗留系统适配接入
协议转换是ESB的一个重要功能，其中包括了HTTP，TCP，FTP，JMS，EJB，MQ，FILE，SMTP等多种协议之间转换和适配能力。比如你可以接收一个SOAP WS服务调用请求，并将接收到消息写入到JMS；或者说你也可以通过JCA适配到某一个数据库，将数据库表发布为一个Http Rest查询服务接口。
消息格式和内容转换
这个一定要和协议转换分开来谈，支持多种消息格式和类型往往就是指的可以通过transform和数据映射功能将XML，JSON，Flat File，MFL等多种消息格式类型之间进行数据映射和转换。举例来说，你可以服务调用的输入都是Http Rest服务接口，但是输入可以是Json格式，而输出可以转换为XML文本输出。
服务路由（包括静态路由和动态路由）
路由是ESB中非常重要的仲裁逻辑之一。路由场景是非常普遍的。譬如，针对不同的客户提供不同QoS的场景，执行时需根据客户的类型将其路由到不同执行能力的服务提供者；再比如当响应消息到达ESB时，总是需要将该响应消息送回最初的服务请求者处。
路由可分为静态路由和动态路由。静态路由指得是设计时已经明确路由分支的情况，而动态路由的路由分支选择是在运行时动态确定的。不论是静态路由还是动态路由，路由分支的选择一定伴随着一个或一系列决策依据。决策依据可简单如一个If-Else语句，也可以复杂到需要通过多维决策表并通过多次判断才能得到最后的路由分支。
数据映射转换（Transform）& 内容丰富(Service Enrichment)
数据映射转换是ESB的另外一个核心功能，举个例子来说我们根据一个标准的WSDL契约要求定义一个代理服务，而对于业务服务则是适配和连接到一个数据库表并返回一个结果集，那么这个WSDL结构就需要和数据库返回结果集的业务服务间进行数据映射和转换。
一般而言，大多数ESB产品都提供了多种数据转换的方式，很多产商宣传中力推的都是“拖拽式”可视化映射的转换方式。该功能听起来的确很酷，看上去很直观。但是正如我们前面所说的，ESB是一个偏向技术层整合的组件，业务人员一般不会关心XML是如何转换成SOAP的。所以，对于开发者来说，这种“炫”功能并无太大吸引力。更重要的是，他们可能非常习惯于自己的编程语言，如Java、XSLT、ESQL和PHP等，这些语言操作起来要简单很多。
在OSB 12C增加了可视化的XSLT数据映射功能，XSLT是一个标准的XML转换语言，使用XSLT实现的转换逻辑可很轻易地在不同ESB产品间移植。几乎所有主流商业ESB产品都支持XSLT的转换机制。
对于内容丰富来说，举例来说当接收到消费者的服务调用请求后，我们需要对输入消息内容进行补填再去调用原始的业务服务，也可能是OSB接收到Response返回消息后，我们会进一步补充实例ID，服务状态等信息后再返回给服务消费方，这些都属于内容丰富的范畴。
消息处理机制和运行原理
OSB中的服务包括代理服务（Proxy Service）和业务服务（Business Service）两种。业务服务一般用作将外部已有服务接入到OSB总线上，代理服务的作用是将已有服务进行重新包装和整合，进行服务路由、逻辑处理之后对外发布新的服务。
在OSB消息流中，一般都是通过Proxy Service对外发布服务的，客户端通过调用在Proxy Service中定义好的URL来调用OSB总线上的服务。
当客户端调用Proxy Service的时候，消息先经过Proxy Service传输层（Transport）进入，传输层是有协议的，他可以解析和接入各种传输协议；然后通过绑定层（Binding）对传输层接入的消息及协议进行解析 ，对消息内容进行解析并且存放到上下文变量中，经过绑定层解析后的消息格式一般是通过SOAP格式进行包装并且附在以后的整个消息流传输过程中，以后的处理节点就通过访问上下文变量来查看、获取、编辑消息内容和消息结构；当然，在绑定层解析之后，消息协议仍然可以访问，绑定层会将协议信息存放在上下文变量中的$inbound变量中。消息输出时候的处理过程与消息输入相反。
OSB核心经过Pipeline管道来进行消息路由，转换，映射，异常处理等一系列操作，如下图：
里面的几个关键组件为：
Pipeline表示一个消息流转中批量的处理逻辑
Stage可以被认为是一组动作处理的容器
Action是消息流中的逻辑，它用于具体决定如何处理消息
Branch节点可以让流程处理进入具体多个可能的处理路径中的一个
在OSB消息流开发过程中，对于各种功能节点都可以使用XQUERY或者XPATH语言对节点属性、处理流程进行配置；而对于消息流的流程控制语句也是使用XQUERY来实现的。对XQUERY和XPATH有个基本的了解是能够进行消息流深入开发的重要基础。
XPATH是标准的XML表达式语言，用于标识或定位XML文档中的某一部分，对于很多消息处理节点中的配置参数，都需要使用XPATH语言来表述，如对于DELETE（作用是删除消息中的某个元素或者属性）处理节点，就需要使用XPATH语言来描述删除目标元素；XQUERY是一种用于XML文档的结构化语言，用来描述循环和判断、函数处理、流程处理和控制、构造SOAP消息、处理消息结构和内容等处理命令的一种语言。在OSB上，一般比较复杂的处理逻辑都需要这两种语言来实现。
OSB中对消息结构/内容进行转换一般通过XQUERY语言来实现，可以在WORKSHOP中使用可视化界面进行拖拽操作来实现消息格式转换，然后将生成的xq文件上传到控制台即可。
OSB中的其它关键术语进一步解释和说明
业务服务(Business Service)
业务服务是您要与其交换消息的企业服务的AquaLogic ServiceBus 定义。使用WSDL（Web Services 定义语言）定义业务服务的方式与定义代理服务的方式相同。但是，业务服务的配置与代理服务的配置不同，因为业务服务没有管道。因此，不是由BEAAquaLogic Service Bus 管道实现的服务即为业务服务。
Business Service是在OSB中所定义的，用于表示希望与后端交换信息的企业服务。
代理服务(Proxy Service)
代理服务是在WebLogic Server 上本地实现的服务的AquaLogicService Bus 定义。可以在WSDL、管道和策略等方面定义代理服务。如果代理服务需要安全凭据，则可以创建代理服务提供程序，以管理这些从AquaLogic Service Bus 控制台映射到密钥库条目的安全证书。通过配置代理服务的消息流可以实现代理服务。消息流可包括下列节点：启动、管道对、分支和路由。
端点(Endpoint)
一个基于资源定位标志符的地址。Business Service的端点是接入的外部服务的资源地址；而Proxy Service是对外发布的新服务的资源地址。
网上可访问的一些WSDL地址：http://blog.csdn.net/carnival_/article/details/7264368
注意WSDL地址和端点地址不同，在访问到WSDL后，断点地址在WSDL的Port部分可以看到具体location。
消息流(Message Flow)
消息流定义了代理服务的实现。消息流可以包括管道对和下列节点：开始、路由和分支。消息路由、业务逻辑处理、服务编排、服务整合等操作都是在消息流中实现，在OSB开发中，主要工作就是消息流的开发和调试。
管道对(Pipeline Pair)
通过“编辑消息流”页可以添加管道对节点。管道对节点包含一个请求管道和一个响应管道。消息流可以不包含管道对节点，也可以包含多个管道对节点：代理服务（或对服务的操作）的请求和响应管道，以及可为阶段、管道和代理服务定义的错误处理程序管道。管道可以包括一个或多个阶段，阶段又可以包括操作。
阶段（Stage ）
阶段是操作的容器，如消息路由、日志记录、消息广播、消息传送等操作都可以放到阶段中操作。
动作（Action ）
动作是用户定义的运行时的逻辑步骤，用户需要实现的功能一般通过添加动作节点来实现，OSB已经提供了很多不同类型功能各异的默认节点，方便用户进行消息流开发。
路由节点（Route Node ）
路由节点是在管道对中的请求和返回之间的交换节点，主要是用于调用业务服务。用于定义消息目标的容器也可以用于执行单向通信，例如使用文件或email作为代理服务中请求处理和应答处理的分界点当Route节点分发了请求消息后，请求处理就认为结束，而当Route节点收到应答消息时，表明应答处理的开始。
路由节点一般出现在管道对之后，处于管道对中的请求和应答之间。
上下文变量（Context Variables）
上下文变量是消息进入OSB总线之后的存储载体。在消息通过传输层之后，绑定层会自动根据消息协议和消息内容，将其绑定到上下文变量中；当消息要输出OSB之前，OSB会根据需要自动将上下文变量中的消息内容转换成为符合输出协议类型的消息格式。
上下文变量主要包括以下结构：
$header: 包含SOAP 消息的SOAP 标头（用于包含SOAP 标头的SOAP 消息）。header 变量对于非SOAP 消息类型包含一个空的SOAP 头元素。
$body: 有下列几种情况：SOAP 消息- 包含从SOAP 信封中提取的 部分；非SOAP、非二进制消息- 包含包括在 元素中的整个消息内容。二进制消息- 包含包括在 中的对该二进制消息的内存中副本的引用。
$attachments: 包含某个特定消息的MIME 附件。
$fault: 包含在消息处理期间所发生错误的相关信息。
OSB中的消息上下文是一组存储消息内容的属性，并提供消息的元信息。