Centralizing your WCF Configuration with Neuron ESB

Centralizing Your WCF Configuration with Neuron ESB

Today I’d like to talk about how you can store your WCF configuration information centrally with Neuron ESB . While it’s great that WCF allows you to move details such as endpoint, binding, and other information out of code and into config file settings, it can still be inconvenient to work with many individual config files. If you are dealing with large numbers of services, you may desire a way to centralize your configuration information. Neuron ESB provides a service repository for this purpose, plus a neat factory for creating WCF clients. Together, they free you from needing local WCF configuration settings.

There are a number of ways you can program against Neuron, ranging from WCF to JMS to Neuron’s own .NET API. In this case, we’re going to use the Neuron API to retrieve configuration information and create a WCF client; the rest is pure WCF from there.

Adding services to the Neuron service repository is very straightforward. An import wizard can guide you through the steps or you can set things up manually. Service definitions can be imported from metadata at URL, file, or via searching a UDDI directory. The appropriate WSDL, schema, and service endpoints are added to the repository. Neuron employs the same classes for service import that are used by Add Service Reference in Visual Studio and the SvcUtil tool.

Figure 1: Service Definition in Neuron's ESB Explorer

The service repository itself is of course platform independent, making no assumptions about what technologies are used to build services and clients.

For WCF developers, Neuron provides a client factory class that uses the central repository to create auto-configured WCF clients. Here’s how this works. Imagine you are writing a WCF client for an order entry service that has a service contract named IOrderEntry. To develop your WCF client, you go through the usual steps, including generating client code from metadata. However, you don't worry about creating a System.ServiceModel section in your local config file. Instead, you import the target service in Neuron’s service repository.

To instantiate a WCF client in your code, you use Neuron’s Client<T> class, where T is the interface you want a client for.  For example:

      IOrderEntry oeClient = new Client<IOrderEntry>();

What this does is scan the central service repository for a service to locate a matching interface. If a match is found, a WCF proxy is created, using the address, binding, and other information defined in the repository. From this point forward, your client program is using pure WCF, and accesses the service in the usual manner, via named methods:

IOrderEntry oeClient = new Client<IOrderEntry>();
PriceList pricelist = oeClient.GetPriceList();
int orderId = oeClient.SubmitOrder(order);

In the example above, we created the client simply by specifying an interface to Client<T>. In all but the smallest deployments that’s probably not enough information to make a good match. What environment is the service in? Is it available and in good health? Do you have rights to access it? You can be more specific by using alternative constructors to Client<T>. For example, Client<T>(name) will locate a specific service endpoint in the repository by its unique name. More powerful is Client<T>(criteria), which will match an array of name-value properties against properties in the repository. You can use repository properties to indicate any information you like about a service, such as the environment it serves or the version of its contracts.

One valuable service the Client<T> class provides is sparing a developer from having to learn and keep up with the connection details for a target service. Each time a connection is made, the latest information in the service repository determines address, binding details, security settings, and so on. Similarly, administrators can make changes to service locations and access details without worrying about being disruptive to developers.

Another value provided by the Client<T> class is indirection. When you set up a service definition in the Neuron ESB repository, you can optionally enable pass-through of service traffic through the ESB (a subject we will go into more detail about in a separate article). Pass-through of service traffic is transparent to the client and service, but doing so allows additional parties on the bus to share in the messaging. Pass-through also enables bus-managed scenarios such as workflow sharing among multiple service instances. All of this is transparent to the WCF developer, however. if you invoke Client<T> and the matching service definition enables service traffic pass-through, the WCF client that is created will point to a hosting service on the ESB. If service pass-through is not enabled, the WCF client that is created points directly to the actual service. Either way, the usage is the same and the developer won’t know the difference.

Client<T> and the service repository is an example where Neuron adds value, yet you are still using solid, familiar WCF technology to create your clients and services.