This is a summary on how ESB.NET exposes your business services as SOA compliant XML Web Services, and the advantages over exposing your services as standard Web Services.
Pure Internet Standards based Lightweight Enterprise Service Bus
ESB.NET is a lightweight Enterprise Service Bus, capable of several enterprise architecture roles such as exposing business services, rudimentary publish/subscribe, EAI, providing layering & partitioning of complex systems and exposing workflows to aid BPM. This article discusses only how ESB.NET exposes SOA compliant services for your developed business services. ESB.NET uses only Internet Standards based Transports and Data representations (i.e. HTTP, SOAP, XSD etc.). This guarantees interoperabililty across all platforms.
It does this by hosting Adaptors, and providing several key aspects of server based enterprise application such as
- exposing internet standard endpoints - eg. XML Web Services
- defining a generic and extensible messaging envelope
- providing extensible instrumentation & logging, hot-configuration & caching (using MS application blocks)
- a simple Web based Management Console to manage system parameters, view logs etc.
There is nothing revolutionary about ESB.NET. It just puts a bunch of technologies & patterns together, sets some simple interfaces that need to be adhered to by clients and adaptors, and then does the rest.
ESB.NET Pipeline
ESB.NET uses a configurable pipeline to allow you to plug in your functionality using custom Adaptors (including hosting Windows Workflows to implement more complex logic). Once you configure your adaptor's message handlers to listen for a specific request, ESB will match up the request with the appropriate handlers that need to be executed. As such, you avoid the necessity for creating and managing a myriad of WSDL's.
ESB messages are XSD document centric. There is a request message and a response message (containing a special document in the case of async requests which are accomplished in 2 ways). You can also have attachments, and they are transferred according to the Transport chosen (eg. Raw HTTP, SOAP - WSE 2, SOAP - WSE 3, SOAP - WCF). All Transports are available simultaneously.
Security is left to the Transport chosen Adaptor. This ensures ESB.NET does not provide any redundant functionality that Transport Adaptors provide. As such, if you have differing security requirements per service, you will need to have multiple instances of ESB.NET configured and configure the transports accordingly.
Further, ESB.NET mandates a few simple and common restrictions:
- Adaptors and Handlers must be stateless
- Must contain XSD compliant documents for the requests & responses (non XML data can be passed around as attachments)
- All Incoming Requests should be the Front Door only - i.e. through the Internet Standards based Transports provided. You can add your own, so long as they're Internet Standards based. Adaptors should be used to communicate to non Internet Standards based systems (eg. COM+, RMI, CORBA etc.)
- Course grained messages
This simple architecture, seemingly restrictive (single WSDL etc.), provides a basic seperation of concerns between service (Business data and logic implemented by service), and how the service is deployed, exposed and invoked.
Service Definition
ESB.NET exposes a higher level Service Definition than does WSDL, as WSDL is a low level description language. Once a standard message and set of parameters has been set, WSDL is no longer required for defining the service (it can probably be automatically generated using the information in the ESB.NET Service Definition if required). The ESB.NET Service Definition exposes some high level information such as:
- Service Name
- Request & Response XSD's that the data must conform to.
- Any attachments
- Synchronous/Asynchronous behaviour to clients
- Priority of message
- Transactional and Gauranteed only once message delivery characteristics of the Client-ESB.NET interaction (WCF only)
With these restrictions in place, it is now possible to integrate any piece of software (EAI - although only at Internet Standards Protocols level. Use adaptors for other protocols etc. or interface to BizTalk, eGate, WebMethods etc. for any more complex EAI type work). With that problem solved, in a lightweight manner, we can now focus on plugging pieces together, exposing everything in a generic manner, as the Business Level, by specifying 3 key things:
- Business Service Name
- Business Service Data
- ESB.NET Server URL
These are the core constituents of the Service Definition, and are pretty much what's required to specify what we want done (Service name & data), and where we want to get it done (URL).
This makes life easy for BPM tools & brings the idea of the Business defining their process in the BPM tools, one step closer. In your BPM tool, you can abstract away many details of outgoing calls as they now all look the same. Pretty much only the data required at the business level changes.between requests. An ESB.NET facade cluster can be setup to be the first port of call for any request, and route it (content based routing implemented through confguration - no coding required unless you really want to) accordingly. Alternatively, you can setup a static Pub-Sub ESB.NET instance (or cluster...) to make the routing more flexible/complicated. Static Pub-Sub is an extension of the simple forwarding facade and involves only additional request configuration to achieve.
The pattern above can be implemented in pretty much any platform. ESB.NET is the .NET implementation. A J2EE or MONO implementation & seemless integration for example are entirely possible & feasible.
Isolated Service Provisioning, Transparent Service Consolidation
As you can see, the possibilities start to become limitless. Multiple ESB.NET instances can be scattered around, and joined at a later point in time, forming central/aggregation points for services. Live message tracing can allow administrators to understand the location of services and thus get a clear picture of what can be consolidated as time goes on/new services are deployed etc.
A typical issue in an enterprise & an extended enterprise, is the proliferation of unrelated, non-interoperable services. Web Services & Basic Profiles alone, cannot provide the flexibility described above. Some rigidity needs to be introduced. This comes at a price, however, that being the abovementioned restrictions. When taken in context, they are a small price to pay for Enterprise Service Flexibility (ESF).
Low priced (or free) ESB's such as ESB.NET help lower the barrier to entry to Enterprise Service Flexibilty. Cross-platform availability of something like ESB.NET is required to make ESF even a dream.