ServiceMix - JBI - 1. Overview

Overview

What is JBI ?

A Brief Intro to JBI A brief introduction to JBI is available in the What is JBI? document. This document is more in-depth and supplemental.

The Java Business Integration spec (JBI) is a java based standard to build integrations systems by using plug-in components which interoperates through mediated normalized message exchanges.The message exchange model is based on the web services description language (WSDL).

The figure at the top shows a high level concept of JBI of the plug-in framework. The JBI environment provides interfaces to be used by plug-in components, while the components provides interfaces used by the JBI environment. Components do not interact with each other directly. Instead, as shown in the bottom figure, JBI acts as an intermediary to route messages between components. This separation is the key to decoupling between service providers and consumers, which is one of the goal of service oriented architectures. In addition, it provides a key point for message processing and monitoring.

JBI plugin framework

JBI decoupling

In this WSDL-based, service-oriented model, JBI plug-in components are responsible for providing and consuming services. By providing a service, a component is making available a function or functions that can be consumed by other components (or even itself). Such functions are modeled as WSDL 2.0 operations, which involve the exchange of one or more messages.A set of four WSDL-defined, basic message exchange patterns (MEPs) crisply defines the sequence of messages allowed during execution of an operation.This shared understanding, between consumer and provider components, of the message exchange pattern is the foundation of interoperability of such components in JBI.

The services provided by components (if any) are described to JBI by the component, using WSDL 1.1 or 2.0. This provides an abstract, technology-neutral model of services using XML-based message exchanges. WSDL also provides a mechanism for declaring additional service metadata of interest to service consumers and JBI itself. Components can query JBI for the for the WSDL describing available services.

翻译：

JBI - Java Business Integration specification,，Java业务整合规范。它是一个基于Java的、用来构建集成式的系统的规范，它规定这个系统系统是由一些插件式组件构成并且这些组件之间以间接的、规范化的消息交换来实现相互协作。它的消息交换模型是基于网络服务描述语言， web services description language (WSDL)。

第一张图片从比较高的层次展示了组件框架JBI的概念。JBI环境向组件提供接口，同时组件也向JBI环境提供接口。组件之间不会直接交互。而在第二张图片中，JBI扮演了一个在组件之间传递消息的介质。这种分离是降低服务的提供者与消费者之间耦合性的关键，这也是面向服务架构的目的之一。此外，它提供了消息处理与消息追踪的要点。

在这个基于WSDL的、面向服务的模型中，JBI组件负责提供服务和使用服务。提供了一个服务，一个组件就有一个或几个可以被其它组件（甚至自己）使用的功能。这些功能被塑造成WSDL2.0 operations（wsdl中的概念，所代表的含义类似于Java中的方法），它涉及到一个或多个消息的交换。4个由WSDL定义的基本的消息交换模式很干脆的定义了在一个operation（操作）执行期间所允许的消息顺序。在使用者与提供者对消息交换模型有共同的理解是JBI中组件间相互协作的基础。

JBI Architecture

JBI Architecture

This picture describes the architecture of the JBI system.

• The JBI environment provides deployment, control & monitoring features through JMX based administration tools
• The Normalized Message Router or NMR, which provides the mediated message exchange infrastructure
• Components (in white rectangles)

Components are divided in two categories:

• Service Engines (on top) provides business logic and transformation services and also consumes such services.
• Binding Components provide connectivity to services external to the JBI environment.
  Service engines and binding components can function as service providers, consumers, or both. Note that the distinction between SEs and BCs is purely pragmatic, but the separation of business logic from communications logic reduces complexity and increases flexibility.

The JBI environment, in addition to the messaging system, defines a management structure based on JMX which provides standard mechanisms for:

• Installing components
• Managing a component's life cycle (start / stop)
• Deploying service artifacts to components
  JBI components often function as a type of container to which artifacts can be deployed to add new service or provider logic. For example, a service engine that provides XSLT-based transformation services would have XSLT style sheets deployed to it, in order to add new transformation operations. This process of adding such component-specific artifacts to an installed component is called deployment, to distinguish it from component installation. Such an artifact is called a service unit, while collection of deployment artifacts and associated metadata is called a service assembly.

The core message exchange concept implements WSDL messaging. Service requests are generated by consumer components, routed by the NMR, and delivered to a provider component. For example, the BPEL SE may generate a request, which happens to be provided by the external service provider connected to the WS-I BC. The NMR will route the request to the WS-I binding. The SE in this case is a service consumer, and the BC a provider.

翻译：

这个图片描述了JBI系统的架构：

• JBI环境通过基于JMX的管理工具来提供部署、控制和监控的功能
• 规范化消息传递（Normalized Message Router or NMR），它作为中间消息交换的基础。
• 组件（白色的长方形）

组件被分为两类：

• Service Engines（上方），提供业务逻辑、转换服务和使用其它服务
• Binding Components，提供外部服务与JBI环境之间的连通性

     Service Engines和Binding Components都可以最为服务的提供者和服务的使用者而存在，或者两者都是。现在你注意到它们之间的区别纯粹是拼写不同，但是将业务逻辑从通信的逻辑中分离出来可以降低复杂度并提高灵活度。

JBI环境还有消息系统定义了一个基于JMX的管理结构，它可以提供一些标准的机制：

• 组件安装
• 管理组件声明周期（启动/停止）
• 将service artifact部署到components

     JBI components经常起一种容器的作用，artifact可以被部署进去用来添加一些新的功能。例如，一个提供基于XSLT转换服务的service engine中一定会某些部分来给它提供XSLT样式表。给这样一个可以被安装的组件添加一个由组件来具体化的、来指定的artifact，我们把这个过程称为部署，以区别于组件安装。这样的artifact我们称为service unit，将这些artifacts收集到一起并将它们相互关联的构件，我们把它称为service assembly。

以消息交换作为基础的核心实现了WSDL规范。consumer component发出请求，消息经过NMR传递，被送达provider component。例如，BPEL SE可能请求一个服务，恰巧有一个连接到WS-I BC上的外部组件可以提供这个服务。NMR就会传递这个请求到WS-I binding。在这个案例中SE是service consumer，BC是service provider.