- Introduction
- Features of Integration Brokers
- Harris Kern's Enterprise Computing Institute
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Features of Integration Brokers
Once a message (which may or may not be SOAP-based) has been received, the integration broker optionally transforms it and then routes it to the correct recipient internally, which is often a legacy or ERP system.
Transformation
A feature more common in integration brokers than pure MOM packages, transformation is the process of converting a message from one format to another. This is commonly performed to deal with differences in data formats or to decompose the message to the appropriate level of granularity.
As a simple example, suppose an incoming message contains two fields: first name (First) and last name (Last). Unfortunately, the structure of the recipient system (a database, an ERP system, etc.) requires that the name be concatenated to one field, Name. In this case, there has to be a mechanism for mapping the incoming field to the appropriate destination fields. This is a common occurrence in data-level integration with enterprise application integration.
Figure 1 illustrates such a sample data-transformation process.
)
Figure 1 A sample transformation process.
The mappings between the systems are typically stored in a mapping repository that tracks the source system, the format of the incoming messages, the destination system, and the desired format of the destination system.
Content-Based Routing
In many cases, the integration broker has to determine where to route the incoming message, choosing among more than one possible recipient based on some kind of criteria. Basic routing is usually specified at design time through a GUI; while useful, this setup may not be adequate for many firms. Content-based routing is more powerful because it can route messages based on topics, header, or payload. Consider the example of a financial company that caters to individuals with varying levels of net worth. The firm wants to route certain messages to designated brokers who handle orders above a specific amount (say $50,000). For such large orders, the firm wants the broker to have the customer's trading history, risk profile, and recommendations for similar securities.
To perform the routing correctly, the integration broker must be able to look at the fields of the incoming message, perform additional processing (pull up the trading history, risk profile, and so on), and then include this information with the message to the broker. This content-based routing results in a more optimal solution than just routing the bare message to the broker; with the additional context, the broker should be able to provide better customer service.
Workflow Modeling
Most integration brokers provide some form of workflow modeling tool to visually capture the mappings of message and routing. This produces a model that's stored in a repository to be updated (and versioned) as necessary. Unfortunately, there is no standard format for the workflow models that these tools create, resulting in incompatibilities.
Adapters
Most enterprises have a number of legacy applications that were either acquired (through third parties or literally from an acquisition) or built as the company matured. Of course, these applications typically have their own APIs, which often are incompatible with other APIs. Similar to a database driver, an adapter is a software module that allows a connection to be established to a particular system: ERP system, legacy system, and so on. Adapters are typically written by third-party software companies or consulting firms that have built this knowledge through multiple projects. (In many cases, the software companies started as consulting firms). It stands to reason that the most popular adapters connect to popular systems, including ERP packages such as SAP, PeopleSoft, and so forth, and customer relationship management packages such as Siebel, Clarify (purchased by Nortel), and so on.
Often, before the integration broker can communicate with the destination system, it has to load the adapter and use it to establish a connection. The J2EE specifications define the Java Connector Architecture (JCA), a platform-independent mechanism for connecting to an external system. It's analogous to the JDBC driver concept, a database-independent API for connecting to data sources (relational databases and flat files).
Message Warehousing
Some of the integration brokers offer a message warehouse: persistent storage that stores the messages that have flowed through the message broker. This persistent storage can be used to perform additional functionality such as message mining and message integrity:
Similar to a data warehouse, the message warehouse allows the administrator to perform message mining to determine trends or performance metrics. As an example, the frequency of a refund message (matched to the refund goods business process) may indicate declining quality of sold goods. Likewise, a light load of messages between two systems may indicate that the business relationship is not generating the expected revenues. The message warehouse can also be used to perform audits to potentially enforce the terms of a service-level agreement.
As persistent storage, the message warehouse stores all the messages that have been sent (or will be sent, if the destination system is down). This message logging can then be used to manually reconcile any discrepancies or exceptions between the source and destination system.
Management
Usually the weakest areas of most integration brokers, the management feature is typically offered in the form of a console. The console allows the administrator to start and stop processes, view performance statistics, and set alerts for exceptional conditions (for example, if the number of messages per second fall below an acceptable range). This feature will be further explored with the discussion on web service networks.