Every program has a "flow" or any kind of "main routine" where you can inspect the different steps involved in your application, now with graphical tools such BizTalk Server 2004 you could "draw" all your "main routines", but obviously this is not a great approach due to complexity of the BTS platform.
I've been looking for information about when to choose BTS vs Components, and I found that the
Application Architecture for .NET guide has a nice paragraph about it:
When implementing business functionality, you have to decide if you need to orchestrate the business process or if a set of business components will be sufficient.
You should use business workflows (implemented with BizTalk Orchestration) to:
You can implement the business process using only business components when:
In the retail example, the process of placing an order involves multiple steps (authorizing the credit card, processing payment, arranging delivery, and so on), and these steps need to be performed in a particular sequence. The most appropriate design approach for this kind of business process is to create business components to encapsulate each individual step in the process and to orchestrate those components using a business workflow.]
I'm totally agree, I've found another interesting post about it here [ http://dotnetjunkies.com/WebLog/sober/archive/2004/06/30/17989.aspx ] from Eliav Gnessin, because this is the only post in the blog, and probably the resource will get loose in the dark I'm going to copy the whole content here..
In the recent two months Oren Kandel from MCS and me did some thinking regarding the role of BizTalk in comparison with pure code business logic.We concluded with some guidelines - "when to use BizTalk".Part 1 is about Orchestration. The other parts that will be posted later deal with BRE, HWS, etc.Eliav.
Part 1 - When should we use BizTalk Orchestration?
• Long-Running Transactions – When business processes combine automated processing with human involvement and/or non-sequent workflow, BizTalk Orchestration provides rich functionality for long-running transactions management (error handling, compensation, hydration etc.). In such cases, our motivation to use BizTalk Orchestration will increase. • Data Transformation – when data transformation takes a major role in the implementation of a use case, BizTalk provides a useful and friendly designer for mapping inbound messages to outbound messages. The maps created using this designer can be easily incorporated in BizTalk Orchestrations and therefore increase our motivation to use BizTalk Orchestration when implementing the use case.• Business Rules Evaluation – BizTalk Rules Engine can be invoked conveniently by BizTalk Orchestration as well as directly from code using the BRE API. This consideration might slightly increase our motivation to use BizTalk Orchestration but does not serve as a deciding factor.• Strongly-Typed Inbound Messages – Although several types of messages are supported, BizTalk Orchestration best handles data in the form of simple XML. When the implemented use case receives a strongly-typed message (such as diff-grams extracted out of an ADO.NET Dataset) and is required to analyze and update this message, major technical issues may arise. In order to overcome these technical difficulties we need to transform the inbound message into XML and in the end of the process convert it back while losing row states and degrading performance. This consideration dramatically decreases our motivation to use BizTalk Orchestration when implementing such use cases. Therefore, BizTalk Orchestrations will not be used as a substitute to the traditional in-module synchronous business workflow managers (orchestration components). These components will continue to be implemented using standard .NET programming languages (C#, VB.NET etc.) and .NET Enterprise Services (COM+).• Business Process Flexibility – In cases where the flexibility of the business process plays a major role in the use case requirements, BizTalk Orchestration presents a clear advantage over the option of implementing the same functionality through code. • EAI / Inter-Module Integration – BizTalk Orchestration is, by definition, an enterprise application integration tool. In cases where a business process consumes services from more than one module, our motivation to use BizTalk Orchestration will increase. This also applies to cases of integration between the application and other applications or legacy systems such as SAP.