JBI is a Java based standard for building an integration systems by using plug-in components which interoperate through mediated message exchanges. The message exchange model is based on the WSDL 2.0 spec. 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. 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.
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.
Let’s take a brief look at some lessons we’ve learned in using JBI 1.0. The JBI specification covers several areas including message passing between components, packaging, deployment and installation of JBI artifacts, lifecycle management and more. In our view, the central piece is the concept of Normalized Message Exchanges and the Normalized Message Router. Normalized Exchanges allow different components to interact with each other without any knowledge of each other, and the Normalized Message Router, being the only mean of communications between components, is the key to loose coupling between services. In short, we see JBI 1.0 as the only way to plug in existing third party components. We’ve also learned that normalizing on XML alone can be problematic because handling non-XML messages as attachments to a normalized message is not always easy. The JBI packaging and the JBI classloading architecture was also not flexible enough – and JBI shared libraries are not a good enough answer. Also, creating components is too complex due to restrictions and requirements of the JBI spec. Another problem is related to some Java specification like JAX-WS and JAX-RS which do not fit well inside a JBI world, mainly because they tie the service to the protocol using annotations. JBI strongly Decouples the business logic from the protocol, which is a good thing, but JAX-WS and JAX-RS have a much simpler approach. Many of these lessons have caused ServiceMix 3 to go beyond the specification requirements to provide additional features. Additionally, the ServiceMix 4 design works to accommodate these lessons directly into it’s design and architecture.
The ServiceMix 4 architecture is quite different from the ServiceMix 3 architecture. Most notably, the core of ServiceMix 4 is based on OSGi instead of JBI. The reason for this is simple and can be described with a single word – flexibility. As shown by the diagram, ServiceMix 4 can more easily accommodate the integration of various technologies through the OSGi underpinnings and the NMR and JBI simply become one of the supported services. The OSGi implementation used by ServiceMix 4 is Apache Felix, but the goal is to be able to deploy on top of any OSGi container. Using OSGi as the base of the ServiceMix 4 Kernel provides the best runtime platform for Java. The OSGi modularity provides a superior classloading architecture, many container level services and a registry for services and what are known as bundles in OSGi parlance – jar files with enhanced metadata. Now let’s take a closer look at some of these container level services.
The ServiceMix 4 architecture is quite different from the ServiceMix 3 architecture. Most notably, the core of ServiceMix 4 is based on OSGi instead of JBI. The reason for this is simple and can be described with a single word – flexibility. As shown by the diagram, ServiceMix 4 can more easily accommodate the integration of various technologies through the OSGi underpinnings and the NMR and JBI simply become one of the supported services. The OSGi implementation used by ServiceMix 4 is Apache Felix, but the goal is to be able to deploy on top of any OSGi container. Using OSGi as the base of the ServiceMix 4 Kernel provides the best runtime platform for Java. The OSGi modularity provides a superior classloading architecture, many container level services and a registry for services and what are known as bundles in OSGi parlance – jar files with enhanced metadata. Now let’s take a closer look at some of these container level services.
The ServiceMix 4 architecture is quite different from the ServiceMix 3 architecture. Most notably, the core of ServiceMix 4 is based on OSGi instead of JBI. The reason for this is simple and can be described with a single word – flexibility. As shown by the diagram, ServiceMix 4 can more easily accommodate the integration of various technologies through the OSGi underpinnings and the NMR and JBI simply become one of the supported services. The OSGi implementation used by ServiceMix 4 is Apache Felix, but the goal is to be able to deploy on top of any OSGi container. Using OSGi as the base of the ServiceMix 4 Kernel provides the best runtime platform for Java. The OSGi modularity provides a superior classloading architecture, many container level services and a registry for services and what are known as bundles in OSGi parlance – jar files with enhanced metadata. Now let’s take a closer look at some of these container level services.
ServiceMix 4 provides a powerful console in the form of a command line shell for access to the ServiceMix runtime. This command shell is extensible and has the ability to spawn sub-shells such as separate shells for OSGi, for the OSGi bundle repository, for ActiveMQ, for certain utilities, etc. The console also provides remote access via the command line to the ServiceMix runtime. Creating new commands for the console is actually pretty easy as commands are just annotated Java classes. The shell currently supports a command history, pipes and some utility functions like cat and grep which combined together are really helpful when developing or using the ServiceMix Kernel.
ServiceMix Kernel comes with a file based deployer to provide advanced deployment capabilities. In addition to being able to hot-deploy OSGi bundles, the deployer can also handle other types of Artifacts, such as JBI artifacts, plain WARs or Spring xml configuration files. The deployer also supports exploded artifacts which is quite handy at development time so that you don’t have to repackage and redeploy your application. Support for non OSGi artifacts is achieved by implementing deployment listeners, registered in the OSGi registry. These deployment listeners also register URL handlers which can be used together with the other URL handlers provided by the Kernel, such as a maven URL handler and an OBR (Object Bunde Repository) to access maven and OBR repositories. For example, you can install a WAR from a maven repository in a single command line in the console. Last, the deployer also support a file based mechanism for OSGi Configuration Admin (a standard OSGi service for storing configuration which can easily be leveraged by spring application) where the configuration can be updated at runtime by simply modifying a given property file. This can be used to change the logging system configuration for example.
SerS
ServiceMix Kernel provides a simple provisioning system that you can use to easily install and uninstall your applications. Applications are defined using a very simple xml descriptor that contains a list of dependant features, a list of bundles to install and some optional configuration as a map of key value pairs. The bundles allow reusing any url available in ServiceMix Kernel and this enabled JBI artifacts deployment and reuse existing maven repositories. Available applications can be listed, installed and uninstalled in a single command line. ServiceMix Kernel can also be integrated in the operating system as a service, so that the lifecycle of ServiceMix Kernel can be tied to the OS. A few commands are also provided to manage instances (such as creating new instances, starting and stopping instances), but this is still work in progress.
The Normalized Message Router (referred to as the NMR) has been reworked to focus on its purpose (message passing between components) and fit nicely into the OSGi environment. The concept of a JBI component does not exist anymore at the NMR level though it is fully supported at the JBI layer level. The main reason is that the concept of endpoint is required to achieve binary compatibility for JBI artifacts, but not as a core concept for the NMR as the NMR really only knows about endpoints. In doing that, there is no packaging requirement beyond what OSGi specifies: any OSGi bundle can be used to impement the component Concept, which is not mainly about registering endpoints is the NMR. This is why we now consider endpoints as first-class citizens in ServiceMix 4. Endpoints are the same than in JBI 1.0, but they now need to implements a really simple interface which consists in two methods: one for injecting the Channel that will be used by the endpoint to communicate with the NMR, and another one to receive message exchanges sent to it. This means that the endpoint will use a push delivery rather than having the component actively poll for messages. The NMR is also available through the provisioning system and thus can be installed very easily on ServiceMix Kernel.
ServiceMix 4 supports JBI 1.0 through a layer developped on top of ServiceMix 4 NMR. It simply consists in a few bundles that need to be deployed, but these are provided through the provisioning system and is installed by default in ServiceMix 4. The JBI packaging is supported through the use of ServiceMix Kernel deployer that we’ve seen which also registers a URL handler to be able to install JBI artifacts from OSGi or from the provisioning system. This layer provides an easy migration path from ServiceMix 3.
![About the presenter ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)