|Think Outside the Bit|
|The general approach to development in ExperiaSphere is to write Experiams! An Experiam is a handler that provides the logic to deliver a service/experience or an atomic component of one. The basic way to develop an Experiam is to start with a foundation stub of code (which we supply) and to then code in the details based on how the service or experience works.|
All Experiams have a case-driven structure, meaning that they are a compound SWITCH/CASE structure, where the outer switch block is the state of the Experiam and the inner one the event or command that is being processed. We provide a general state/event table that represents a "typical" experience and you fill in the details for your own application. In general, each of the state/event intersections will be coded as anaction and a next-state, and in general the action will be either to generate an error indication or to generate a command to a management system that controls resource behavior.
All Experiams are based on a Java Interface, and so anything that implements that Interface is a valid Experiam. Commercial Experiams can be written to the interface and even if they are based on the Java sample class for Experiams we've described above, they can be sold commercially and mingled with open-source Experiams without violating our license requirements (CDDL). However, Experiams in the Alpha-One release use a "base object" that is extended by the functional Experiams, and since this object is open source, commercial implementations of Experiams will have to be created without it to avoid coming under our open source license.
Experiams execute in some runtime context, the recommended one of which is a thread-safe process driven by an event queue. Requests for service from any source (a operator, a network protocol, web service, GUI, management system API, or whatever, should be translated into a relevant event and posed to the event queue for handling. The event handler dispatches the Experiams that will process the events, and so the event handler and the Experiams must be designed to support whatever level of threading/concurrency is desired. It is perfectly reasonable to do single-threated Experiams for testing and demonstration, but obviously this behavior will present problems in most production applications. We will be providing a sample of queuing and dispatch logic based on a GUI, and we recommend that this example be extended to add whatever additional event sources may be required. Most Experiams should be equipped with some GUI capability for logging and debugging and we will be happy to talk about best practices.
Experiams are all expected to report their names and descriptions via a method, and this mechanism can be used at run time to establish whether an Experiam is compatible with the practices used by the caller. We recommend that Experiam names be registered if that is to be done. Experiams may also report their use of parameters, allowing partners to call an Experiam method to learn what it expects and what it produces as a result. We do not recommend this level of run-time dynamism; Javadocs should be used to describe the behavior of Experiams instead. The state/event logic of Experiams need not be exposed this way, but it is recommended that at least a simple state/event table describing Experiam behavior be developed and published to help with integration and to diagnose problems.
Experiams should be POJOs rather than relying on J2EE or any other special version or commercial extension of Java, but commercial Experiams can transition to RTJ or J2EE internally if necessary, and open source Experiams can do so providing they expose the dependency in their descriptions and also respond to the method call and report the dependency.
For sample code, you must be a member of the ExperaSphere community; please contact us for more information!
|ExperiaSphere, SocioPATH, and Think Outside the Bit Copyright (C) CIMI Corp. Follow us on Twitter: @experiasphere|