reviewing the costs of SOA

31: addm/reviewing the costs of soa:
. when looking at SOA architecture,
how does that affect the
cross-module communications costs ?
there could be a devil in the details;
but, the bird's eye view is that
it could actually be quite minimal .
. traditionally we save costs by
sending references instead of copying data;
we are then calling another module
and handing access to our data .
. then came the OOP paradigm
where we ensure data integrity
by having one manager for each datum:
that manager (in SOA fashion)
is taking messages from other processes
which are wishing to read or modify the data
and then applying these changes itself,
rather than letting arbitrary code
affect any piece of data .

. finally, in SOA,
not only can't we directly access data,
we can't directly access subroutines either:
everything is a message to the SOA exec
. messages include a reference to the caller,
a ref' to the routine being called,
and ref's to the arguments of the call .
. then the SOA exec determines the actual address
of the subprogram being called,
and may offer a substitution;
there may also be logging of calls
for security audits .
. by doing it this way,
nothing is accessable to malware;
because, malware is trying to hide,
and thus it doesn't have a callee ID .

. the SOA exec is an obvious bottleneck;
but it is needed only for cross-module calls;
thus, intra-module calls can be very speedy;
however, for most mobile platforms,
the developer is encouraged to use
pre-existing modules for maximal code reuse
in order to limit application size .

. the security of this all depends upon
a sort of virtualization,
where every line of code is being
interpreted by a bytecode exec,
so that a module never has direct access
to the machine's instruction processor .
. when the bytecode exec starts a module,
only the bytecode exec can access
the current module's callee ID,
therefore this can't be fabricated by a malware .
. when the bytecode exec comes to a call instruction,
it knows what the current module is
and what its callee ID is;
because its own private database
is what assigned that callee ID to that module .
. when a cross-module call is made,
the SOA exec knows it can trust the bytecode exec,
because they are both part of the microkernel .

. because we are using OOP,
we can still use references as arguments
even with objects affected by concurrency:
the modules that are using the same object
are just sending it messages,
and these are placed on its queue .
. this will work within the Ada language;
so, we may assume it is applicable to
a wide range of stock platforms .

. each processor needs its own bytecode exec;
because, a processor can't read code directly:
the processor runs the bytecode exec;
and, then that exec translates the bytecode .
. one processor needs to be dedicated to
use by the SOA exec:
and, all cross-module call requests
are funneled through that processor .

. if there are many processors,
each module can have its own processor;
but, a module that is less used
or whose use has a lower priority,
may have to be swapped out occasionally;
so, the SOA exec is keeping a map
showing for a given module,
whether it's currently loaded into a processor,
and then which processor that is .