| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html> |
| <head> |
| <meta content="text/html; charset=ISO-8859-1" |
| http-equiv="content-type"> |
| <title>org.eclipse.ecf.sdo</title> |
| <meta content="Peter Nehrer" name="author"> |
| </head> |
| <body> |
| <p>Provides the ability to share structured data graphs among Shared |
| Object Containers joined in the same group. The shared data graphs must |
| comply with the Service Data Objects API.</p> |
| <h2>Package Specification</h2> |
| <p>This package provides the API to support replication of structured |
| object state (represented by SDO data graphs) across multiple |
| processes. Specifically, it allows the clients to:</p> |
| <ol> |
| <li>publish SDO data graphs to the group, thus making them available |
| for subscription</li> |
| <li>subscribe to data graphs published by other group members</li> |
| </ol> |
| <p>Subsequently, both publishers and subscribers are:</p> |
| <ol> |
| <li>able to commit changes they make locally, thus making them |
| visible to the whole group</li> |
| <li>notified when other group members make changes</li> |
| </ol> |
| <p>In terms of SDO, the group (or network) acts as a Data Mediator to |
| clients committing a change. That is, the network logs any changes that |
| are made to the data graph by the client between commits. When the |
| client commits, the network uses the data graph's Change Summary to |
| determine what has changed and make it available to other group members |
| (the specifics of how this is done depend on the chosen |
| implementation). |
| </p> |
| <p>When a client listens to changes from the network, the client itself |
| acts as a Data Mediator to the network; that is, the client logs any |
| changes that are made to the data graph by the network between updates. |
| When an update is received, the client is notified and may use the data |
| graph's Change Summary to determine what has changed (at which point it |
| may process the changes in an application-specific manner). |
| </p> |
| <p>In the generic case, a client may both commit and receive updates at |
| the same time; it may make changes to the local data graph (with the |
| intention to commit at some point) and decide what to do when a remote |
| update is received (e.g., it may choose to discard its local changes, |
| or merge them in, etc.) |
| </p> |
| <p>To get started, the client must have a container instance and make |
| sure it is connected (i.e., part of a group) before changes can be made |
| and/or received. With this the client may obtain the service facade, |
| which will allow it to publish/subscribe to data graphs; for instance: |
| </p> |
| <pre>ISharedObjectContainer container = <container instance>;<br>IDataGraphSharing svc = SDOPlugin.getDefault().getDataGraphSharing(container);<br>// publish existing data graph instance<br>ISharedDataGraph sharedDataGraph = svc.publish(dataGraph, id, provider, consumer);<br>// --OR-- subscribe to a published data graph<br>ISharedDataGraph sharedDataGraph = svc.subscribe(id, callback, provider, consumer);<br>DataGraph dataGraph = sharedDataGraph.getDataGraph();<br>// make changes to the data graph<br>// ...<br>sharedDataGraph.commit();<br></pre> |
| <p>Notes: |
| </p> |
| <ul> |
| <li>the container need not be connected until publications or |
| subscriptions are attempted</li> |
| <li>committing changes and receiving updates will not be possible |
| once the container disconnects</li> |
| <li>data graph IDs must be unique within the given container</li> |
| </ul> |
| </body> |
| </html> |
