Service Pass-Through in Neuron ESB

Today I’d like to talk about how you can connect your services (and clients) to pass message traffic through an ESB, rather than directly connecting to each other. We call this “service pass-through”.

Why Service Pass-Through?

Before getting into how this is done, let’s explore why you might want to.

Loosely-coupled routing. Imagine you have a client that interacts with a service (Figure 1a), but now you have a requirement to involve a third program that also needs to know about the information the client is exchanging with the service. How do you bring this third system into the mix? A conventional answer is to either make the original service a client of a new service (Figure 1b); or make the original client a client of two services (Figure 1c).

Figure 1: interconnecting services in code is not loose coupling

 Neither of these answers is very satisfactory because they force you to tightly couple your routing. If you are a fan of SOA and value loose coupling in other areas of your work, this tight coupling of how your services are linked should offend you.

 In contrast, if your client and service are have an ESB interposed between them (Figure 2), the ESB can share information with other messaging parties. This approach helps keeps your services pure, context-free and reusable, as you don’t have to add program code to link services together.

Figure 2: passing service traffic through the ESB easily accommodates additional parties.

Mediation of differences. You might have clients and services that can’t interact directly because they aren’t quite compatible, due to differences in transport, security model, message format, or semantics. You can connect each of them to an ESB, however, and the ESB can then interconnect them, mediating between their differences.

Figure 3: Mediation bridges differences in protocol, security model, message format, semantics

Workload Sharing. The ESB can work with multiple instances of services and share workload across them. You can freely add services instances or take them away while running; workload distribution automatically adjusts.

When Worlds Collide. You can get services and non-services to work together. Neuron interconnects easily to services and clients using WCF. Neuron also interconnects to non-services such as legacy system and line-of-business systems using adapters. Once joined to the ESB, these programs can interact even though there be huge gap between the technologies they are use and when they were created.

Auditing and Compliance Monitoring. You may want to keep an audit of your messages in order to show compliances with state, federal, or industry regulations. If your messaging traffic flows through the bus, the bus can take care of the rest.

 Figure 4: Both services and non-services can work cooperatively

The Mechanics of Service Pass-Through

When you define a service to Neuron (usually by importing metadata), one or more service endpoint definition(s) are created. By itself, a service definition is nothing more than an interesting record in a repository. I blogged yesterday about how you can use this repository to create WCF clients based on central configuration.

Things get more interesting when you authorize service-pass through for your service definition. You can enable service pass-through for the client-side and/or the service-side, as shown in Figure 5.

 Figure 5: A service definition with client- and service-side pass-through enabled

Enabling client-side pass through causes Neuron to create a client connector, which is a hosting service for clients. This hosting service looks just like the client’s actual target service, with the same binding and security model. The only difference is that you point the client to a different address on the ESB Server. Client-side pass- through maps incoming client messages to an ESB topic and to a publisher. As client messages are received, the ESB publishes those messages on a topic. Any party with a subscription to that topic receives a copy of the message. This works for both 1-way and request-reply messaging.

Enabling service-side pass through causes Neuron to create a service connector, which is a client to the service used by the ESB Server. This client has a matching binding and security model for the service it is connecting to. The service connector is mapped to a topic and a subscriber. As messages are received over the ESB, the service connector passes them on to the service. Replies from the service are passed back over the bus to the originating client.

Notice that in service pass-through, you aren’t asked to modify your client and service in any way, other than to change the address the client points to.

Service pass-through the ESB avoids tightly-coupled routing and keeps your services more modular and reusable. It allows for mediation between program differences and allows services and non-services to interact.