Customization of Policies to Meet Site-Specific Needs
One of the features that makes Coral as flexible as it is is the use of policies to encapsulate the business logic of each facility. These allow for significant variations amongst various Coral installations while maintaining a common Java code base. There are two main uses of polices in Coral:
- XACML (eXtensible Access Control Markup Language) policy files assoiciated with each server that control what each member may do within Coral based on their roles and other properties.
- Castor files that determine which runtime data is collected for each piece of equipment during it's use.
- XCRML (eXtensible Cost Recovery Markup Language) policy files that determine how costs are calculated based on each Coral activity.
Each of these policy files is an XML document that makes use of an application-specific schema that controls the syntax allowable in that file. Not only is the syntax of each file different but there is a different set of tools for each of these files that interprets these files and takes the appropriate actions.
XACML is a standard produced by the OASIS(Organization for the Advancement of Structured Information Standards) consortium that allows the flexible description of authorization and entitlement policies. There are a number of implementations of the XACML standard but in Coral we make use of Sun's Open Source implementation of that standard known as sunxacml
Castor is an Open Source data binding framework for Java that provides a migration path between Java objects, XML documents, and relational tables. In Coral, we use Castor to describe in an XML document the data that should be collected for any piece of equipment prior to disabling that equipment. For example, in a sputtering system, one might wish to collect data on the base pressure of the system, the material sputtered, and the thickness of the sputtered layer. For a resist coating system, one might wish to capture the resist used, the number of wafers coated, and the resist thickness. Castor provides the framework that allows a different data collection window to appear for each tool without requiring a specific Java popup to be designed in each case. Moreover, because we do not know a priori what data will be collected, the collected data is stored in the database as a small XML document (rather than specific rows and columns) that is associated with each equipment activity.
XCRML is a "standard" that has been developed internally as a part of Coral because we could find no pre-existing capability that allowed us to describe the algorithm that will be used to calculate appropriate charges for laboratory activities. In our experience, there is a large variation from facility to facility in the way that charges are calculated and, as a result, there is a need to support a flexible means of specifying and applying a wide range of algorithms to determine charges for laboratory usage.