Overview of deliverables for ESB project

by | Mar 27, 2006 | BizTalk Community Blogs via Syndication | 0 comments

When I first arrived onsite, I was coming in cold. I knew what the consensus opinion was of what an ESB is, but I knew nothing about what the actual requirements were, nor functionality or delivery plans. I stepped into a large project, however my part of it was a blank slate. The infrastructure was being laid down (a very lengthy process as it is a complex environment, both technically and from an organizational perspective), but beyond what was done in the Proof of Concept that turned this into a BizTalk project, there was no code or finalized designs.


 


Perfect: just the way I like it!


 


So, the first thing we needed to do was explore requirements and define the scope.  I’m a firm believer in iterative development with phased deliverables, as are the client’s personnel, so that’s the approach we are taking for what will likely be a very long-term project.


 


After discovery, our list of deliverables breaks down as shown below.


 


What we are calling the “ESB Core Engine” will provide:


 



  • Dynamic routing – the ability for a message entering the ESB to be routed to an endpoint. This could be a protocol hop, or to an application

  • Dynamic transformation – the ability to dynamically transform a document from one type to another (think BizTalk mapper, but dynamic application of maps)

  • Exception management – a standardized and common way to surface and handle exceptions

 


Beyond the core functionality, additional capabilities will be:


 



  • JMS pipeline component (for JMS header promotion and full fidelity preservation of JMS headers as a message passes through BizTalk)

  • “Heartbeat” service that can be used for interop testing

 


This is not a case of “if you build it they will come”, so to accelerate getting developers up to speed, we will include an SDK, which will contain:


 



  • Code samples (for consistency, these will look and feel like the BizTalk SDK samples)

  • Documentation, “A Developer’s Guide to the ESB Core Engine”

 


From an admin/operations perspective, we will have two additional pieces (after Iteration 1):


 



  • Provisioning tool – defines the “on-ramps” and “off-ramps” into the ESB, the message receipt points

  • Engine Central (still looking for a better name here J) – a portal that allows ESB administrators to see metrics about engine performance and ESB usage patterns. We may (or may not) also opt to include some kind of self-provisioning here. This piece is a bit fuzzy at the time this was written, as we have a few possible approaches, and just need some time to think it through further. I will elaborate later, but this could become a core piece of the puzzle.

 


There will be phased deliveries within each of those areas. There will almost certainly be additional areas in the future, but for now, I’m happy with the mix and feel it will provide the infrastructure we need to facilitate interop between the 1,700 applications running in this enterprise.


 


On a side note: I recently saw an “ESB vendor” (remember, so companies would have you believe that an ESB is a product) proudly proclaiming that their ESB consists of 144 “pieces”. As impressive as that number sounds (no doubt one of the competing vendors will come out with one that has 150 pieces!), I’m a minimalist and prefer the “keep it simple” approach. The technology stack that we will be using is:


 


Submit a Comment