This project is read-only.
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

Credentials are:

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.

Last edited Mar 20, 2009 at 9:25 AM by MINAS, version 17


No comments yet.