Architected Processing

A runtime instance of EATS is called an Architected Service Facility, or a processing node. It corresponds to a runtime executable instance that can be addressed and dealt with as a unique processing environment. There may be more than one instance on a machine, a computer, but each instance needs to be uniquely identifiable, and have a separate IP:Port addressability. Conversely, a single instance may be addressed by more than one IP:Port address, as in the case of dual ported computers.

EATS provides the infrastructure for operation of the node, as a virtual machine, in a layered hierarchy. Every node conceptually, is organized into three process management type spaces: presentation, service and resources. The EATS infrastructure uses an Inversion of Control pattern to drive "architected objects" in each of these spaces. The architected objects, software scripts, usually written in Java, vary from procedural code to model driven, generic scripts. 

EATS can be configured to run as a single instance, on a single machine, in standalone fashion. However, it was designed to be able to run as a distributed, federated network of systems, with two or more nodes involved, using an arbitrary topology.

For the infrastructure this presents challenges primarily in the presentation services layer.

The architecture is organized in two binary slices:

First, presentation interactions are separated from all content processing services, and handled with tailored processes based on the type of presentation required. A lot of functions in this layer can be handled generically, but they have to be tailored to the technologies employed. This is also where we tailor for user personalities with things like "skins." Presentation interaction events tend to originate in the client environment as some level of request, and need to be responded to with some system action. Interactions can take all forms, and are handled by "adapters" and converted to architected requests to be processed by the service layers, the other part of the binary slice, consisting of the business and resource service layers. The presentation layer is "the glass" or "the shell" between the client and the services, which define the real machinery of the system. 

Internally the architecture differentiates between Business Services, logic machines, and Resource Services, content machines, but the presentation objects are unaware of the difference. Both appear simply as service processors for "architected messages." 

The presentation layer is also responsible for potential process conversion from synchronous to asynchronous processing. All processing by the service layers is accomplished via asynchronous messages. Generally this is resolved with callbacks, but other techniques can also be used. For example, rather than fighting this battle, this architecture fits with an Ajax-type web design where the browser can fire and handle asynchronous messages.