BAM/e
BAM is probably the most useful & undervalued piece of software built for SOA world so far. Reason being is the complexity of design/deployment for the component (or at least the first design/deployment)
BAM is Business activity monitoring tool that allow your BizTalk solution (did I say BTS? Actually all of your solution keep reading..) what happens is BAM sneaks peaks into your messages and workflows (orchestrations) and start extracting and saving data in a separate store based on a preset tracking profile. This process called interceptors.
BTS 2004 was shipped with one interceptor only for BTS orchestrations which back then everybody was scratching his head trying to figure out what is that? Almost immediately everybody was coming to same conclusion
- Why cannot I use BAM to track business activities from other parts of my solution, I mean come on messages reaches BTS after they have been going thru other systems.
- Almost immediately people was saying ok I use BTS for messaging only why can’t I BAM that?
- The answer was BAM API, with one catch. API was not strong typed in other words it allow you to pass any number of parameter to a single activity and that will not be checked in compile type (a recipe for disaster to tell you the truth)
- Then strong type API generator, was on gotdotnet. Then gotdotnet was phased outL
- Then Microsoft PG actually blogged on how to use the API to BAM messages as they go thru BTS pipeline.
Everybody was happy, especially when BTS 06 came out with
- BAM built in pipelines
- BAM WCF interceptors to intercept messages on WCF services.
- BAM WF interceptors to intercept WF activity shapes.
The thing catch is:
Here is a typical SOA BAMed solution (anyway..)
From it:
- You will have to configure each service in isolation, even if the same message type is moving from one service to the another
- Administration is hardcore XML/XSD guru’s. users can not actually change it.
- You cannot really intercept anything other than WCF/WF
- You cannot control error cases, in a configurable manner, for example if I couldn’t BAM “new customer activity” I am fine, but if I can’t BAM “new order” I need to fail the order. And a lot of similar examples.
- BAM interceptors with BTS 06 R2 is highly tight to WCF/WF model so you can not use anything other than those.
Well BAM SHOULD BE BAM/EVERYWHERE hence BAM/E
I mean you should be able to BAM anything, that includes types, messages, xml anything that goes thru your application is BAMable.
Here is how it might look like
1- Separation of configuration from actual interception process
2- Configuration is loaded and centralized in a DB; meaning a user interface can be built on top of the configuration to manipulate it.
3- Configuration store takes care of exporting configuration changes to BTS TPE
4- Multiple interceptors can consume one configuration instance to provide a full view of message life time across multiple services
5- Message can move from WCF service to ASMX service to WF and to a custom code and still complete view of activities is there.
6- Complete support of milestone & activity continuation is there.
Note that "/e" thing is from WPF/e which later on came out as SilverLight
just thinking!..