Re: [ws-caf] Context example assignments

["Mark Little" <mark.little@arjuna.com>]

OK, here's my sample (non-normative) use case for using WS-Context in a replication scenario.

 

First some background: there are a lot of different replication protocols, ranging from strong consistency (where all replicas have the same state and are essentially in lock-step) to weak consistency (where all of the replicas potentially have different states, usually divergent by some known delta). Within these categories there are specific protocols like Weighted Voting, Available Copies, Coordinator-Cohort and Primary/Secondary (often characterized as either active replication, where all replicas receive invocations, or passive replication, where typically only a single replica receives invocations).

 

In this example, I'll consider a weakly consistent replication protocol (more appropriate for Web services), that uses replica groups and an epidemic protocol for disseminating updates to state and group membership. What this means is that state updates and group membership changes don't necessarily get distributed to all replicas when they occur; they occur lazily in a viral manner by "natural" infection - replicas are told of such updates through periodic "gossip" messages or when application messages are received. This kind of approach has been around for quite a while and has the advantage that in a large-scale, loosely coupled environment it scales better and performs better than other approaches.

 

So, the kind of information we want in the replication context is:

 

(i) replica group identity (an application may be using many different groups).

(ii) replica group membership (as current as the sender knows). This may contain weight information for each replica (essentially a level of importance of that replica in the group).

(iii) timestamp associated with the group to indicate currency.

(iv) state updates, although these could be obtained from individual replicas. The fact that WS-Context is arbitrarily extensible does allow for updates to state to be propagated in an epidemic manner too, though, so we shouldn't lose sight of this fact.

 

In this situation the context is definitely not immutable and it is expected to be updated by senders and receivers (e.g., a recipient of a message containing a context may have a more up-to-date view of the replica group).

 

Updates to the replicas may be compensatable. Although the combination of replication and transactions have a relatively short history (about 10 years), replica protocols exist that have "transaction-like" semantics in that updates may be undone later.

 

The example scenario would bind the scope of an activity to the lifetime of a replica group. What this means is that when start is issues on the context service, a new replica group is created (for simplicity, let's just consider one group, but obviously this argument extends to an arbitrary number of suitably scoped groups). This newly formed group may have no replicas in it (in which case the context simply contains the group id), or it may have an initial set of replicas.

 

As the application progresses, replicas may fail and hence leave the group or may recover and be added back. More replicas may be added in order to increase the availability of the group. However, availability isn't necessarily proportional to the number of replicas in a group (and neither is performance). What this means is that although the size of the replica group may actually remain constant, it may be necessary for the replication protocol (or replica management system) to migrate replicas from machine to machine in order to keep (or improve) a level of availability. All of these group membership changes are reflected in the context when services and clients discover them (either explicitly or implicitly when they next use the replica group).

 

In addition, as I mentioned above because we can extend the context, it's possible that the protocol could take advantage of that and distribute replica updates within it.

 

Now, when the activity service ends the replica group is deleted. We know that an activity can end in either a fail or success mode and the replication protocol may take advantage of this. As I said earlier, some protocols may be batching updates and not actually making them visible outside the group until a "commit". We can use the successful termination of an activity to map to this, and likewise a failure termination will undo all state changes. Now, how this undo affects users of the replica group is outside the scope of WS-Context (and this email), but basically if it's a weak consistency protocol then the result may be to do nothing or it may be that the replica group has to inform users of the undo and they then have to take appropriate action. (The Andrew File System and CODA had a variation of this approach).

 

I think WS-Context offers a good match to something like a weak consistency protocol for Web services. However, that's not to say that strong consistency protocols can't be used either - they can, but less information would typically be required in the context.

 

Mark.

 

P.S. Apologies in advance, but I may not be able to make the teleconference on Monday.

 

----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.

 

www.arjuna.com

----- Original Message -----

From: Newcomer, Eric

To: ws-caf

Sent: Thursday, December 11, 2003 8:15 PM

Subject: [ws-caf] Context example assignments

Hi,

 

For Monday's concall it would be great to have some of the context examples circulated to the email list far enough in advance to be able to discuss them on the call.

 

In no particular order:

 

-- User Context example, Jan Alexander

-- Security context example, Eric Yuan

-- Database/File/Device example, Eric Newcomer

-- Cluster group membership example, Mark Little

-- Session state example, Greg Pavlik

 

I think that's it, someone let me know if I've forgotten to include them.  Apologies for the delay in getting the reminder out.

 

Eric       

 

 

 

 

Eric Newcomer
Chief Technology Officer
eric.newcomer@iona.com

-------------------------------------------------------
IONA Technologies
200 West Street Waltham, MA 02451 USA
Tel: (781) 902-8366
Fax: (781) 902-8009
-------------------------------------------------------
Making Software Work Together TM