3.3. Package - JBoss RULES 4.0.0.11754MR2 manual 英文版使用指南文档
A package is a collection of rules and other related constructs, such as imports and globals. The package members are typically related to each other - perhaps HR rules, for instance. A package represents a namespace, which ideally is kept unique for a given grouping of rules. The package name itself is the namespace, and is not related to files or folders in any way.
It is possible to assemble rules from multiple rule sources, and have one top level package configuration that all the rules are kept under (when the rules are assembled). A common structure, however, is to have all the rules for a package in the same file as the package declaration (so that is it entirely self contained).
The following rail road diagram shows all the components that may make up a package. Note that a package MUST have a namespace and be declared using standard java conventions for package names; i.e. no spaces, unlike rule names which allow spaces. In terms of the order of elements, they can appear in any order in the rule file, with the exception of the "package" and "expander" statements being at the top of the file, before any rules appear. In all cases, the semi colons are optional.
Import statements work like import statements in Java. You need to specify the fully qualified paths and type names for any objects you want to use in the rule. Drools automatically imports classes from the same named java package.
The expander statement (optional) is used to specify domain specific language configurations (which are normally stored in a seperate file). This provides clues to the parser as to how to understand what you are raving on about in your rules.
Globals are global variables. If multiple packages declare globals of the same identifier they must be of the same type and the all reference the same global value. They are typically used to return data, such as a log of actions, or provide data or services that the rules use. Globals are not asserted into the Working Memory so the engine is not aware when globals are modified; for this reason globals should not be used in constraints unless their values are considered final. Incorrect use of globals in constraints may yield suprising results - surprising in a bad way, like when a doctor says "thats interesting" to a chest XRay of yours.
Note that these are just named instances of objects that you pass in from your application to the working memory. This means you can pass in any object you want: you could pass in a service locator, or perhaps a service itself.
One example may be an instance of a Email service. In your integration code that is calling the rule engine, you get your emailService object, and then set it in the working memory. In the DRL, you declare that you have a global of type EmailService, and give it a name "email". Then in your rule consequences, you can use things like email.sendSMS(number, message); etc... (you get the idea).