1

I recently had an integration project with a very short timeline. It's a requirement that we use Biztalk where all the integration related processes are centralized.

My project requires that I use a job queue pattern where an order coming from the procurement system may result into multiple tasks which must be executed in order. This becomes more complex as more tasks are created for that order on certain events later in time.

Writing a framework for this which can be reusable, easy to maintain, and pluggable for later use with new customers, target system, and transactions can't be handled in BizTalk. I instead opted for pure C# + EF4.1 approach, where the job creation and execution is initiated from Biztalk.

Basically, we have reduced BizTalk to take the role of Windows Service.

Is this bad design? Is this a poor approach? My heart says it is, but with the constraints I'm faced with this is the best approach available.

However, ultimately, we are building software solutions to address problems. Even if it means not following the norm.

What are your thoughts?

4

1 回答 1

1

我的想法是——首先，如果你被迫使用一个不适合手头工作的工具，只是为了完成一些愚蠢的政策，那么将其归为整体架构中的某个象征性功能是可以接受的。

但是，BizTalk 是一个工具，它有一套非常具体的技能。例如，大容量消息传递、非常快速的 xslt 转换以及易于配置的路由和监控。如果您在系统中需要这些功能中的任何一个，您可能会比使用 BizTalk 做得更糟。

于 2013-09-25T08:10:59.203 回答