Domain Models

• Refined domain models: Overview, Governance (Orgs), Contracts, Commitments, Governance (Operation), Formal Structure, Vocabulary. These consist of class diagrams along with textual descriptions.
• Rich Services model: shows the Rich Services view of the community use case. Each Rich Service has its local policies and a local representation of the contracts it participates in. Community Rich Services have also the community specification.

Interaction Patterns for Community to Community Use Case

• Overview interaction for community-to-community use case - a user registers to community A and accesses comm A resources. Then, Comm A establish affiliation with Comm B. We have two case: 1) the user has access directly to the affiliate Comm B to access its resources, or 2) comm A projects all resources (its own and also from its affiliates) and the user interacts only with comm A.
• Community Membership models cover the negotiation for membership, the negotiation for resource use, and accessing the community to see which resources & members are available.
• Community Affiliation models cover the negotiation between two community to establish an affiliation, the access from a member to the list of affiliates, and the access from a member to an affiliated community.

Messaging Service Use Case

• Exchange Space - Community
• MS Federation - Community
• Broker - Community
• Exchange Point - Resource

Core pattern:

1. user registers to a Broker (Establish membership MSC)
   • Broker has Community Spec.
   • User registers to only one broker
2. user registers to an exchange space (Establish membership MSC)
   • Exchange Space has Community Spec.
   • User gives the Exchange Space the address of its Broker
   • User can register to many Exchange Spaces
3. user uses the exchange space to see the list of Exchange Points
4. user requests the right for access to an exchange point (Negotiate resource use MSC)
5. user asks the exchange point for the names of the entities (e.g. queues) in the broker, which represent the exchange point locally
6. user uses the named entities from its broker to send/receive messages to/from it

MS service federation

1. Broker registers with the MS Federation (Community to Community affiliation)
2. An Exchange space registers to a MS Federation (Community to Community affiliation)

Specification Language

The motivation behind developing a Specification Language is that it would provide well defined constructs that would enable one to specify various possible interactions, roles their powers, authorizations, prohibitions, messages and associated commitments in a setting. Effort has been made to keep the language generic and not limited in use to this model alone. This way it can be used to express various scenarios with ease. We aim to develop a tool to generate computable rules from a specification. Hitherto, the generation of the rules from the specification was being done by hand. When the process is automated, the rules can be checked for completeness with greater ease. Discussed here are some of the constructs and the motivation behind them. One need not dwell upon the syntax of the constructs as they are prone to some change as a part of the refinement. A document for the OOI Community and Affiliate Scenario is available here.

• Firstly, we define the predicates for use in the scenario and the signatures along with them.
• The predicates are associated with a scope and are also classified into domain and organizational predicates depending on the kind of effect they have.
• Organizational : The predicates/capabilities have an effect at the community level of participation.

  Capability:Organizational Admit(?Who, ?Org, ?Role, ?Whom);
  Capability:Organizational Eject(?Who, ?Org, ?Role, ?Whom);

  * For Example the Eject predicate achieves the effect that ?Who EJECTS ?Whom from the community ?Org role ?Role. 
• Another category , the Domain predicates comprise those that are more local in their scope and concern entities at a level lower than organizational.

  Capability:Domain Apply(?member, ?resource, ?capability);
   Capability:Domain Evaluate(?expression);

  * For Example the Apply predicate achieves the effect that ?member Applies the ?capability on the ?resource.
• Normative Capabilities have been used with the notion that they have the effect of altering the state of powers or authorizations of a member.
• Powers and Authorizations have been distinguished. A Power is expressed as a capability which when exercised shall have the expected effect, irrespective of whether the agent exercising it had the authorization to do so or not. So long as the effect shall come about, the capability is expressed as a power and is gained access to by means of some condition. Say, being a Priest, or being Ordained gives one the power to marry people.
• Prohibitions : These are acts that may not be brought about and are stated explicitly as so.
• Sanctions : The breach of a contract by either failing the terms of a contract or by committing an act that was prohibited there may be respective sanctions applied on the agent.
• Penalty: While these are akin to the sanctions in intention, the effects or manner of imposition are different. Example: One may be penalized a few dollars. A sanction may be refusal to allow interaction with the rest of the group.
• Commitments: These express the obligation that one agent has to another for some reason. Example, when transacting for a cup of coffee, the commitment the buyer presents is that if provided with a cup of coffee, the buyer would pay a said amount of money. And the other side of the interaction would dictate the commitment that if the buyer pays a said amount of money then the merchant has the obligation to provide the buyer with coffee. The commitments here are represented as tuples that require one to say ?who owes the commitment to ?whom and the ?preconditions (antecedent) that must be met for the ?effects to be brought about (consequent).
• The variables used in the specification are represented as ?variable_name. This is to show that they can bind to any value that may fit the template, very like the rule syntax of JESS.

Policy Specification

We have considered and partially assessed rule representations and technologies. Our current prototype uses Jess. The following are some leading approaches and their pros and cons.

• Jess, the Java Expert System Shell, was originally a reimplementation of the CLIPS expert system shell. Jess supports forward and backward chaining, and integrates well with Java. Its native syntax is based on Lisp, but it supports an XML syntax as well. It is available free for academic use. However, each download comes with usage license for 30 days. A longer term license is possible but imposes onerous terms. State institutions of North Carolina cannot agree to such terms.
• RuleML is an XML-based representation language for rule systems. It is intended to facilitate interchange among rule systems. Transformations exist between RuleML and other syntaxes, notably that of Jess. However, RuleML seems not to be in active development anymore and is frozen at version 0.91.
• Drools is an open source rules project that supports JSR-94 rules. It is incorporated in JBoss and is supported by other leading open source Enterprise Service Bus implementations such as ServiceMix and Mule. Drools supports only forward chaining. Drools comes with extensive tool support including Eclipse plugins.

The following is a brief discussion of what we expect our needs for a rule-based system to be. We would expect that our specification language will be compiled into executable rules. Therefore, the syntax of the underlying rule system is not highly relevant. However, we expect that our specification language will be influenced by what is naturally supported by the underlying system. The portability of the compiled representations would be desirable. The performance of the rule system and its ease of incorporation into the execution architecture is relevant as well.

Implementation