Design Analogy

In an attempt to provide an elegant and a self-explanatory naming scheme, the Core API for the ZNIX Framework was built around an Agent-Role-Actor Analogy, which is outlined below:

Often in film industry, an Agent serves as the middle-man between directors and Actors. They generally maintain a pool of Actors under contract and are solely responsible for the number of jobs each Actor receives. During a film casting, a director would contact such an Agent and give him the details of the Roles present in the script. The Agent, fully aware of the capabilities and the experiences of each of his Actors, would pick the one most appropriate for the Role. The director then interviews the candidate and decides whether he is suitable or not. If the latter is the case, the director may continue to ask for another candidate until he is satisfied. In some instances, rather than asking the Agent for a candidate, the director may ask for a specific Actor, whom he himself knows to be the best.

The Core components of the ZNIX Framework too, function in a similar manner. A client process is analogous to a director. When a client needs to query or manipulate some set of information, it will ask the Framework's "Agent" to provide him with an interface to that information. This interface is called an "Actor". Like a real life director, the client may know exactly which Actor is appropriate for the task at hand. For example, if the client wants to store the e-mail address of a person named John, it will ask the Agent for the Actor named "John." Alternatively, the client need to find out to which Actor does a particular address belong to, it may ask the Agent to fetch him any known Actors with a matching email address.

•  Definitions

In order to reinforce the above analogy, the following formal definitions are provided for the key terms that will be used hereafter.

•  Actor

Actors are the basic blocks that build up the ZNIX Data Store. They are first class citizens of the ZNIX framework; which simply means that the Identity of an Actor is unique and non-dependant on any other Actor. Each Actor is uniquely identified by an Actor ID or an AID .

•  Role

Roles define all the characteristics (or Attributes, as they are formally known), that Actors may posses. It is said that an Actor adopts a Role. An Actor adopting a Role, will be able to hold all the types of information understood by that Role. When the Framework encounters an Attribute, it will ask the Role responsible for the Attribute to "explain" how it should be interpreted. Roles are uniquely identified by Role IDs (or RID s).

Roles exist as an object hierarchy within the Framework. Each Role will have exactly one parent Role. Actors on the other hand do not exist in a hierarchy. Rather, they will exist, adopting as many Roles as they prefer. The rationale behind is quite simple. Actors represent real world entities. While at first glance, such entities seem to implement hierarchical relationships, the reality is that there are parent roles and child roles, and entities that fulfill them.

•  Agent

Agents are responsible for dispatching Roles and Actors to client processes. Therefore, they are only a part of the Data Store API and are not reflected in the backend.

•  Attribute

An Attribute is an atomic piece of information that an Actor can hold. Atomic means that the Framework itself differs from trying to sub divide the information contained in an Attribute. However, one is always free to come up with his own set of rules to store structured data in an Attribute. This is achieved by providing what are known as Resolvers.

•  Resolver

A Resolver is an object specifying how an Attribute should be interpreted. Two of the most commonly used types of Resolvers are Text Resolvers and AID Resolvers . Text Resolvers are used to store or interpret a textual data item while AID Resolvers are used when an Attribute of one Actor, refers to another Actor. Resolvers are preferably modeled as pluggable components, although the current implementation does not facilitate this.

•  Associate

An Associate is similar to an Actor, differing in that its existence depends solely on its relationship(s) to first class citizens. As such, when the last related citizen breaks the relationship to an Associate (i.e. loses interest in it), it will be removed from the ZNIX DS as it no longer has any significance to the Framework. For example, a photograph of Joe may be placed in an Associate and attached to the Actor /people/Joe .