Integration
At the core of most any enterprise which faces the need to integrate their various backend systems, lies the challenge of these systems often not being designed for integration. Usually the "older" the backend system, the more siloed or proprietary they tend to be which in turn hampers integration efforts. Even some of the newer systems which claim to follow open standards or open interfaces still present a challenge by making use of non-standardized business objects such as a customer record in system A not structured the same as in system B.
To solve these kinds of integration issues, we usually find the architectural component called an Enterprise Service Bus (ESB). Its main function is to ease the integration issues with backend systems, hiding the need to know how to communicate with each backend system, what message format they want, or with what technology they require for interaction. All the caller needs to know is that there is a mediator who will take their requests, process it, and return some response back.
Best practices and reference architectures, which are based on collected experiences from projects all over the world, propose to keep the ESB-based operations short running if needed in one transactional scope and without higher-leveled business logic. If an operation needs to have some of these features that it would be advised to offload these tasks to some sort of a business rules engine or a business process engine for more complex actions. A perfect combination is to add the Red Hat JBoss Business Rules Management System (BRMS) into the mix, allowing for an orchestrator to enhance the ESB functionality, raising your enterprises integration abilities to a new level.
The Red Hat JBoss Fuse product provides you with the tools to build your enlightened ESB. It is built on five core components, being Apache Camel, Apache CXF, Apache ActiveMQ, Apache Karaf and Fuse Fabric.
Apache Camel takes the core of the ESB. It is an Integration Framework, based on the Enterprise Integration Patterns which provide functionality like routing, mediation and transformation of messages. These functions can be defined in Domain-Specific Languages (DSL) including Java-based Fluent API, Spring or Blueprint XML Configuration Files and Scala DSL. Apache Camel includes 100+ components out of the box (OOTB). The components allow integration with protocols and systems through an endpoint where the endpoint is the object listening for a message, from clause, or sending a message, to clause. Camel is also designed to seamlessly integrate with other frameworks such as Spring, Blueprint and Guice.
Apache CXF is a services framework which helps to build and develop services using front end programming APIs, like JAX-WS and JAX-RS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI.
Apache ActiveMQ provides services for a reliable, multi-protocol messaging. While having a small footprint it does run on various operating systems and provides a set of native language clients. Its pluggable architecture does not only take the pain out of transporting messages from one system to another, it also allows protocols and features to be added or customized when required.
Apache Karaf is a small OSGi based runtime which provides a lightweight container onto which various components and applications can be deployed. It provides the latest OSGi containers: Apache Felix Framework and Eclipse Equinox.
Fuse Fabic provides a framework for configuring, provisioning and running Fuse and Apache integration software on any number of machines. It provides distributed management and dynamic configuration, with automatic discovery of resources. Service endpoints can be relocated and load-balanced, and can grow or shrink elastically. By doing so it helps enterprises to automate the configuration, deployment and versioning of integration components, even when configurations are complex with clustering and fail-over. Fuse Fabric also enables the operation of hybrid deployments, including on-premise, on-cloud or across both. It should be noted that while Fuse Fabric is for management, JBoss Operations Network (JON) is for monitoring.
For more information on Red Hat JBoss Fuse please refer to http://www.redhat.com/products/jbossenterprisemiddleware/fuse/.
Enhancing
Your vision of the future for your enterprise includes moving towards integration with an ESB. You are looking to work with open standards, are interested in expanding your organizations abilities with messaging, routing, and all that is provided for in the JBoss Fuse technology.
Now as we move onwards, what is next?
You have taken that extra step into the future, brought your enterprise forward in a natural evolution by empowering integration with your various systems through the use of an ESB based on JBoss Fuse technology. Integration has been achieved, the open standards are being leveraged, the various JBoss components in your architecture are humming along and your enterprise is expanding. Now it is time to leverage the powers that yet remain untapped, the subtle enhancements that it can bring your workflows, your messaging, and your business processes to the forefront of the expanding toolbox your development teams are using.
We will take a look at a few of these enhancements by explaining a few use cases you might run into during your application development, your integration development, or when exploring business processes that lend themselves to automation of your organization.
Use Cases
- call JBoss Fuse (Camel) services from a business process (BPM).
- call a business process from a JBoss Fuse (Camel) route, such as leveraging human tasks.
- call JBoss BRMS to apply rules from JBoss Fuse (Camel) route, such as content based routing rules.
This use case is one of the most interesting so we will start with this one. The idea is that you want to reuse your existing JBoss Fuse Camel routes, by calling an endpoint during some business process step. With JBoss BRMS the way to approach this is one of two ways, either you embed the Camel route into a domain specific node that you created, or you can use a service task to call a service endpoint that exposes the Camel route to your application.
 |
| Fuse specific node |
Both solutions would look just like the home loan process shown here where the Credit Report Node is a domain specific node that is available on the design palette for a business user to leverage an external service that provides a credit report. This is a Camel route that transforms this enterprises standard message into a third party service format and translates the reply back into a digestible format for further usage.
Start a business process
The second interesting use case is that you want to trigger a more complicated process, maybe one that includes human tasks, at some point in the Camel route you are designing. Setting up a wait state in your Camel route would be adding complexity and more code you would need to maintain. Leveraging the BPM engine provided in JBoss BRMS product will enable you to implement processes with an open standards based approach, centralize your processes, centralize any business logic, enable your human tasks, provide for domain specific interactions, and support advanced initiatives such as adaptive case management.
To facilitate this sort of external usage, the JBoss BRMS BPM engine provides a RESTful interface, so that all you need to do is to gather the data required for submission to your process and call it through the REST API. It is left to you to decide if your architecture needs to interact with the process synchronously or asynchronously. This method also provides for complete decoupling of your BPM components from your messaging components in the ESB.
Leverage business rules
The final use case involves externalized business logic, removing it from your integration efforts and wanting to expose this to all existing and future applications in a unified manner. With JBoss BRMS you can provide for externalized business logic by deploying this as an OSGI bundle in your ESB, you can expose is as a decision service, or you can embed it within your applications directly.
Within your Camel routes you might be interested in applying content based routing based on configurable rules. These rules you want to leave to some business person to tweak as they see fit for the products and services that they want to leverage in your architecture. By allowing your messaging routes to make a call out to a decision service, you are leveraging all the powers that a rules engine gives you, along with the ability to change these rules at runtime without changing any of your deployed applications or ESB service routes.
Future
So what are some of the things that might be of interest for the coming releases of these products? What might be helpful and make implementing your use cases even easier? Here is a short list, nothing given with a timeline, just a wish list of sorts.
- it would be interesting to be able to leverage our JBoss Fuse Camel routes in the JBoss Enterprise Application Platform (EAP) container. This would ease some of the integration in our architecture when we look at the use cases discussed above.
- worth looking into is having better OSGI integration in various JBoss products, such that it would ease our use of JBoss BRMS as a rules engine if we could deploy it as an OSGI bundle in our existing ESB architecture.
- when integrating more of our existing web services into the ESB described above we could use some better product integration, thus not having to host several ESB environments or service layers across our architecture.
Webinar
On 20 August 2013 there will be a live webinar hosted by Red Hat on the topics discussed in this article. Register below on the link provided and you will be taken on a tour of the topics discussed here.
(Thanks to Patrick Steiner, Red Hat JBoss Solutions Architect, contributing author)