Biztalk vs Business components

  • Article

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:

[Business Components and Workflows

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:

  • Manage a process that involves multiple steps and long-running transactions.
  • Expose an interface that implements a business process enabling your application to engage in a conversation or contract with other services.
  • Take advantage of the broad range of adaptors and connectors for multiple technologies that are available for BizTalk Server.

You can implement the business process using only business components when:

  • You do not need to maintain conversation state beyond the business activity, and the business functionality can be implemented as a single atomic transaction.
  • You need to encapsulate functionality and logic that can be reused from many business processes.
  • The business logic that needs to be implemented is computationally intensive or needs fine-grained control of data structures and APIs.
  • You need to have fine-grained control over data and flow of logic.

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 [ https://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..

Some thoughts about the role of BizTalk 2004 (Part 1)

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.