Enterprise Service Buses (ESBs) Drive SOA Adoption - Part 3
Blog Post 3 – High Level View of the Neuron Architecture
Introduction
Last time around, in the second installment of this series, I moved from an abstract discussion of ESBs in general to a concrete one focusing on Neuron specifically. I focused on some key aspects of the product. These included the simplicity of the product, the building of the product on the Windows Communication Foundation, and Basic Connectivity. As you saw, you can set up basic messaging within 5 minutes of installing the product. Instead of writing about 500 lines of WCF code for basic publish-subscribe, you can this basic communication without any code.
This time around, I am going to focus on a very high level view of the Neuron ESB architecture. This will help lay a solid foundation for the articles to come. This material in this particular article is influenced by both posts and talks with Neuron’s Architect, David Pallmann.
The bus is best thought of as having a distinct outside and inside, as the figure below illustrates.
· The outside of the bus is concerned with connecting to diverse enterprise applications, services, and legacy systems
· The inside of the bus is concerned with interconnecting endpoints via publish-subscribe messaging and performing integration services
The Outside of the Bus
The outside of the bus has exactly one purpose: to establish connections to any kind of business endpoint in the enterprise. Neuron has strong support for both services and non-services. Applications can talk to the bus in a way that is natural to them in terms of protocol, security model, and message format.
· For service-oriented endpoints, Neuron uses WCF to connect both clients and services.
· For non-service endpoints, Neuron uses adapters to communicate. Neuron supports several types of adapters.
· When you have an endpoint that's neither a service nor has an existing adapter, you can consider wrapping the endpoint with a service, or writing a new adapter (writing a Neuron adapter is nowhere near the daunting task it is in many other products). There is also a .NET API for Neuron that can be helpful in new integrations.
Service support is extensive. You start by defining a service to Neuron. You can locate a service endpoint in a UDDI directory, import a service from its WSDL, or manually define the service as you prefer. You can specify any standard WCF binding or any custom binding you may have. You can use any of the common WCF security scenarios, spanning transport security to message security to federated security.
Adapters supported include WCF LOB adapters, which are superseding the earlier family of BizTalk Adapters. There are already WCF LOB adapters for Oracle, SAP and Siebel available from Microsoft, and many more adapters are available or in development from a variety of sources. Neuron also supports its own .NET adapters, which have a simple interface and are easy to write. Adapters that come with Neuron include ActiveMQ, BizTalk RFID, eConnect (Great Plains), file, MSMQ, SharePoint Server, SMTP Email, SQL Server, and WebSphere MQ.
Anyone who's done a lot of enterprise integration in the EAI space knows that integration jobs can vary from the simple to the complex to the really difficult. A lot of effort has been put into Neuron to make enterprise connectivity as simple and painless as possible, as often as possible.
The Inside of the Bus
The inside of the bus is concerned with interconnecting endpoints through publish-subscribe messaging. Each endpoint that connects to the bus is related to Neuron's internal publish-subscribe messaging model.
Every endpoint is mapped to a party. A party is just a messaging node: we call a party that send messages a publisher, and a party that receives messages a subscriber. Subscriptions link a party to one or more topics of interest. Finally, a topic is a name for a business conversation. So, for example, you might have a publisher named OrderEntry and a subscriber named OrderProcessing, both subscribing to the topic Orders. When OrderEntry publishes a message over the topic Orders, OrderEntry receives a copy of the message because it has a matching subscription. If additional parties want to know about orders, all they have to do is subscribe to the Orders topic. Publish-subscribe is extremely flexible, and Neuron allows you to add parties and change subscriptions live while the system is running.
What makes the communication happen? Neuron supports a variety of Microsoft technologies to perform the communication, from WCF to BizTalk Server. You can also run a mix of technologies, such that different topics provide different qualities of service.
The inside of the bus has another job, which is to provide integration functions. While a message is en route between endpoints, the bus can apply pipelines of processing steps. Functions that can be performed include validating schema, transforming a message, executing rules, executing a workflow, performing additional messaging, and moving message data to/from persistent storage. Integration services are part of what it takes to mediate differences between endpoints: you might for example need to transform a message from one endpoint in order to make it intelligible to another endpoint. They also allow applying business rules or workflows via the bus instead of having to make code changes to your business programs.
Where Are We?
In this installment, we took a very high-level look at the Neuron architecture. The next installment of the series will begin to focus on the internal view of the bus, the issue of publish-subscribe messaging provided by Neuron’s Topic Networks. From there, I will begin to build some applications and tools that show the value of using this tooling rather than writing all this stuff yourself. In particular, I will look at Mediation, Message Routers, and Message Transforms among others.
Thank you for submitting this cool story - Trackback from DotNetShoutout