Skip to content

High Level Patterns

These patterns are often seen in the Enterprise and can be applied to a broad set of problems.

System/application integration

One of the most common applications of a messaging platform is integrating disparate systems.  An ESB with its support for services, processes, and complex interactions is ideally suited for this task.  Neuron easily connects systems together, often with no coding; using many different types of connections, such as Web services or native protocol adapters, combined with simple and elegant management tools.

It is often tempting to simply write integration solutions from scratch, just like any other custom application development effort, but there is usually more to consider than initially thought.  Using Neuron as an intermediary for message traffic provides a number of important advantages, including:

  • Location transparency – the physical addresses of the services are known only to the ESB, eliminating impact to applications that use these services, should the service address change.
  • Operational support – message traffic, service endpoint health, errors and exceptions are just a few of the elements that are easily monitored, without the need for any coding.
  • Protocol mediation – endpoints are free to use any protocol (e.g. WS-Security, S/FTP, etc.), if the client can connect to the ESB, messages are routed and converted as required, with no impact to the client applications/services.
  • Message processing – messages can be transformed, enhanced, and processed in almost endless ways as they pass through the ESB.
  • Centralized management tools – ESB configuration is maintained via a single tool, eliminating impact to developers of applications and services.

All of these advantages add up to reduced cost of ownership, greater developer focus on business value, quicker delivery of business functionality, better error and exception handling, greater visibility into operational conditions; more bang for the buck.

As an example, Figure 6 shows a configuration that integrates a multi-system process where Neuron connects an LOB system using an adapter (either Microsoft LOB Adapters, or custom Neuron adapters) with multiple systems exposing Web service interfaces.  Neuron provides the connectivity between the systems, message transformations, message routing and business process in the appropriate sequence.

Figure_6.gif
Figure 6 – Self Contained EAI

This example illustrates how an adapter configured to periodically (1) trigger a request for a customer record (2) from the LOB application (3) would route the response to multiple services (4, 5), potentially transforming the message at any point.  Neuron provides support for conditional subscriptions and/or conditional process execution (used for transformation), allowing for very sophisticated message routing and business process scenarios.

This same pattern also supports client initiated processes that keep multiple systems in sync (for example, when data is updated in the LOB application a message is routed to other systems where the data is also updated and the systems are kept in sync.)

Real-time BI/MDM

The proliferation of databases in the enterprise often leads to data duplication which can hinder the ability to obtain a single source of the “truth” for data.  Synchronizing the systems with this data becomes essential in maintaining data integrity across the enterprise.

Neuron provides a convenient and powerful platform to synchronize data across disparate systems.  By adding adapter connectors and/or service connectors to provide a connection directly to databases or data services, messages flowing across the ESB can be routed to these databases to update the data model as required.  Messages can be triggered by change capture features of LOB adapters, or invocation of client services.

Figure_7.gif
Figure 7 – Message Based Real-Time BI/MDM

Leveraging the processes for message transformation, messages can be reshaped and reformed to match the required format for insertion into existing databases and data models, often without coding.

Service virtualization (gateway)

As Web service proliferation grows, managing endpoint addresses gets more and more challenging.  Neuron can be configured to expose a single Web service endpoint that functions as a gateway for all service calls, this is often referred to as service virtualization or service abstraction; Neuron provides the layer of abstraction to all business Web services.

Figure_8.gif
Figure 8 – Service Virtualization

This configuration is shown in Figure 8, and also highlights the use of processes and transformations to modify the format or content of the messages.  As discussed earlier, Neuron (by default) does not care about the contents of the messages, so any message may be exchanged with a client connector, as long as the physical binding will allow (clearly you cannot successfully send SOAP messages to a REST endpoint, and vice versa.)

Neuron provides support for virtualizing services addresses, database addresses, and other system components that might be required for a complete SOA implementation.  Configurations can be uniquely identified, applied, and executed by the Neuron environment.  This capability allows users to create configurations for development, test, QA, and production environments, and switch between them, very easily.

Event Driven Architectures

In an effort to move enterprise systems closer to real-time, event driven architectures have begun to become more and more popular.  Neuron provides the features and capabilities that can form the platform of an event driven architecture through the use of components such as LOB adapters that can automatically generate messages from systems that normally cannot produce them, from changes in data contained in the LOB application.

Figure 9 shows a configuration using a LOB adapter configured to generate a message from a LOB application and publish that message onto the ESB where zero or more subscribers can then receive that message.  This configuration is similar to a standard system integration configuration, only the configuration of the adapter is different.

Figure_9.gif
Figure 9 – Event Driven Architecture

As an example, using the Microsoft CRM adapter for Neuron, events can be defined and generated from within Microsoft CRM and published directly to Neuron for routing, processing, and consumption as specified by the Neuron configuration.

Was this article helpful?
Dislike 1
Previous: Technology Patterns
Next: What Can Neuron Do