In an enterprise IT architecture, we typically use the rule engine as a standalone service for the different applications in the enterprise, and this is in line with the SOA idea that everything is serving today. So the question is, in what form will the rule service be deployed? How to integrate with application interaction? Webservice? Well, it's a standard answer, and it's a pretty good one, but we have more to think about.
I have seen this design in a customer of the insurance industry: The customer has designed a webservice that defines the input and output of the underwriting, and then defines an EJB service to wrap the rule service for WebService invocation, in the implementation of the EJB, Then call the ODM's own EJB remote Interface execution rules, the key is that these services are all deployed on the same application server. There may be historical reasons, but obviously such cumbersome design is not a good design, for performance, maintenance will be a challenge. You might ask how performance is? The customer told me that the time of the underwriting call was 1-2 seconds. The advice I gave them was to invoke the rule engine directly in WebService using the ODM Pojo method, removing the intermediate layer two EJB so that performance could at least be increased by an order of magnitude.
In ODM, the product provides a method of invocation in both the javase and Java EE environments, which are done using the rule session API.
The applicable scenarios are as follows:
- Java SE: For javase environments or web-only containers. This rule session uses the Java SE Execution Unit (execution unit).
- POJO: A simple Java object model for use in a Java EE environment. This rule session uses the Java EE Execution Unit (execution unit).
- EJB: Used for EJBS in a Java EE environment. This rule session uses the Java EE Execution unit to support local or remote access.
- MDB: Used for asynchronous execution in a Java EE environment. This rule session uses the Java EE Execution unit.
ODM also provides auto-generated webservice and rest service for use by applications that require remote calls. The use of specific invocation methods must be based on the requirements of the framework to make a reasonable choice.
For example, is a customer-priced platform and the integration of the Rules engine design, in the batch scenario, using the Javase mode, the online scene, the use of Webservice+pojo mode.
In general, rules service integration design-time principles are:
- Local calls take precedence over remote calls,
- When a remote call must be supported, customize a WebService or Restservice and invoke the rule internally through Pojo
- Try not to use EJBS
- Batch execution mode, executed using the Javase method,
- For extreme performance, consider using an embedded rules engine (ILRCONTEXT)
Note: This article is also published in Http://decisionrule.com/zh/2015/03/rule-integration-best-practices, reproduced please indicate the source.
Best practices for IBM ODM rules service integration