getting more efficiency along with safety from #SOA

20.9.25: addx/soa/

getting more efficiency along with safety:

10.19: summary:

. soa (service oriented architecture)

is expensive when it intervenes 

every call to a subprogram;

instead of calling soa mgt for every call,

we shouldn't be worried about an app making 

internal calls to parts of the same app

by the same author with the same privileges.

. a complement of soa controlling the calls,

is stack isolation controlling the returns.

20.9.25: 10.14:

. in oop (object-oriented programming),

rather than call a function ourselves,

we make a call to a datatype's mgt,

telling it the name of the function we want,

and then type mgt decides which method to use

for implementing the function,

depending on the particular datatypes 

of the function's arguments.

. in a soa (service-oriented architecture)

rather than call a function or type mgt ourselves,

we call the soa mgt,

telling it not only the functions name

and the datatype mgt

but also the name of the app requesting the call;

like so:

the app says "call soa(datatype, function, args)";

and, then the os knows the currently active process 

and when the soa mgt gets the call from an app

it can ask the os for the current process info

to find out who the app is, 

and what resources belong to it.

[10.7:

. we use soa to spy on the applications

to make sure they are doing what is expected

and are not malicious or hijacked by malware.

10.9: 

. when soa mgt can know an app's expected calls

then it can know when a hijacking has occurred

because the app will make unexpected calls.]

. isn't soa rather expensive?

every call is turned into a double call!

here's a way to get more efficiency:

instead of calling soa mgt for every call,

we shouldn't be worried about an app making 

internal calls to parts of the same app

by the same author with the same privileges.

[10.7:

. apps also need soa mgt to assign additional processors;

because when one app wants to employ another,

it needs to know which processor

the employee might already reside at.

. the task mgt is the one assigning processors;

and it always keeps soa mgt informed.

]

. I wondered if each processor should have its own soa mgt;

but was assuming each processor has its own memory;

whereas, it's usual to have several processors sharing memory.

. soa is about defending a modular machine;

when several processors are sharing memory,

a single soa mgr should have control over 

every process that can affect any part of that memory.

10.8:

. the os gives each app and service its own process 

and when an app wants to call 

some other author's process or module

then it calls the os(msg for process)

and os gives msg request to soa mgt

who keeps track of all components used by caller.

. each of the components is run in their own process

and os mem mgt protects each process from

affecting each other's personal mem space.

10.7, 10.9: 10.14: type-specific soa:

. for each module implementing a data type,

that module can be put in a library

and be employed by many different apps.

. there are 3 approaches to sharing;

each app can have its own type mgt process;

or all the apps can share one type mgt process

or an app and its imports can share the same process.

. also there are 2 ways of storing objects;

in the process space of datatype,

or the process spaces of each client app.

. the most efficient and less modular way

is to have the app copy the datatype's code

so it is considered to be internal to the app

rather than having its own process;

but then the datatype's code can be modified by the app

and if it is designed to spy on an app

we can no longer expect that it will do that,

and we say that datatype code is no longer autonomous.

. if I'm using an oop language to encapsulate objects,

how can I be sure an app can't be hijacked

and then overwrite an object

without permission from that object's type mgt?

. here is why a type mgt might want to 

keep its objects in its own process space:

. the usual os memory protections

happen at the process level:

each process can modify its own memory

in any way it sees fit.

. a compiler offers memory protection per object

so that only that object's type mgt

can be modifying that object;

but once an app is compiled,

an app author may modify the code

so that the type mgt loses control and autonomy.

. also it might be possible for malware

to modify arbitrary objects

by doing a buffer overflow that corrupts the app's heap,

but malware might find it much more difficult

to be able to corrupt the heap of a datatype's module

because it can be separately designed and tested

and employ an author that is more trustworthy

than would be found in your arbitrary app.

. also, suppose the type mgt manages trees,

and it is passing trees between apps;

then if the type mgt has its own local heap,

it can transfer ownership with a single pointer assignment

instead of copying so many tree nodes 

from one app's local heap space 

to another app's local heap space.

. in what I call a type-specific soa,

an autonomous type mgt process 

can analyze all the apps that are its clients

and inform the central soa mgt

how each app typically uses that datatype

-- to help the central soa do its job

of knowing when a resource is being used

in a suspicious way.

. when a dataype is provided by the os,

that datatype can be autonomous

and can implement a type-specific soa,

yet it is more efficient than an soa

because, the app is calling type mgt directly

instead of through the soa.

. a type-specific soa requires trust;

but if the author is the same as for the os,

that author is already very trusted.

. if a type mgt can be implemented by 

one service that multiple apps must share;

that creates a bottleneck on service from that type;

so, the service should have a process for each client,

and then each process can be run on its own processor.

20.9.11: 10.19: soa tracking nodes:

. for decomposing a large program,

not only can there be subprograms and datatypes,

but also there can importing of packages

that combine related subprograms and datatypes.

. in a network situation, 

each website is a node of a graph;

and each node has a library of packages.

. a node can either copy a package definition

into its library,  or use the services

of some other node's instance of the package.

. a globally used package might want to be aware of

not just which app is using it, but also which node.

. each call comes from an app at a node,

and all that is noted by a node's soa.