Architecture /

Cybernetics

Input Processing Output

In this paradigm, where the system operates in the environment Internet, Boxary clearly takes the process box. And, as opposed to application modules, the input is NOT a database model with user data, nor a stream with application data. It constitutes a query, command, request and such. Also, the output is NOT a signal that can trigger feedback. It will be an extract of the user data resting within the storage layer.

Input Layer.

All input is coming in thru internet protocols; that is, the underlying protocol (i.e. its syntax) is of interest. Variations are HTTP(s), REST, SOAP, WSXL In Boxary, this input data is merely interpreted as configuration parameters, commands, and identifiers.

Output layer.

All output is generated and/or assembled thru Templates. Boxary takes variations called snippet, templet, and template.
HTML pages are rendered using a sophisticated layout concept. Web services deliver clean XML or JSON.

snippet
  • A single line or simple string. Just substitute variables with text.
templet
  • A text, either a snippet, either a file read from the fileSystem. Recursively substitute variables with text or new variable names.
template
  • A complete text, assembled from multiple files. Contains also logic.

Processing Engine.

Processing is parameterized by a mode parameter: list, view, edit, count.
Modules prepare for a specific App, than invoke that App's control. This will load input data, load the Graph, walk the Graph to collect (harvest) the needed data, run the transaction if any, persist the result, produce the result output.

list
  • Process multiple units (rows) with the same structure, extracted from the storage layer.
view
  • Process a single unit (a row) and allow for hyperlinking.
edit
  • Process a single unit (a row) and build a form that will instruct Boxary for the update.
count
  • Process a graph and count for specified occurrences (analytics).

Input Processing Output with Storage

Now, let's pretend the storage is an archive, or, at least, it can be handled as such. Inspired by the Open Archive Initiative, all input obey the rules set for harvesting metadata. With this in mind, the input can be seen as metadata that may trigger configuration(s) and contains identifiers (search criteria). The output is a response in a specific format.
Implemented in OAI are the concepts for repository, dataprovider, serviceprovider, dataharvester, dataaggregator, using terminology like identifier, item, record, set.

repository
  • A repository has the flavor of a resource, an item or a record, and is identified by a symbolic name.
  • An item needs a unique identifier. A collection of items is a Set.
  • A record is a complete (canonical) representation of the repository.
  • A resource is a lazy-loading record.
dataprovider
  • A dataprovider maintains one (or more) repositories as a means of exposing data.
  • The data that a dataprovider exposes is identified by a (unique) setName.
  • A dataprovider manifests by the objectInstance thru a method name.
serviceprovider
  • A service provider issues requests to dataprovider(s) and builds value-added services from the results.
  • A service provider in this manner is "harvesting" the data exposed by dataprovider(s) and may refine it as a service.
dataharvester
  • A dataharvester is the client application issuing requests to dataprovider(s) and/or serviceprovider(s).
  • Harvesting refers specifically to the gathering together of data from a number of 'unrelated' repositories into a combined data store.
dataaggregator
  • A dataaggregator is both a serviceprovider and a dataprovider.
  • It is a service that gathers data from multiple dataproviders and then makes those data available for gathering by others.

These OAI concepts are very useful in Boxary. Practically spoken, the serviceprovider concept is ambiguous because Boxary utilizes its own, and closed environment. But it could be attached to Boxary's main class as a container that injects the described providers above. Such a container could provide a service like a phone book.
Furthermore, the dataprovider concept can be applied to some input protocols.

Storage layer.

All user data is stored within a relational database; ex: mySql, Maria, Postgres.
Application configuration, model parameters, templates are stored as flat files in the filesystem.

repository
  • The database layer.
serviceprovider
  • A specific database abstraction, like mySql(i), PDO and such.
dataprovider
  • A resultSet.
dataharvester
  • A rowSet.
dataaggregator
  • A groveSet.

Having said this, a slight optimization can be added to the input layer: because the input in Boxary's case is NOT metadata and the distinguished OAI entities are NOT organizations in Boxary.

dataprovider
  • formDataProvider manages all POST variables.
  • webServiceDataProvider manages SOAP interfaces on their input side.