在该系列的第一篇文章中(请见参考资料)我们引入了适用于定制加工处理系统(Order to Manufacturing Processing System,OTMPS)的随需应变业务流程场景。那时,OTMPS 执行者或所有者可能对 OTMPS 实现提出新的需求。例如,他们可能要求改变策略(对于策略的定义请见侧栏“策略、规则及实施点”),按照指定的要求确定使用哪个加工工厂。竞争需要、外在的规则、新的业务模型以及其他的因素都有可能导致策略的变更。
分析师可以使用 IBM® WebSphere® Business Integration Modeler(Business Integration Modeler)将目标策略指定为业务流程模型中的自然语言注释,该系列中的第 3 部分对此进行了描述(请见参考资料)。然而,如果在适当的位置执行了规则,那么就不必实施策略了。我们不能从策略声明中自动实现这些规则。在某些情况下,没有明确指定策略,但是通过一套实现规则非常明确地定义了这些策略。
在传统的应用程序中,规则连同逻辑一起被嵌入到应用程序内部。在这样的应用程序中,当更改策略的时候,需要更新应用程序代码并重新部署它来反映该变更。将规则具体化使得分析师及其他缺乏技术的用户能够在不改变流程逻辑的情况下有效地修改这些策略。
考虑到业务流程的长期性,通常需要动态地更改这些策略。为了复用现有的流程及服务构件,必须保证体系结构能适合于定制策略的变更。在对于实现及实施策略的规则进行动态变更的工作流的执行过程中完成了这些定制。可以通过配置参数来实施一些策略(请见侧栏“比较使用规则的情况与使用配置参数的情况”来获得详细信息)。
在本文中,我们描述了业务规则 Bean(Business Rules Beans,BRBeans)的框架及规则服务外观的实现。此外,我们通过下面的步骤方法举例说明:
- 使用 Business Integration Modeler 来指定策略。
- 建立必要的规则来实现该策略。
- 通过流程及工作流模型中的实施点来实施那些策略。
图 1. BRBeans 的体系结构
BRBeans 是 IBM WebSphere Business Integration Server Foundation 中的规则框架(请见图 1)。使用诸如 Rule、RuleFolder 及 RuleHelper 之类的 Enterprise Java Bean 组件来实现它。每种规则都由一个实体 bean 来表示,该 bean 永久地存储与规则相关的信息。每种规则都被指派了适宜的规则名称及相关联的属性(例如,起始日期、终止日期、有效性、javaRuleImplementorName)并将其存储在适当的规则文件夹中。规则的实现是用 Java 语言编写的运算法则,该运算法则通过 javaRuleImplementorName 规则属性与规则相关联。清单 1 展示了规则实现的样例。
清单 1. 规则实现的样例
public class RuleSelectManufacturingPlant implements RuleImplementor {
public Object fire(TriggerPoint arg0, Object arg1, IRuleCopy arg2,
Object[] arg3) throws BusinessRuleBeansException {
String mfgPlant = null;
… //set mfgPlant using the initialization and input parameters i.e. arg3
return mfgPlant;
}
public void init(Object[] arg0, String[] arg1, String arg2, IRuleCopy arg3){
… //set initialization parameters
}
}
|
当发送规则时,它的持久不变的数据及其每一个参数将一起被发送到 RuleImplementor 代码中。提供规则管理应用程序来创建并修改规则。该框架的实现可以动态地将规则名称与特殊的规则实现相联系。如清单 2 所示,BRBeans 客户端通过调用 TriggerPoint 类的 trigger() 方法来执行这些规则。使用该类将对于触发点框架的控制转换成寻找并发送应用程序触发点中指定的规则。
清单 2. 使用 BRBeans
TriggerPoint tp = new TriggerPoint();
params [ ] = { var1, var2, var3 };
String ruleName = "com/xyz/Rule…";
Object result = tp.trigger(this, params, ruleName);
|
我们建议使用 BRBeans API 的服务调用(如图 2 所示)作为另一种直接调用 BRBeans API 的方法。这为调用规则提供了面向服务的方法,而不是直接调用中间件提供的 API。该服务 façade 解决方案提供松耦合的规则访问机构,它可以非常好地适合于 Web 服务编程模型及流程模型。此外,通过使用 façade 模式,您可以加入扩展功能,如规则调整、版本更换等等。
这里有许多方法来将规则逻辑分割并打包成服务 façade 的部分。例如:
- 您可以使用每种公布为方法的规则来将所有应用程序指定的规则包装在服务 façade 中,或者
- 您可以使用访问方法来将每种规则都包装在服务 façade 中。
在其它公共服务 façade 中定义了所有可被应用程序共享的规则(例如安全、业务性能等等)。
图 2. 规则服务外观
图 3 阐明了工作流组件、我们已定义好的 OTMPS Rule 服务 façade 以及 BRBeans 规则框架之间的交互。
图 3. 规则服务外观
在 OTMPS 服务 façade 中,我们将所有规则都包装在了一个单独的服务(OTMPSRules)中,其中将每种规则都发布成该服务的方法,如清单 3 所示。
清单 3. OTMPSRule 服务
public class OTMPSRules {
public String SelectManufacturingPlant (Order order) {
return ….;
};
public String DetermineConfigurator(Order order) {
return ….;
};
}
|
该规则 façade 服务通过使用 WSDL portTypes 来发布规则,如清单 4 所示。
清单 4. OTMPSRule portType
<portType name=" OTMPSRules">
<operation name="SelectManufacturingPlant" parameterOrder="order">
</operation>
<operation name=" DetermineConfigurator" parameterOrder="order">
</operation>
</portType>
|
在实施时,将规则作为正常的 Web 服务来调用,该服务传递必要的执行参数。通过使用业务流程执行语言(Business Process Execution Language,BPEL)partnerLink 及 BPEL 的 invoke 操作来从工作流中调用 OTMPPSRules 服务 façade。
每种规则服务 façade 操作都创建了 TriggerPoint 类的实例并通过使用对于调用的引用、输入参数及规则名称来调用该类的 trigger() 函数。清单 5 展示了它的实现。
清单 5. OTMPSRule 实现
public class OTMPSRules {
public String SelectManufacturingPlant (Order order) {
TriggerPoint tp = new TriggerPoint();
params [ ] = { order };
String ruleName = "com/ibm/otmps/RuleSelectManufacturingPlant";
String result = (String)tp.trigger(this, params, ruleName);
return result;
};
public String DetermineConfigurator (Order order) {
……..
}
}
|
在我们的样例场景中,业务所有者定义了一种策略,该策略用于为特定的定购选择加工工厂。例如,策略可能指定超过一百万美元的订单应当由某些加工工厂按照某些优先权标准来处理,例如往返时间。另一个实例的策略可能指定当首选的工厂停产时如何处理订单。
图 4 展示了角色、工具,以及当实现策略的时候每种角色所操作的具体行为。分析师从业务所有者那里收集了所需的策略,并将这些策略编写在 Business Integration Modeler 创建的流程模型中。您可以通过添加必要的代码来实现这些策略,需要实现规则、规则服务及将工作流与规则服务相连接。部署管理负责部署并管理这些规则。
图 4. 实现业务策略——角色、工具及行为
将策略编写在 Business Integration Modeler 中
分析师通过注释来编写策略。每种策略的声明注释最终都通过实施点来实现。例如,它们可能作为工作流的外部规则来实现。图 5 展示了 Business Integration Modeler 中的策略注释的实例。
图 5. 带有策略注释的流程模型
我们推荐两种方法来向流程模型中添加实施点:
- 添加模型服务元素,该元素表示提供实施点的预先存在的服务。
- 添加任务来表示代码占位符,该代码将实施策略。
图 5 展示了一个任务(应用加工的工厂选择策略),将该任务定义成实施策略的占位符(选择加工工厂)。您可以添加必要的代码来实现该任务。
当需要的时候使用流程模型中的注释,开发人员对必要的规则及规则服务实现进行编码。
作为开发人员,您应当完成下面的工作:
- 使用 BRBeans API 来为定义在模型中的相应的策略创建规则实现。
- 部署并配置 BRBeans 框架中的规则。
- 为新建的规则创建服务 façade。
- 为规则服务创建必要的接口及绑定。
我们接下来详细说明这些步骤:
1. 规则实现
清单 6. 规则实现
package com.ibm.coats.poc2004.ruleimplementors;
import coats.objects.order.item.OrderItem;
import com.ibm.websphere.brb.BusinessRuleBeansException;
import com.ibm.websphere.brb.RuleImplementor;
import com.ibm.websphere.brb.TriggerPoint;
import com.ibm.websphere.brb.mgmt.IRuleCopy;
import java.util.StringTokenizer;
public class RuleSelectManufacturingPlant implements RuleImplementor {
private StringTokenizer Plant1Codes;
private StringTokenizer Plant2Codes;
private String delimeter = ",";
public Object fire(
TriggerPoint arg0,
Object arg1,
IRuleCopy arg2,
Object[] arg3)
throws BusinessRuleBeansException {
String mfgPlant = null;
String mfgCode = ((OrderItem)arg3[0]).getMfgCode();
if (findCode(Plant1Codes, mfgCode)) {
mfgPlant = "Plant1";
} else if (findCode(CRSCodes, mfgCode)) {
mfgPlant = "Plant2";
} else throw new BusinessRuleBeansException("No manufacturing
plant found for \"" + mfgCode + "\"\n\n");
return mfgPlant;
}
public String getDescription() {
return "This rule finds the manufacturing plant to send the order to by
comparing the manuPlant code for the order against the
initialization parameters.";
}
public void init(Object[] arg0, String[] arg1, String arg2, IRuleCopy arg3)
throws BusinessRuleBeansException {
String plant1CodeString = (String)arg0[0];
String plant2CodeString = (String)arg0[1];
Plant1Codes = new StringTokenizer(plant1CodeString, delimeter);
Plant2Codes = new StringTokenizer(plant2CodeString, delimeter);
}
private boolean findCode(StringTokenizer st, String code){
String token;
while (st.hasMoreTokens()) {
token = st.nextToken().trim();
if (token.equals(code)){return true;};
}
return false;
}
}
|
清单 6 展示了规则选择加工工厂的实现。在 BRBeans 中,规则作为 Java 类(例如 RuleSelectManufacturingPlant)来实现。每个规则类都实现了 RuleImplementor 接口,该接口包含两个方法:fire 和 init。触发 fire 方法用于执行规则,并为执行业务规则(如加工工厂的选择)提供了必要的逻辑。fire 方法使用了存储在规则 bean 及为了执行规则而作为变量传递的参数中的数据。“init”为规则 bean 提供了初始化程序。
2. BRBeans 中的规则管理:BRBeans 提供了 Java 应用程序——rulemgmt,用于管理应用程序规则。通过使用属性文件作为输入来调用该应用程序,该输入是对 BRBeans 的访问信息的引用。 清单 7 展示了用于 OTMPS 的属性文件。
清单 7. OTMPSBRBeans 属性
host=localhost port=2809 RuleJndi=brbeans/OTMPS/Rule RuleFolderJndi=brbeans/OTMPS/RuleFolder RuleHelperJndi=brbeans/OTMPS/RuleHelper |
为了启动该应用程序,应当先启动 BRBeans 服务器。图 6 展示了 rulemgmt 的 GUI。使用该应用程序可创建新的文件夹及规则。规则的三个必要的属性是:1)完整的限定名,2)实现类,3)初始化属性。双击该规则可以打开规则配置窗口。图 7 展示了 selectManufacturingPlant 规则的规则配置窗口。
图 6. rulemgmt 应用程序
图 7. 规则配置
3. 规则服务 façade 的实现:可以通过使用规则服务 façade 来调用上面的规则实现,如清单 5 所示。
4. 规则服务接口:一旦实现了服务 façade,就生成了服务接口及绑定元素。清单 4 展示了为 OTMPSRule 服务而生成的 WSDL 的简化版。
您可以使用 IBM WebSphere Studio Application Developer Integration Edition 的功能 Service build from… 来建立 WSDL 接口。例如,选择 OTMPSRules 服务 façade 并调用 Service build from…。检查那些将发布成服务操作的方法。该工具生成了 WSDL 接口、服务及访问 OTMPSRules 服务所需的绑定文件。
在 Business Integration Modeler 模型中的每种任务都被映射成了 BPEL 工作流中的合作服务。如图 8 所示,展示在 Business Integration Modeler 模型(图 5)中的策略实施任务(应用加工工厂选择策略)被映射成了 BPEL 中的调用服务。
图 8. 带有策略实施点的 BPEL(应用加工工厂选择策略)
正如前面所阐述的一样,可以将调用行为与适宜的规则服务相连接,也可以将其指向占位符服务。如果使用占位符服务,那么您需要通过 BPEL partnerLink 将调用行为连接到合适的规则服务实现中去。您通过执行下面的三种行为来调用规则服务:
- 为规则服务创建新的 Partner Link。
- 创建输入及输出变量,这些变量与规则服务操作消息相对应。
- 将应用加工工厂选择策略 BPEL 调用行为连接到新创建的合作链接上。
- 添加规则服务的 partnerLink:选择 BPEL 编辑器中的 OrderProcessSystem 流程的 artnerLinks。添加新的 partnerLink(RuleServicePartner)。在合作链接的 Implementation 属性单中,单击 Edit 来编辑合作链接的类型。为流程赋予角色名称,并将该流程链接到规则服务接口中。此外,从 WSDL 文件中选择合适的 portType。
-
创建规则服务的输入及输出变量:图 9 展示了两个变量 RulesServiceInput 和 RulesServiceOutput,以及它们相应的信息,包括 WSDL 文件名称、消息名称及角色名称。
图 9. 变量及其属性
- 将调用行为连接到 partnerLink 上:一旦定义了 partnerLink 及相关的消息,就选择调用行为(应用加工工厂选择策略)并连接合适的 partnerLink、portType、请求变量及响应变量,并将适当的操作与调用行为相关联。图 10 展示了在连接先前创建的规则服务 façade 之后的调用行为的属性。
图 10. 为了适合于 BPEL 调用行为而修改 BPEL partnerLinks
在 BRBeans 管理员接口中可以使用各种定制选项(请见图 6)。包括下面的选项:
- 选择规则的有效期。
- 为规则添加初始化参数。
- 更改规则实现类。
- 终止当前的规则。
分析师可以使用这些功能在不改变工作流代码的情况下实施业务流程所需的定制。例如,分析师可能改变 selectManufacturingPlant 规则的初始化参数,并在不改变工作流代码的情况下重新部署规则类。
依赖于系统规则 BRBCacheRule(在 brb 文件夹中)的配置 PollFrequency 更改规则变得更加高效了。PollFrequency 默认的时间是 10 分钟。减少该值意味着规则变更的时间更加短了,然而这也会产生负面的影响,因为对于系统的查询将变得更加频繁了。
支持工作流定制的动态策略是随需应变业务流程生命周期方法的关键。本文描述了通过使用 SOA 框架中的规则实施的策略来定制随需应变业务流程的方法。
作者非常感谢 Mark H. Linehan、Margie Mago、Jon K. Peterson 和 Catherine Rivi 对本文给予的建议及帮助。
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
- 获取有关 Eclipse 的历史及概况,包括如何安装 Eclipse 及插件的详细信息,请见文章 Eclipse 平台入门(developerWorks,2004 年 02 月)。
-
阅读随需应变业务流程的生命周期的所有部分,并且随时注意我们新的文章。
- 阅读 developerWorks 上的 Web 服务的业务流程执行语言,版本 1.1。
GermÁn Goldszmidt 博士是 IBM 软件组的一位高级技术人员,主要研究用于实现、定制和发布随需应变解决方案集成平台的体系结构。在此之前,他是 IBM T.J. Watson 研究中心的研究员,带领设计和实现了多种技术,包括第一个自动电子公共设施原型 OcÉano、网络分派器(Websphere 产品的负载均衡组件)。
Joshy Joseph 是 IBM 软件组随需应变体系结构和开发组织的一位软件工程师。作为一名架构师和程序员,他的主要技能和专长包括分布式计算、网格计算、Web 服务、业务流程以及和工作流开发等领域。2003 年他的专著网格计算 由 Prentice Hall 出版社出版。另外,他还撰写了大量的关于网格计算、业务流程开发以及 Web 服务方面的文章。