A Dynamic and Policy-Controlled Approach to Federating Information Systems

Massimiliano Marcon, Niranjan Suri, Andrzej Uszock, Maggie Breedy, Jeffrey M. Bradshaw, Marco Carvalho, James Hanna, Asher Sinclair, Vaughn Combs

Summary

»  SCENARIO   Information Systems   The need for Federation

»  OUR APPROACH TO FEDERATION

  Federation Architecture: Overview   Federation Architecture: Key Components   Federation in action   Adaptation mechanism   Policy management

»  EXPERIMENTAL EVALUATION

  Test case   Results

SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

Information Systems SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

»  Essential to ensuring the successful execution of any military mission.

»  Traditionally information management was supported by heterogeneous systems → Hard to integrate to support information sharing among

coalition forces. »  US Air Force Research Lab tried to address this problem

→ Joint Battlespace Infosphere (JBI) and Phoenix specifications as standard for information management architectures.

→ Publish/Subscribe/Query model.

The need for Federation SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

»  A common information management model still does not address the need for information sharing.

»  Federation supports the interconnection of multiple, independently managed information spaces.

Federation Architecture: Overview

»  Support for seamless and secure integration of multiple information spaces.   Seamless: transparent to clients   Secure: federation workflow regulated via policies

»  P2P approach: each federate manages its connection with other federates and has its own set of policies.

SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

Federation Architecture: Key Components

»  Federation Service: handles all the information sharing and federation management operations:   Handles discovery process

➞ DISCOVERY MANAGER COMPONENT

  Manages the connections with remote federates ➞ REMOTE FEDERATION SERVICE PROXY & REMOTE REQUEST HANDLER COMPONENTS

  Forwards the information from the local IMS to the remote federates and vice versa.

  Handles the adaptation mechanism ➞ ADAPTATION MANAGER COMPONENTS

  Entirely governed by policies

»  Monitoring Service: provides system-level monitoring and supports federation-level monitoring

SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

Federation in Action

»  Federation Establishment 1. Discovery Manager registers with sub-layer with discovery and grouping capabilities. 2. Federation Group is created. Any IMS that joins the group becomes a potential

federate. 3. Federates are notified about the presence of other federates. The notification

triggers the beginning of a handshake phase. 4. Federates negotiate contracts. Upon contract acceptance by the federates the

federation is established.

SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

XLayer Substrate

IMSA

Discovery Manager

IMSB

Discovery Manager

»  Federation Establishment 1. Discovery Manager registers with sub-layer with discovery and grouping capabilities. 2. Federation Group is created. Any IMS that joins the group becomes a potential

federate. 3. Federates are notified about the presence of other federates. The notification

triggers the begin of a handshake phase. 4. Federates negotiate contracts. Upon contract acceptance by the federates the

federation is established.

Federation in Action SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

Federation Group

XLayer Substrate

IMSA

Discovery Manager

IMSB

Discovery Manager

»  Federation Establishment 1. Discovery Manager registers with sub-layer with discovery and grouping capabilities. 2. Federation Group is created. Any IMS that joins the group becomes a potential

federate. 3. Federates are notified about the presence of other federates. The notification

triggers the begin of a handshake phase. 4. Federates negotiate contracts. Upon contract acceptance by the federates the

federation is established.

Federation in Action SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

Federation Group

XLayer Substrate

IMSA

Discovery Manager

IMSB

Discovery Manager

Handshake

»  Federation Establishment 1. Discovery Manager registers with sub-layer with discovery and grouping capabilities. 2. Federation Group is created. Any IMS that joins the group becomes a potential

federate. 3. Federates are notified about the presence of other federates. The notification

triggers the begin of a handshake phase. 4. Federates negotiate contracts. Upon contract acceptance by the federates the

federation is established.

Federation in Action SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

Federation Group

XLayer Substrate

FEDA

Discovery Manager

FEDB

Discovery Manager

FEDERATION

RFSP

RFSP

»  Subscription Forwarding 1. A Subscriber Client issues a subscription with FEDA. 2. Federation Service in FEDA captures the request, and forwards it to FEDB by selecting

the appropriate Remote Federation Service Proxy (RFSP). 3. FEDB receives the subscription and stores it in a Remote Subscriptions Table, ready to

be matched against its local publications.

Federation in Action SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

Federation Group

XLayer Substrate

FEDA FEDB

Remote Subs Table

FEDERATION

RFSP

Subscriber

RFSP

»  Subscription Forwarding 1. A Subscriber Client issues a subscription with FEDA. 2. Federation Service in FEDA captures the request, and forwards it to FEDB by selecting

the appropriate Remote Federation Service Proxy (RFSP). 3. FEDB receives the subscription and stores it in a Remote Subscriptions Table, ready to

be matched against its local publications.

Federation in Action SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

Federation Group

XLayer Substrate

FEDA FEDB

Remote Subs Table FEDERATION

RFSP

Subscriber

RFSP

»  Subscription Forwarding 1. A Subscriber Client issues a subscription with FEDA. 2. Federation Service in FEDA captures the request, and forwards it to FEDB by selecting

the appropriate Remote Federation Service Proxy (RFSP). 3. FEDB receives the subscription and stores it in a Remote Subscriptions Table, ready to

be matched against its local publications.

Federation in Action SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

Federation Group

XLayer Substrate

FEDA FEDB

Remote Subs Table FEDERATION

RFSP

Subscriber

RFSP

»  Publication Handling 1. A Publisher Client publishes information to FEDB. 2. FEDB attempts to execute the predicate matching locally, using the Remote

Subscriptions Table. 3. Matching publications are sent to FEDA using the appropriate RFSP. 4. FEDA receives the information and forwards it to the IMS for delivery.

Federation in Action SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

Federation Group

XLayer Substrate

FEDA FEDB

Remote Subs Table

FEDERATION

RFSP

Subscriber

RFSP

Publisher

»  Publication Handling 1. A Publisher Client publishes information to FEDB. 2. FEDB attempts to execute the predicate matching locally, using the Remote

Subscriptions Table. 3. Matching publications are sent to FEDA using the appropriate RFSP. 4. FEDA receives the information and forwards it to the IMS for delivery.

Federation in Action SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

Federation Group

XLayer Substrate

FEDA FEDB

Remote Subs Table

FEDERATION

RFSP

Subscriber

RFSP

Publisher

»  Publication Handling 1. A Publisher Client publishes information to FEDB. 2. FEDB attempts to execute the predicate matching locally, using the Remote

Subscriptions Table. 3. Matching publications are sent to FEDA using the appropriate RFSP. 4. FEDA receives the information and forwards it to the IMS for delivery.

Federation in Action SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

Federation Group

XLayer Substrate

FEDA FEDB

Remote Subs Table FEDERATION

RFSP

Subscriber

RFSP

Publisher

»  Publication Handling 1. A Publisher Client publishes information to FEDB. 2. FEDB attempts to execute the predicate matching locally, using the Remote

Subscriptions Table. 3. Matching publications are sent to FEDA using the appropriate RFSP. 4. FEDA receives the information and forwards it to the IMS for delivery.

Federation in Action SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

Federation Group

XLayer Substrate

FEDA FEDB

Remote Subs Table FEDERATION

RFSP

Subscriber

RFSP

Publisher

»  Federation Termination 1.  One of the nodes dies or lives the group. 2.  The other node is notified about these events and cleans up any

references to the former remote federate.

Federation in Action SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

Federation Group

XLayer Substrate

FEDA

Discovery Manager

FEDB

Discovery Manager

FEDERATION

RFSP

»  Federation Termination 1.  One of the nodes dies or lives the group. 2.  The other node is notified about these events and cleans up any

references to the former remote federate.

Federation in Action SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

Federation Group

XLayer Substrate

IMSA

Discovery Manager

IMSB

Discovery Manager

Policy management

»  The operational behavior described is entirely governed by policies.

»  Before taking any action, Federation Service verifies with the policy framework whether the operation is allowed and if there is any restriction.

»  Policies regulate:   Whether to establish a federation with the remote federate   Priorities assigned to remote federates   Resource allocation per remote federate   Type of subscriptions and queries supported per remote federates

»  Federation Service uses the KAoS Policy Service for the specification, management, conflict resolution and enforcement of policies.

SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

Adaptation mechanism

»  The behavior of federation adapts to the resource availability.

  Adaptation to CPU Overload ➞ Triggered when CPU load is above a predefined threshold.

➞ Predicate matching disabled, based on hit-rate

  Adaptation to Low Bandwidth ➞ Triggered in situations of network overload

➞ Remote Subscription are disabled, based on priority

»  Monitoring Service provides all the metrics that are necessary for the decision making (CPU, bandwidth utilization per federate, predicate hit-rate)

SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

Test case

»  Goal: measure the overhead (in terms of throughput) from adding federation capabilities to a base IMS.

»  IMS implementations: Apollo and Phoenix. »  Setup:

SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

IMSA

Subscriber1 Subscriber2 Publisher

BASELINE

IMSB

Subscriber1 Subscriber2 Publisher

WITHFEDERATION

IMSA

Experimental results

265.29

137.63

45.22

31.19

265.29

137.55

45.31

30.97

322.09

327.80

42.10

29.20

0 50 100 150 200 250 300 350

Phoenix with Federation

Phoenix Baseline

Apollo with Federation

Apollo Baseline

Publisher Throughput

Subscriber 1 Troughput

Subscriber 2 Troughput

SUMMARY – SCENARIO – OUR APPROACH TO FEDERATION – EXPERIMENTAL EVALUATION

InformaAonObjects/second

Thank you for your attention.

This research project was sponsored by the US Air Force Research Laboratory