Service End Point support

ESB.NET services are exposed via a number of different end points (different transports).
These are:
-WCF (WS-HTTP Binding, WS-Reliable Messaging by default, and you can configure other Endpoints using the WCF config as you please)
You can also write your own transport adaptor to suit whatever protocols you wish to support.
ESB.NET Out of the box only supports Internet Standard Transport protocols and data formats.

Multi-language support

ESB.NET does NOT currently have any resource libraries for the Management Console to support other languages.
The code is available on Codeplex though, and can be extended to do so if need be.
The foundations on which ESB.NET are all Multilingual capable, and so this should not cause any architectural issues.
All Data Payloads and XML based, as are all configuration files.

ESB Administration

ESB.NET Ships with the ESB.NET Management Console that manipulates the XML Based configuration files. Anything that can be done via the Management Console can be done by direct XML file manipulation for scripted changes etc.
It supports multiple instances and a simple copy & paste, then run script to configure new instance. Configuration of new instances basically sets up IIS.
The ESB.NET Management Console allows you to submit requests for testing, view logs, set instrumentation & auditing levels (hot config), as well as to configure instance settings.
They all support the Federated Service Domains model Pioneered by ESB.NET, which is key to making a Service bus truly viable. (Otherwise, scalability, single point of contention etc. become an issue organizationally).

Deployment of services

This is a core strength for ESB.NET. It has multiple options, all designed to make Service Provisioning in the Enterprise easy and predictable.
- Service Configuration (for Service Virtualization and advanced features) is done in a per-instance configuration file, supporting advanced data inheritance.
- A Convention over Configuration Adaptor allows you to easily deploy a service today (without configuration) and Virtualize the service transparently to the clients when you decide need to.
- A “Enabled” flag allows you to deploy a configured service (or group of services), and disable it until a certain point in time, then flick the switch and enable it/them.
- Envelope support for multiple environments means you can point multiple clients to a single entry point for differing environments, and have the ESB point off to different service implementations as required (as long as service handlers are built to take advantage of this feature).
- Context fields in the request envelope allow you to route requests to different implementations based on the context supplied.
o Eg. An Online Web Oriented Enquiry service can be built today, and tomorrow, a similar enquiry can be built for say, mobile devices or IVR. The mobile device client could call the same service with a different context (i.e. Web, Mobile, IVR) and the service implementation would vary the Service Handlers it invokes accordingly to address the channel.
- Federation – Services can be grouped according to Business Services, Units etc. or however you decide to partition it. This ensures services are not all required to be built and hosted by the same team, but by their respective owners. This limitation in other ESB’s is a primary reason for ESB implementation failures altogether or failure to realize all the expectations/benefits that a True ESB can offer an Organization.
- Service handlers can be deployed within or outside of the IIS Hosting directories. This means you can keep your ESB.NET core installation clean, and not HAVE to pollute it with implementation/version/project specific service handlers.
- Custom Handlers can be built to do generic processing as required, at various levels.
- Service Handlers can be developed in your favorite native .NET language, or using Windows Workflow for service Orchestration.
- Services can be hot-swapped, configured, disabled etc. and can be hot-replaced (if put into the IIS App-Bin directory, otherwise staged web.config changes, rename & copy needs to be done…still hot, but a little more work)
- NO Registration of Services is REQUIRED. Whilst configured services need an entry added to configuration i.e. Registration, Convention Based Services allow you to bypass this step, performing it only when needed. As such, initial service provisioning can be automatic. As simple as dropping an Assembly in a Directory.
- For the scenarios where a service is configured, deploying to another instance is as simple as copy & paste whole instance, and run script to create IIS Virtual Directory. There are NO HARD-CODED PATHS. ALL paths are relative, even in configuration. Also, advanced Data inheritance allows you to configure relative paths that can be added to along the way, to the point where your configuration only needs to store the tail end of the configuration item which is different, avoiding having to do erroneous search & replace operations.

Ability to do Logging/Tracking/Monitoring of service use in ESB

- ESB.NET comes with detailed logging levels, and Performance Counters, which can be set from the Management Console, and are hot configurable.
- A SQL Database script accompanies the SQL Server Entry Point and SQL Logger. These can be replaced by your own providers if you wish. You can have multiple Entry Point Managers and Loggers configured.
- Service Utilization is captured in the database, and can be used for accounting purposes. The Logging Database is rich enough to be used as a source of data for a Datamart/Data Warehouse setup specifically for the ESB if required.
- Service Invocation, Execution Time etc. are available in the logs if necessary, and Windows Performance Counters can also be used for Real-Time Monitoring if required.

Support for versions/change management/governance of service on ESB

Service Version support is a first class citizen in ESB.NET. As well as advocating the use of Contract-First Definition of Data via XSD Schemas for Payload Document Versioning, ESB.NET contains fields for Service Versioning. These are used as Context fields, so that the service implementation can be transparently modified to support multiple versions of services, and are implemented according to how you wish to develop your handlers.
You can decide to have Multiple handlers for a service based upon version, or a single handler that handles multiple versions. All done via configuration.
Multiple instances & Service Federation helps reduce the number of ESB hosts/instances that need to be changed in production environments. For example, a HR Service Domain can be used to House all HR related services, and service requests directed to it. A Banking Service Domain can be used to house all Banking services, clustered and Federated itself, with its own Service Domain Entry Point.
All along, a COMPLETE SINGLE REQUEST TRACE of all activity for that request can be captured and audited to the finest detail, or tuned as required, spanning multiple Service Domains, Clusters, Nodes and Instances, making troubleshooting much easier than it would otherwise be. No other ESB Framework can currently do this.
The Documents at:
Open Standards Presentation -
Cover the ESB.NET view on ESB’s, and help implement that architecture, supporting the ESB aspects of it.


Installation and Upgrades

Installation is relatively simple.
It is done via a simple Extract .Zip file and run an initial setup script. As well as creating users, IIS directory structure for multiple instance support, IIS Application Pools, it initializes a SQL Database used for Logging. This is the only use of the Database – centralized logging by all instances. You can choose to use different Databases per instance as you wish though, or even log to multiple databases from a single instance.
Pre-requisite software includes Windows Server, Vista or Even Windows XP (Not recommended/supported). IIS 6 or 7 is recommended, with MSMQ for asynchronous message handling related functionality.
SQL Server 2005 is the currently supported database. SQL Server 2000 support has been dropped, although there is nothing really stopping you supporting it yourself. An Oracle provider will need to be written by you if you need Oracle support, but it’s relatively simple, and the SQL Provider code is freely available. You can even support all providers simultaneously if need be.

Upgrades are generally as simple as run up another instance, or replace an instance, copying over the XML config files from the existing instance. If the interfaces change versions etc. then you MAY need to re-compile your code accordingly.
You can happily run different instances with different versions of ESB.NET on the same computer (instance of OS) without any issues. Only issues surround Transport Adaptors – eg. WCF Version & associated dependencies etc.
That said, as usual, keeping up with the latest version is recommended practice. There are seldom any majorly breaking changes to developed service handlers though. A recompile should GENERALLY be the most drastic thing you need to do. The Keystroke ESB Architecture has matured over the last 8 -9 years (established in 1999) and although the implementation has changed a number of times over the years, the changes have generally been contained internally. Client changes are generally limited to advances in Transport Adaptors, as well as Envelopes/Payload. The clients are completely shielded from the service implementations themselves, as it should be in a True ESB.
If you use more of the advanced features available to Application Adaptors, then you may need to re-assess this code between versions. As this code is usually generic code, it is generally minimal in comparison to the general service handler code usually developed.

Use in the Market Place

Unfortunately, as ESB.NET is open source, it is hard to get any real guage as to who is and is not using it.
It's pre-cursor was though, for the first 6-7 years of its lifetime, used by at least half a dozen projects by one of the big 4 consulting companies in the world - Computer Sciences Corporation (CSC).
Over time, the architecture has been implemented in Java, BizTalk and webMethods. Initially, it was a MTS/COM based ESB, then moved to COM+. Finally moving to .NET, with the Java, BizTalk and other spin-offs in between.
Components of the ESB.NET have also been used by Australian Government Agencies.

You can check out the Codeplex Stats page at:
to get a feel for how adoption has been growing since being released to Codeplex.
Select “project lifetime” from the droplist to get an overview.

Documentation availability

Documentation is available with releases, and is continually evolving. A series of light books is also planned, covering theory and Enterprise Architecture aspects of an ESB, a Solution Architecture for a particular ESB Initiative, and the implementation of it using ESB.NET.
Dribs and drabs of these books will be released as public documentation prior to the books release.

Adherence to standards

ESB.NET adheres to Internet Standards for Protocols and Data formats. This provides a low barrier to entry and a lowest common denominator approach sees it stand the test of time when interfacing to clients. Internally, it uses the latest relevant technologies to give the best possible ESB platform and delivery experience possible.
The ESB.NET architecture has been implemented on many platforms, to varying degrees, and ensures integration between technologies is a non event. Beyond integration, ESB.NET provides a true service bus platform, relegating integration functions to an integration layer, as required.

There are also pseudo-standard technologies used for integration where required, such as Microsoft and IBM MQ transport adaptors. Although these are not mainstream ESB.NET transport adaptors, they are available.

Hardware requirements

ESB.NET requires very little memory for the service bus, and is highly CPU bound.
Performance optimised: In terms of performance, with a small payload (~ 0.5 KB as available on test requests), ESB.NET will deliver over 1200 requests per second (~1200 (test) rq/s on a single socket 2.8GHz Quad Core CPU, with HTTP Transport and 1/2k sample message and test adaptor), near linear scalability with CPU & NLB.
Disable logging, performance counters, Configuration over Convention Handler etc..

Community activity/support of product


Project backed by

Keystroke IT Australia.

Strategy for failover and redundancy

Being a true ESB platform, there is no single point of failure in the architecture. Organizationally, a Federated Service Bus ensures that services are owned and managed by their respective Business Units etc. so there should never be a scenario where a Service Domain going down takes out an entire organization’s ESB!
Likewise, ESB.NET is highly fault tolerant. Commodity HTTP based Network Load Balancing technologies can be used for load balancing. Servers are stateless, so run in Active-Active configurations. Failover is therefore automatic by the network load balancers. In the event of a crash of a particular ESB.NET instance, IIS will automatically restart (unless configured not to).
Site level load balancing is also possible as long as any Line Of Business Systems are available in other sites
‘Ping’ services can be invoked to test that a particular node is alive.
Orthogonal Adaptors or Always Execute handlers can be developed and easily be setup to send additional notifications/keep-alives to monitoring systems if required. Performance counters can be used to monitor response times and trigger events if response times grow.
Built-in IIS CPU & Memory limits can be used to contain rogue processes, and IIS Web Gardens provide per-instance isolation.
Multiple ESB.NET instances per host allow for further partitioning and isolation as required.

Last edited Jan 9, 2011 at 11:29 AM by MINAS, version 12


No comments yet.