This document summarizes my proposals for enhancing the BES interface
with an operation for purging jobs. The "purge" operation instructs
the BES service to completely remove all information and temporary
files and disk space related to a specific activity or set of
activities. This operation is useful because, in practice. most
execution services do allocate at least some disk space to hold
temporary, activity-related informations, but with the standard BES
interface there is no way to reclaim such disk space.

The JobPurge operation can be implemented in different ways. The
proposals are described in the following:

1. Calling the TerminateActivities BES operation on an activity which
already is in a terminal state (Failed, Finished or Cancelled). Thus,
in order to purge a running activity, the user has to call the
TerminateActivities operation twice, the first to put the activity in
Cancelled state, and the second one to invoke the actual purge
operation. PRO: This solution does not require the definition of any
new BES operation; CON: This solution violates the current semantic of
the TerminateActivities operation: from Section 6.2.3: "Invoking this
operation on a Cancelled activity has no further effect. How long the
activity remains in the Cancelled state before the EPR no longer
returns a reference to the activity is not defined".

2. Use the ChangeActivityStatus operation, as being defined in the GIN
interoperability profile. This requires the state model of
GIN-compliant BES implementations to support an additional
(fictitious) state, "Purged". Of course no activity can ever be in the
"Purged" status, as a purged activity simply no longer exists in the
BES service. The "Purged" status is only used by the
ChangeActivityStatus operation to request the purge of an
activity. Thus, Job Purge is implemented by changing the activity
status to "Purged". PRO: This approach does not require further
extensions of the BES interface, and the same ChangeActivityStatus
operation can be used for two different, but related, purposes. CON:
According to the current specification of ChangeActivityStatus, it is
not possible to change the status of a bulk of activities, so it is
currently not possible to purge multiple activities with the same
operation. This limitation however will hopefully be fixed.

3. Defining an ad-hoc, new PurgeActivities BES operation. This
operation requires the purge of a set of activities. Implementations
MAY define activity statuses which are not compatible with the purge
operation, so that for example BES implementations MAY refuse to purge
an activity which is not in a terminal state (DISCUSS THIS!!!). The
PurgeActivities operation can be defined mostly like the
TerminateActivities. Input parameters are a set of EPRs; Output can be
defined as:

<PurgeActivityResponse>
  <ActivityIdentifier>EPR</ActivityIdentifier>
  <Purged> xsd:Boolean </Purged> |
  <SOAP-1.1:fault>...</SOAP-1.1:fault>
</PurgeActivityResponse>

Valid faults:

- UnknownActivityIdentifierFault: The requested EPR does not exist in
the container;

- NotAuthorizedFault: The user is not authorized to perform the
operation on the requested EPR;

- CantApplyOperationToCurrentStateFault: The activity status does not
allow the user to invoke the purge operation. Which status are
incompatible with the Purge operation needs to be discussed.

CON: A new, ad-hoc operation needs to be defined.