2004 Encapsule Prototype Screen Shots

This page presents a number of screenshots of the 2nd generation Encapsule prototype running on the Windows platform at various stages of its development. (See also: Encapsule Aurora Platform Whitepaper)

Pictured below: Encapsule Aurora Specification Editor (EASE) shows a user beginning the process of creating an application specification via drag-and-drop. The tiles on the left are visual representations of re-usable application building blocks, or modules in Encapsule parlance. Each module represents some arbitrarily complex interconnection of low-level binary plug-ins, or filters in Encapsule parlance.

Modules are effectively chunks of virtual circuit board that expose input/outputs at their edges, contain embedded logic (interconnection networks of binary plug-ins), and potentially sockets into which other modules may be inserted as part of the application specification process. The entire process of specifying an application from a kit of modules is thus reduced to an iterative stacking of modules into sockets.

At any point, the user may click a button and execute the specified application without the need to write a single line of code.

Note that modules are ultimately simple XML documents that encode a description. The platform enumerates available XML documents and dynamically constructs the editor. This means that there’s no direct coupling between the platform and a specific problem domain: any software that can be expressed in terms of plug-in interconnection graphs may be encapsulated in a domain-specific set of modules and exposed via the platform. In this example, the modules represent a web application. Executing the specified application, builds a runtime (from plug-ins) that actually generates the website.

Dropping a module into the application specification expands the module to reveal sockets. Sockets are points of extensibility into which compatible modules may be deposited via drag-and-drop. The user iteratively completes the application specification by stacking modules into the specification treeview. The screenshot shows the specification of a hypothetical enterprise web application.

Note that the specification tree is deceptively simple looking. What’s important to understand is that the edges in the specification graph actually represent arbitrarily complex interconnection buses (collections of one or more strongly-typed signal paths effectively). This detail is not exposed to end-users of the system as it’s quite overwhelming. Developers of domain-specific model/plug-in sets leverage lower level reports and graph visualization diagrams generated by the platform to inspect and understand these details.

The following screenshot shows a later revision of the prototype renamed “Hyperworx”. Note that this screenshot shows the entire prototype actually working end-to-end with real plug-ins doing real work (in this example the graphical specification represents a website). The module models reference plug-ins that implement document generators. Executing the specification (i.e. graph splicing, analysis, plug-in instantiation, and runtime dispatch) results in the creation of a throw-away custom application that generates the website when it executes.