The Red Hat JBoss Fuse Architecture

Introduction

IT system integration is one of the biggest challenges facing modern enterprises. Red Hat JBoss Fuse; one of the modern open source integration platform, using a lightweight standards-based, loosely-coupled approach. By relying on standards, JBoss Fuse reduces the chances of vendor lock-in. By advocating loose coupling, Red Hat JBoss Fuse reduces the complexity of integration.

An ESB is a standards-based integration platform that combines messaging, web services, data transformation, and intelligent routing to reliably connect and coordinate the interaction of significant numbers of diverse applications across extended enterprises with transactional integrity.

An ESB is typically defined by the list of services it provides. Services commonly included are:

• Transport mediation—not all applications and services that need to be integrated use HTTP or JMS.
• Dynamic message transformation—not all services use SOAP and are unlikely to require the same message structures.
• Intelligent routing—not all messages emanating from a source are intended for the same destination. The target destination will likely depend on some criteria inherent in the message.
• Security—only authorized and authenticated users need have administrative access to the JBoss Fuse runtime; services and brokers that handle sensitive information may restrict access by unauthorized or unauthenticated clients only; similarly, messages that contain sensitive information may be encrypted as they transit their routes.

An ESB simplifies the complexity of integration by providing a single, standards-based infrastructure into which applications can be plugged. Once plugged into the ESB, an application or service has access to all of the infrastructure services provided by the ESB and can access any other applications that are also plugged into the ESB.

Architecture

Red Hat JBoss Fuse has a layered architecture that consists of the following three layer as shown below.

Kernel layer

The Red Hat JBoss Fuse kernel layer is based on Apache Karaf, an OSGi-based runtime that provides a lightweight container into which you can deploy various components and applications.

The kernel layer interacts with the Services layer to set up, coordinate, and manage logging, and security; and to manage transactions on a per service basis. It also interacts with the Service layer to set up message broker instances with the configuration specified in the supplied activemq.xml file.

The kernel layer provides these features:

Console

The Red Hat JBoss Fuse console is a shell environment that enables you to configure all JBoss Fuse components and to control the JBoss Fuse runtime, including brokers and messages, JBoss Fuse kernel instances, logging, and so on.

Logging

A dynamic logging back end supports different APIs (JDK 1.4, JCL, SLF4J, Avalon, Tomcat, OSGi). By default, Red Hat JBoss Fuse enters all log messages in a single log file, but you can change this behavior by configuring different log files to store log messages generated by specific JBoss Fuse components.

Deployment

We can manually deploy applications using the osgi:install and osgi:start commands, or you can automatically deploy them by copying them to the hot deploy folder. When a JAR file, WAR file, OSGi bundle, or FAB file is copied to the InstallDir/deploy folder, it's automatically installed on-the-fly inside the Red Hat JBoss Fuse runtime.

Fuse Application Bundle (FAB)

FABs automate the creation and maintenance of OSGi bundles, freeing application developers to focus on building their applications.

Provisioning

Applications are provisioned through hot deployment, the Maven repository, and remote downloads.

Configuration

The properties files contained in the InstallDir/etc directory are continuously monitored, and changes are automatically propagated to the relevant services at configurable intervals.

Security

The security framework is based on Java Authentication and Authorization Service (JAAS). You can secure separately, Red Hat JBoss Fuse's OSGi container, deployed instances of the embedded messaging service, and deployed instances of the embedded routing and integration service.

OSGi container

We can deploy a variety of packages and files into Red Hat JBoss Fuse's OSGi container including Fuse Application Bundles, OSGi bundles, JARs, WARs, Blueprint, and Spring.

Dependency injection frameworks

The supported dependency-injection frameworks facilitate deploying new OSGi applications and updating existing ones dynamically:

• Blueprint
• Spring

Services layer

The Red Hat JBoss Fuse services layer consists of all of the interfaces and implementation classes for each of the embedded services. It interacts with the application layer to communicate with user-developed applications that want to access and use these services.

• Messaging

Using Red Hat JBoss Fuse's messaging service, based on Apache ActiveMQ, we can create JMS message brokers and clients, then deploy them as OSGi bundles. JBoss Fuse comes with a default message broker that autostarts when you start up JBoss Fuse, but you can replace it with your own message broker implementation.

• Routing and integration

Using JBoss Fuse's routing and integration service, based on Apache Camel, we can define routes and implement enterprise integration patterns, then deploy them as OSGi bundles.

• Web services

Using JBoss Fuse's web services framework, based on Apache CXF, you can create JAX-WS web services, then deploy them as OSGi bundles.

• RESTful services

Using JBoss Fuse's RESTful services framework, based on Apache CXF, you can create JAX-RS web services, then deploy them as OSGi bundles.

• JBI

Using JBoss Fuse's JBI service you can create and deploy Java Business Integration (JBI) 1.0 service assemblies and service units in JBoss Fuse. See Using Java Business Integration for an introduction to JBoss Fuse's JBI environment.

• Transaction Manager

JBoss Fuse's transaction framework employs a JTA transaction manager, based on Apache Aries, to expose various transaction interfaces as OSGi services. The transaction manager enables you to create and deploy JTA-based or Spring-based transacted applications in JBoss Fuse. Both the embedded messaging service and the embedded routing and integration service provide easy means for interacting with the transaction manager to implement JMS transactions.

• Normalized Message Router (NMR)

The JBoss Fuse NMR is a general-purpose message bus whose primary role is to transmit messages between the various application bundles deployed into the OSGi container. In this case, no normalization is required because OSGi places no restrictions on the format of message content.

However, when the JBI container is also deployed, the NMR is also used to transmit messages between OSGi and JBI applications. Normalization must be performed on messages transmitted to a JBI endpoint, because JBI requires that message content be formatted in XML, as defined in a WSDL service description.

JBoss Fuse provides a simple Java API for creating NMR endpoints that receive and process messages from the NMR and for writing clients that send messages to NMR endpoints.

Application layer

The JBoss Fuse application layer is where user-developed applications reside. JBoss Fuse provides many APIs with which you can create client and service applications that access and use the embedded services running within JBoss Fuse.

• Messaging—Client-side APIs
• Routing and integration—The Embedded Routing and Integration Service
• Web and RESTful web services—Front end options.

Download

S.No	File Name	Download
1	The Red Hat JBoss Fuse Architecture.pdf	Download