An Ambient ASM Model for Client-to-Client Interaction via Cloud
Computing
K´aroly B´osa
Christian Doppler Laboratory for Client-Centric Cloud Computing, JKU, Linz, Austria
Keywords:
Cloud Computing, Ambient Abstract State Machines, Ambient Calculus.
Abstract:
In our former work we have given a high-level formal model of a cloud service architecture in terms of a novel
formal method approach which combines the advantages of the mathematically well-founded software engi-
neering method called abstract state machines and of the calculus of mobile agents called ambient calculus.
This paper presents an extension for this cloud model which enables client-to-client interaction in an almost
direct way, so that the involvement of cloud services is transparent to the users. The discussed solution for
transparent use of services is a kind of switching service, where registered cloud users communicate with each
other, and the only role the cloud plays is to switch resources from one client to another.
1 INTRODUCTION
In (B´osa, 2012b) we proposed a new formal
method approach which is able to incorporate the
major advantages of the abstract state machines
(ASMs) (B¨orger and Stark, 2003) and of ambient cal-
culus (Cardelli and Gordon, 2000). Namely, one can
describe formal models of distributed systems includ-
ing mobile components in two abstraction layers such
that while the algorithms of executable components
(agents) are specified in terms of ASMs; their com-
munication topology, locality and mobility described
with the terms of ambient calculus in our method.
In (B´osa, 2013) we presented a high-level formal
model of a cloud service architecture in terms of this
new method. In this paper, we extended this for-
mal model with a Client-to-Client Interaction (CTCI)
mechanism via a cloud architecture. Our envisioned
cloud feature can be regarded as a special kind of
services we call channels, via which registered cloud
users can interact with each other in almost direct way
and, what is more, they are able to share available
cloud resources among each other as well.
Some use cases, which may claim the need of such
CTCI functions, can be for instance: dissemination of
large or frequently updated data whose direct trans-
mitting meets some limitations; or connecting devices
of the same user (in the later case an additional chal-
lenge can be during a particular interpretation of the
modeled CTCI functions, how to wrap and transport
local area protocols, like upnp via the cloud).
The rest of the paper is organized as follows.
Section 2 informally summarizes our formerly pre-
sented high-levelcloud model. Section 3 gives a short
overview on the related work as well as ambient cal-
culus and ambient ASM. Section 4 introduces the def-
initions of some non-basic ambient capability actions
which are applied in the latter sections. Section 5 de-
scribes the original model extended with the CTCI
functions. Section 6 demonstrates how a request for
a shared service is processed by the discussed model.
Finally, Section 7 concludes this paper.
2 OVERVIEW ON OUR MODEL
Roughly our formal cloud model can be regarded as
a pool of resources equipped with some infrastructure
services, see Figure 1a. Depending whether these ab-
stract resources represent only physical hardware and
virtual resources or entire computing platforms the
model can be an abstraction of Infrastructure as a Ser-
vice (IaaS) or Platform as a Service (PaaS), respec-
tively. The basic hardware (and software) infrastruc-
ture is owned by the cloud provider, whereas the soft-
wares running on the resources are owned by some
users. We assume that these softwares may be offered
as a service and thus used by other users. Accord-
ingly, we apply a relaxed definition of the term service
cloud here, where a user who owns some applications
running on some cloud resources may become a soft-
459
Bosa K..
An Ambient ASM Model for Client-to-Client Interaction via Cloud Computing.
DOI: 10.5220/0004490904590470
In Proceedings of the 8th International Joint Conference on Software Technologies (ICSOFT-PT-2013), pages 459-470
ISBN: 978-989-8565-68-6
Copyright
c
 2013 SCITEPRESS (Science and Technology Publications, Lda.)

I
n
t
e
r
f
c
e
a
a) Scenario I.
b) Scenario II.
.
.
.
.
.
.
Client
l
Client
l
I
n
t
e
r
f
a
c
e
O
m m+1
2 3
O
4
O
5
O
1
O O
2 3
O
4
O
5
O
1
O O
2 3
O
4
O
5
O
1
O O
2 3
O
4
O
5
O
1
O O O
m m+1
Legend:
Outer Firewall
Cloud
. . .
S1 S1 Sj
Infrastructure Services
. . .
. . .
Cloud (nowadays)
S1
S1
Sj
Outer Firewall
Client−Cloud Interaction Controller
. . .
. . .
Infrastructure Services
Rn
Ri
R1
R1 Ri Rn
.
.
.
.
.
.
O
O
. . .
Ri : Cloud Resource Sj : Service
Protected Area
Area
: Firewall Protected
: Credential
Service OwnerV
Service OwnerW
Contact Point of
Contact Point of
Service OwnerV
Contact Point of
Contact Point of
Service OwnerW
abstract...
abstract...
abstract...
abstract...
Specific Functions
for UserY
Specific Functions
for Service OwnerW
Specific Functions
for Service OwnerV
Specific Functions
for UserX
Protected Area
of UserX
Protected Area
of UserX
Specific Functions
for UserY
Specific Functions
for Service OwnerW
Specific Functions
for Service OwnerV
Specific Functions
for UserX
Figure 1: Application of our Model According to Different Scenarios.
ware service provider at the same time. Thus, from
this aspect the model can be regarded as an abstrac-
tion of a mixture of Software as a Service (SaaS) and
of IaaS (or a mixture of SaaS and PaaS).
We make a distinction between two kinds of cloud
users. The normal users are registered in the cloud
and they subscribe to and use some (software) ser-
vices available in the cloud. The service owners are
users as well, but they also rent some cloud resources
to deploy some service instances on them.
For representing service instances, we adopt the
formal model of Abstract State Services (AS
2
s) (Ma
et al., 2008; Ma et al., 2009). In an AS
2
we have views
on some hidden database layer that are equipped
with service operations denoted by unique identifers
o
1
,..., o
n
. These service operations are actually what
are exported from a service to be used by other sys-
tems or directly by users. The definition of AS
2
s also
includes the pure data services (service operations are
just database queries) and the pure functional services
(operation without underlying database layer) as ex-
treme cases.
In our approach the model assumes that each ser-
vice owner has a dedicated contact point which re-
sides out of the cloud. It is a special kind of client that
can also act as a server for the cloud itself in some
cases. Namely, if a registered cloud user intends to
subscribe to a particular service, she sends a subscrip-
tion request to the cloud, which may forward it to such
a special kind of client belonging to the correspond-
ing service owner. This client responses with a spe-
cial kind of action scheme called service plot, which
algebraically defines and may constrain how the ser-
vice can be used by the user
1
. (e.g.: it determines the
permitted combination of service operations). This
special kind of client is abstract in the current model.
The received service plots, which may be com-
posed individually for each subscribing user by ser-
vice owners, are collected with other cloud functions
1
For an algebraic formalization of plots Kleene algebras
with tests (KATs) (Kozen, 1997) has been applied.
available for this particular user in a kind of personal
user area by the cloud. Later, when the subscribed
user sends a service request, it is checked whether the
requested service operations are allowed by any ser-
vice plot. If a requested operation is permitted then it
is triggered to perform, otherwise it is blocked as long
as a plot may allow to trigger it in the future. Each
triggered operation request is authorized to enter into
the user area of the corresponding service owner to
whom the requested service operation belongs. Here
a scheduler mechanism assigns to the request a one-
off access to a cloud resource on which an instance
of the corresponding service runs. Then the service
operation request is forwarded to this resource, where
the request is processed. Finally, the outcome of the
performed operation returns to the area of the initiator
user, where the outcome is either stored or send fur-
ther to a given client device. In this way, the service
owners have direct influence to the service usage of
particular users via the provided service plots.
Regarding our proposed cloud model one of the
major questions can be whether it is adaptable to the
leading cloud solutions (e.g.: Amazon S3, Microsoft
Azure, IBM SmartCloud, etc.). Since due to the ap-
plied ambient concept the relocation of the system
components is trivial, we can apply our model accord-
ing to different scenarios. For instance, all our novel
functions including the client-to-client interaction can
be shifted to the client side and wrapped into a mid-
dleware software which takes place between the end
users and cloud in order to control the interactions of
them, see Figure 1b. The specified communication
topology among the distributed system components
remains the same in this later case.
3 RELATED WORK
It is beyond the scope of this paper to discuss the
vast literature of formal modeling mobile systems
and SOAs, but we refer to some surveys on these
ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies
460

fields (Boudol et al., 1994; Cardelli, 1999; Schewe
and Thalheim, 2007).
One of the first examples for representing various
kinds of published services as a pool of resources, like
in our model, was in (Tanaka, 2003).
In (Ma et al., 2012) a formal high-level specifica-
tions of service cloud is given. This work is similar to
ours in some aspects. Namely, it applies the language-
independent AS
2
s with algebraic plots for represent-
ing services. But it principally focuses on service
specification, service discovery, service composition
and orchestration of service-based processes; and it
does not apply any formal approach to describe ei-
ther static or dynamically changing structures of dis-
tributed system components.
In the rest of this section, we give a short summary
on ambient calculus and ambient ASM, respectively,
in order to facilitate the understanding of the latter
sections.
3.1 Ambient Calculus
The ambient calculus was inspired by the π-
calculus (Milner et al., 1992), but it focuses primarily
on the concept of locality and process mobility across
well defined boundaries instead of channel mobility
as π-calculus. The concept of ambient, which has the
following main features, is central to the calculus:
• An ambient is defined as a bounded place where
computation happens.
• Each ambient has a name, which can be used to
control access (entry, exit, communication, etc.).
Ambient names may not be unique.
• An ambient can be nested inside other ambients.
• An ambient can be moved. When an ambi-
ent moves, everything inside it moves with it
(the boundary around an ambient determines what
should move together with it).
The ambient calculus includes only the mobility
and communication primitives depicted in Table 1.
The main syntactic categories are processes (includ-
ing both ambients and agents) and actions (including
both capabilities and communication primitives). A
reduction relation P −−→ Q describes the evolution of
a term P into a new term Q (and P −−→
∗
Q denotes
a reflexive and transitive reduction relation from P to
Q). A summarized explanation of the primitives and
the relevant reduction rules is given below:
Parallel Composition. Parallel execution is denoted
by a commutative and associative binary operator
2
,
which complies the rule:
2
The parallelism in ambient calculus is always inter-
preted via interleaving.
Table 1: The Mobility and Communication Primitives of
Ambient Calculus.
P,Q,R::= processes
P | Q parallel composition
n[ P ] an ambient named n with P in its body
(ν n)P restriction of name n within P
0 inactivity (skip process)
!P replication of P
M.P (capability) action M then P
(x).P input action (the input value is bound
to x in P)
hai async output action
M
1
.M
2
... .M
k
.P a path formation on actions then P
M::= capabilities
IN n entry capability (to enter n)
OUT n exit capability (to exit n)
OPEN n open capability (to dissolve n’s boundary)
P −−→ Q =⇒ P | R −−→ Q | R
Ambients. An ambient is written as n[P], where n is
its name and a process P is running inside its body (P
may be running even if n is moving):
P −−→ Q =⇒ n[ P ] −−→ n[ Q ]
Ambients can be embedded into each other such that
they can form a hierarchical tree structure. An ambi-
ent body is interpreted as the parallel composition of
its elements (its local ambients and its local agents)
and can be written as follows:
n[ P
1
| .. . | P
k
| m
1
[...] | . . .| m
l
[...] ] where P
i
6= m
i
[...]
Replication. !P denotes the unlimited replication of
the process P. It is equivalent to P | !P. There is no
reduction rule for !P (the term P under ! cannot start
until it is expanded out as P | !P).
(Name) Restriction. (ν n)P creates a new (unique)
name n within a scope P. n can be used to name am-
bients and to operate on ambients by name. The name
restriction is transparent to reduction:
P −−→ Q =⇒ (ν n)P −−→ (ν n)Q
Furthermore, one must be careful with the term
!(ν n)P, because it provides a fresh value for each
replica, so
(ν n)!P 6= !(ν n)P
Inactivity. 0 is the process that does nothing.
Actions and Capabilities. An action defined in the
calculus can precede a process P. P cannot start
to execute until the preceding actions are performed.
Those actions that are able to control the movements
of ambients in the hierarchy or to dissolve ambient
boundaries are restricted by capabilities. By using
capabilities an ambient can allow some processes to
AnAmbientASMModelforClient-to-ClientInteractionviaCloudComputing
461

perform certain operations without publishing its true
name to them (see the entry, exit and open below).
Communication Primitives. The input actions and
the asynchronous output actions can realize local
anonymous communication within ambients, e.g.:
(x).P | hai −−→ P(x/a)
where an input action captures the information a
available in its local environment and binds it to the
variable x within a scope P. In case of the model-
ing of a real life system, communication of (ambient)
names should be rather rare, since knowing the name
of an ambient gives a lot of control over it. Instead,
it should be common to exchange restricted capabili-
ties to control interactions between ambients (from a
capability the ambient name cannot be retrieved).
Entry Capability. The capability action IN m in-
structs the surrounding ambient to enter a sibling am-
bient named m. If a sibling ambient m does not exist,
the operation blocks until such a sibling appears. If
more than one sibling ambient called m can be found,
any of them can be chosen. The reduction rule for this
action is:
n[ IN m.P | Q ] | m[ R ] −−→ m[ n[ P | Q ] | R ]
Exit Capability. The capability action OUT m in-
structs the surrounding ambient to exit its parent am-
bient called m. If the parent is not named m, the opera-
tion blocks until such a parent appears. The reduction
rule is:
m[ n[ OUT m.p | Q ] | R ] −−→ n[ P | Q ] | m[ R ]
Open Capability. The capability action OPEN n dis-
solves the boundary of an ambient named n located
in the same ambient as OPEN n. If such an ambient
cannot be found in the local environment of OPEN n,
the operationblocks until an ambient called n appears.
The relevant rule is:
OPEN n.P | n[ Q ] −−→ P | Q
Path Formation on Actions. It is possible to com-
bine multiple actions (e.g.: capabilities and input ac-
tions). For this, a path formation operation is intro-
duced on actions (M
1
.M
2
... .M
k
). For example. (IN
n.IN m).P is interpreted as IN n.IN m.P (P does not
start to execute until the preceding capabilities are
performed).
3.2 Ambient ASM
In (B¨orger et al., 2012) the ambient concept (notion of
”nestable“ environments where computation can hap-
pen) is introduced into the ASM method. In that arti-
cle an ASM machine called MOBILEAGENTSMAN-
AGER is described as well, which gives a natural for-
mulation for the reduction of three basic capabilities
(ENTRY, EXIT and OPEN) of ambient calculus in
terms of the ambient ASM rules. For this machine an
ambient tree hierarchy is always specified initially in
a dynamic derived function called curAmbProc. The
machine MOBILEAGENTSMANAGER transforms the
current value of curAmbProc according to the capa-
bility actions given in curAmbProc. Since one of
the main goals of (B¨orger et al., 2012) is to reveal
the inherent opportunities of the new ambient concept
introduced into ASMs, the presented definitions for
moving ambients are unfortunately incomplete.
In (B´osa, 2012b) we extended this ASM machine
given in (B¨orger et al., 2012), such that it fully cap-
tures the calculus of mobile agents and it can interpret
the agents’ algorithms (given in terms of ASM syn-
tax in curAmbProc as well) in the corresponding con-
texts. By this one is able to describe formal models
of distributed systems including mobile components
in the mentioned two abstraction layers.
Since the definition of ambient ASM is based
upon the semantics of ASM without any changes,
each specification given this way can be translated
into a traditional ASM specification.
4 DEFINITIONS
As Cardelli and Gordon showed in (Cardelli and Gor-
don, 2000) the ambient calculus with the three ba-
sic capabilities (ENTRY, EXIT and OPEN) is power-
ful enough to be Turing-complete. But for facilitating
the specification of such a compound formal model
as a model of a cloud infrastructure, we defined some
new non-basic capability actions encoded in terms of
the three basic capabilities. Table 2 summarizes the
definitions of these non-basic capabilities.
4.1 Applied Notations
In the rest of this paper, the term P −−→
∗
Q denotes
multiple reduction. In addition, P
asm
−−→
∗
Q denotes one
or more steps of some ASM agents.
In the reductions presented in the latter sections,
the names of some ASM agents are followed by sub-
scripts which contain some enumerated expressions
between parenthesis. Such a subscript refers to (a
relevant part of) the current state of an agent, e.g.:
AGENT
(ctr
state:=RunningState, x:=a)
.
We also apply the following abbreviations:
M
1
. .. . M
n
≡ M
1
. . .. .M
n
.0 where 0 = inactivity
n[] ≡ n[0] where 0 = inactivity
(ν n
1
,.. . ,n
m
)P ≡ (ν n
1
)... (ν n
m
)P
ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies
462

Table 2: A Summary of the Definitions of some Non-Basic Capabilities.
Names New Reduction Relations (Based on the Definitions) Definitions of the New Capabilities
1) Renaming n[ n BE m.P | Q ] −−−→
∗
m[ P | Q ] n BE m.P ≡ (ν s)(s[ OUT n | m[ OPEN n.OUT s.P ] ] | IN s.IN m)
2) Seeing n[ ] | SEE n.P −−−→
∗
n[ ] | P SEE n.P ≡ (ν r, s)( r[ IN n.OUT n.r BE s.P ] | OPEN s )
3) Wrapping n[ m WRAP n.P ] −−−→
∗
m[ n[ P ] ] m WRAP n.P ≡
(ν s, r)( s[ OUT n.SEE n.s BE m.r[ IN n ] ] | IN s.OPEN r.P )
4) Allowing Code ALLOW key.P | key[ Q ] −−−→
∗
P | Q ALLOW key.P ≡ OPEN key.P
5) Drawing in m[ Q | ALLOW key ] | n[ n DRAWIN
key
m.P ] n DRAWIN
key
m.P ≡
(an Ambient) −−−→
∗
n[ Q | P ] key[ OUT n.IN m.IN n ] | ALLOW m.P
6) Drawing in m[ Q | ALLOW key ] | n DRAWIN
key
m THENRELEASE lock.P ≡
Then Release n[ DRAWIN
key
m THENRELEASE lock.P ] key[ OUT n.IN m.IN n ] | SEE m.lock WRAP n.ALLOW m.P
a Lock −−−→
∗
lock[ n[ Q | P ] ]
7) Concurrent SERVER
n
key
m.P ≡
Server m[ Q | ALLOW key ] | SERVER
n
key
m.P
(ν next)(next[ ] |
Process −−−→
∗
SERVER
n
key
m.P | n
uniq
k
[ Q | P ] !(ν n)(OPEN next.n[
n DRAWIN
key
m THENRELEASE next.P ] ) )
4.2 Non-Basic Capabilities
Below we give an informal description of each non-
basic capability in Table 2. It is beyond the scope of
the paper to present detailed explanations and reduc-
tions of their ambient calculus-based definitions, but
we refer to our former works (B´osa, 2013) and (B´osa,
2012a) for more details.
1. Renaming. This capability is applied to rename an
ambient comprising this capability. Such a capability
was already given in (Cardelli and Gordon, 2000), but
our definition differs from Cardelli’s definition. In the
original definition, the ambient m was not enclosed
into another, name restricted ambient (it is called s in
our definition), so after it has left ambient n, n may
enter into another ambient called m (if more than one
m exists as sibling of n).
2. Seeing. This operation was defined in (Cardelli and
Gordon, 2000) and it is used to detect the presence of
a given ambient.
3. Wrapping. Its aim is to pack an ambient compris-
ing this capability into another ambient.
4. Allowing Code. This capability is just a basic
OPEN capability action. It is applied if an ambient
allows/accepts an ambient construct (which may be a
bunch of foreign codes) contained by the body of one
of its sub-ambients (which may was sent from a for-
eign location). The name of the sub-ambient can be
applied for identifying its content, since its name may
be known only by some trusted parties.
5. Draw in (an Ambient) The aim of this capabil-
ity is to draw in a particular ambient (identified by
its name) into another ambient (which contains this
capability) and then to dissolve this captured ambi-
ent in order to access to its content. For achieving
this, a mechanism (contained by the ambient key) is
applied which can be regarded as an abstraction of a
kind of protocol identified by key. The ambient key
enters into one of the available target ambients which
should accept its content in order to be led into the
initiator ambient.
6. Draw in Then Release a Lock. This capability
is very similar to the previous one, but after m has
been captured by n (and before m is dissolved), n is
wrapped by another ambient. The new outer ambient
is usually employed as release for a lock
3
.
7. Concurrent Server Process. This ambient con-
struct can be regarded as an abstraction of a multi-
threaded server process. It is able to capture and
process several ambients having the same name in
parallel. In the definition n is a replicated ambient
whose each replica is going to capture another ambi-
ent called m. Since there is a name restriction quanti-
fier in the scope of the replication sign, which bounds
the name n, a new, fresh and unique name (denoted
by n
uniq
k
) is generated for each replica of n. One of
the consequences of this is that nobody knows from
outside the true name of a replica of the ambient n,
so each replica of n is inaccessible from outside for
anybody (even for another replica of n, too).
5 THE EXTENDED FORMAL
MODEL
In the formal model discussed in this section, we as-
sume that there are some standardized public ambi-
ent names, which are known by all contributors. We
distinguish the following kinds of public names: ad-
dresses (e.g.: cloud, client
1
, . .., client
n
), message
types (e.g.: reg(istration), request, subs(cription),
3
In ambient calculus the capability OPEN n.P is usually
used to encode locks (Cardelli and Gordon, 2000). Such a
lock can be released with an ambient like n[ Q ] whose name
corresponds with the target ambient of the OPEN capability.
AnAmbientASMModelforClient-to-ClientInteractionviaCloudComputing
463

returnValue, etc.) and parts of some common pro-
tocols (e.g.: lock, msg, int f, access, out, o
1
, ..., o
s
,
op). All other ambient names are non-public in the
model which follows:
curAmbProc := root[ Cloud | Client
1
|... | Client
n
]
4
In this paper, we focus on the cloud service side
and we leave the client side abstract.
5.1 User Actions
In the model user actions are encoded as messages. A
user can send the following kinds of messages to the
cloud:
MsgFrame ≡ msg[ IN cloud.ALLOW int f .content ]
where content can be:
RegMsg ≡ reg[ ALLOW CID.hUID
x
i ]
SubsMsg ≡ subs[ ALLOW CID.hUID
x
,SID
i
, pymti ]
RequestMsg ≡ request[ IN UID
x
|
o
i
[ ALLOW op.hclient
k
,args
i
i ] |
.
.
.
o
j
[ ALLOW op.hclient
k
,args
j
i ] ]
AddClMsg ≡ addCl[ IN UID
x
|
ALLOW CID.hclient
k
, path
l
,UID
(on client
l
)
i ]
AddChMsg ≡ addCh[ ALLOW CID.hUID
x
,cnamei ]
SubsToChMsg ≡ subsToCh[
ALLOW CID.hUID
x
,cname,uname,client
k
, pymti ]
ShareInfoMsg ≡ share[ IN CHID
i
|
ALLOW CID.hsndr,rcvr,infoi ]
ShareSvcMsg ≡ share[ IN CHID
i
| ALLOW CID.
hsndr,rcvr, info, o
i
,argsP, argsFi ]
In the definitions above: the ambient msg is the
frame of a message; the term IN cloud denotes the
address to where the message is sent; the term AL-
LOW int f allows a (server) mechanism on the tar-
get side which uses the public protocol int f to cap-
ture the message; and the content can be various kind
of message types. The term ALLOW CID denotes
that the messages are sent to a service of a particu-
lar cloud which identifies itself with the non-public
protocol/credential CID (stands for cloud identifier).
The first three kinds of messages were introduced
in the original model. In a RegistrationMsg the user
x provides her identifier UID
x
that she is going to use
in the cloud. By a SubscriptionMsg a user subscribes
to a cloud service identified by SID
i
; the information
4
The ambient called root is a special ambient which
is required for the ASM definition of ambient calculus,
see (B¨orger et al., 2012) and (B´osa, 2012b).
represented by pymt proves that the given user has
paid for the service properly.
Again, cloud services provide their functionalities
for their environment (users or other services) via ac-
tions called service operations in our model. In a
RequestMsg a user who has subscribed to some ser-
vices before can request the cloud to perform some
service operations belonging to some of these ser-
vices. o
i
and o
j
are the unique names of these ser-
vice operations and denote service operation requests;
client
k
is the identifer of a target location (usually a
client device) to where the output of a given opera-
tion should be sent by the cloud; and args
i
and args
j
are the arguments of the corresponding requested ser-
vice operations. Furthermore, the term IN UID
x
rep-
resents the address of the target user area within the
Cloud and ALLOW op denotes that the request will be
processed by a service plot, which expects service op-
eration requests (and which interacts with the request
via the public protocol op).
The rest of the message types is new in the model.
With AddClMsg a user can register a new possible
target (client) device or location for the outcomes of
the requests initiated by her. Such a message should
contain the chosen identifier client
k
of the new device,
the address path
l
of the device and the user identifier
UID
(on client
l
)
used on the given target device.
By AddChMsg users can open new channels, by
SubsToChMsg users can subscribe to channels and
by ShareInfoMsg and ShareSvcMsg users can share
information as well as service operations with some
other users registered in the same channel. For the de-
tailed description of the arguments lists of these last
four messages, see Section 5.3.1, Section 5.3.2 and
Section 5.3.3.
5.2 The Cloud Service Architecture
The basic structure of the defined cloud model, which
is based on the simplified Infrastructure as a Service
(IaaS) specification given in (B´osa, 2012b), is the fol-
lowing:
Cloud ≡ (ν f w, q, rescr
1
,... rescr
m
)cloud[
inter face |
fw [ rescr
1
[ service
1
] |...| rescr
l
[ service
1
] |
rescr
l+1
[ service
2
] |.. . | rescr
m
[ service
n
] |
q[ !OPEN msg |
BasicCloud functions | CTCI f unctions |
UID
x
[ userIntf ] |. . .| UID
y
[ userIntf ] |
UID
owner
v
[ ownerIntf ] |.. .| UID
owner
w
[ ownerIntf ]
] ] ]
where
inter face ≡ SERVER
n
intf
msg.IN f w.IN q.n BE msg
In the cloud definition above, the names of the
ambients f w, q and rescr
1
,.. .rescr
m
are bound by
ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies
464

name restriction. The consequence of this is that the
names of these ambients are known only within the
cloud service system, and therefore the contents of
their body are completely hidden and not accessible
at all from outside of the cloud. So each of them can
be regarded as an abstraction of a firewall protection.
The ambient expression represented by interface
“pulls in” into the area protected by the ambients fw
and q any ambient construct which is encompassed by
the message frame msg. The purpose of the restricted
ambients fw and q is to prevent any malicious content
which may cut loose in the body of q after a message
frame (msg) has been broken (by OPEN msg) to leave
the cloud together with some sensitive information.
For more details we refer to (B´osa, 2013).
The restricted ambients resrc
1
,.. ., resrc
m
, repre-
sent computational resources of the cloud. Within
each cloud resource some service instances can be
deployed. A service may have several deployed
instances in a cloud (see instances of service
1
in
resrc
1
,.. ., resrc
l
above).
Every user area is represented by an ambient
whose name corresponds to the corresponding user
identifier UID
i
. Furthermore, the user areas extended
with service owner role are denoted by UID
owner
i
. The
terms denoted by BasicCloud functions are responsi-
ble for cloud user registration and service subscrip-
tion. Finally the terms denoted by CTCI functions
encode the client-to-client interaction.
It is beyond the scope of this paper to describe
all parts of this model in details (e.g.: the structure
of service instances service
i
, functions of a service
owner area ownerIntf, the service plots and the ASM
agents in BasicCloud functions). For the specifica-
tion of these components, we refer to (B´osa, 2013).
5.2.1 User Access Layers
A user access layer (or user area) may contain
the following mechanisms: accepting user requests
(!ALLOW request), accepting new plots (!ALLOW
newPlot), accepting outputs of service operations
(!ALLOW returnValue) and some service plots.
userIntf ≡
!ALLOW request | !ALLOW newPlot | clientRegServer |
!ALLOW returnValue | sortingOutput |
PLOT
SID
i
|... | PLOT
SID
j
|
client
1
[ posting
client
1
] |.. . | client
k
[ posting
client
k
]
where
sortingOutput ≡ !(o, client, a).output[
IN client.ALLOW CID | ho, client, ai ] ]
clientRegServer ≡ SERVER
n
CID
addCl.
(client, path, UID).(n BE client | posting
client
)
posting
client
i
≡ SERVER
n
CID
output.(o, client, a).
OUT client
i
.forwardTo
client
i
.returnValue[
IN UID
(on client
i
)
| ho, client, ai ] ]
forwardTo
client
i
≡ n BE outgoingMsg.
OUT UID
x
.leavingCloud.path
i
leavingCloud ≡ OUT q.OUT fw.
OUT cloud.outgoingMsg BE msg
This paper extends the user areas with some new
functionalities. clientRegServer is applied to pro-
cess every AddClMsg sent by the corresponding user.
It creates new communication endpoint for target
(client) devices. Each such an endpoint is encoded by
an ambient whose name client
i
corresponds the given
identifier provided in a message AddClMsg. By these
endpoints outputs of service operations can immedi-
ately be directed to registered (client) devices after
they are available. Of course, if no target device or
a non-registered one is given in a RequestMsg, the
outcome will be stored in the area of the user.
Every service operation output, which is always
delivered within the body of an ambient called
returnValue, consists of three parts: the name of the
performed service operation, the identifier of a target
location to where the output should be sent back and
the outcome of the performed service operation itself.
sortingOutput distributes every service operation
output among the communication endpoints in an am-
bient called output, see Section 6. The mechanism
posting
client
i
, which resides in each such a commu-
nication endpoint, is responsible to wrap each output
of service operations which reaches the correspond-
ing endpoint again into an ambient returnValue and
to forward it to the specified userUID
(on client
i
)
on the
corresponding device client
i
.
5.3 Client-to-Client Interaction
Again, the client-to-client interaction in our model is
based on the constructs called channels. These are
represented by ambients with unique names denoted
by CHID
i
which contain some mechanisms whose
purpose is to share some information and service op-
erations among some subscribed users, see below:
CTCI f unctions ≡
CHID
1
[ channelInt f ] |.. .| CHID
l
[ channelInt f ] |
SERVER
n
CID
addCh.(UID, cname).
CHMGR(n, UID
x
, cname) |
SERVER
n
CID
subsToCh.(UID,cname,uname,client,pymt).
CHSUBSMGR(n,UID, cname, uname, client, pymt)
where
channelInt f ≡
SERVER
n
CID
share.(
(sndr, rcvr, info).hsndr,rcvr,info,undef,undef,undefi |
(sndr, rcvr, info, o, argsP, argsF).
SHARINGMGR(n, sndr, rcvr, info, o, argsP, argsF))
AnAmbientASMModelforClient-to-ClientInteractionviaCloudComputing
465

Every cloud user can create and own some chan-
nels by sending the message AddChMsg to the cloud,
where an instance of the ASM agent CHMGR, which
is equipped with a server mechanism, processes such
a request and creates a new ambient with unique
names for the requested channel, see Section 5.3.1.
If a user would like to subscribe to a channel
she should send the message SubsToChMsg to the
cloud. The server construct belongs to the ASM
agent CHSUBSMGR is responsible for processing
these messages, see Section 5.3.2. In the subscrip-
tion process the owner of the channel can decide
about the rights which can be assigned to a subscribed
user. According to the presented high-level model,
the employed access rights are encoded by the fol-
lowing static nullary functions: listening is a default
basic right, because everybody who joins to a chan-
nel can receive shared contents; sending authorizes a
user to send something to only one user at a time; and
broadcasting permits a user to distribute contents to
all member of the channel at once.
Both ShareIn foMsg and ShareSvcMsg are pro-
cessed by the same server which belongs to the ASM
agent SHARINGMGR and which is located in the body
of each ambient CHID
i
, see Section 5.3.3. In the
case of ShareInf oMsg the server first supplements
the arguments list of the message with three additional
undef values, such that it will have the same num-
ber of arguments as ShareSvcMsg has. Then an in-
stance of the ASM agent SHARINGMGR can process
the ShareInfoMsg similarly to ShareSvcMsg (the first
three arguments are the same for both messages).
5.3.1 Establishing a New Channel
CHMGR is a parameterized ASM agent, which ex-
pects UID of the cloud user who is going to create
a new channel and cname which is the name of this
channel as arguments. The additional argument n is
the unique name of an ambient which was provided
by the surrounding server construct and in which the
current AddChMsg is processed by an instance of this
agent (such an argument is also applied in the case of
the other ASM agents below).
First the agent checks whether the given UID has
already been registered on the cloud and whether the
given name cname has not been used as a name of an
existing channel yet (the unary function ownerOfCh
returns the value undef if there is no assigned owner
to this name). If it is the case, the agent generates
a new and unique identifier denoted by CHID for the
new channel with the usage of the function new which
provides a unique and completely fresh element for
the given set each time when it is applied. The ab-
stract ASM macro STORECHANNEL inserts into an
abstract database a new entry with all the details of
the new channel which are the channel identifier, the
channel name and the identifier of the owner.
Then it calls the abstract derived function create-
Channel, which creates an ambient calledCHID with
the terms denoted by channelInt f in its body which
encode the functions of the new channel. By the ab-
stract tree manipulation operation called NEWAMBI-
ENTCONSTRUCT
5
introduced in (B´osa, 2012b), this
generated ambient construct is placed into the ambi-
ent tree hierarchy as sibling of the agent.
CHMGR(n, UID, cname) ≡
ctr
state : {InitialState, EndState}
initially ctr
state := InitialState
if ctr
state = InitialState then
ctr
state := EndState
if UID ∈ userIds then
if ownerOfCh(cname) = undef then
let CHID = new(channelIds) in
STORECHANNEL(CHID,cname, UID)
let CHConstruct = createChannel( CHID ) in
NEWAMBIENTCONSTRUCT(CHConstruct)
where
CHConstruct ≡ CHID[ OUT n
| channelIntf ]
Although a channel is always created as a sibling
of the current instance of CHMGR, but as a first step it
leaves the ambient n which was provided by the sur-
rounding server construct and in which the message
was processed (see the underlined moving action in
CHConstruct above). After that it is prepared to serve
as a channel for client-to-client interaction (it is sup-
posed that the name cname of every channel is some-
how announced among the potential users).
5.3.2 Subscribing to a Channel
CHSUBSMGR is a parameterized ASM agent, which
expects the following as arguments: UID of the user
who is going to subscribe to the channel, cname
which is the name of the channel, uname is the name
that the user is going to use within the channel, client
which is the identifier of a registered client device to
where the shared content will be forwarded and pymt
which is some payment details if it is required. A user
can register to a channel with different names and var-
ious client devices in order to connect these devices
via the cloud.
First the agent checks whether the given UID and
cname have already been registered on the cloud and
whether the given uname has not been used as a name
of a member of the channel yet. If it is the case,
5
This is the only way how an ASM agent can make
changes in the ambient tree hierarchy contained by dynamic
derived function curAmbProc (B´osa, 2012b).
ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies
466

the agent informs the owner of the channel about
the new subscription by applying the abstract ASM
macro CONFIRMRIGHTS, who responses with a set of
access rights to the channel that she composed based
on the information given in the subscription.
CHSUBSMGR(n,UID,cname,uname,client,pymt) ≡
ctr
state : {InitialState, EndState}
initially ctr
state := InitialState
if ctr state = InitialState then
ctr
state := EndState
if UID ∈ userIds then
if ownerOfCh(cname) 6= undef then
if uname /∈ members(cname) then
let owner = ownerOfCh(cname) in
let rights =
CONFIRMRIGHTS(owner,uname,cname,pymt) in
if rights 6=
/
0 then
STOREMEMBER(UID,uname,client,cname,rights)
if rights 6= {listening} THEN
let CHID = idOfCh(cname) in
NEWAMBIENTCONSTRUCT( returnValue[
OUT n.IN UID
.hcname,client, IN CHIDi ] )
If the subscription has been accepted by the owner
and besides listening some other rights are granted to
the new user, an ambient construct is created and sent
as a message returnValue to the user by NEWAMBI-
ENTCONSTRUCT. This message contains the capabil-
ity IN CHID by which the new user can send mes-
sages called ShareInfoMsg and ShareSvcMsg into
the ambient CHID which represents the correspond-
ing channel (the owner of a channel also has to sub-
scribe in order to receive this information and to be
able to distribute content via the channel).
5.3.3 Sharing Information via a Channel
Every server construct in which the agent SHAR-
INGMGR is embedded is always located in an ambi-
ent which represents a particular channel and whose
name corresponds to the identifier of the channel. In
order to be able to perform its task, it is required that
each instance of SHARINGMGR knows by some static
nullary function called myChId the name of the am-
bient in which it is executed.
SHARINGMGR is a parameterized ASM agent,
which expects the following arguments: sndr is the
registered name of the sender, rcvr is either the reg-
istered name of a receiver or an asterisk “*”, info is
either the content of ShareInfoMsg or the descrip-
tion of a shared service operation in ShareSvcMsg.
The last three arguments are not used in the case of
the message ShareIn foMsg and the value undef is
assigned to each of them by the surrounding server
construct. In the message ShareSvcMsg o denotes the
unique identifier of the service operation that sndr is
going to share, argsP denotes the arguments of o that
rcvr can freely modify if she calls the operation and
argsF denotes those part of the argument list of o,
whose value is fixed by sndr.
The agent first generates a new and unique op-
eration identifier for the service operation o in the
control state InitialState. This new identifier which
is stored in the nullary location function shOp will
be announced to the channel member(s) specified in
rcvr. In the control state SharingState the agent
checks whether the sndr is a registered member of
the channel by calling the function members(cname).
Then if the given value of rcvr is equal to “*” the
agent broadcasts the content of the current message to
all members of the channel, see code branch bordered
by the first rectangular frame below. Otherwise if the
value of rcvr corresponds to the name of a particular
member of the channel, the agent sends the content of
the current message only to her, see the code branch
bordered by the second rectangular frame below.
SHARINGMGR(n, sndr, rcvr, info, o, argsP, argsF) ≡
ctr
state : {InitialState, SharingState, EndState}
initially ctr
state := InitialState
if ctr state = InitialState then
ctr
state := SharingState
if o 6= undef then //svc. sharing
let newOpId = new(sharedOpIds) in
shOp = newOpId
else shOp = undef //msg. sharing
if ctr
state = SharingState then
ctr
state := EndState
let cname = getChannelName(myChId) in
if sndr ∈ members(cname) then
let rights = getRights(cname, sndr) in
if rcvr = ”*“ then //broadcasting a msg.
if boradcasting ∈ rights then
forall M ∈ members(cname) do
let UID = getId(M), client = getAddress(M) in
if shOp = undef then
NEWAMBIENTCONSTRUCT( sharedM
content
1
)
else
NEWAMBIENTCONSTRUCT( sharedM
content
2
)
let UID
sndr
= getId(sndr) in
NEWAMBIENTCONSTRUCT( sharedPlot )
else //sending a msg.
if sending ∈ rights and rcvr ∈ members(cname)
then
let UID= getId(rcvr), client= getAddress(rcvr) in
if shOp = undef then
NEWAMBIENTCONSTRUCT( sharedM
content
1
)
else
NEWAMBIENTCONSTRUCT( sharedM
content
2
)
let UID
sndr
= getId(sndr) in
NEWAMBIENTCONSTRUCT( sharedPlot )
where
sharedM
content
i
≡ returnValue[
OUT n.OUT myChId.IN UID
.hcname,client, content
i
i ]
AnAmbientASMModelforClient-to-ClientInteractionviaCloudComputing
467

content
1
≡ {“sender:” sndr, “content:” info}
content
2
≡ {“sender:” sndr, “operation:” shOp,
“arguments:” argsP, “description:” info}
sharedPlot ≡
newPlot[ OUT n.OUT myChId.IN UID
| PLOT
shOp
]
PLOT
shOp
≡ SERVER
s
op
shOp.trigger
o
trigger
o
≡ (ν tmp)
(client, argsP).(OUT UID.IN UID
sndr
.s BE request |
o[ ALLOW op.htmp,(argsP\ argsF) + argsFi ] |
tmp[ ALLOW output | CID[ (o, c, a).OUT UID
sndr
.
IN UID.tmp BE returnValue.hshOp,client, ai ] ] )
Apart from the number of users to whom the in-
formation is sent the both code branches mentioned
above define the same actions. Accordingly at the
end of the processing of ShareInfoMsg the agent
sends to the member(s) specified in rcvr the message
sharedM
content
1
, which contains the sender sndr and
the shared information info.
At the end of the processing of ShareSvcMsg
two ambient constructs are created by NEWAMBI-
ENTCONSTRUCT. The first one is the message
sharedM
content
2
and it is sent to the member(s) speci-
fied in rcvr. It contains the sender sndr, the new op-
eration identifier shOp, the list of public arguments
argsP and the informal description of the shared op-
eration denoted by inf o.
The second ambient construct is the plot PLOT
shOp
enclosed by the ambient newPlot and equipped with
some additional ambient actions (see the underlined
capabilities in the definition of sharedPlot) which
move the entire construct into the user area of the
channel member(s) specified in rcvr, where the plot
will be accepted by the term !ALLOW newPlot.
The execution of the shared service operation
shOp can be requested in a usual RequestMsg as nor-
mal service operations. The PLOT
shOp
is a plot, which
can accept service operation requests for shOp several
times. It is special plot, because instead of triggering
the execution of shOp as in the case of a normal oper-
ation a normal plot does, see (B´osa, 2013), it converts
the original request to another request for operation
o by applying the term trigger
o
. This means that it
substitutes the operation identifier o for shOp, it com-
pletes its arguments list with argsF and it forwards
the request for o to the user area of the user sndr who
actually has access to trigger the execution of the op-
eration o, see Section 6.
To the new request the name restricted ambient
tmp is attached, whose purpose is similar to the com-
munication endpoints of registered clients. Namely, it
is placed into the user area of sndr temporary and it is
responsible to forward the outcome of this particular
request from the user area of sndr to the user area of
the user who initiated the request, see Section 6.
6 PROCESSING OF SHARED
SERVICES
In the following we present a draft of a reduction how
a particular request for a shared operation is processed
in our model. We assume that the user UID
sndr
has
already shared the service operation o
shared
i
with an-
other user called UID
x
. shOp is used as the shared
identifer of o
shared
i
. According to our example the user
UID
x
sends an operation request for shOp and ex-
pects to receive the outcome at the client device clnt
1
.
6.1 Triggering of Shared Operations
After a message RequestMsg has arrived at the re-
stricted cloud area protected by ambient fw and q and
the message frame msg has been dissolved, the ambi-
ent request enters into the user area which is identified
by UID
x
(see the numbered ambient actions in the de-
picted reduction outlines below):
Cloud | RequestMsg
= (ν fw, q, rescr
1
,... rescr
m
)cloud[
(2nd)
z
}| {
SERVER
n
intf
msg
.
(3rd)
z
}| {
IN fw.IN q.
(4th)
z
}| {
n BE msg |
fw [ rescr
1
[ service
1
] |...| rescr
i
[ service
1
] |
rescr
i+1
[ service
2
] |.. . | rescr
m
[ service
n
] |
q[
(5th)
z
}| {
! OPEN msg
|
BasicCloud functions | CTC functions |
UID
x
[ userIntf | PLOT
shOp
] |
UID
sndr
[ userIntf | PLOT
(o
shared
i
...)
] |
UID
owner
v
[ ownerIntf ]
] ] ] |
msg[
(1st)
z
}| {
IN cloud
.
(2nd)
z
}| {
ALLOW int f .request[
(6th)
z
}| {
IN UID
x
|
shOp[ ALLOW op.hclnt
1
,argsPi ] ] ]
After the ambient request has arrived at the ambi-
ent UID
x
, it is dissolved and PLOT
shOp
captures and
converts the request to another request for o
shared
i
:
−−→
∗
(ν f w, q, rescr
1
,... rescr
m
)cloud[
.
.
.
UID
x
[
(7th)
z
}| {
!ALLOW request
|
!ALLOW newPlot | clientRegServer |
!ALLOW returnValue | sortingOutput |
clnt
1
[ posting
clnt
1
] |
(8th)
z
}| {
SERVER
s
op
shOp
.
(9th)
z
}| {
trigger
o
shared
i
|
request[
shOp[
(8th)
z
}| {
ALLOW op
.hclnt
1
,argsPi ] ]
] ]
ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies
468

In the 8th step the bound names s and tmp, which lo-
cated under a replication sign in the server construct,
get new unique names, respectively (denoted as s
uniq
and tmp
uniq
in the rest). In the 9th step, the path for-
mation on (client, argsP).OUT UID.IN UID
sndr
is ap-
plied in trigger
o
shared
i
, which captures the given argu-
ments of the original request and forwards the ambi-
ent s
uniq
with the request for o
shared
i
in its body to the
user area of UID
sndr
.
The captured arguments will be changed in the
new request. Namely, the original target location
clnt
1
, to where the output of the request should be
sent, is replaced with tmp
uniq
. Furthermore, the argsP
which is given as set of identifiers to which some val-
ues are assigned is complemented with argsF which
is specified in the same way. In the term (argsP \
argsF) + argsF below, the employment of the set
difference of argsP and argsF ensures that the user
UID
x
cannot overwrite any fixed argument of o
shared
i
(even if she somehow knows the syntax of o
shared
i
).
After the ambient s
uniq
has arrived at the ambient
UID
sndr
it is renamed to request in the 10th step and
then it is processed as a normal request for o
shared
i
.
This means that the abstract plot PLOT
(o
shared
i
...)
into
which the current service operation request fits,
triggers the execution of o
shared
i
, for more details
see (B´osa, 2013). The only difference compared to
the processing of a normal request is that the ambient
tmp
uniq
is left behind in UID
sndr
:
−−→
∗
(ν fw, q, rescr
1
,.. . rescr
m
)cloud[
.
.
.
UID
sndr
[
(11th)
z
}| {
!ALLOW request
|
!ALLOW newPlot | clientRegServer |
!ALLOW returnValue | sortingOutput |
clnt
j
[ posting
clnt
j
] |
(12th)
z
}| {
PLOT
(o
shared
i
...)
|
s
uniq
[
(10th)
z
}| {
s
uniq
BE request
| o
shared
i
[
(12th)
z
}| {
ALLOW op
.
htmp
uniq
,(argsP \ argsF) + argsFi ] |
tmp
uniq
[ ALLOW output | CID[
(o, c, a).OUT UID
sndr
.IN UID
x
.
tmp
uniq
BE returnValue.hshOp, clnt
1
,ai ] ] ]
] ]
6.2 Redirecting the Outcome
The output for a service operation request is always
a triple which is always delivered within the body of
an ambient called returnValue and which consists of
three parts: the name of the performed service opera-
tion, the identifier of a target location to where the
output should be sent back and the outcome of the
performed service operation itself.
After the request has been processed by an in-
stance of the corresponding service located on one
of the cloud resources and the output of o
shared
i
has arrived at UID
sndr
, the mechanism denoted as
sortingOutput forwards the output in an ambient
called output to the given communication endpoint
of the specified target location, which is tmp
uniq
in
the current case, see the 14th, 15th and 16th steps:
−−→
∗
(ν f w, q, rescr
1
,...rescr
m
)cloud[
.
.
.
UID
sndr
[ !ALLOW request |
!ALLOW newPlot | clientRegServer |
(13th)
z
}| {
!ALLOW returnValue
|
(14th)
z }| {
!(o, client,a).output[
(15th)
z
}| {
IN client
.
(17th)
z }| {
ALLOW CID | ho, client, ai ] ] |
clnt
j
[ posting
clnt
j
] | PLOT
(o
shared
i
...)
|
tmp
uniq
[
(16th)
z
}| {
ALLOW output | CID[
(18th)
z
}| {
(o,c, a).
(19th)
z }| {
OUT UID
sndr
.IN UID
x
.
tmp
uniq
BE returnValue.hshOp,clnt
1
,ai ] ] |
returnValue[ ho
shared
i
,tmp
uniq
,outcomei ]
] ]
The ambient terms in tmp
uniq
capture the output
triple and set back the target location of the out-
put to clnt
1
and the performed operation to shOp;
then tmp
uniq
is moved with this new output triple
in its body to the user area of UID
x
, see the 18th
and 19th steps.
After the ambient tmp
uniq
has arrived at the ambi-
ent UID
x
, it will be renamed to returnValue, see the
20th step. Then the body of the ambient returnValue
will be processed similarly in the 21st, 22nd and 23rd
steps as before, but this time the output triple will be
redirected to the communication endpoint of clnt
1
by
the sortingOutput mechanism, see below:
−−→
∗
(ν f w, q, rescr
1
,... rescr
m
)cloud[
.
.
.
UID
x
[ !ALLOW request |
!ALLOW newPlot | clientRegServer |
(21st)
z
}| {
!ALLOW returnValue
|
(22nd)
z
}| {
!(o,client,a)
.output[
(23rd)
z
}| {
IN client
.
(24th)
z
}| {
ALLOW CID
| ho, client, ai ] ] |
clnt
1
[
(24th)
z
}| {
posting
clnt
1
] |
SERVER
s
op
shOp.trigger
o
shared
i
|
AnAmbientASMModelforClient-to-ClientInteractionviaCloudComputing
469

tmp
uniq
[
(20th)
z
}| {
tmp
uniq
BE returnValue
.
hshOp,clnt
1
,outcomei ]
] ]
Then in the 24th step the functionality denoted by
posting
clnt
1
send the output triple to the client device
clnt
1
, where only the user who initiated the request
can access to it (via the user identifier UID
(on clnt
1
)
).
7 CONCLUSIONS
In this paper we extended our formerly given cloud
model with the high-level formal definitions of some
client-to-client interaction functions, by which not
only information, but cloud service functions can be
also shared among the cloud users. Our approach is
general enough to manage situation in which a user
who has access to a shared service operation to share
it again with some other users via a channel (who in
turn may share it again, etc.).
Furthermore, if we apply the scenario proposed
in Section 2 and depicted on Figure 1b, according
to which we shift (among others) the client-to-client
functionality to client side and wrap into a middle-
ware, then no traces of the user activities belonging to
the shared services will be left on the cloud, since all
the service operations which are shared via a chan-
nel are used on behalf of its initial distributor. This
consideration can lead one step into the direction of
anonym usage of cloud services. The consequence of
this that if a cloud user who has contracts with some
service providers completely or partially shares some
services via a channel, then she should be aware of
the fact that all generated costs caused by the usage
of these shared services will be allocated to her.
ACKNOWLEDGEMENTS
This research has been supported by the Christian
Doppler Society.
REFERENCES
B¨orger, E., Cisternino, A., and Gervasi, V. (2012). Ambi-
ent Abstract State Machines with Applications. J.CSS
(Special Issue in honor of Amir Pnueli), 78(3):939–
959.
B¨orger, E. and Stark, R. F. (2003). Abstract State Machines:
A Method for High-Level System Design and Analysis.
Springer-Verlag New York, Inc., Secaucus, NJ, USA.
B´osa, K. (2012a). A Formal Model of a Cloud Service Ar-
chitecture in Terms of Ambient ASM. Technical re-
port, Christian Doppler Laboratory for Client-Centric
Cloud Computing (CDCC), Johannes Kepler Univer-
sity Linz, Austria.
B´osa, K. (2012b). Formal Modeling of Mobile Computing
Systems Based on Ambient Abstract State Machines.
Semantics in Data and Knowledge Bases, 7693 of
LNCS:18–49.
B´osa, K. (2013). An Ambient ASM Model for Cloud Ar-
chitectures. Formal Aspects of Computing. Submitted.
Boudol, G., Castellani, I., Hennessy, M., and Kiehn,
A. (1994). A Theory of Processes with Local-
ities. Formal Aspects of Computing, 6:165–200.
10.1007/BF01221098.
Cardelli, L. (1999). Mobility and Security. In Bauer, F. L.
and Steinbr¨uggen, R., editors, Foundations of Secure
Computation Proc. NATO Advanced Study Institute,
pages 3–37. IOS Press. Lecture Notes for Markto-
berdorf Summer School 1999 (A summary of several
Ambient Calculus papers).
Cardelli, L. and Gordon, A. D. (2000). Mobile Ambients.
Theor. Comput. Sci., 240(1):177–213.
Kozen, D. (1997). Kleene Algebra with Tests. Transactions
on Programming Languages and Systems, 19(3):427–
443.
Ma, H., Schewe, K.-D., Thalheim, B., and Wang, Q. (2008).
Abstract State Services. In Object-Oriented and
Entity-Relationship Modelling/International Confer-
ence on Conceptual Modeling / the Entity Relation-
ship Approach, pages 406–415.
Ma, H., Schewe, K.-D., Thalheim, B., and Wang, Q. (2009).
A Theory of Data-Intensive Software Services. Ser-
vice Oriented Computing and Applications, 3(4):263–
283.
Ma, H., Schewe, K.-D., Thalheim, B., and Wang, Q. (2012).
A Formal Model for the Interoperability of Service
Clouds. Service-Oriented Computing and Applica-
tions. To appear.
Milner, R., Parrow, J., and Walker, D. (1992). A Calculus
of Mobile Processes, Parts I. and II. Information and
Computation, 100(1):1–77.
Schewe, K.-D. and Thalheim, B. (2007). Personalisation
of Web Information Systems - A Term Rewriting Ap-
proach. Data & Knowledge Engineering, 62(1):101 –
117.
Tanaka, Y. (2003). Meme Media and Meme Market Archi-
tectures: Knowledge Media for Editing, Distributing,
and Managing Intellectual Resources. Wiley.
ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies
470