用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。