This project is read-only.

Enterprise Service Bus (ESB) Framework for the Microsoft .NET Platform 

Live test site

Login as: admin/admin

Getting started




Pledge for a feature
Ever wanted an ESB.NET feature? Here's a way to make it happen as quickly as you like...


ESB.NET Application Architecture

Business and Technology Architecture view of an Enterprise

Where an ESB fits in & what ESB.NET can do for your organization...

Features at a glance:

Development/Implementation Benefits

A distributed lightweight .NET 2.0/3.0/3.5 based Enterprise Service Bus supporting:

  • Graphical Service Orchestration (via WWF) including custom Mapping(Xslt) and Validation(Xsd) activities, all with Dynamic Configuration support
  • Dynamic Configuration Based Service Hosting/Execution - Global and Service Local configuration
  • Dynamic Configuration (Service Virtualization) and/or Convention Based Service Broker
  • Dynamic Configuration Based Publish and Subscribe
  • Dynamic Configuration Based Service Bus Federation
  • Configurable WS-* support (via WCF and Microsoft Stack)
  • Domain Specific Language (DSL) for ESB Service Definitions (BSDL)
  • Easily pluggable features in many dimensions to ensure you get what you want from your ESB
  • Service Metering
  • Request Execution Simulation
  • Web based management console for testing & configuration


Deployment/Implementation Benefits

  • Hosted by IIS to provide a highly fault tolerant and scaleable Lightweight Enterprise Service Bus
  • Highly modularised fully Distributed ESB allows you to deploy ESB features in separate instances (same or different servers) to match your requirements, including Federation
  • Standard HTTP network load balancer friendly design

Operations/Monitoring Benefits

  • IIS Hosted so no surprises
  • Custom ESB Oriented Performance Counters
  • Federation & Distribution Supporting Logging Framework. Allows for single or distributed Logging for a given request. A single End To End view of a request spanning many ESB instances and nodes can be stored in a single trace.
  • Service Accounting to bill clients on a Service Usage basis
  • Rudementary BAM and Data Mart can be setup to work with rich logs to extract valuable information as to how services are performing

Enterprise Architecture Benefits

  • Promotes a Federated Services Architecture closely aligned with Business Archtiecture. Developed Services moulded to Business Service/Vertical.
  • Promotes and benefits greatly from a well defined Enterprise Information Architecture.
  • Promotes the simple & high level definition of Services, narrowing the Business<==>IT Communication barriers. Results in Services & Capabilities being better understood by the Business, and helps manage expectations at all levels.
  • Promotes understanding of Current and Future State of Services within the Organization, and lowers barriers to implementing Future State, by encouraging Services to be targetted at specific Business Service Verticals, and removing unnecessary dependencies.
  • Promotes Service Architecture to minimizing data translation, minimizing dependencies/coupling, and promotes an inherently fault tolerant Service Architecture
  • Promotes a layered Technical Architecture that is based around Business Services to help isolate Services to particular Business Verticals
  • Single mode for Services, Pub/Sub, Integration, App Servers...
  • Future Proofing - Business Oriented, long term view of Imposed Architecture. Lowest Common Denominator driven Archtiecture, not Technology Driven Archtiecture. Guarantees Imposed Service and Information Architecture will be able to live on and be supported in newer Technologies as Technologies change. Whilst implementation has radically changed many times over the past decade, the imposed Architecture has only evolved slightly.
  • Architecture can be replicated in J2EE

Federated ESB

The diagram below shows the federation of ESB.NET domains based upon Business Domains.
Multiple Entry points to the Organization or Domain can be nominated. These should have the router service configured in such that service requests are forwarded onto the appropriate Service Domain for processing.
The router can either use DNS to locate the Service Domain directly, or for smaller or DNS independent implementations, route the message along to a known Service Domain which will then forward the message along until the final destination is reached.
Custom routers can also be used.

Distributed ESB

Each Service Domain above can be distributed internally over multiple ESB.NET instances as shown in the diagram below.
Major ESB Services can distributed amongst different ESB.NET instances. These can run on the same, different or Network Load Balanced OS instances as desired.
Only the Database and Business Process Servers cannot be Network Load Balanced as they're stateful servers.
For example, you can deploy your Logging and Workflow DB's onto Clustered Servers, whilst deploying stateless services for Implementing Activity Services such as Service Orchestration, Data Transformation, Data Validation, Static Pub/Sub etc. on Network Load Balanced Servers for those highly loaded services. This helps to scale out the ESB in any direction required, without carrying any unnecessary baggage to load balance unneeded services.
For example, typical .NET & J2EE monolithic EAI products require custom load balancing for the whole server. Even if you wish to scale out a particular mapping or validation component which is CPU intensive, you would need to use sub-standard load balancing schemes and deploy Orchestrations, Brokers, Routers etc. that are not needed.
With ESB.NET, you can run and manage instances as appropriate for your needs. For example, an image processing service can be run on a farm of dedicated servers which run just that service if need be. Similarly, complex validations and data transformations can be deployed separately to Orchestration and Routing services.
This is all done consistently via configuration.


Last edited Aug 21, 2013 at 5:57 PM by MINAS, version 193