Structs and Nodes Development:

An automation basis for data-intensive applications

Data intensive applications are composed of a custom data model and supporting processing. Even moderate applications can have significant database schemas, accessed by workflow, modification rules, timer events, and external connections within a secure authorization environment. User interaction with the application can be through a web browser, standalone GUI application, web services, or other communication protocols.

The design of a data application must balance the database schema, the object model for processing, communication formats, and data entry forms. This is complicated by authorization, which may disallow actions, restrict views of data, or filter out data at the field level. The application must be modular, with clear inputs and outputs to support extension, modification, and testing.

Working at a higher level

1. The first step in working at a higher level is to create a central data definition structure or "struct". The struct definition drives the database schema, the object definitions, the communication formats, and data manipulation interfaces. Modification of a struct automatically changes all the dependent formats and associated processing.

   Persistent structs normally declare the standard derived messages of query, collection, and update (creation, modifications, or deletion). An AggregateUpdate message holds multiple updates for execution within a single transaction. Structs can also declare non-persistent runtime messages or actions.

2. The second step is to create program processing components or "nodes" that declare which messages they accept and return. So for example an AccountManager node might accept an AccountQuery and return an AccountCollection. It may also receive an AccountUpdate (or AggregateUpdate) and return the same message confirming the updated information. Input and output may be synchronous (call/response) or asynchronous (publish/subscribe)

   Nodes declare their configuration parameters. Initial values are set in the deployment configuration, and runtime access is provided through application management interfaces. Node logic is not directly concerned with messaging mechanics or configuration, but is implemented using "get" methods for configuration parameters, overriding "onReceive" or "onDelivery" methods, and using generated "call" and "send" methods. UI forms, web service interfaces, and supporting bridge code are generated automatically from deployment parameter values.

3. The third step is a framework for authorization and update processing that controls both what is displayed in the user interface and what is allowed in processing. An Authorizer enforces allowed access to information at the level of:

   • Message: e.g. a user may not be authorized to use an AccountUpdate message under any circumstances.
   • Instance: e.g. a user may be authorized for an AccountUpdate message but only for their own account.
   • Field: e.g. a user may be authorized for an AccountUpdate message but may only change certain fields.
   • Value: e.g. a user may may be authorized for an AccountUpdate message but may only set some fields to a subset of their possible values.
   • Match restrictions: e.g. any AccountQuery must match on an active status.

   The same authorization mechanism can also include UI tokens such as screens, or custom action buttons, to provide a single centralized authorization mechanism. Changes to authorization are automatically implemented across all access points ensuring consistent security and presentation.

Application

The "Structs and Nodes Development" (SAND) methodology provides enormous leverage for automatic code generation, reducing effort for in development, maintenance, and testing. It also helps to separate application logic from user interface and supporting technology APIs.

So far, SAND has been applied to the Java (tm) programming language through the use of a custom tag library, naming conventions, and a custom build process that reads the tag library information to create the supporting code for a web application/web service. At the time of this writing, SAND has been used to design a half dozen applications, three of which are in production use. Current work is focused on improving the development environment.