Welcome to TiddlyWiki created by Jeremy Ruston, Copyright © 2007 UnaMesa Association
<!--{{{-->
<link rel='alternate' type='application/rss+xml' title='RSS' href='index.xml' />
<!--}}}-->
Background: #fff
Foreground: #000
PrimaryPale: #8cf
PrimaryLight: #18f
PrimaryMid: #04b
PrimaryDark: #014
SecondaryPale: #ffc
SecondaryLight: #fe8
SecondaryMid: #db4
SecondaryDark: #841
TertiaryPale: #eee
TertiaryLight: #ccc
TertiaryMid: #999
TertiaryDark: #666
Error: #f88
/*{{{*/
body {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}
a {color:[[ColorPalette::PrimaryMid]];}
a:hover {background-color:[[ColorPalette::PrimaryMid]]; color:[[ColorPalette::Background]];}
a img {border:0;}
h1,h2,h3,h4,h5,h6 {color:[[ColorPalette::SecondaryDark]]; background:transparent;}
h1 {border-bottom:2px solid [[ColorPalette::TertiaryLight]];}
h2,h3 {border-bottom:1px solid [[ColorPalette::TertiaryLight]];}
.button {color:[[ColorPalette::PrimaryDark]]; border:1px solid [[ColorPalette::Background]];}
.button:hover {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::SecondaryLight]]; border-color:[[ColorPalette::SecondaryMid]];}
.button:active {color:[[ColorPalette::Background]]; background:[[ColorPalette::SecondaryMid]]; border:1px solid [[ColorPalette::SecondaryDark]];}
.header {background:[[ColorPalette::PrimaryMid]];}
.headerShadow {color:[[ColorPalette::Foreground]];}
.headerShadow a {font-weight:normal; color:[[ColorPalette::Foreground]];}
.headerForeground {color:[[ColorPalette::Background]];}
.headerForeground a {font-weight:normal; color:[[ColorPalette::PrimaryPale]];}
.tabSelected{color:[[ColorPalette::PrimaryDark]];
background:[[ColorPalette::TertiaryPale]];
border-left:1px solid [[ColorPalette::TertiaryLight]];
border-top:1px solid [[ColorPalette::TertiaryLight]];
border-right:1px solid [[ColorPalette::TertiaryLight]];
}
.tabUnselected {color:[[ColorPalette::Background]]; background:[[ColorPalette::TertiaryMid]];}
.tabContents {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::TertiaryPale]]; border:1px solid [[ColorPalette::TertiaryLight]];}
.tabContents .button {border:0;}
#sidebar {}
#sidebarOptions input {border:1px solid [[ColorPalette::PrimaryMid]];}
#sidebarOptions .sliderPanel {background:[[ColorPalette::PrimaryPale]];}
#sidebarOptions .sliderPanel a {border:none;color:[[ColorPalette::PrimaryMid]];}
#sidebarOptions .sliderPanel a:hover {color:[[ColorPalette::Background]]; background:[[ColorPalette::PrimaryMid]];}
#sidebarOptions .sliderPanel a:active {color:[[ColorPalette::PrimaryMid]]; background:[[ColorPalette::Background]];}
.wizard {background:[[ColorPalette::PrimaryPale]]; border:1px solid [[ColorPalette::PrimaryMid]];}
.wizard h1 {color:[[ColorPalette::PrimaryDark]]; border:none;}
.wizard h2 {color:[[ColorPalette::Foreground]]; border:none;}
.wizardStep {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];
border:1px solid [[ColorPalette::PrimaryMid]];}
.wizardStep.wizardStepDone {background:[[ColorPalette::TertiaryLight]];}
.wizardFooter {background:[[ColorPalette::PrimaryPale]];}
.wizardFooter .status {background:[[ColorPalette::PrimaryDark]]; color:[[ColorPalette::Background]];}
.wizard .button {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::SecondaryLight]]; border: 1px solid;
border-color:[[ColorPalette::SecondaryPale]] [[ColorPalette::SecondaryDark]] [[ColorPalette::SecondaryDark]] [[ColorPalette::SecondaryPale]];}
.wizard .button:hover {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::Background]];}
.wizard .button:active {color:[[ColorPalette::Background]]; background:[[ColorPalette::Foreground]]; border: 1px solid;
border-color:[[ColorPalette::PrimaryDark]] [[ColorPalette::PrimaryPale]] [[ColorPalette::PrimaryPale]] [[ColorPalette::PrimaryDark]];}
.wizard .notChanged {background:transparent;}
.wizard .changedLocally {background:#80ff80;}
.wizard .changedServer {background:#8080ff;}
.wizard .changedBoth {background:#ff8080;}
.wizard .notFound {background:#ffff80;}
.wizard .putToServer {background:#ff80ff;}
.wizard .gotFromServer {background:#80ffff;}
#messageArea {border:1px solid [[ColorPalette::SecondaryMid]]; background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]];}
#messageArea .button {color:[[ColorPalette::PrimaryMid]]; background:[[ColorPalette::SecondaryPale]]; border:none;}
.popupTiddler {background:[[ColorPalette::TertiaryPale]]; border:2px solid [[ColorPalette::TertiaryMid]];}
.popup {background:[[ColorPalette::TertiaryPale]]; color:[[ColorPalette::TertiaryDark]]; border-left:1px solid [[ColorPalette::TertiaryMid]]; border-top:1px solid [[ColorPalette::TertiaryMid]]; border-right:2px solid [[ColorPalette::TertiaryDark]]; border-bottom:2px solid [[ColorPalette::TertiaryDark]];}
.popup hr {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::PrimaryDark]]; border-bottom:1px;}
.popup li.disabled {color:[[ColorPalette::TertiaryMid]];}
.popup li a, .popup li a:visited {color:[[ColorPalette::Foreground]]; border: none;}
.popup li a:hover {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; border: none;}
.popup li a:active {background:[[ColorPalette::SecondaryPale]]; color:[[ColorPalette::Foreground]]; border: none;}
.popupHighlight {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}
.listBreak div {border-bottom:1px solid [[ColorPalette::TertiaryDark]];}
.tiddler .defaultCommand {font-weight:bold;}
.shadow .title {color:[[ColorPalette::TertiaryDark]];}
.title {color:[[ColorPalette::SecondaryDark]];}
.subtitle {color:[[ColorPalette::TertiaryDark]];}
.toolbar {color:[[ColorPalette::PrimaryMid]];}
.toolbar a {color:[[ColorPalette::TertiaryLight]];}
.selected .toolbar a {color:[[ColorPalette::TertiaryMid]];}
.selected .toolbar a:hover {color:[[ColorPalette::Foreground]];}
.tagging, .tagged {border:1px solid [[ColorPalette::TertiaryPale]]; background-color:[[ColorPalette::TertiaryPale]];}
.selected .tagging, .selected .tagged {background-color:[[ColorPalette::TertiaryLight]]; border:1px solid [[ColorPalette::TertiaryMid]];}
.tagging .listTitle, .tagged .listTitle {color:[[ColorPalette::PrimaryDark]];}
.tagging .button, .tagged .button {border:none;}
.footer {color:[[ColorPalette::TertiaryLight]];}
.selected .footer {color:[[ColorPalette::TertiaryMid]];}
.sparkline {background:[[ColorPalette::PrimaryPale]]; border:0;}
.sparktick {background:[[ColorPalette::PrimaryDark]];}
.error, .errorButton {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::Error]];}
.warning {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::SecondaryPale]];}
.lowlight {background:[[ColorPalette::TertiaryLight]];}
.zoomer {background:none; color:[[ColorPalette::TertiaryMid]]; border:3px solid [[ColorPalette::TertiaryMid]];}
.imageLink, #displayArea .imageLink {background:transparent;}
.annotation {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; border:2px solid [[ColorPalette::SecondaryMid]];}
.viewer .listTitle {list-style-type:none; margin-left:-2em;}
.viewer .button {border:1px solid [[ColorPalette::SecondaryMid]];}
.viewer blockquote {border-left:3px solid [[ColorPalette::TertiaryDark]];}
.viewer table, table.twtable {border:2px solid [[ColorPalette::TertiaryDark]];}
.viewer th, .viewer thead td, .twtable th, .twtable thead td {background:[[ColorPalette::SecondaryMid]]; border:1px solid [[ColorPalette::TertiaryDark]]; color:[[ColorPalette::Background]];}
.viewer td, .viewer tr, .twtable td, .twtable tr {border:1px solid [[ColorPalette::TertiaryDark]];}
.viewer pre {border:1px solid [[ColorPalette::SecondaryLight]]; background:[[ColorPalette::SecondaryPale]];}
.viewer code {color:[[ColorPalette::SecondaryDark]];}
.viewer hr {border:0; border-top:dashed 1px [[ColorPalette::TertiaryDark]]; color:[[ColorPalette::TertiaryDark]];}
.highlight, .marked {background:[[ColorPalette::SecondaryLight]];}
.editor input {border:1px solid [[ColorPalette::PrimaryMid]];}
.editor textarea {border:1px solid [[ColorPalette::PrimaryMid]]; width:100%;}
.editorFooter {color:[[ColorPalette::TertiaryMid]];}
#backstageArea {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::TertiaryMid]];}
#backstageArea a {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::Background]]; border:none;}
#backstageArea a:hover {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; }
#backstageArea a.backstageSelTab {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}
#backstageButton a {background:none; color:[[ColorPalette::Background]]; border:none;}
#backstageButton a:hover {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::Background]]; border:none;}
#backstagePanel {background:[[ColorPalette::Background]]; border-color: [[ColorPalette::Background]] [[ColorPalette::TertiaryDark]] [[ColorPalette::TertiaryDark]] [[ColorPalette::TertiaryDark]];}
.backstagePanelFooter .button {border:none; color:[[ColorPalette::Background]];}
.backstagePanelFooter .button:hover {color:[[ColorPalette::Foreground]];}
#backstageCloak {background:[[ColorPalette::Foreground]]; opacity:0.6; filter:'alpha(opacity=60)';}
/*}}}*/
/*{{{*/
* html .tiddler {height:1%;}
body {font-size:.75em; font-family:arial,helvetica; margin:0; padding:0;}
h1,h2,h3,h4,h5,h6 {font-weight:bold; text-decoration:none;}
h1,h2,h3 {padding-bottom:1px; margin-top:1.2em;margin-bottom:0.3em;}
h4,h5,h6 {margin-top:1em;}
h1 {font-size:1.35em;}
h2 {font-size:1.25em;}
h3 {font-size:1.1em;}
h4 {font-size:1em;}
h5 {font-size:.9em;}
hr {height:1px;}
a {text-decoration:none;}
dt {font-weight:bold;}
ol {list-style-type:decimal;}
ol ol {list-style-type:lower-alpha;}
ol ol ol {list-style-type:lower-roman;}
ol ol ol ol {list-style-type:decimal;}
ol ol ol ol ol {list-style-type:lower-alpha;}
ol ol ol ol ol ol {list-style-type:lower-roman;}
ol ol ol ol ol ol ol {list-style-type:decimal;}
.txtOptionInput {width:11em;}
#contentWrapper .chkOptionInput {border:0;}
.externalLink {text-decoration:underline;}
.indent {margin-left:3em;}
.outdent {margin-left:3em; text-indent:-3em;}
code.escaped {white-space:nowrap;}
.tiddlyLinkExisting {font-weight:bold;}
.tiddlyLinkNonExisting {font-style:italic;}
/* the 'a' is required for IE, otherwise it renders the whole tiddler in bold */
a.tiddlyLinkNonExisting.shadow {font-weight:bold;}
#mainMenu .tiddlyLinkExisting,
#mainMenu .tiddlyLinkNonExisting,
#sidebarTabs .tiddlyLinkNonExisting {font-weight:normal; font-style:normal;}
#sidebarTabs .tiddlyLinkExisting {font-weight:bold; font-style:normal;}
.header {position:relative;}
.header a:hover {background:transparent;}
.headerShadow {position:relative; padding:4.5em 0 1em 1em; left:-1px; top:-1px;}
.headerForeground {position:absolute; padding:4.5em 0 1em 1em; left:0px; top:0px;}
.siteTitle {font-size:3em;}
.siteSubtitle {font-size:1.2em;}
#mainMenu {position:absolute; left:0; width:10em; text-align:right; line-height:1.6em; padding:1.5em 0.5em 0.5em 0.5em; font-size:1.1em;}
#sidebar {position:absolute; right:3px; width:16em; font-size:.9em;}
#sidebarOptions {padding-top:0.3em;}
#sidebarOptions a {margin:0 0.2em; padding:0.2em 0.3em; display:block;}
#sidebarOptions input {margin:0.4em 0.5em;}
#sidebarOptions .sliderPanel {margin-left:1em; padding:0.5em; font-size:.85em;}
#sidebarOptions .sliderPanel a {font-weight:bold; display:inline; padding:0;}
#sidebarOptions .sliderPanel input {margin:0 0 0.3em 0;}
#sidebarTabs .tabContents {width:15em; overflow:hidden;}
.wizard {padding:0.1em 1em 0 2em;}
.wizard h1 {font-size:2em; font-weight:bold; background:none; padding:0; margin:0.4em 0 0.2em;}
.wizard h2 {font-size:1.2em; font-weight:bold; background:none; padding:0; margin:0.4em 0 0.2em;}
.wizardStep {padding:1em 1em 1em 1em;}
.wizard .button {margin:0.5em 0 0; font-size:1.2em;}
.wizardFooter {padding:0.8em 0.4em 0.8em 0;}
.wizardFooter .status {padding:0 0.4em; margin-left:1em;}
.wizard .button {padding:0.1em 0.2em;}
#messageArea {position:fixed; top:2em; right:0; margin:0.5em; padding:0.5em; z-index:2000; _position:absolute;}
.messageToolbar {display:block; text-align:right; padding:0.2em;}
#messageArea a {text-decoration:underline;}
.tiddlerPopupButton {padding:0.2em;}
.popupTiddler {position: absolute; z-index:300; padding:1em; margin:0;}
.popup {position:absolute; z-index:300; font-size:.9em; padding:0; list-style:none; margin:0;}
.popup .popupMessage {padding:0.4em;}
.popup hr {display:block; height:1px; width:auto; padding:0; margin:0.2em 0;}
.popup li.disabled {padding:0.4em;}
.popup li a {display:block; padding:0.4em; font-weight:normal; cursor:pointer;}
.listBreak {font-size:1px; line-height:1px;}
.listBreak div {margin:2px 0;}
.tabset {padding:1em 0 0 0.5em;}
.tab {margin:0 0 0 0.25em; padding:2px;}
.tabContents {padding:0.5em;}
.tabContents ul, .tabContents ol {margin:0; padding:0;}
.txtMainTab .tabContents li {list-style:none;}
.tabContents li.listLink { margin-left:.75em;}
#contentWrapper {display:block;}
#splashScreen {display:none;}
#displayArea {margin:1em 17em 0 14em;}
.toolbar {text-align:right; font-size:.9em;}
.tiddler {padding:1em 1em 0;}
.missing .viewer,.missing .title {font-style:italic;}
.title {font-size:1.6em; font-weight:bold;}
.missing .subtitle {display:none;}
.subtitle {font-size:1.1em;}
.tiddler .button {padding:0.2em 0.4em;}
.tagging {margin:0.5em 0.5em 0.5em 0; float:left; display:none;}
.isTag .tagging {display:block;}
.tagged {margin:0.5em; float:right;}
.tagging, .tagged {font-size:0.9em; padding:0.25em;}
.tagging ul, .tagged ul {list-style:none; margin:0.25em; padding:0;}
.tagClear {clear:both;}
.footer {font-size:.9em;}
.footer li {display:inline;}
.annotation {padding:0.5em; margin:0.5em;}
* html .viewer pre {width:99%; padding:0 0 1em 0;}
.viewer {line-height:1.4em; padding-top:0.5em;}
.viewer .button {margin:0 0.25em; padding:0 0.25em;}
.viewer blockquote {line-height:1.5em; padding-left:0.8em;margin-left:2.5em;}
.viewer ul, .viewer ol {margin-left:0.5em; padding-left:1.5em;}
.viewer table, table.twtable {border-collapse:collapse; margin:0.8em 1.0em;}
.viewer th, .viewer td, .viewer tr,.viewer caption,.twtable th, .twtable td, .twtable tr,.twtable caption {padding:3px;}
table.listView {font-size:0.85em; margin:0.8em 1.0em;}
table.listView th, table.listView td, table.listView tr {padding:0px 3px 0px 3px;}
.viewer pre {padding:0.5em; margin-left:0.5em; font-size:1.2em; line-height:1.4em; overflow:auto;}
.viewer code {font-size:1.2em; line-height:1.4em;}
.editor {font-size:1.1em;}
.editor input, .editor textarea {display:block; width:100%; font:inherit;}
.editorFooter {padding:0.25em 0; font-size:.9em;}
.editorFooter .button {padding-top:0px; padding-bottom:0px;}
.fieldsetFix {border:0; padding:0; margin:1px 0px;}
.sparkline {line-height:1em;}
.sparktick {outline:0;}
.zoomer {font-size:1.1em; position:absolute; overflow:hidden;}
.zoomer div {padding:1em;}
* html #backstage {width:99%;}
* html #backstageArea {width:99%;}
#backstageArea {display:none; position:relative; overflow: hidden; z-index:150; padding:0.3em 0.5em;}
#backstageToolbar {position:relative;}
#backstageArea a {font-weight:bold; margin-left:0.5em; padding:0.3em 0.5em;}
#backstageButton {display:none; position:absolute; z-index:175; top:0; right:0;}
#backstageButton a {padding:0.1em 0.4em; margin:0.1em;}
#backstage {position:relative; width:100%; z-index:50;}
#backstagePanel {display:none; z-index:100; position:absolute; width:90%; margin-left:3em; padding:1em;}
.backstagePanelFooter {padding-top:0.2em; float:right;}
.backstagePanelFooter a {padding:0.2em 0.4em;}
#backstageCloak {display:none; z-index:20; position:absolute; width:100%; height:100px;}
.whenBackstage {display:none;}
.backstageVisible .whenBackstage {display:block;}
/*}}}*/
/***
StyleSheet for use when a translation requires any css style changes.
This StyleSheet can be used directly by languages such as Chinese, Japanese and Korean which need larger font sizes.
***/
/*{{{*/
body {font-size:0.8em;}
#sidebarOptions {font-size:1.05em;}
#sidebarOptions a {font-style:normal;}
#sidebarOptions .sliderPanel {font-size:0.95em;}
.subtitle {font-size:0.8em;}
.viewer table.listView {font-size:0.95em;}
/*}}}*/
/*{{{*/
@media print {
#mainMenu, #sidebar, #messageArea, .toolbar, #backstageButton, #backstageArea {display: none !important;}
#displayArea {margin: 1em 1em 0em;}
noscript {display:none;} /* Fixes a feature in Firefox 1.5.0.2 where print preview displays the noscript content */
}
/*}}}*/
<!--{{{-->
<div class='header' macro='gradient vert [[ColorPalette::PrimaryLight]] [[ColorPalette::PrimaryMid]]'>
<div class='headerShadow'>
<span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>
<span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
</div>
<div class='headerForeground'>
<span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>
<span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
</div>
</div>
<div id='mainMenu' refresh='content' tiddler='MainMenu'></div>
<div id='sidebar'>
<div id='sidebarOptions' refresh='content' tiddler='SideBarOptions'></div>
<div id='sidebarTabs' refresh='content' force='true' tiddler='SideBarTabs'></div>
</div>
<div id='displayArea'>
<div id='messageArea'></div>
<div id='tiddlerDisplay'></div>
</div>
<!--}}}-->
<!--{{{-->
<div class='toolbar' macro='toolbar [[ToolbarCommands::ViewToolbar]]'></div>
<div class='title' macro='view title'></div>
<div class='subtitle'><span macro='view modifier link'></span>, <span macro='view modified date'></span> (<span macro='message views.wikified.createdPrompt'></span> <span macro='view created date'></span>)</div>
<div class='tagging' macro='tagging'></div>
<div class='tagged' macro='tags'></div>
<div class='viewer' macro='view text wikified'></div>
<div class='tagClear'></div>
<!--}}}-->
<!--{{{-->
<div class='toolbar' macro='toolbar [[ToolbarCommands::EditToolbar]]'></div>
<div class='title' macro='view title'></div>
<div class='editor' macro='edit title'></div>
<div macro='annotations'></div>
<div class='editor' macro='edit text'></div>
<div class='editor' macro='edit tags'></div><div class='editorFooter'><span macro='message views.editor.tagPrompt'></span><span macro='tagChooser excludeLists'></span></div>
<!--}}}-->
To get started with this blank [[TiddlyWiki]], you'll need to modify the following tiddlers:
* [[SiteTitle]] & [[SiteSubtitle]]: The title and subtitle of the site, as shown above (after saving, they will also appear in the browser title bar)
* [[MainMenu]]: The menu (usually on the left)
* [[DefaultTiddlers]]: Contains the names of the tiddlers that you want to appear when the TiddlyWiki is opened
You'll also need to enter your username for signing your edits: <<option txtUserName>>
These [[InterfaceOptions]] for customising [[TiddlyWiki]] are saved in your browser
Your username for signing your edits. Write it as a [[WikiWord]] (eg [[JoeBloggs]])
<<option txtUserName>>
<<option chkSaveBackups>> [[SaveBackups]]
<<option chkAutoSave>> [[AutoSave]]
<<option chkRegExpSearch>> [[RegExpSearch]]
<<option chkCaseSensitiveSearch>> [[CaseSensitiveSearch]]
<<option chkAnimate>> [[EnableAnimations]]
----
Also see [[AdvancedOptions]]
The DDS specification [[formal/07-01-01|http://www.omg.org/cgi-bin/doc?formal/07-01-01]] describes the service architecture. OpenDDS extends this architecture to provide a full implementation including features not specified by the OMG.
The OpenDDS architecture currently contains objects providing services for the following:
*ServiceParticipant - singleton within each application using the DDS service encapsulating the service API
*[[Implementations]] - implementations for all DDS defined objects
*[[Transport]] - Interfaces, configuration objects and implementations providing low level transport services
*[[Repository]] - service metadata manager
The features allowing federation of [[repositories|Repository]] will be part of the OpenDDS extended architecture. These include the addition of a CORBA IDL interface incarnation within the [[repository|Repository]] process to manage the federation activities and DDS publications and subscriptions for distributing [[data coherency|http://en.wikipedia.org/wiki/Memory_coherence]] updates. Modifications to the ServiceParticipant within the application processes is also required.
[[Federation scope identifiers|RTPS GUID Identifiers]] for the managed data are required. This allows each DDS Entity to be uniquely identified within the federation. In order to allow [[repositories|Repository]] the ability to join and leave a federation at any time without requiring synchronization of internal state before becoming federated, the federation wide identifiers will be mapped to and from the internal identifiers used within the [[repository|Repository]] to locate individual Entities.
When data is transfered over the transport layer, a publication Id value is sent as part of the header information. This publication Id value must be a federation wide identifier value in order to avoid misidentifying samples. This means that the entire [[Federation scope identifier|RTPS GUID Identifiers]] is marshaled with each sample.
The basic feature of federation is the replication of [[repository|Repository]] information across all federated [[repositories|Repository]]. This replication is done by publishing data modification events from the originating [[repository|Repository]] to all other federated [[repositories|Repository]]. The nature of the service metadata allows only a single application ServiceParticipant to create or modify any given Entity. This means that only a single writer of the data is allowed at any time, which simplifies the required replication behavior. When management of a ServiceParticipant for any given application is transitioned from one [[repository|Repository]] to another the ownership of the Entity for purposes of writing is effectively transfered as well. Each [[repository|Repository]] retains knowledge of Entity ownership in order to determine which [[repository|Repository]] is required to make callbacks to the Entity and which are not allowed to do so.
The mechanisms for transferring the management of application [[ServiceParticipants|ServiceParticipant]] from one [[repository|Repository]] to another is performed using an enhancement to the existing multiple [[repository|Repository]] feature of [[OpenDDS]] and an additional interface method for the repository. When a domain is switched from one repository to another, a call to a new 'attach_participant()' method for each ~DomainParticipant within that domain in that ServiceParticipant is made to the [[repository|Repository]] which is to become the manager for those ~DomainParticipants. This allows that repository to obtain ownership of that ~DomainParticipant, as well as its contained Entities, which it then publishes to the other federated [[repositories|Repository]].
Failure or unreachability of a repository is detected by the applications through modifying the specified default LIVELINESS.lease_duration ~QoS policy value of the ~DCPSParticipant Built-in Topic. Failover sequencing is initiated by installing a federation ~ParticipantDataDataListener into the Built-in Topic reader for the ~DCPSParticipantData Built-in Topic. This means that the application will not be able to install a listener at this location without providing a separate mechanism to initiate failover sequencing.
Modifications to existing OpenDDS objects being proposed to provide the federation feature:
*ServiceParticipant - addition of federation scope publication identification mappings. Extension of the multirepo feature to make remote calls to the new [[repository|Repository]] for each ~DomainParticipant within a managed domain;
*~OpenDDS::~DataSampleHeader - modified to use the federation scope publication identification values.
Additional objects are being proposed to provide the federation feature:
*[[Federator::Manager|Manager]] - CORBAL IDL interface to allow federation of [[repositories|Repository]].
*Update publications and subscriptions for distribution of data updates within the federation.
For federated operation data needs to be made available to all federated [[repositories|Repository]] in order to ensure the ability of any [[repository|Repository]] to provision any attached ServiceParticipant. This is done using the ~UpdateManager and Updater persistence interfaces to push create, update and delete events as well as ownership assertions on managed data to the entire federated set of [[repositories|Repository]].
Additional interfaces to allow [[repositories|Repository]] to become federated as well as to remove themselves from federation are provided as well. A candidate extension of the [[repository|Repository]] including additional CORBA IDL interfaces and DDS Topics for federation is:
[img[images/Federation.jpg]]
The ~DCPSInfo and ~Updater are existing components of the [[repository|Repository]] while the [[Federator::Manager|Manager]] is a new component. The DDS Topics for [[Federator::ParticipantUpdateTopic|ParticipantUpdate]], [[Federator::TopicUpdateTopic|TopicUpdate]], [[Federator::PublicationUpdateTopic|PublicationUpdate]] and [[Federator::SubscriptionUpdateTopic|SubscriptionUpdate]] are published by the [[Federator::Manager|Manager]] through the ~Updater publisher to propagate changes to other [[repositories|Repository]] within the federation. The [[Federator::Manager|Manager]] creates subscriptions to these topics published from other [[repositories|Repository]] as they join the federation.
Background: #fff
Foreground: #000
PrimaryPale: #eee
PrimaryLight: #ccc
PrimaryMid: #600
PrimaryDark: #600
SecondaryPale: #eee
SecondaryLight: #ccc
SecondaryMid: #999
SecondaryDark: #666
TertiaryPale: #eee
TertiaryLight: #ccc
TertiaryMid: #999
TertiaryDark: #666
Error: #f88
[[Overview]]
[[UseCases]]
--- address the packaging and linking issues here ---
A DDS Domain is a partition of the service for the purposes of isolating the generated service Entities in different domains from each other. Domains are defined by the [[DDS specification|http://www.omg.org/cgi-bin/doc?formal/07-01-01]] as part of the Domain module.
#[[What kind of document is this?|FAQ1]]
#[[What happened to the Masters and Slaves?|FAQ2]]
#[[I don't like this at all! I have a much better way to do all this!|FAQ3]]
#[[Why don't you just use multiple profiles for redundant repositories?|FAQ4]]
#[[What happened to this routing feature I kept hearing about?|FAQ5]]
"What kind of document is this?"
This is a TiddlyWIki document.
"What happened to the Masters and Slaves?"
They are still there! But at a much finer granularity. Each data item under management (the data managed by the [[repository|Repository]]) is allowed a single writer or updater - this is where the Master is now. All other [[repositories|Repository]] correspond to the Slave role. The difference is that rather than assigning a role to an entire [[repository|Repository]], each data item receives a role.
This finer granularity of roles - ownership in this case - allows individual application [[ServiceParticipants|ServiceParticipant]] to create and update the Entities which it owns in the current 'Master' repository to which it is attached. This results in less data transfered when redirecting an application ServiceParticipant to a new [[repository|Repository]] for management since only the application being redirected needs to be modfied. With the coarser granularity ALL applications would need to pause and redirect their ServiceParticipant to a new [[repository|Repository]]. It also means that if groups of applications and repositories become isolated, they are not dependent on a single [[repository|Repository]] for management.
"I don't like this at all! I have a much better way to do all this!"
Talk to Jonathon. Be prepared to support your ideas and justify any changes.
"Why don't you just use multiple profiles for redundant [[repositories|Repository]]?"
That would be a great thing to do. But there are some issues with using multiple profiles to redirect [[ServiceParticipants|ServiceParticipant]] to additional [[repositories|Repository]]. If these issues can be addressed satisfactorily then we can consider doing this.
*All possible redundant [[repositories|Repository]] need to be known and available at initialization of the ServiceParticipant which will reference them - dynamic addition of [[repositories|Repository]] is not possible. Nor is removal of [[repositories|Repository]] from the list (in case one or more becomes unavailable).
*Transitioning from one [[repository|Repository]] to another cannot be controlled easily - while catastrophic failures will fail over well, if movement to an alternate incarnation is desired for other reasons then doing so is not straighforward.
*When a transition from one profile to another occurs, it is necessary for this event to be made available to the federation in order to pass ownership of the data from the old to the new location.
"What happened to this routing feature I kept hearing about?"
The ability to route data through an arbitrary topology of connections was developed on a previous project to provide the ability to use DDS in a mesh of point to point connections. Since that project also started working on interfaces used for federation, the routing feature had been thought to be required for federation. At least by me anyway. It turns out that the baseline case for federation is the use of DDS using fully routed transports, which requires no additional routing help.
If it ever becomes necessary to constrain a federation of repositories to use specific interfaces only then this feature may become necessary. It would be incorporated through additional use of the PARTITION ~QoS policy to constrain created associations and is not necessarily needed internal to the repository or federation implementations.
OpenDDS provides implementations for each of the [[DDS specified|http://www.omg.org/cgi-bin/doc?formal/07-01-01]] components. These include the Publisher, Subscriber, Topic, ~DataWriter, ~DataReader, Participant and ~ParticipantFactory components and supporting types.
[[Overview]]
[[Use Cases|UseCases]]
[[Software Reuse|Reuse]]
[[Architecture]]
[[Deployment]]
[[FAQ]]
The Federator::Manager is a component used to manage federation between [[repositories|Repository]]. It does this by providing a CORBA IDL interface which has methods to establish and remove direct connections between Federator::Manager objects executing within different [[repository|Repository]] processes.
To provide data coherence within the federation this component implements the ~UpdaterBase interface to allow it to be called when internal data elements are updated. It then publishes these updates to other repositories as the individual update DDS topics. It also subscribes to publications from repositories to which it is connected. These subscriptions are for all of the update information published about changes within the federation which it then uses to update the internal data elements.
OpenDDS is an open source C++ implementation of the Object Management Group (OMG) Data Distribution Service (DDS). OpenDDS also supports Java bindings through JNI and can be included with JBoss (ESB) frameworks by means of a JMS wrapper. OpenDDS leverages the ADAPTIVE Communication Environment (ACE) to provide a cross platform environment.
OpenDDS is supported by [[Object Computing, Inc.|http://www.ociweb.com/]]
OpenDDS is an implementation of the OMG Data Distribution Service (DDS) [[specification|http://www.omg.org/cgi-bin/doc?formal/07-01-01]]. This implementation is managed by attaching individual application ServiceParticipant to a remote [[repository|Repository]] process which provides a CORBA IDL interface for managing the service. Application code need not be aware of the details of this interface as it is used internally by the DDS ServiceParticipant. The application is required to establish and maintain connections with these remote processes.
As of this time, each ServiceParticipant is allowed to attach to one or more [[repositories|Repository]] for management of individual domains. Currently there is one [[repository|Repository]] allowed to manage one or more DDS defined [[domains|Domain]] for an application with each [[domain|Domain]] used by an application managed by one and only one [[repository|Repository]]. This means that if the remote [[repository|Repository]] process managing a specific [[domain|Domain]] for an application fails for any reason, that [[domain|Domain]] and any Topics, [[publications|Publications]] or [[subscriptions|Subscriptions]] will no longer be available to the application. This is undesirable.
In order to eliminate this problem for users of OpenDDS, a mechanism that allows multiple [[repositories|Repository]] to become federated and manage the same domains is being proposed. This mechanism means that if one [[repository|Repository]] fails, another repository will be able to replace it so that applications will be able to operate correctly as long as at least a single [[repository|Repository]] is attached.
The proposed mechanism is required to satisfy several [[use cases|UseCases]] during operation. These cases include operating in the presence of one or more [[repositories|Repository]], switching the management of an applications DDS ServiceParticipant for any given [[domain|Domain]] from a failed [[repository|Repository]] to one that is still operational.
[[Previous work|Reuse]] done to demonstrate the ability of DDS to provide a data transfer capability within a dynamic topology of point to point links established the ability of the DDS service to route data over defined connections within a topology. Work was done on that project that prototyped interfaces needed to manage the federation of repositories and can be used directly.
<!--{{{-->
<div class='header'>
<div class='headerForeground'>
<span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>
<span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
</div>
</div>
<div id='mainMenu' refresh='content' tiddler='MainMenu'></div>
<div id='sidebar'>
<div id='sidebarOptions' refresh='content' tiddler='SideBarOptions'></div>
<div id='sidebarTabs' refresh='content' force='true' tiddler='SideBarTabs'></div>
</div>
<div id='displayArea'>
<div id='messageArea'></div>
<div id='tiddlerDisplay'></div>
<div class='footer'>$Id: federation.html 2855 2010-01-05 00:15:38Z stallions $</div>
</div>
<!--}}}-->
This is a data type published by each federated [[repository|Repository]]. Samples of this type provide create, update and delete information about individual service ~DomainParticipant Entities as they are updated in the [[repository|Repository]].
The structure of this update data needs to contain the FederationId of the element being updated, a sequence number for the update, the [[domain|Domain]] in which contains the element and a new ~QoS value to replace the existing one. The structure is keyed by the [[repository|Repository]] portion of the FederationId value. Only the [[repository|Repository]] which owns the ~DomainParticipant Entity is the one which publishes updates for the element.
This is a data type published by each federated [[repository|Repository]]. Samples of this type provide create, update and delete information about individual service publication Entities as they are updated in the [[repository|Repository]].
The structure of this update data needs to contain the FederationId of the element being updated, the FederationId of the Topic of the publication, the FederationId of the ~DomainParticipant element which contains this publication, a sequence number for the update, the [[domain|Domain]] which contains the publication, a bitfield indicating which structure elements to update and the new values to update them with. The values include a new ~QoS value for the Publisher and ~DataWriter comprising the publication and the transport Id and transport Blob information for the publication. The structure is keyed by the [[repository|Repository]] portion of the FederationId value. Only the [[repository|Repository]] which owns the publication is the one which publishes updates for the publication.
Publications within the DDS service consist of individual ~DataWriter Entities which an application uses to write data for one or more instances of a Topic. Each ~DataWriter Entity is attached to one an only one Publisher Entity (which can have any number of ~DataWriters attached) which provides presentation level scope for the publication. The [[Transport]] implementation attached to the Publisher Entity is what is used to actually deliver the data samples to any associated [[subscriptions|Subscriptions]].
To simplify generation of federation scope identifiers the RTPS defined GUID data type will be used. This 128 bit value is partitioned into sections by the RTPS GUID_t data structure definition. Anticipating an eventual interoperability with RTPS, we maintain the same structures for the repository use. These values will be used to uniquely identify all service entities managed by a federation of [[OpenDDS]] [[repositories|Repository]].
Part of the information mapped into the GUID value requires that each [[repository|Repository]] be assigned an identifier value that is unique among all [[repositories|Repository]] within the federation. This value assignment is beyond the scope of the federation architecture and will be assumed. The issue of repository identifier assignment is analogous to assigning MAC addresses to interfaces - each interface (analogous to a [[repository|Repository]]) has a single, unique, 32 bit value assigned at creation that does not change during its lifetime or conflict with any other assigned value.
Use of a unique [[repository|Repository]] Id value allows individual repositories to be identified as they join, leave and rejoin a federation of repositories. It also allows a [[repository|Repository]] that has persistence enabled to be stopped and restarted then join or rejoin a federation as if it had not been terminated.
Information will be mapped onto the GUID value as follows:
|~GUID_t byte|Element|Subelement|Content|
|0|guidPrefix||~VendorId|
|1|~|~|~|
|2|~|~|0|
|3|~|~|~|
|4|~|~|repository Identifier|
|5|~|~|~|
|6|~|~|~|
|7|~|~|~|
|8|~|~|participant identifier|
|9|~|~|~|
|10|~|~|~|
|11|~|~|~|
|12|entityId|entityKey|sequential identity|
|13|~|~|~|
|14|~|~|~|
|15|~|kind|~EntityKind code|
Where the
*~VendorId is assigned by the OMG in the RTPS specification and the value of 0x03 (OCI) is used for [[OpenDDS]] identifiers;
*repository identifier value is the 32 bit unique identifier for each individual repository;
*participant identifier is a 32 bit unique identifier for ~DomainParticipants initially created within the instant repository;
*sequential identity is a sequence of values for each entity kind within the instant participant uniqiuely identifying the entity;
*~EntityKind code is the OMG RTPS defined code value with the extended value of 0x45 indicating a Topic entity, which is needed by the [[OpenDDS]] implementation for managing service metadata.
The ~DCPSInfo CORBA IDL interface provides the interface used by the ServiceParticipant within applications to manage the service for the applications. This interface is called to register [[ServiceParticipants|ServiceParticipant]], Topics, Publishers, Subscribers, ~DataWriters and ~DataReaders. As new Entities are registered, if new associations should be created between publications and subscriptions the repository calls back to the Entities involved in the new association to establish communication between them.
The data stored in the repository is modeled as:
@@margin-left: 25%; [img[images/info-dm.png]]@@
Work for another project produced many of the individual features that are needed by a federation of [[repositories|Repository]]. Initially this project was to create a candidate federation implementation that allowed repositories to join and leave the federation at will and managed replication of data between all federated [[repositories|Repository]]. In order to remove the project from the critical path for the release of OpenDDS version 1.1 these features were removed from the OpenDDS implementation and added to the project specific code base. The work done was saved to a separate federation branch in the DDS code base (https://svn.dre.vanderbilt.edu/DOC/DDS/branches/federation).
Relevant work that is present in the federation branch, but was completed in the project code includes the [[Federator::Manager|Manager]] CORBA IDL interface. The details of the [[Federator::Manager|Manager]] implementation are slightly different in the project code from the implementation required for the [[repository|Repository]] federation. This includes specifics about data types used as well as publication and subscription data types and topics.
This code does not contain any of the ~UpdaterBase implementations or code to allow the provisioning of a participating application by different [[repositories|Repository]] within the federation.
Application creates a new service Entity. Note that these scenarios do not show any resulting behavior triggered by the creation event. The [[Operate Federated|UseCase5]] use case describes that information.
[img[images/CreateParticipant.jpg]]
[img[images/CreatePublication.jpg]]
[img[images/CreateSubscription.jpg]]
[img[images/CreateTopic.jpg]]
Application updates an existing service Entity.
The [[repository|Repository]] processing is essentially the same as performed for [[scenario 1|Scenario1_1]] but with the ~DCPSInfo interface call to the corresponding 'update_..._qos' method for the entity being destroyed. The application would also need to have called the corresponding 'update' method as well.
Application destroys an existing service Entity.
The [[repository|Repository]] processing is essentially the same as performed for [[scenario 1|Scenario1_1]] but with the ~DCPSInfo interface call to the corresponding 'remove' method for the entity being destroyed. The application would also need to have called the corresponding 'destroy' method as well.
~DataWriter or ~DataReader becomes associated with other ~DataReader or ~DataWriter.
This operation proceeds without modification from the existing [[repository|Repository]] and ServiceParticipant processing. The only difference is that a [[repository|Repository]] may have only one end of the association for which to call back into the ServiceParticipant to make the association. The information to make the add_associations call to the ~RemoteDataWriter or ~RemoteDataReader is available to the [[repository|Repository]] since it is part of the distributed update information. This includes the transport endpoint information required for establishing the connection. @@color:red;Note that this requires that all participants be able to connect directly with all other participants.@@
The event that triggers an add_associations() call within a [[repository|Repository]] is predicated on the ownership of the endpoint. This means that if a [[repository|Repository]] 'owns' a particular [[publication|Publications]] or [[subscription|Subscriptions]], then it needs to issue the callback. Since ownership may be passed (see [[Failover|UseCase2]]) it is not sufficient for the [[repository|Repository]] to check the [[repository|Repository]] identifier of the actor but ownership needs to be checked explicitly. It may be the case that an application ServiceParticipant has passed ownership of remotely created Entities to this [[repository|Repository]] or that locally created Entities have had ownership passed to another [[repository|Repository]].
Processing within a given ServiceParticipant is unaffected. Once the add_associations call is made to the ~RemoteDataWriter or ~RemoteDataReader all subsequent processing proceeds without modification.
~DataWriter or ~DataReader becomes unassociated with other ~DataReader or ~DataWriter
The processing of this scenario is the complement of that described in the [[associating scenario|Scenario1_4]]. The key is the triggering the remove_associations callback correctly.
ServiceParticipant changes manager for domain to new repository.
This is currently shown as a remote call to the [[Federator::Manager|Manager]] to assert ownership with a CORBA request/response call to each remote repository in the federation to propagate the ownership through the federation. This may be better done by distributing the ownership information via DDS (as with the update topics) instead.
[img[images/PassOwnership.jpg]]
The remap operation as shown presumes that all of the Entities created within the ServiceParticipant are switching ownership to a new [[repository|Repository]]. This is the expected granularity at this time since the ServiceParticipant currently only allows [[domains|Domain]] to be attached to [[repositories|Repository]]. If a repository becomes unavailable, then all of the [[domains|Domain]] which are attached to it must be re-targeted to another [[repository|Repository]]. The remap must change the binding internally for each and assert the ownership change to the new repository after this rebinding. The new repository that receives the ownership then needs to propagate this ownership information out to the remainder of the federation.
The assertOwnership operation as shown provides the old repository identifier and the new repository identifier. This allows the ownership mapping to be maintained by repository identifier and domain within the [[repositories|Repository]]. Unfortunately this may not be sufficient. It is not only possible but likely that data elements created within a [[repository|Repository]] have been created by separate [[ServiceParticipants|ServiceParticipant]]. The ability for individual [[ServiceParticipants|ServiceParticipant]] to change the attached [[repository|Repository]] for a domain is required. This means that either ownership needs to be maintained keyed with the ServiceParticipant that created the data (ownership is by ServiceParticipant) or ownership needs to be asserted and maintained for each individual data element within the [[repository|Repository]].
"[[Repository]] joins an unfederated repository"
This is when two [[repositories|Repository]] become federated for the first time. Both [[repositories|Repository]] are unfederated at the start of the scenario and each will become federated with an attachment to the other by the close of this scenario. The overall processing, including a gloss of the startup and discovery is illustrated below. Note that the scenario processing for the join is symmetrical. That the passive (callee) participant to the first join_federation() call is the participant which is the first to attach to the other may not be immediately intuitive.
Steps 20 through 30 of this diagram illustrate this scenario.
[img[images/StartAndFederate.jpg]]
"[[Repository]] joins an already federated repository"
This scenario is identical to the [[previous scenario|Scenario4_1]] with the omission of steps 22, 23 and 24. Since the existing, already federated, repository already as an attachment for publication and subscription to the Update Topics used for federation, it is not necessary to reestablish this attachment.
Application creates new service Entity and no associations are created.
This is the same processing as [[use case 1|UseCase1]] [[scenario 1|Scenario1_1]].
Application updates existing service Entity and no new associations are made.
This is the same processing as [[use case 1|UseCase1]] [[scenario 2|Scenario1_2]].
Application deletes existing service Entity and no associations are removed.
This is the same processing as [[use case 1|UseCase1]] [[scenario 3|Scenario1_3]].
The ~ServiceParticipant is a singleton object created within each application which participates in the DDS service. The API for accessing the DDS components is made available via this ~ServiceParticipant. It is an OpenDDS specific extension and is not specified by the OMG.
<<search>><<closeAll>><<permaview>><<newTiddler>><<saveChanges>><<slider chkSliderOptionsPanel OptionsPanel "options ยป" "Change TiddlyWiki advanced options">>
Repository Federation Design
a:hover {
text-decoration: none;
}
.headerForeground {
position: relative;
background-color:[[ColorPalette::Background]];
background-image: url(../template/images/opendds.png);
background-position: left;
background-repeat: no-repeat;
color:[[ColorPalette::SecondaryDark]];
padding: 20px 0 5px 72px;
border-bottom: 1px solid [[ColorPalette::SecondaryLight]];
}
.headerForeground a {
color:[[ColorPalette::SecondaryDark]];
font-weight: bold;
}
.footer {
border-top: 1px solid [[ColorPalette::SecondaryLight]];
color:[[ColorPalette::SecondaryLight]];
margin-top: 20px;
font-size: 1.1em;
}
.siteTitle {
font-weight: bold;
}
#mainMenu {
padding: 25px 0 0 20px;
}
.toolbar {
float: right;
}
/*{{{*/
body {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}
a {color:[[ColorPalette::PrimaryMid]];}
a:hover {/*background-color:[[ColorPalette::PrimaryMid]]; color:[[ColorPalette::Background]];*/}
a img {border:0;}
h1,h2,h3,h4,h5,h6 {color:[[ColorPalette::SecondaryDark]]; background:transparent;}
h1 {border-bottom:2px solid [[ColorPalette::TertiaryLight]];}
h2,h3 {border-bottom:1px solid [[ColorPalette::TertiaryLight]];}
.button {color:[[ColorPalette::PrimaryDark]]; border:1px solid [[ColorPalette::Background]];}
.button:hover {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::SecondaryLight]]; border-color:[[ColorPalette::SecondaryMid]];}
.button:active {color:[[ColorPalette::Background]]; background:[[ColorPalette::SecondaryMid]]; border:1px solid [[ColorPalette::SecondaryDark]];}
.header {background:[[ColorPalette::PrimaryMid]];}
.headerShadow {color:[[ColorPalette::Foreground]];}
.headerShadow a {font-weight:normal; color:[[ColorPalette::Foreground]];}
.headerForeground {color:[[ColorPalette::Background]];}
.headerForeground a {font-weight:normal; color:[[ColorPalette::PrimaryPale]];}
.tabSelected{color:[[ColorPalette::PrimaryDark]];
background:[[ColorPalette::TertiaryPale]];
border-left:1px solid [[ColorPalette::TertiaryLight]];
border-top:1px solid [[ColorPalette::TertiaryLight]];
border-right:1px solid [[ColorPalette::TertiaryLight]];
}
.tabUnselected {color:[[ColorPalette::Background]]; background:[[ColorPalette::TertiaryMid]];}
.tabContents {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::TertiaryPale]]; border:1px solid [[ColorPalette::TertiaryLight]];}
.tabContents .button {border:0;}
#sidebar {}
#sidebarOptions input {border:1px solid [[ColorPalette::PrimaryMid]];}
#sidebarOptions .sliderPanel {background:[[ColorPalette::PrimaryPale]];}
#sidebarOptions .sliderPanel a {border:none;color:[[ColorPalette::PrimaryMid]];}
#sidebarOptions .sliderPanel a:hover {color:[[ColorPalette::Background]]; background:[[ColorPalette::PrimaryMid]];}
#sidebarOptions .sliderPanel a:active {color:[[ColorPalette::PrimaryMid]]; background:[[ColorPalette::Background]];}
.wizard {background:[[ColorPalette::PrimaryPale]]; border:1px solid [[ColorPalette::PrimaryMid]];}
.wizard h1 {color:[[ColorPalette::PrimaryDark]]; border:none;}
.wizard h2 {color:[[ColorPalette::Foreground]]; border:none;}
.wizardStep {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];
border:1px solid [[ColorPalette::PrimaryMid]];}
.wizardStep.wizardStepDone {background:[[ColorPalette::TertiaryLight]];}
.wizardFooter {background:[[ColorPalette::PrimaryPale]];}
.wizardFooter .status {background:[[ColorPalette::PrimaryDark]]; color:[[ColorPalette::Background]];}
.wizard .button {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::SecondaryLight]]; border: 1px solid;
border-color:[[ColorPalette::SecondaryPale]] [[ColorPalette::SecondaryDark]] [[ColorPalette::SecondaryDark]] [[ColorPalette::SecondaryPale]];}
.wizard .button:hover {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::Background]];}
.wizard .button:active {color:[[ColorPalette::Background]]; background:[[ColorPalette::Foreground]]; border: 1px solid;
border-color:[[ColorPalette::PrimaryDark]] [[ColorPalette::PrimaryPale]] [[ColorPalette::PrimaryPale]] [[ColorPalette::PrimaryDark]];}
.wizard .notChanged {background:transparent;}
.wizard .changedLocally {background:#80ff80;}
.wizard .changedServer {background:#8080ff;}
.wizard .changedBoth {background:#ff8080;}
.wizard .notFound {background:#ffff80;}
.wizard .putToServer {background:#ff80ff;}
.wizard .gotFromServer {background:#80ffff;}
#messageArea {border:1px solid [[ColorPalette::SecondaryMid]]; background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]];}
#messageArea .button {color:[[ColorPalette::PrimaryMid]]; background:[[ColorPalette::SecondaryPale]]; border:none;}
.popupTiddler {background:[[ColorPalette::TertiaryPale]]; border:2px solid [[ColorPalette::TertiaryMid]];}
.popup {background:[[ColorPalette::TertiaryPale]]; color:[[ColorPalette::TertiaryDark]]; border-left:1px solid [[ColorPalette::TertiaryMid]]; border-top:1px solid [[ColorPalette::TertiaryMid]]; border-right:2px solid [[ColorPalette::TertiaryDark]]; border-bottom:2px solid [[ColorPalette::TertiaryDark]];}
.popup hr {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::PrimaryDark]]; border-bottom:1px;}
.popup li.disabled {color:[[ColorPalette::TertiaryMid]];}
.popup li a, .popup li a:visited {color:[[ColorPalette::Foreground]]; border: none;}
.popup li a:hover {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; border: none;}
.popup li a:active {background:[[ColorPalette::SecondaryPale]]; color:[[ColorPalette::Foreground]]; border: none;}
.popupHighlight {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}
.listBreak div {border-bottom:1px solid [[ColorPalette::TertiaryDark]];}
.tiddler .defaultCommand {font-weight:bold;}
.shadow .title {color:[[ColorPalette::TertiaryDark]];}
.title {color:[[ColorPalette::SecondaryDark]];}
.subtitle {color:[[ColorPalette::TertiaryDark]];}
.toolbar {color:[[ColorPalette::PrimaryMid]];}
.toolbar a {color:[[ColorPalette::TertiaryLight]];}
.selected .toolbar a {color:[[ColorPalette::TertiaryMid]];}
.selected .toolbar a:hover {color:[[ColorPalette::Foreground]];}
.tagging, .tagged {border:1px solid [[ColorPalette::TertiaryPale]]; background-color:[[ColorPalette::TertiaryPale]];}
.selected .tagging, .selected .tagged {background-color:[[ColorPalette::TertiaryLight]]; border:1px solid [[ColorPalette::TertiaryMid]];}
.tagging .listTitle, .tagged .listTitle {color:[[ColorPalette::PrimaryDark]];}
.tagging .button, .tagged .button {border:none;}
.footer {color:[[ColorPalette::TertiaryLight]];}
.selected .footer {color:[[ColorPalette::TertiaryMid]];}
.sparkline {background:[[ColorPalette::PrimaryPale]]; border:0;}
.sparktick {background:[[ColorPalette::PrimaryDark]];}
.error, .errorButton {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::Error]];}
.warning {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::SecondaryPale]];}
.lowlight {background:[[ColorPalette::TertiaryLight]];}
.zoomer {background:none; color:[[ColorPalette::TertiaryMid]]; border:3px solid [[ColorPalette::TertiaryMid]];}
.imageLink, #displayArea .imageLink {background:transparent;}
.annotation {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; border:2px solid [[ColorPalette::SecondaryMid]];}
.viewer .listTitle {list-style-type:none; margin-left:-2em;}
.viewer .button {border:1px solid [[ColorPalette::SecondaryMid]];}
.viewer blockquote {border-left:3px solid [[ColorPalette::TertiaryDark]];}
.viewer table, table.twtable {border:2px solid [[ColorPalette::TertiaryDark]];}
.viewer th, .viewer thead td, .twtable th, .twtable thead td {background:[[ColorPalette::SecondaryMid]]; border:1px solid [[ColorPalette::TertiaryDark]]; color:[[ColorPalette::Background]];}
.viewer td, .viewer tr, .twtable td, .twtable tr {border:1px solid [[ColorPalette::TertiaryDark]];}
.viewer pre {border:1px solid [[ColorPalette::SecondaryLight]]; background:[[ColorPalette::SecondaryPale]];}
.viewer code {color:[[ColorPalette::SecondaryDark]];}
.viewer hr {border:0; border-top:dashed 1px [[ColorPalette::TertiaryDark]]; color:[[ColorPalette::TertiaryDark]];}
.highlight, .marked {background:[[ColorPalette::SecondaryLight]];}
.editor input {border:1px solid [[ColorPalette::PrimaryMid]];}
.editor textarea {border:1px solid [[ColorPalette::PrimaryMid]]; width:100%;}
.editorFooter {color:[[ColorPalette::TertiaryMid]];}
#backstageArea {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::TertiaryMid]];}
#backstageArea a {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::Background]]; border:none;}
#backstageArea a:hover {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; }
#backstageArea a.backstageSelTab {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}
#backstageButton a {background:none; color:[[ColorPalette::Background]]; border:none;}
#backstageButton a:hover {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::Background]]; border:none;}
#backstagePanel {background:[[ColorPalette::Background]]; border-color: [[ColorPalette::Background]] [[ColorPalette::TertiaryDark]] [[ColorPalette::TertiaryDark]] [[ColorPalette::TertiaryDark]];}
.backstagePanelFooter .button {border:none; color:[[ColorPalette::Background]];}
.backstagePanelFooter .button:hover {color:[[ColorPalette::Foreground]];}
#backstageCloak {background:[[ColorPalette::Foreground]]; opacity:0.6; filter:'alpha(opacity=60)';}
/*}}}*/
This is a data type published by each federated [[repository|Repository]]. Samples of this type provide create, update and delete information about individual service subscription Entities as they are updated in the [[repository|Repository]].
The structure of this update data needs to contain the FederationId of the element being updated, the FederationId of the Topic of the subscription, the FederationId of the ~DomainParticipant element which contains this subscription, a sequence number for the update, the [[domain|Domain]] which contains the subscription, a bitfield indicating which structure elements to update and the new values to update them with. The values include a new ~QoS value for the Subscriber and ~DataReader comprising the subscription and the transport Id and transport Blob information for the subscription. The structure is keyed by the [[repository|Repository]] portion of the FederationId value. Only the [[repository|Repository]] which owns the subscription is the one which publishes updates for the subscription.
Subscriptions within the DDS service consist of individual ~DataReader Entities which an application uses to read data for one or more instances of a Topic. Each ~DataReader Entity is attached to one an only one Subscriber Entity (which can have any number of ~DataReaders attached). The [[Transport]] implementation attached to the Subscriber Entity is what is used to actually receive the data samples from any associated [[publications|Publications]].
~TiddlyWiki is a complete [[wiki|http://en.wikipedia.org/wiki/Wiki]] in a single HTML file. It contains the entire text of the wiki, and all the ~JavaScript, CSS and HTML goodness to be able to display it, and let you edit it or search it. Without needing a server.
You can find out more at the [[TiddlyWiki home|http://www.tiddlywiki.com/]].
This is a data type published by each federated [[repository|Repository]]. Samples of this type provide create, update and delete information about individual Topic Entities as they are updated in the [[repository|Repository]].
The structure of this update data needs to contain the FederationId of the element being updated, the FederationId of the ~DomainParticipant element which contains this instance of the Topic, a sequence number for the update, the [[domain|Domain]] which contains the element, the topic name, datatype name and a new ~QoS value to replace the existing one. The structure is keyed by the [[repository|Repository]] portion of the FederationId value. Only the [[repository|Repository]] which owns the ~Topic Entity is the one which publishes updates for the element.
OpenDDS provides an abstract interface to transport data for the service. Several implementations of this interface are provided which include ~SimpleTCP, ~SimpleUDP, Multicast and ~ReliableMulticast. These implementations can be specified for use by the application and attached to individual Publisher and Subscriber service components.
"Normal Operation" - Application ServiceParticipant operates with one or more federated [[repositories|Repository]]
This is the steady state of an application using a DDS service provisioned by federated [[repositories|Repository]]. Applications initialize attaching to one or more [[repositories|Repository]]. Each domain utilized by that application is then mapped to a single [[repository|Repository]] for managing the Entities within that domain.
Scenarios include:
#[[Application creates a new service Entity|Scenario1_1]]
#[[Application updates an existing service Entity|Scenario1_2]]
#[[Application destroys an existing service Entity|Scenario1_3]]
#[[DataWriter or DataReader becomes associated with other DataReader or DataWriter|Scenario1_4]]
#[[DataWriter or DataReader becomes unassociated with other DataReader or DataWriter|Scenario1_5]]
"Failover" - Application ServiceParticipant redirects service management to different [[repository|Repository]]
This is how each application ServiceParticipant redirects its management to a different [[repository|Repository]]. If the [[repository|Repository]] managing a domain within an application becomes unavailable, through either process or communication failure, then the application needs to attach to a different [[repository|Repository]] to manage that domain and pass ownership within the federation for that applications data to the new [[repository|Repository]].
Scenarios include:
#[[ServiceParticipant detects repository as unavailable|Scenario2_1]]
#[[ServiceParticipant changes manager for domain to new repository|Scenario2_2]]
"Discovery" - Discovery of [[repositories|Repository]]
This is where the rubber meets the road for federation. This is the mechanism to allow [[repositories|Repository]] to become federated. The details of this have not been determined as of this time. As each [[repository|Repository]] is started, it should be joined into an existing federation (the first [[repository|Repository]] will join an empty federation). Discovery of the federation and choosing how many connections to make into that federation are choices that need to be made. Each process will have an incarnation each of the [[DCPSInfo|Repository]] and [[Federator::Manager|Manager]] interfaces.
Since the goal is to make connections between different incarnations of identical interfaces, it is unlikely that use of the standard 'mcast' protocol will succeed, since that assumes that only one incarnation of an interface will answer. Use of a ~NamingService or Implementation Repository in a separate process would be pushing the single point of failure to another location. Collocating one of these services within a [[repository|Repository]] process while possible generates other problems; such as how to choose where to locate the service and what happens if that process becomes unavailable. We end up with the same problem as we had initially.
Scenarios include:
#[[Starting and initializing the first repository|Scenario3_1]]
#[[Starting and initializing additional repositories|Scenario3_2]]
#[[Discovery of remote repository while operating|Scenario3_3]]
"Join Federation" - [[Repository]] joins the federation
This is where a [[repository|Repository]] becomes federated with other [[repositories|Repository]]. This involves establishing communications with another [[repository|Repository]] and synchronizing the internal data between the [[repository|Repository]] and the federation. At the end of this process, each [[repository|Repository]] within the federation will have a copy of the same information, with ownership - or the ability to write or update a piece of data - held by one and only one [[repository|Repository]] for each data item.
Part of joining a federation includes how the individual [[repositories|Repository]] are connected. The distributed update data does not need explicit connectivity since it is done via DDS which does not require references to be held at a high level between participants. The join and leave operations and (currently) the assertion of ownership are CORBA IDL interfaces and references to other repository [[Federation::Manager|Manager]] incarnations are required to invoke these operations. When joining a federation, references to all participating [[repositories|Repository]] can be made available to all [[repositories|Repository]] within the federation, or some subset of references can be maintained. Passing all references would be a good solution for smaller (for some sense of smaller) systems. As the number of [[repositories|Repository]] within a federation grows this may become large enough to become undesirable.
The initial implementation will pass all available references to all participating [[repositories|Repository]] but only invoke operations on a single reference. The initial reference that was used to join the federation will be the first one used. There does not appear to be a compelling reason to chose another interface other than randomly at this time if connectivity to the first reference is lost.
Scenarios include:
#[[Repository joins an unfederated repository|Scenario4_1]]
#[[Repository joins an already federated repository|Scenario4_2]]
"Operate Federated" - [[Repositories|Repository]] operate within a federation of [[repositories|Repository]]
This is the steady state of a federation of [[repositories|Repository]]. This involves maintaining the coherency of data within the federation as changes are made to the managed metadata.
Scenarios include:
#[[Application creates new service Entity and no associations are created|Scenario5_1]]
#[[Application creates new service Entity and associations are created|Scenario5_2]]
#[[Application updates existing service Entity and no new associations are made|Scenario5_3]]
#[[Application updates existing service Entity and new associations are created or existing ones removed|Scenario5_4]]
#[[Application deletes existing service Entity and no associations are removed|Scenario5_5]]
#[[Application deletes existing service Entity and existing associations are removed|Scenario5_6]]
"Leave Federation" - [[Repository]] leaves the federation
This is where a [[repository|Repository]] becomes disconnected from other [[repositories|Repository]]. This involves communications with other [[repositories|Repository]] within the federation becoming unavailable. At the end of this process, each [[repository|Repository]] will retain information about only reachable service Entities and have removed all other information. This means that if [[repositories|Repository]] become disjoint such that they no longer contain information about managed DDS Entities for each other, any established associations between these Entities will be removed, regardless of whether the association could have been maintained independently of the federation.
A [[repository|Repository]] might leave a federation due to being commanded to leave the federation by the user application or if connectivity with the federation is not available.
There are some issues with federation topology and connectivity discussed in the [[join federation|UseCase4]] case that are applicable here.
Scenarios include:
#[[Repository loses connectivity to federation|Scenario6_2]]
#[[Repository leaves federation|Scenario6_2]]
Federation of [[repositories|Repository]] is required to satisfy the following use cases: [img[images/UseCases.jpg]]
#[[Normal Operation|UseCase1]] - Application ~ServiceParticipant operates with one or more federated repositories
#[[Failover|UseCase2]] - Application ~ServiceParticipant redirects service management to different repository
#[[Discovery|UseCase3]] - Discovery of repositories
#[[Join Federation|UseCase4]] - Repository joins the federation
#[[Operate Federated|UseCase5]] - Repositories operate within a federation of repositories
#[[Leave Federation|UseCase6]] - Repository leaves the federation