The diagrams below show 2 main architectural diagrams relating to SOA based design of an Organization's internal infrastructure.

1 - The main components/services of an ESB (whether distributed or not - eg. BizTalk, webMethods are monolithic type ESB's). Distibuting these components makes the deployment more flexible. For example, if you have huge amounts of transformation loads, you can setup a load balanced cluster for that specific task, or if you have no need for any transformation (eg. new businesses or business areas starting up with little integration work required intially) work, then you can leave that component out altogether.

Also, the various functions can be tied together as required in a pure distributed architecture. For example, the configuration below depicts a considerably featured ESB consisting of BPM/Workflow, Process Step Services (PSS) to carry out software tasks for the Business Process Steps. Orchestrations that can be developed separately to the PSS if required - eg.PSS may be developed in .NET and orchestrations may be develped in JBPM, Windows Workflow, webMethods Modeler and BizTalk Orchestrations. They may just be other Web Services or lower level components.

Pub-Sub may also get invoked for various PSS, and various XSLT or other services be invoked along the way.

All along, using ESB.NET as the ESB Execution Engine Core, all of the below scenarios are easily and consistently realizable, with a centralized data store for request level tracing across all ESB instances - an otherwise daunting task in the case of a distributed ESB. The lightweight nature of ESB.NET means that multiple instances can easily be configured (via copy & paste deployment and an IIS Virtual Directory using the simple deployment scripts) to run on a single or multiple servers.

Single entry points for all services - via both the facade ESB and the single entry point used by ESB.NET for all requests, means that reconfiguring the ESB is a trivial exercise. Just copy the instance over, and change a single URL.

Even in a federated service router scenario, a simple custom router handler can be built to route requests to the various servers as desired. You can even have this custom router map to DNS if you like to make the service federation & distribution management tied to your corporate or extranet based DNS servers.

2 - How services can be federated for enterprise-wide management yet distributed amongst appropriate Business Domains.

Partner Specific Trading, Common Information Models are out of Scope for this purpose