All ,
I was just thinking about how to reuse the workflow request journeling
mechansims
that Guy and I developed last year. It occurred to me that we could be
journeling
all requests as a repostiory behavior, not only for workflow concerns. This
gives us
one mechanism for restoring history, analyzing DOS attackes, etc. We can
also
resurrect the resource versioning mechanism that I did originally and expose
access
to version histories as a service aspect for any resource.
a. Migrate workflow request, error, log mechanisms into the core
repository to provide optional journeling for all requests. The
journel entry should include the request headers, should
optionally include various information about the HTTP
Connection, especially the source IP, etc. for use not only in
being able to playback the journel to re-create a repository
state but also in analyzing DOS attacks. Use the journel
IDENTITY column to assign a unique local name to resources
created during POST requests (unless overriden by
Local-Name-Hint). This will make it possible to replay the
journel without breaking any depending external URIs.
b. Add optional support for snapshot based version history to the
representation table. Consider whether this is the primary
representation table or a secondary (and possible a set of
secondary) representation tables specifically for version
histories. Note that XML diff algorithms could be used here,
but we are already getting most of the benefit of from the
request journel that if people use XPointer and PUT to make
changes in resource state.
c. Entries in both the version history and journel replay
mechanisms can be sunset based on coherent repository state
snapshots (as an optional admin task) since the repository can
always be replayed from either the zero state or any other known
state using the journel. If the version history mechansism is
used to restore the state of a resource, then it must be done
using another PUT (walking in forward time only) otherwise the
repository state can no longer be used for journel playback
restoration. That is: always make corrections through the HTTP
interface, whether correcting by re-establishing the state of a
resource from the version history or by re-establishing the
state of the repository by playback from a known historical
state. Provide a mechanism to mark resources and requests that
should not be re-created during playback so that the journel can
be annotated such as to not re-create a journeled DOS attack
during playback.
d. Playback can encounter stale authentication tokens that cause
problems with either the direct manipulation of the repository
(if there is local network security between the repository and
the playback mechanism) and with delegated requests. Such
authentication can be circumvented by tunneling the playback
requests. However, requests that require delegating authority
across network boundaries will always need to provide a
challenge to the original agent. Clearly this can only succeed
under certain network architecture plans.
Happy holidays to all,
-bryan
|
