jpgneves / iota Goto Github PK

As part of an optional, user-triggered check, iota could be able to verify application layers to ensure applications are interacting in a correct fashion among themselves beyond merely calling the correct APIs.

For example, consider an application X consisting of a web interface application W, business logic applications B1 and B2 and a datastore interface D, with a generic utilities application U that is shared by all of them.

The desired interactions are:

• W can call to B1 or B2
• B1 and B2 can call to D
• B1 and B2 cannot call W
• D cannot call any of the above applications
• All applications can call U

The layer definitions could be as such:

% Unspecified applications are not subject
% to the checks and can call or be called by every application.
% This is mostly to keep iota silent about third-party applications
% which generally are only called by user-defined applications.
% Layers are also specified in a top-down order.
% Each layer consists of a tuple with the layer name and the
% list of applications that belong to that layer.
{layers, [ {view, [w]},
           {business, [b1, b2]},
           {storage, [d]}
         ]}.

This information can be specified in the existing iota.config file.

This check could be run using iota check_layers <path> and would not be part of any default checks.

iota could produce artifacts describing the application (e.g. exposed API, git tag/commit) that can be used to inform dependency resolution systems to get exact dependencies for another application (e.g. "I want the latest version of application A that exposes foo/1 and bar/3").

iota could produce an SVG graph with all bad dependencies between applications, probably using annotated arrows describing the invalid call.

Your example doesn't work as priv/test_app1 doesn't get compiled. To make it work:

$ pushd priv/test_app1
$ ../../rebar compile
$ popd

and then

$ ./iota check priv/test_app1

works as expected.