This is a detailed description of one of the general General Use Case Categories abstracted from the possible Use Cases.
1. Abstract
The main common characteristic shared by use-cases falling in this category is the desire for flexibility in matching the needs of 1) users of a service or a 2) service-delivery device, or 3) particpants in a set of activities falling within the scope of some organization, with providers and/or regulators of such services, devices, and activities.
Example of (1): Service Users
The use of Service Level Agreements (SLAs) within a Web Services or Service Oriented Architecture (SOA) is a case in which flexible matching of service providers and consumers is desirable. Traditional practice typically entailed that service definitions, parameters, etc. be more or less fixed and agreed upon by consumers and producers statically. The advent of web-based service architectures offers the possibility of a more dynamic and flexible approach in which differentiated service definitions can be matched to particular circumstances automatically as required. For example, what constitutes a certain level of service, or an acceptable premium for such a level, might vary depending upon the laws in the region in which the service is provided or contracted. However, the ability of a consumer process to understand the rules defining and governing differentiated SLAs is contingent upon those rules being in a form that the consumer process can use.
Example of (2): Service-Delivery Device Users
Currently cell phones and other wireless communication devices allow end-users to subscribe to communication services. These devices are engineered and configured to operate within the constraints specified by regional regulations, which means that they typically cannot operate in regions that are governed by different regulations, nor are they allowed to operate outside of pre-allocated frequency bands. However, recent technological and regulatory trends are converging toward a more flexible architecture in which devices will have the ability to reconfigure themselves dynamically to operate legally in whatever regulatory region and service environment they may find themselves. However the ability of a device to absorb the rules defining the policies of a given region, or the operational protocols required to dynamically access available spectrum, is contingent upon those rules being in a form that the device can use.
Example of (3):
Both of these examples therefore point to the possible usefulness of a third party system sitting between the consumers/devices and the service providers and or regulatory agencies. The role of these third party systems would be to allow service providers and regulatory agencies to write the rules defining and governing their services once and register them with the third party system. This system would then provide suitable translations of those services for any consumer process or device interested in using them.
The key distinction between this use case and the Write Once, Run Everywhere use case can be easily drawn by appeal to the concept of a metamodel. The latter deals with situations in which interchange is based on the assumption of a shared metamodel that is specifiable within the RIF. A third party rule-interchange service that does translation would not provide much value-added in such scenarios since the tools and rule-platforms in the use cases would already be able to export-to and import-from other such systems that share the same metamodel and can use the RIF.
2. Status
This is a generalized use case. For the status of the use cases it subsumes, follow the links to related use cases in the next section.
3. Links to Related Use Cases
This generalized use case is based on:
The Message Transformation use case, proposed by DavidReynolds of HP.
The Operationally Equivalent Translations use case, proposed by AllenGinsberg of MITRE.
The Rule-based Service Level Agreements (SLA) and Web Services use case proposed by SteveRoss-Talbot, SaidTabet, SharmaChakravarthy ,and GaryBrown .
The Rule Based Service Level Management and SLAs for Service Oriented Computing Original version proposed by: AdrianPaschke (TU Munich). Current version joint effort by: NRC (HaroldBoley), Adrian Paschke (TU Munich) and JensDietrich (Massey University).
4. Relationship to OWL/RDF Compatibility
This is a generalized use case. For relationship to OWL/RDF Compatibility of the use cases it subsumes, follow the links to related use cases in the previous section.
5. Examples of Rule Platforms Supporting this Use Case
This is a generalized use case. For Examples of Rule Platforms etc, of the use cases it subsumes, follow the links to related use cases in the section above.
6. Benefits of Interchange
- Enables “write once, run everywhere” paradigm.
- Helps to determine equivalence or extent of differences among rule-sets written in different languages.
- Enables “graceful degradation” by providing partial translations of a rule-set suitable for devices with restricted capabilities.
* Neutral format - enabling the separate organizations at each end of the service link to publish and inspect the transformation definition, independent of the rule implementation technology.
- Future proofing - enables the implementor of the transformation mediary to switch to alternative rule implementation technologies without without requiring re-authoring of the rules.
- Reuse - enables third parties to reuse published rules to define new transformations.
* The interchange format enables the use and integration of SLA engines from various platform and in a web-based and distributed fashion
- Support for network-based SLA architectures
- Reusability and ease of maintenance of SLA rules (by not being hardcoded)
7. Requirements on the RIF
Requirement 1: In addition to providing a rule interchange format, the RIF must also provide
- A standard format for specifying the inference procedure (inference engine) that can be applied to a set of rules. For the sake of brevity we refer to this as the IPIF (Inference Procedure Interchange Format).
- A standard format for specifying the intended interpretation (semantics) of a set of RIF rules with accompanying IPIF inference procedure. For the sake of brevity we refer to this as the SIF (Semantics Interchange Format). Note that the SIF is where a formal characterization of the possible inputs to a rule-set is provided.
Requirement 2: Given a rule-set R written in the RIF together with an inference procedure P specified in the IPIF and an intended interpretation S specified in the SIM, it must be possible to construct a virtual machine that uses P to execute R for any input allowed by S.
- Representation of RDF transformation rules
- Support for object introduction ("gensym" of URI's, bNodes in conclusions)
- Quantification over RDF predicates
- Negation over extensional data
- expressive power of the interchange format to match the capabilities required by SLAs
- Support for the both the static and dynamic aspects of SLAs
- Support for the functionality and requirements of Web Services and distributed architectures
- Online exchange of rules.
- Supports loosely coupled and distributed IT service contract structures and decentralized management, execution and maintenance of SLAs
- Permits coexistence of differentiated contract variants
- Integration of external facts and domain specific vocabularies from arbitrary distributed sources
- Reuse of once defined rules in several SLAs, even permitting rule templates which are stored in a repository. We have implemented such a repository approach in the contract manager of the RBSLM tool.
- Integration and combination of rules sets into SLA specifications, e.g. integration of compliance rules from new regulations such as Saban Oxley, integration of operational rule sets from supplying parties, buying/integration of rule sets (policies, e.g. price models) from specialized "rule" vendors.
- Various rule types such as ECA rules, derivation rules, normative rules etc.
- Expressive power of the interchange format to represent complex SLA rules, e.g. rule priorities, defeasible rules, temporal reasoning, event algebras for complex event processing, etc.
- Typed Logic and Mode declarations e.g. Java type system, Semantic Web taxonomies, Input/Output modes.
- Integration of external fact bases, e.g. databases, Web sources, data warehouses etc.
- (Re)use of (existing) external functions or methods, e.g. SQL aggregations, mathematical functions implemented in Java, EJBs, event driven architectures, system/network mgt. tools, messaging capabilities, etc.
- Semantic annotations to support transformation of the normalized interchange format into different execution syntaxes and enable execution in different rule engines with different (logic programming) semantics.
- Rule sets/modules, e.g. defining different contract modules in a hierarchical contract structure (terms and condition module, master SLA, standard SLAs, OLAs).
- Meta rules for meta reasoning.
- Verification and validation support.
- Support for different roles, i.e. different abstraction layers, e.g. model layer (e.g. UML, MDA PIM), if-then related layer, XML-based layer, logical layer (e.g. Prolog)
8. Breakdown
8.1. Actors and their Goals
Service consumer The consumer of the service (user of the service–delivery device) wants to access the appropriate service under diverse circumstances including differing local policies.
Service provider Wants to supply the service for as many diverse circumstances as it can and deploy it in efficient manner.
Service-delivery-device manufacturer The manufacturer of the device wants it to work well and legally in as many locales as possible and wants to support that goal without undue cost.
Service regulator Wants to make sure that the services in under its jurisdiction meet the necessary regulations.
Third-party rule-interchange service provider Wants to make it possible for consumers to easily find the appropriate service by translating rule-based regulations, policies, and service specifications into formats that are required by the circumstances.
8.2. Main Sequence
Provide the typical course of events, ordered as below in a sequence of steps.
First step of sequence
...
Last step of sequence
8.3. Alternate Sequences
Describe possible variations of the main sequence in separate subsections, assigning a title to each.
8.3.1. (Title of Alternate Sequence)
Describe the alternate sequence, referring to the steps in the main sequence above if convenient (to avoid repetition).
9. Narratives
Describe possible scenarios illustrating the use case in separate subsections, assigning a title to each.
9.1. (Title of Narrative)
Describe an individual scenario. Samples rules and other test data may be optionally included.
10. Commentary
Comments, issues, etc. Again, note that the wiki automatically keeps a revision history.