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
-------------------------------------------------------
IONA
Technologies
200 West Street Waltham, MA 02451 USA
Tel: (781)
902-8366
Fax: (781)
902-8009
-------------------------------------------------------
Making
Software Work Together TM
