Extreme idea for the Uber-BTDF

Topics: General Questions
May 27, 2010 at 8:45 PM

I've been brainstorming a little about what I like and don't like about BizTalk deploy limitations.  The worst thing to deal with on every project seems to be what to group and what to separate.  

If we over-group, then we have large applications that must be stopped when we make small changes.  Extreme side of this would be one large project with dozens of schemas, maps, orchestrations, in it.

If we over-separate , then we much more flexibility on redeploying just the items that have bugs.  Extreme side of this would be every single schema, map and orchestration in an entirely different project.   I'm kind of thinking if we had a Uber-BTDF this might be a reasonable scenario.  If a client has long-running orchestrations, this can be even more important (to change just the impacted entities). 

My feature request (issue 6130) is about sort of an Uber-BTDF that would help with the dependency stack. So suppose Orch-A uses Schema-B and Schema-C, and Orch-D uses Schema-B and Schema-D.  I need to add an element to Schema-B.  What if the Uber-BTDF would just allow me to do that?  In other words, I tell that I changed the Schema-B, and it would auto-deploy Schema-B, Orch-A, and Orch-D.  

At my current client, I currently have 7 BizTalk Applications, and I had to drawn a pyramid (or tree structure) to show the dependencies among them.  Mosts of the apps have 1-5 schemas, a few maps, and 1 or 2 orchestrations.  But I have one case where A depends on B which depends on C which depends on D. So what if every single entity was in its own project.  I would just open the solution, and now I would have one solution with about 30 projects which doesn't seem too unwieldy. 

Further, refactoring seems to be tricky given the naming conventions I usually adopt.  For example, suppose I have in schema in Company.Project.ABC.BizTalk.Schemas, then it's target namespace is http://Company.Project.ABC.BizTalk.Schemas/SchemaX.  If I want to move it to a different project to change the dependency stack, then either I needed a different naming convention to start with, or I just live with the offbeat names.

Any thoughts, or did I just drink the wrong coffee today? Or maybe the ESB on-ramp off-ramp addresses this in a different way (something I still need to study up on).

Thanks,

Neal