业务逻辑开发框架用于开发实现业务逻辑处理的服务或业务操作。包括服务引擎、AOP框架组成，其中服务引擎是一个WCF的Hosting。

怎样开发服务

首先应用使用UBF Studio的服务设计器设计服务，然后使用代码生成工具生成特定业务服务的框架性代码。每个服务将产生三个代码类，即Agent、Stub和实现。Agent和Stub组件用于跨服务组访问访问用途。当一个服务准备调用另一个服务组的服务时，需要通过Agent调用，如果在一个服务组内可以选择直接调用实现类。

服务引擎

远程调用支持

UBF支持多种灵活的部署方式，如支持U9按企业和组织分布的应用服务器部署方式。服务引擎在代理端提供了远程服务自动化定位机制，应用开发者可以按照自己确定的分布部署模式提供策略插件。这样应用开发人员在开发时将不必考虑与部署相关的问题。

同时服务引擎针对多个服务组部署在同一服务器时，其相互间调用的本地调用优化机制。

实体Key封送处理

同样由于UBF支持按企业和组织的分布模式，因此在跨组织的服务调用时如果源和目标组织被分布部署会导致实体Key中的ID失效。UBF针对此种场景提供了实体Key封送功能，在代理端将所有传递参数中的实体Key中的ID转换位相应的实体业务主键（在模型设计阶段定义具有唯一性），到服务Stub端再用业务主键还原为目标组织所连接库的该实体的ID。对于返回值也做同样的处理。

UBF Studio在生成服务代码时，在服务的Agent上将生成三个方法，分别是Do()、Do(long targetOrgId)和Do(string targetSite)。其中：

1. Do()是通常使用的方法
2. Do(long targetOrgId)用于跨组织调用，开发者需要指定目标组织
3. Do(string targetSite)用于与组织无关但有明确的分布场景。如U9的档案上传、下发。

缓存管理

UBF提供服务会话的线程级缓存和服务级缓存主要用于持久化引擎。持久化引擎将加载的实体保存在线程级缓存中，同时也保存在加载该实体的服务级缓存中。持久化引擎将创建的实体也同时保存在两级缓存中，而对实体修改产生的变更数据仅体现在当前服务的服务级缓存中。

如果是本地调用业务操作，UBF将保证他们共享相同的服务级缓存。如果是通过Agent进行的服务调用则分别由各自的服务级缓存，因此在调用方对实体的修改将不会在被调用方看到，除非在实体框架的Session中执行过提交操作。

AOP框架

AOP框架用于为服务和业务操作增加通用方面的功能提供支持机制，如事务、权限等。这些方面功能应当是相互独立的，因此也是次序无关的。目前UBF提供了事务和权限。

事务

UBF支持四种事务声明：Required，RequiresNew，Supported，NotSupported。

1. 当声明为Required时，如果当前事务上下文存在事务，则创建一个依赖事务，否则建立一个可提交事务。这样在该事务上所做的任何操作将于当前存在的事务一起提交或回退。
2. 当声明为RequiresNew时，无论当前事务上下文是否存在事务都将创建一个新的可提交事务，以保证自己及后续在数据库上的操作可以独立地提交或回退。
3. 当声明为Supported时，如果当前事务上下文存在事务，则创建一个依赖事务，否则不会创建事务。
4. 当声明为NotSupported时，将清除事务上下文，以保证自己在数据库上的操作不受事务成功或失败的干扰。

事务是通过开发者在服务模型阶段指定，并通过代码生成在服务的Do方法上添加事务标签。UBF的AOP框架在进入服务时处理事务标签，且换到开发者指定的事务上下文，在退出时提交事务并还原到进入前的事务上下文。当AOP框架拦截到异常时，将回退事务。

权限

UBF通过AOP框架的权限标签提供服务准入的认证功能机制。开发者可以开发并注册提供服务准入功能的Provider。