RE: [acs-wg] Replication discussion material
Sachiko, this is very helpful, as usual, thanks so much for the valuable input. I have attached a few new slides that I hope might serve to provide the necessary data elements required by a replicative data storage service. I had hoped to include all of the rules that would apply to maintaining the element values for bi-directional replication (when updating, when creating, when deleting), but they are fairly complex, and I just haven't found adequate time so far. But, for what it's worth, (see attached). Pete. -----Original Message----- From: owner-acs-wg@ggf.org [mailto:owner-acs-wg@ggf.org] On Behalf Of Sachiko Wada Sent: Wednesday, August 10, 2005 11:07 AM To: acs-wg@ggf.org Subject: [acs-wg] Replication discussion material Pete and all, Here is the input material for the replication discussion. The purpose of this document is to examine the feasibility of constructing a replication service on top of ACS. There are the two scenarios: Scenario 1: One-way synchronization, triggered by modification of the master ACS. Scenario 2: Two-way synchronization, triggered periodically. Conclusion: The replication service can work with ACS if it supports the update event notification as far as considering the two scenarios. My impression and proposal: The replicator is supported to be highly sophisticated especially in case of bi-directional synchronization. So I propose that ACS should provide infrastructural functionalities such as notification mechanism for the outer replication services instead of supporting replication capability by itself. This time I examined two scenarios to find out that the event mechanism is required to realize them. There may be more replication scenarios which have requirements for ACS spec. For example, the capability to get change histories of an AA should be useful. Your comments are very much welcomed. Sachiko
Hi Pete, I read your document. Slide 3: This diagram seems to represent a generic replication concept. Concerning ACS replication, I assume that an ACS corresponds to a Replication Element. Am I correct? If so, GUID is AA ID or AA EPR in ACS term, and ElementValue is Application Content. Yes, I agree that ACS should handle change history meta data. As I wrote in the previous mail, I prefer the replication specific information be maintained by an outer replication service rather than ACS itself, since those information varies according to the QoS of the replication service. Slide 4: Is this a scenario of replicating multiple AAs controled by a single policy? Sachiko At Wed, 10 Aug 2005 11:18:43 -0400, Ziu, Peter wrote:
[1
] Sachiko, this is very helpful, as usual, thanks so much for the valuable input. I have attached a few new slides that I hope might serve to provide the necessary data elements required by a replicative data storage service. I had hoped to include all of the rules that would apply to maintaining the element values for bi-directional replication (when updating, when creating, when deleting), but they are fairly complex, and I just haven't found adequate time so far. But, for what it's worth, (see attached). Pete.
-----Original Message----- From: owner-acs-wg@ggf.org [mailto:owner-acs-wg@ggf.org] On Behalf Of Sachiko Wada Sent: Wednesday, August 10, 2005 11:07 AM To: acs-wg@ggf.org Subject: [acs-wg] Replication discussion material
Pete and all,
Here is the input material for the replication discussion.
The purpose of this document is to examine the feasibility of constructing a replication service on top of ACS. There are the two scenarios: Scenario 1: One-way synchronization, triggered by modification of the master ACS. Scenario 2: Two-way synchronization, triggered periodically.
Conclusion: The replication service can work with ACS if it supports the update event notification as far as considering the two scenarios.
My impression and proposal: The replicator is supported to be highly sophisticated especially in case of bi-directional synchronization. So I propose that ACS should provide infrastructural functionalities such as notification mechanism for the outer replication services instead of supporting replication capability by itself. This time I examined two scenarios to find out that the event mechanism is required to realize them. There may be more replication scenarios which have requirements for ACS spec. For example, the capability to get change histories of an AA should be useful.
Your comments are very much welcomed.
Sachiko
[2 ReplicaElement.ppt
]
participants (2)
-
Sachiko Wada
-
Ziu, Peter