How does a Perspectives ‘program’ interface with the outside world of existing (legacy) software? We want to handle three scenarios: an ‘ask’ scenario, a ‘listen’ scenario and a ‘tell’ scenario.
- ask: Perspectives retrieves a value from an external system;
- listen: Perspectives reacts to an event triggered by an external system;
- tell: Perspectives modifies a value in an external system.
Ask
Let’s concentrate on the simplest kind of question we can ask an external system for, to wit a property value. We represent the relevant parts of the external system in Perspectives and part of that representation should be a Role with a Property that corresponds to the property we’re interested in.
To make this less abstract, consider a thermometer that can be reached on some IP address. It will have a REST interface that yields the temperature. It can be represented by a context with an external property, “temperature”. As soon as this property is consulted, i.e. when an Action is executed by a user- or bot-role that accesses that property, a small piece of external code is executed that retrieves the current temperature through the REST interface.
This can be considered to be a special kind of computed property (ComputedProperty). It is not calculated from other properties (CalculatedProperty); it is an external computation.
Conceptually, more complex data structures to be retrieved from external systems are a variation on this theme. There is more technical detail to handle, but no new conceptual machinery.
Listen
Conceptually, we model the listen-interface with a Bot. A Bot is like a user-Role. A Bot has a perspective, too, consisting of the Actions he can perform in the Context.
The Actions of a Bot need to be qualified with a condition. The condition is written in terms of the state of the Context and its Roles. A Bot performs any Action whose condition evaluates to true, immediately and only once. As a side effect of a Bot Action, the state of the Context (or at least one of its Roles) will change.
Now let there be a system S that needs to interface with Perspectives. Let S be a system that contributes orders, with a limited number of simple properties. These orders are probably entered by humans in S, but need to be available in Perspectives.
To begin with, the order and its properties is modelled as a Role in some Context. We add a Bot to this Context and provide him with Actions that create and modify the Order (which is a role!).
So when a human operator of S enters a new order, we want our Bot to somehow know of that event and to copy the information from S into Perspectives, by performing the aforementioned Actions. How do we accomplish this?
Let’s assume that the system S will place a small Json file, describing the order, in a fixed directory. The appearance of such a file is an event that should trigger our bot. This is how we implement the Bot’s behaviour: by creating a script that runs in the operating system environment external to Perspectives, triggered by the event and using an interface library to Perspectives.
The library is described here. It is used to create custom screens for a Perspectives Model and it allows us to perform an Action of a Role in a Context. We write a simple Javascript script (or a program in any other language) that reads the file from the directory, parses the JSON and uses the library to create an Order-Role in the aforementioned Context and then gives it the properties that characterise the Order. Then we create a Cron-job (assuming a Unix OS; on other systems, use equivalent mechanisms to watch a directory). This job checks the directory periodically with a desired frequency; if it finds a file in it, it runs the Javascript script.
This is standard practice for simple system interfacing. What is special is the library used to interface with Perspectives. What is special, too, is the modelling of the interface as a Bot with Actions.
Tell
Again, we’ll just discuss the way we can modify a simple property of an external system. Again, we’ll have to model the relevant part of the external system with (at least) a Role bearing the Property we want to write.
Like with the computed Property used for the Ask interface, we have an ExternalWritableProperty. As soon as an Action is executed that modifies the Property on the Role, some external code is executed that calls the API of the external system to modify the relevant property.
API mapping
ComputedProperty’s and ExternalWritableProperty’s are the Perspectives way of wrapping an external API. Wrapping ExternalWritableProperties is much like using the library mentioned above that can be used to create custom screens.