HomeAboutBlogNew ArchitectureOriginal ProjectOriginal ArchitectureContact Us
ExperiaSphere
Think Outside the Bit
SocioPATH

Well, yes, it's probably true that a lot of technologists harbor those tendencies, but please note the spelling! In ExperiaSphere, a special P2P/DHT (Distributed Hash Table) architecture is used to mediate all of the inter-Entity signaling that's associated with communication and collaboration. We call it SocioPATH because it's the first architecture that is built around relationships rather than accommodating them.

SocioPATH provides for the policy-based exchange of information among entities of all sorts, and it will form a very critical central element in many of ExperiaSphere's processes. The obviious application is to support connections among users, but SocioPATH is also used for all of the following:
  • The registration and location of partners in ExperiaSphere services, what is called Role Management. SocioPATH is one of the optional ways in which Role exchange can occur, and it is especially valuable for brokerage of the bindings between Proxy and Host Experiams for cloud computing applications.
  • Obtaining demongraphic information about a user, and policies relating to demographics use, for purposes of advertising.
  • Validating financial information before creating chargeable services.
  • Reporting errors and problems to partners and distributing services information.

In the communications context, SocioPATH provides a means of obtaining (subject to policies) all of the information about communications channels that a user exposes, and how to link to the user via each. It also provides a means of creating links between a user's actual Entity data and alias Entities that can be established for a variety of purposes. For example, the "real" user can use SocioPATH to "watch" activity of an Entity.

SocioPATH development will likely begin in March, as soon as the high-level design has progressed far enough. Our policy, as always, is to prototype concepts quickly and then refine them based on testing rather than to attempt to visualize all of the ramifications of each alternative approach in abstract.
 
 

Social Policies: SocioPOLICY


Social communications, network connections, and pretty much everything in communications and networking faces two fundamental issues--ease of use and cost of operations. Capital cost of technology is falling, but human costs are moving in the opposite direction, and advanced and valuable services are worthless if the user can't figure them out. Thus, a communications framework needs to be to a degree "self-organizing" and control its own complexity to maximize its benefits to all.

In ExperiaSphere and SocioPATH, automating communications/network/service processes is managed through a policy-based system we call (no surprise!) SocioPOLICY. The SocioPOLICY framework is explicit in SocioPATH in that the policies are actually a part of the model of an Entity, the foundation for all SocioPATH communications. But SocioPOLICY could also be used in other parts of ExperiaSphere where there was no Entity or social communications at all.

SocioPOLICY is based on a simple structure as shown below:

Event > if (Condition) THEN Action


Since ExperiaSphere is event-driven, it's logical that policy handling is implemented as a means of controlling how events are processed. The events created by any ExperiaSphere or SocioPATH event source are passed through a SocioPOLICY filter before being posted to their destination. The policy process is based on event type, and each policy term consists of a set of actions that are executed if the specified conditions are met. The actions can include pretty much anything that can be done in ExperiaSphere, including activation of Experiams, Service Channels, etc. and they can also set a return to indicate whether an event is to be processed, rejected, dropped, etc.

Every action and condition used in an implementation is specified as a Java ENUM instance, and this ENUM is then used to index an array of objects for both actions and conditions. This mechanism lets developers create customized condition/action objects if the standard ones provided in SocioPOLICY aren't sufficient. SocioPOLICY includes the ability to register objects in either the action or condition arrays so the handling of events can be very dynamic.

All of the policies are authored in XML, and the XML is translated to a more efficient in-memory array that is used when the application runs. The application could, of course, store this array in object form on any form of Java data store and reload it without the XML translation step.




Principles
Abstraction/Facilitation
ExperiaSphere
SocioPATH
Integration
HomeAboutBlogNew ArchitectureOriginal ProjectOriginal ArchitectureContact Us