This is a quick overview of what ESB.NET is and is not...
Miscellaneous ESB.NET info
ESB.NET - Architecture and Implementations
The Keystroke ESB is an SOA based Architectural Approach.
ESB.NET is an implementation of this Approach.
The Keystroke ESB Architecture has been (at least partially) implemented on other platforms over its lifetime since 1999 including C++/COM, J2EE, BizTalk, SeeBeyone eGate and webMethods.
The following articles briefly discuss some aspects of the ESB.NET architectural approach:
The Services Meta Model
Business Service Definition Language (BSDL)
Business Oriented Message Envelopes
The Deployment Architecture
ESB.NET is a lightweight, xcopy deployment friendly type of application.
Supports multiple instances on the same server. Instances are trivial to setup. Just copy directory & run the SetupInstance.cmd batch file to create the virtual directories.
Basic ESB.NET Server functionality
The essence of ESB.NET is that it’s message based services rather than just XML document centric or RPC style.
It is Data and Business Service oriented as opposed to Technical feature Oriented. Approach is to add value to the Business spectrum.
In order to keep it as flexible/pluggable as possible, it’s basically a pipeline of pipelines. Leveraging IIS, ASP.NET & WCF, and adding 2-3 pipelined layers, various levels of functionality can be attained. You can extend it in this way also (i.e. by adding
yet more pipelines), or by adding services to any number of the existing pipelines (core Microsoft ones or ESB.NET ones).
Other than that, the framework just helps you write services in a manner that allows you to concentrate on the business aspect – XML data & any large amounts of XML or non-XML data as attachments etc.
You then get request trace functionality, the ability to forward the request onto other servers (by simple config) for functional load balancing clusters or specialized processing (eg. Graphics conversion etc.) or whatever.
There’s loads of high level horizontal services you can add to all services (or just a chosen few) again via config.
All configuration is currently stored in local XML config files and a database only used for centralized logging.
The core benefit of ESB.NET is the proven flexibility the acquired by implementing it.
Rather than starting from scratch with XML and raw Web Services, ESB.NET imposes a proven architecture that spans many enterprise requirements, all of which you get by using it and creating services that run within it.
Ø Microsoft.NET 2.0 based implementation - Internet Standards based interfaces throughout product wherever practicable – SOAP, HTTP, XML
Ø Request level tracing
Ø Multi-instancing (on same server or separate)
Ø Simple Service routing (built-in) or you can write a custom router with minimal fuss
Ø Attachments and large amounts of XML
Ø Network Load Balancing etc.
Ø Pluggable architecture – constantly being made more pluggable
Orchestration and BPM/Workflow/State Management
ESB.NET does this via the Sequential WF (.NET 3.0) Adaptor. Also, for very basic composition, there's a rudimentary pipeline configuration file that can do this.
A production version of the Stateful Workflow Adaptor has yet to be released. This is on the cards for future versions.
Development and Deployment
The directory structure for both ESB.NET core and Line Of Business (LOB) services allows you to hit the ground running with pretty much any sort of services you need to develop.
Assemblies are most often (default configuration) loaded from outside the Core directory structure (however this currently has teh drawback of not being dynamically updateable - still got to write a few lines of code there to get that working - sorry :(. If
urgent need for this, please let me know & I'll adjust priorities accordingly... ), so the only thing you need to do to deploy services to a new server already running ESB.NET is to copy over the Service and XSLT pipeline config files, and then copy
over the relevant service directories (including source code if it’s a dev Box) and you’re up & running (except for service specific requirements such as DB scripts or integration components etc).
Separation of concerns is one of the core aspects of the ESB.NET architecture, and if you’ve ever delivered any projects that have large amounts of functionality or involve a lot of integration, you’ll find this separation of concerns and ultimate architectural
flexibility being the most important factor.
Standards based means that large scale integration with other platforms is a non-issue when using the Message-based rather than just document centric or basic RPC style Web Services approach.
Hot configuration for logging & service configuration/routing allow you to pretty much transparently (riding atop the IIS/ASP.NET functionality) change anything – eg. Provision a new server & services, bring down servers in a farm (using NLB functionality
or Server Virtualization etc.) or just change a simple service’s configuration or add/remove services etc.
Basic ESB.NET Management Console functionality
The Management console doesn’t offer too much functionality.
It’s more of a thrown together set of pages to help do simple admin tasks such as:
Ø Service & Xslt pipeline config file management, and setting log levels/viewing logs
Ø There’s also the facility to submit requests and a basic/self test (via the same basic mechanism).
Ø View Service Definitions
The source code for the Managemene Console has been released to codeplex, however its not pretty or very well thought out (unlike the server itself).
Try out ESB.NET Management Console online
Source Code Currently Released to Codeplex
- Transport Adaptors
- Management Console
- Sample/Test Services
- Various other components
Checkout the SOA and ESB.NET Blogs
eg. BSDL, Services MetaModel, SOA Deployment Architecture and other articles for more specifics.