[acs-wg] Replication discussion material

[Ziu, Peter]

The ReplicaElement is independent of any level of granularity of
replication.  For example, in your text below you see a one to one
relationship between AA and ReplicaElement (AA as the value for
DataElementValue[0] within a ReplicaElement).  Since a ReplicaElement
can only be added and deleted, and not partially edited, any
modification to the AA would be an entire replacement.  

So, if for example we made the AA a collection of ReplicaElements, with
each ReplicaElement being, say, a jar within the AA (many jars == many
ReplicaElements), changes to just a jar within an AA can be replicated
which would save replication time and bandwidth.

So, you can start to image a process by which replication is a procedure
in which two replicas (A and B) compare each others change lists:

A sends adds to B
B adds
B sends adds to A
A adds
A sends deletes to B
B deletes
B sends deletes to A
A deletes
A sends mods to B
B sends mods to A
A and B identify any ReplicaElements modified on both sides
A and B create duplicates and notify modifiers, force overwrite (he who
saves last wins), or throw an error (whatever the conflict resolution
policy is).
B mods
A mods

There is a lot more to define in the way of how adds, mods and deletes
are accomplished, and how the change or history lists are maintained and
cleaned up.  However, you can start to see that as long as the latency
period between replication events is tolerable by the data use case, the
timed or forced replication event (and even an event driven model) is a
model that is lightweight on the network, and tolerable of network
outages/intermittent connectivity, high traffic loads, and can be
interrupted, halted and restarted.  I think it is critical that the
entire AA does not need to be replaced to keep replicas updated.

Pete


-----Original Message-----
From: owner-acs-wg at ggf.org [mailto:owner-acs-wg at ggf.org] On Behalf Of
Sachiko Wada
Sent: Wednesday, August 10, 2005 12:58 PM
To: acs-wg at ggf.org
Subject: Re: [acs-wg] Replication discussion material

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  <text/plain; us-ascii (quoted-printable)>] 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 at ggf.org [mailto:owner-acs-wg at ggf.org] On Behalf Of 
> Sachiko Wada
> Sent: Wednesday, August 10, 2005 11:07 AM
> To: acs-wg at 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 <application/vnd.ms-powerpoint (base64)>]
>