用DotNET实现业务组件
可以使用DotNET框架创建封装业务逻辑的组件。对于分布式事务和其它在分布式应用程序中需要的一般服务，托管代码可以发挥Enterprise Services（COM+）的优势。
业务组件：
l 被用户处理层、服务接口和其它业务过程调用，特别是拥有在上面操作的一些业务数据，用复杂的数据结构表示的（一个文档）。
l 是事务处理的根，因此必须选出它们参与的事务。
l 要验证输入与输出。
l 可以为它们提供的业务处理暴露补偿操作。
l 可以调用数据访问逻辑组件来获取和/或刷新应用程序数据。
l 可以通过服务代理调用外部服务。
l 可以调用其它业务组件和初始化业务工作流。
l 可以使用Enterprise Services的特征初始化和表决不明确的事务。需要考虑这样一个事实：不同事务操作选项对性能有很大的影响。然而，事务管理不是一个矫正机制，或者可变化的改善应用程序性能的变量。不同事务方法对性能影响的比较，可见MSDN上的“Performance Comparison: Transaction Control” (http://msdn.microsoft.com/library/en-us/Dnbda/html/Bdadotnetarch13.asp)。事务设置可能是：
l 必需的。为组件选用这个选项，可以作为事务的根，或者想参与一个已存在的事务。
l 支持的。为组件选用这个选项，不是一定需要一个事务，但应该参与一个已存在的事务。
l 请求新的。当你想用组件启动一个新的事务，而且是独立于以存在的事务，可以选用这个事务。
l 不支持。当你不想让组件参与事务，选用这个选项。
注意：使用请求新的和不支持选项，会影响事务的兼容性。所以，需要明白对依赖的一个父事务的冲突。
业务组件被下面的课件调用：
l 服务接口
l 用户处理组件
l 业务工作流
l 其它业务组件
图2.7显示了一个典型的业务组件，这个组件和数据访问逻辑组件，服务接口，服务代理和其它业务组件。
图2.7 业务组件
注意图2.7中的以下几点：
1. 业务组件可以被表现层的组件调用（典型的是用户处理组件）或者被业务工作流调用（没有显示）。
2. 业务组件也可以被业务接口调用（例如，一个XML服务或者一个消息队列监听功能）。
3. 业务组件调用数据访问逻辑组件来获取返回的数据和刷新数据，它们也可以调用其他业务组件。
4. 业务组件也可以调用服务代理。需要特别注意，为服务访问无效或者花费了长期时间才返回响应的情况，设计补偿逻辑。
注意：图2.7的箭头表示的是控制流，不是数据流。
当为业务组件使用Enterprise Service时
为业务组件寻找宿主环境，Enterprise Service（COM+）是一个很明显的选择。Enterprise Service提供给你组件基于角色的安全，异构事务控制，对象池和基于消息的接口（通过已排队组件方法）。在应用程序中，可以选择不使用Enterprise Service，但是，对于依赖于单一数据源的简单的操作，想做更多的事情，利用Enterprise Service提供的模式在初期就为你的系统提供平滑增长路径。
当实现业务组件时，要决定恰当的设计过程决定开始是否开始使用Enterprise Service，这是因为在编译后，想从业务组件中移走Enterprise Service特征是非常困难的。
当使用Enterprise Service实现组件时，需要注意以下设计特征：
l 远程通道约束。仅HTTP和DCOM-RPC通道被支持。更多信息，见第三章，“安全，运行管理和通讯策略”的“设计通讯策略”部分。
l 强命名组件：需要依次为使用的这些组件和所有组件进行签名。
l 部署。组件应该是自我注册（这种情况，它们需要运行时的管理权限），或者需要执行一个特定的部署步骤。然而，大多数服务边界的组件需要额外的部分步骤（注册事件记录，创建消息队列，等等）。
l 安全。需要选择是否需要使用Enterprise Service角色模型，这个是基于Windows审核体系，或者仅使用基于DotNET的安全。
有关Enterprise Service的更多信息，见MSDN上的“Understanding Enterprise Services (COM+) in.NET” on MSDN (http://msdn.microsoft.com/library/en-us/dndotnet /html/entserv.asp )。
业务组件的一般性的使用模式
无论你的业务组件是否托管在Enterprise Service，在代码中，有许多一般的模式用于实现业务任务。一般性的使用模式包括：
l 管道模式。被组件执行的行为和查询是按照连续的模式。
管道定义为多步骤执行业务功能。所有步骤按顺序被执行。每个步骤可以包括读或写使“管道状态”有效的数据。可能或者不可能访问一个外部服务。当调用一个异步服务作为步骤的一部分时，管道可能等一个响应返回（如果响应被期待），或者如果响应不是必需的，为了进行处理，进入管道的下一步骤。
使用管道模式的情况：
Ø 可以为已知的一套步骤指定顺序。
Ø 不需要等待从每个步骤来的异步响应。
Ø 想使所有下游的组件能够检查和按照来自上游的数据行动（相反不行）。
管道模式的优势包括：
Ø 可以容易理解和实现。
Ø 强迫顺序执行。
Ø 容易封装在一个原子事务中。
管道模式的劣势：
Ø 模式太简单，特别是的编排服务，有多个分支执行的业务逻辑的复杂路径。
Ø 不能处理条件结构，循环和其他流控制。增加一个步骤影响管道的每个执行体的执行。
观点模式广泛地应用在基于Microsoft Commerce Server的应用程序中。有关管道如何使用在Commerce Server的更多信息，见MSDN的Commerce Server 2000 SDK 文档中的“Pipeline Programming Concepts” (http://msdn.microsoft.com/library/en-us/comsrv2k/htm/cs_sp_pipelineobj_woce.asp)。
l 事件模式。事件在特定的业务条件下被激活，代码被写来响应这些事件。
当想让许多活动的发生，几乎接受相同的启动数据和它们不彼此通讯的时候，使用时间模式。平行或者顺序执行活动。可能或者不可能运行的事件的不同实现，依赖于指定的过滤信息。如果实现被设置为顺序运行，次序状态不能被保证。
使用事件模式的情况：
Ø 你想能够管理一个指定独立的功能的独立和隔离。
Ø 来自一个实现的响应不影响另一个实现工作。
Ø 所有实现仅写在或者触发与忽略（fire-and-forget）的业务处理的输出地方，这个业务定义没有一个实现，或者仅有一个指定的业务实现。
事件模式的优势包括：
Ø 可维护性被改善，通过保持独立的不相关的业务处理。
Ø 鼓励平行处理，这个可以导致性能的优势。
Ø 容易在一个原子事务中封装。
Ø 因为没有答复期待，决定实现是运行异步或者同步是未知的。
事件模式的劣势包括：
Ø 不让构建业务功能的复杂响应。
Ø 在事件模式里组件不能使用另一个组件的数据和状态执行它的工作。
Enterprise Service提供事件服务，为时间模式的实现提供好的出发点。有关Enterprise Service事件的更多信息，见MSDN的COM+ SDK文档里的“COM+ Events”
(http://msdn.microsoft.com/library/en-us/cossdk/htm/pgservices_events_2y9f.asp)。
使用BizTalk Server实现业务工作流
当业务过程需要多个步骤或者长期运行的事务时，需要管理工作流，处理与请求各种服务的会话状态和正在交换消息。BizTalk Server包括编排的服务可以帮助这些挑战。
可以使用BizTalk Server 编排服务设计业务过程，创建实现业务功能的XLANG的进度安排。XLANG进度安排使用BizTalk Server编排设计器图形化创建，可以使用BizTalk 消息服务，DotNET组件，COM组件，消息队列，或者执行业务任务的脚本。XLANG进度安排可以用于实现长期运行的事务，它们自动持久化它们的状态在SQL Server数据库。
可以使用BizTalk Server编排来实现大部分类型的业务功能。然而，在长期运行的工作流过程中，业务资料在多个服务中被交换，包括这些过程的业务组件在这个时候，BizTalk Server编排特别地适应。资料可能被提交到BizTalk Server的程序中，或者被转送到一个被监控文件的文件夹中，或者作为接受功能的5消息队列中。接受功能确保被传送的资料和期望的业务资料是匹配的，假如如此，它们会解析资料并提交它到合适的BizTalk Server业务处理通道。从这个角度看，接受功能可被认为是一个简单构成的服务接口。
如何使用BizTalk Server编排和Visual Studio.NET实现业务过程的更深入的例子，见MSDN上的“Building a Scalable Business Process Automation Engine Using BizTalk Server 2002 and Visual Studio .NET” (http://msdn.microsoft.com/library/en-us/dnbiz2k2/html/BizTalkVSautoeng.asp)。
当业务过程包括和已存在的系统交互时，诸如，主框架应用程序，BizTalk Server可以使用适配器来和它们集成。有关和已存在系统集成BizTalk Server的更多信息，见MSDN上的“Legacy File Integration Using Microsoft BizTalk Server 2000” (http://msdn.microsoft.com/library/en-us/dnbiz/html/legacyfileint.asp)。
BizTalk Server编排实现
图2.8显示了如何编排业务过程与服务接口、服务代理、业务组件进行交互。
图2.8 一个被编排的业务过程
图2.8中，注意以下几点：
1. 业务工作流是被其它服务或者表现组件使用服务接口调用的（通常是业务处理组件）。
2. 一个工作流调用其它服务可以通过服务代理，或者直接通过服务接口。每个流出消息不一定需要和一个流入消息匹配。你可以在代码中实现服务接口和服务代理，或者如果仅需要简单的操作，可以利用消息转换和BizTalk Server的functoid特征。
3. 业务工作流调用业务组件。业务工作流或者组件可以调用一个启动的原子事务。
4. 业务工作流调用数据访问逻辑组件执行相关数据的活动。
5. 当设计业务工作流时，必须考虑长期响应时间，或者根本不答复的方法乞求。BizTalk Server自动允许和外部服务进行长期运行的会话。
BizTalk Server 编排进度是使用BizTalk Server编排设计器图形化创建的。图2.9显示可上面图中一个编排流的外观，这个图是通过绘制和图表软件Microsoft Vision绘制的。需要注意的是在图2.9中所看到的图表，业务分析流和开发者需要做的工作流概念上是如何的相似。
图2.9 在BizTalk Server编排设计器上的一个编排流
然后，绘制被编译成XLANG架构，这个架构师XML文件格式，包含在业务处理中执行任务的必要的指令。
被编译之后，架构在以下列举的方法之一中被初始化：
l 一个BizTalk Server消息有计划性地被提交到BizTalk Server，或者通过文件系统，或者消息队列的接受功能。
l 架构可以使用来源于基于COM的代码有计划地使用sked名字被启动。
有关BizTalk Server编排的更多信息，阅读BizTalk Server：全面的参考，这是由David Lowe及其他人一块编写的（被Osborne/McGraw Hill发行）， BizTalk Server 2000文档上的“Designing BizTalk Orchestrations” （http://msdn.microsoft.com/library/en-us/biztalks/htm/lat_sched_intro_xiju.asp)。
有关BizTalk的适配器的更多信息：http://www.microsoft.com/biztalk/evaluation/adapters/adapterslist.asp。
BizTalk Server适配器的开发指南可以在下面的链接找到：
http://www.microsoft.com/biztalk/techinfo/development/wp_adapterdevelopersguide.asp。
