Enterprise Service Bus (ESB) Framework for the Microsoft .NET Platform
Live test site
Login as: admin/admin
Pledge for a feature
Ever wanted an ESB.NET feature? Here's a way to make it happen as quickly as you like...
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:
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
- 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
- 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
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.
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.