Information Technology Reference
In-Depth Information
he goes to the Andago website to play a game. Provided he has a valid account, he
can log into Andago's web portal which manages users, games, and online commu-
nities. On the richly-enabled website, the user can choose a game he wishes to
play. Andago decides to advertise certain game titles depending on agreements with
game title publishers. Up to this point, all interactions take part solely between
Andago and the end user and therefore neither the VHE nor its enabling B2B gate-
ways are in play. However the richness of Andago's offering is a direct consequence
of its ability to form dynamic collaborations with different provider. Once the player
has selected a game, e.g. EnemyTerritory, he can choose a match to take part in. This
is where the VHE and the B2B gateways kick in. A match is in fact a given specific
VO with a virtualized exposed application instance for one of the game servers (GS)
selected e.g. either Sunny or Saygah.
Once the player has selected a match, Andago will kick-start the virtualiza-
tion of its own client application which liaises between the Andago platform and
the hosting environment's virtualized service. In this scenario, Andago exposes a
management client called Agasy. Therefore at this stage Andago is virtualising and
exposing a contextualized instance of the Agasy at its B2B gateway. The Agasy
instance will be exchanging management and monitoring messages with the virtu-
alized game watcher instance at either Sunny or Saygah. This watcher continuously
monitors the state of the running game instance on the host server and sends back
gaming operation statistics to the Agasy instance. Every time the client instance
running behind Andago's B2B gateway makes a call to the virtualized watcher
instance at either Sunny or Saygah, the request goes:
• through Andago's gateway where
-
it is checked and decorated with the appropriate virtual identity (e.g., a
SAML token) issued by the SOI-STS for the given instance
-
checked against client-side authorization rules
-
encrypted for transport between the partners' gateways
-
sent to the partner's gateway, i.e. Sunny or Saygah
• through the receiving partner's gateway where
-
the SAML token is extracted and sent to the STS for validation
-
the STS validates the virtual identity (SAML token) and returns the associ-
ated identity attributes for the given requestor
-
the gateway decrypts the message
-
the gateway requests an authorization decision from the SOI-AuthZ-PDP
based on the XACML attributes extracted from the SAML token and based
on the originating client and targeted service
-
the gateway forwards the request to the internal service i.e. the watcher
During the execution of the sequence of these interactions, the relevant infra-
structure services, in particular the SOI-SMG and the application instances, feed
events into the SLA monitoring services in order to evaluate the status of the infra-
structure and to determine whether any service provider is breaching the agreed
contract.
