![](bg3.png)
sources (and may – independently of sources – have
multiple owners) and/or data that is subject to one or
more policies (security, privacy, etc.). Much of the
metainformation we aspire to record about data is in
various ways associated with data provenance. Over
the years lots of work has been invested in provenance
in various ways – () provides a general overview of
these efforts in the database field. In cases where a
multi-cloud solution is used to implement workflows
that process data, we may also be interested in solu-
tions for workflow provenance.
In practice, incorporating all or even any metain-
formation into one’s (domain) data schema or ontol-
ogy is difficult, and easily results in a very compli-
cated data model that is hard to understand and main-
tain. It can, in fact, be observed that provenance-
related metadata attributes (such as source and owner)
are cross-cutting aspects of associated data, and by
and large are independent of the domain models in
question. The problem is similar to the problem of
cross-cutting aspects in software system design, a sit-
uation
3
that has led to the development of Aspect-
Oriented Programming ().
From the pragmatic standpoint, the granularity of
data described by specific metadata is an important
consideration: Do we record metadata at the level of
individual objects (in which case “mixing” metadata
with the domain schema is achievable in practice), or
even at finer (i.e., “intra-object”) granularity; a possi-
ble solution to the latter is presented in ().
3 COMPUTATION
From the computation perspective we are faced with a
task to enable and create consistent (from the seman-
tics standpoint) and accountable components that can
be leveraged and reused in a larger, distributed infor-
mation system. This translates to several pragmatic
objectives, including (but not limited to) the follow-
ing:
• Design and implementation of scenarios where
computation can be described and represented in a
system-wide understandable way, enabling com-
putation to be “migrated” (transmitted) from one
computational environment to another. This trans-
mission would involve reconstruction of the com-
putational task at the receiving end to match the
defined semantics of task and data involved. It
should be noted that in scenarios like this the se-
mantics of computation are described at a fairly
3
The motivating situation is sometimes referred to as the
“tyranny of dominant decomposition” ().
high, abstract level (rather than, say, in terms of
low-level machine instructions).
• Construction of a system where larger computa-
tional tasks can be decomposed into smaller tasks
or units of computation, independent of what the
eventual execution environment(s) of these tasks
(that is, independent of hardware platforms or op-
erating systems).
Traditional approaches to “mobile code” have in-
cluded various ways to standardize the runtime exe-
cution environment for code, ranging from hardware
architectures and operating systems to various types
of virtual machines. In a heterogeneous configuration
of multiple device and cloud environments, these ap-
proaches may or may not be feasible, and we may
want to opt for a very high level (possibly purely
declarative) description of computation (e.g., describ-
ing computation as a set of goals to be satisfied).
High-level, declarative descriptions of computa-
tion (e.g., functional programming languages such as
Erlang) afford considerable latitude for the target ex-
ecution environment to decide how computation is to
be organized and effected. This way, computation can
be scheduled optimally with respect to various con-
straints of the execution environment (latency budget,
power or other resource consumption, remaining bat-
tery level, etc.) and decisions can also be made to
migrate computation to other environments if needed.
4 MANAGED CLOUD
PERFORMANCE
A new outlined paradigm of distributed systems re-
quires an explicit orchestration of computation across
Edge, Cloud and Core depending on components
states and resource demand, through the proper ex-
ploit of granular and therefore accountable mecha-
nisms. The behavior analysis of the software compo-
nents using live telemetry gathered as the cloud sus-
tain production load is mandatory.
End-to-end latency is seen by us as a major met-
ric for quality assessment of software architecture and
underlying infrastructure. It yields both user-oriented
SLA, the objectives for each Cloud stage. The ulti-
mate goal is the ability to quantitatively evaluate and
trade-off software quality attributes to ensure compet-
itive end-to-end latency of Internet Services.
On another hand, the task of performance analy-
sis is to design systems as cost effectively as possible
with a predefined grade of service when we know the
future traffic demand and the capacity of system el-
ements. Furthermore, it is the task to specify meth-
DATAANDCOMPUTATIONINTEROPERABILITYININTERNETSERVICES
61