Geeks With Blogs
Joel Ross

My trip to California was eventually a successful one. I say eventually because we pounded our heads against a wall for quite a while working through the Biztalk framework to get what we wanted. Every problem we ran into, we would find a solution, usually resulting in us calling into a DLL to handle what we were trying to do. And since it started out as needing to do database lookups, we migrated to calling into our already-built shared library, since it already had the caching capabilities we wanted built into it.

We could either have copy and paste re-use, or actual re-use. We chose to actually re-use our main library, but this presented a dilemma for us. It tied our BTS implementation to our application - closely. Not just because of the database lookups, but because a lot of the mapping was easier to do in code rather than through the mapper provided in BizTalk.

So basically, any time we wanted to do anything other than simple mappings, we called into our already-built DLL. And there wasn't much to our orchestrations - we submitted a request, polled for a response, and once we got a response, we processed. There were no decisions to make - it was just a matter of storing the response. And that's what all of our integration point processes looked like.

Based on those things, we decided that BizTalk was overkill - and too much of a hassle to mess around anymore. We made the decision to switch over to doing it all in custom code, and within 4 hours, the process was in place and working.

So what did we end up doing? We used the Abstract Factory Pattern, actually. The client has a transaction, and calls into an abstract class factory method to get a concrete integration service. Which concrete implementation to use is determined through details in our transaction record. Then, the client treats it like the abstract class and performs the necessary operations to complete an integration process - send a message, poll for a response, and then get the response.

The beauty of this pattern is that adding new integration types is easy - you implement the integration methods, and then you add it to the abstract factory method. The client never changes. We could have gone as far as to use reflection in the abstract factory to create the objects and not have to modify that, but we thought that was overkill for what we were doing.

Back to BizTalk. As we look back, we're pretty sure we could have gotten all the way there with BizTalk (and in fact, that we are set up to go back if we ever want to). The pieces we were missing was due to a lack of BTS knowledge on our part. For example, a problem we ran into could have been solved using a custom pipeline, but we had no experience with pipelines, so it just didn't make sense for us to learn about them and build one, when we could turn around an alternate solution inside of 4 hours.

All in all, BizTalk was a good experiment, and I'm glad I got the knowledge I did. I'm probably at the stage of knowing too much to go back, but knowing too little to the point of being dangerours! Maybe I'll end up on a BTS project with a true expert who can shape my BTS putty of knowledge.

Technorati Tags: | | |

Posted on Wednesday, September 14, 2005 9:43 PM | Back to top


Comments on this post: Why We Gave Up On Biztalk Server

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Joel Ross | Powered by: GeeksWithBlogs.net