[ogsa-bes-wg] Proposed changes to Spec.

[Darren Pulsipher]

I have spent some considerable time with the document.
I know far more than I planned, but it was good time spent.
I think we should discuss these items in our meeting on Thursday.
I have posted some changes to the document but would like to discuss
these items before I make these changes to them.

There are some fundamental problems/questions that we need to resolve.

1. How do we resume from where we left off. There is no Resume anymore
so we are putting the responsibility to the submitter or controller to
keep track of states. We can only use RequestActivityStateChanges to
suspend something and if I want to suspend 1000s of activities that
means I would need to first do a GetActivityState save the states and
then call RequestActivityStateChanges without any of the activities
changing state. That is not going to happen. So I propose we do the
following:
- Add the following interfaces:
SuspendActivites(WS-Name[] activityIdentifiers)
ResumeActivities(WS-Name[] activityIdentifiers)

Or we add one interface
PerformOnActivites("Suspend" | "Resume", WS-Name[] activityIdentifiers)

2. Another problem is how do we terminate an activity. The States that
are available are "Terminated" and "ShuttingDown". According to the
state net the activity is moved to the "ShuttingDown" and then to
"Terminated" so requesting RequestActivityStateChanges for activities
with "ShuttingDown" means it should move to the ShuttingDown state but
it will move the activities to the "Terminated" state. This can be very
confusing. So I suggest we add another interface.
- Add the following interface:
TerminateActivities(WS-Name[] activityIdentifiers)

Or add another possible argument to the interface.
PerformOnActivites("Suspend" | "Resume" | "Terminate", WS-Name[]
activityIdentifiers)

3. Another question that is not clear in the spec is if an action
(staging in or staging out) moves into an exception state does that mean
that the activity moves into the exception state right away or does it
mean that it ever moves into the exception state. Does it mean that if
one of the actions moves into an exception state that all other actions
are halted and moved to the exception state and then the activity?
- I proposed that actions state have no impact on the activity state. If
an action has an exception or is terminated then it should not have any
impact on the activity what so every.

4. Another not so important change but it might help clarify some
confusion and allow for extendibility later on would be to get rid of
the "ExecutionPending" and "ExecutionComplete" and make the "Running"
state a composite state like the "StagingIn" and "StagingOut" states.
This will give the ability to handle complex multiple application
execution definitions that the JSDL group is looking at for the next rev
of the Job Definition. This will allow for multiple Application actions.
This is not workflow. Nor should it be considered the start of workflow.
This just allows for extendibility easily.


Darren Pulsipher