So this speaks to my comment during the OGSA-F2F; the
position that all messages for BES require WS-Names will generate a fair amount
of comments during public comment.
Further, I believe there was some confusion about
where and when OGSA-BES session took place at GGF15; I personally was not
there.
Nevertheless, the position that Andrew expressed
is the 'rough consensus' of the OGSA-BES-WG.
WRT, the WS-Names usage policy in OGSA. From the GGF
F2F minutes:
The group went through the exercise of doing a number of straw polls
to identify the weight people put on various approaches.
<<Straw polls>>
- Agreed that we can choose MUST
- 1. MUST EPR (majority yes; no negative votes) - passed
- 2. MUST {EPR or URL} (yes:2; no:many) - rejected
- 3. MUST {EPR or RNS} (yes:0; no:many) - rejected
- 4. MUST EPR be WS-Name (yes:; no:) - rejected
- 5. SHOULD EPR be WS-Name (yes:; no:) - ?
- 6. RenewableReferences: MUST, SHOULD - rejected
- 7. RenewableReferences: MAY - passed
In summary:
"MUST support EPRs, may support WS-Names or RRs or other things"
It seems to depend on the situation whether to use something
beyond an EPR. Need more exploratory work to identify which areas
would benefit from using WS-Names or RenewableReference.
- Proposal to also just say they are EPRs that may be decorated
(and hence be WS-Names)
In response to the proposal (last item) there was a note
that went to OGSA-WG and OGSA-Naming-WG. Fundamentally, the proposal is
still outstanding and needs to be settled or closed.
Tom
Andrew:
We should ask the OGSA-WG to speak
definitively on the first issue, as there seems to be confusion among
participants as to what the policy means.
Regarding OGSA-BES's use of
WS-Name: I appreciate the information on the decision procedure.
More
generally, I guess this exchange reflects a common tension between the relative
importance of the views of "insiders" vs. "outsiders" in GGF WGs. I know that
quite a few people (myself included) started off wanting to engage as insiders
in OGSA-BES, but after various unsatisfactory interactions (e.g., discussions
like this one, where the response to a concern is to be told that it will be
disregarded), ended up becoming outsiders. The OGSA-BES is of course free to
work as it wants, but excluding the views of so many people also greatly reduces
the likelihood that whatever specifications OGSA-BES produces will be widely
adopted.
I don't understand the discussion of events: I didn't speak to
eventing in my email, but about the right way of specifying the activities to
which an operation should apply.
Regards,
Ian.
At 01:05
PM 10/26/2005 -0400, Andrew Grimshaw wrote:
Ian,
My understanding of the OGSA policy is that OGSA does not mandate
WS-Names & instead it encourages them WHERE THEY ARE APPROPRIATE. That
decision is up to individual working groups, and perhaps a design team working
on a profile. The policy, in my mind, is NOT that WS-Names may not be mandated
by OGSA specifications.
In the case of OGSA-BES, at the last GGF in Boston the
working group discussed at great length the pros and cons of WS-Names, opaque
EPRs, and abstract names (i.e., uris with a few properties). The overwhelming
majority preferred WS-Names (an explicit, comparable return value) (8 to 2). A
further discussion was held as to whether the WS-Names should have both
abstract names AND resolvers, and the vote was 4 to 1 for having a resolver,
with many people indifferent.
Thus, OGSA-BES will have* WS-Names as return
values and input parameters.
We also discussed eventingat some length. I
have not yet typed in my notes, the three high order bits
were:
1) The container is the right place to emit the
events
2) Clients must explicitly subscribe to events (use
filtering from the container, not specific registration& Im not sure what
that means, I think we will need to discuss this in a call and remind
me.)
3) Events are state transitions of the
activities
Andrew
*Of course the document still has to go into public comment, get
revised, and hopefully some day be approved by the GFSG. What is really in the
document may change between now and then.
From:
owner-ogsa-bes-wg@ggf.org [mailto:owner-ogsa-bes-wg@ggf.org] On Behalf Of Ian
Foster
Sent: Wednesday, October 26, 2005 11:40 AM
To:
Darren Pulsipher; ogsa-bes-wg@ggf.org
Subject: Re: [ogsa-bes-wg]
Proposed changes to Spec.
Darren:
I would like to argue
against your proposed operations on the grounds of fragility and
scalability. Your operation definitions require that a client keep track
of the set of activities to be monitored and controlled. That's a big burden
to place on the client.
I suggest (as we have also suggested in
earlier communications to BES-WG) that we should instead allow the user to
specify a set of activities that are to be monitored or controlled in terms of
their properties, not names. E.g., "activities that belong to me", "activities
that involve executable Foo", "activities that have been running for over 2
hours."
A natural way of modeling this is to represent the set of
activities associated with your jobs as a WS-ServiceGroup Service Group, and
then use queries on the service group to specify the activities to which an
operation applies.
Regards -- Ian.
PS: As noted in previous
emails and conversations, I also believe that the use of WS-Names rather than
vanilla EPRs is inappropriate. I also believe that it is inconsistent with the
OGSA policy that WS-Names cannot be mandated in OGSA-related
specifications.
At 08:52 AM 10/26/2005 -0600, Darren Pulsipher
wrote:
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
_______________________________________________________________
Ian
Foster
www.mcs.anl.gov/~foster
Math & Computer Science
Div. Dept of Computer Science
Argonne National Laboratory The University
of Chicago
Argonne, IL 60439, U.S.A.
Chicago, IL 60637, U.S.A.
Tel: 630 252
4619
Fax: 630 252 1997
Globus
Alliance, www.globus.org
_______________________________________________________________
Ian
Foster
www.mcs.anl.gov/~foster
Math & Computer Science
Div. Dept of Computer Science
Argonne National Laboratory
The University of Chicago
Argonne, IL 60439,
U.S.A. Chicago, IL 60637, U.S.A.
Tel: 630 252
4619
Fax: 630 252 1997
Globus Alliance,
www.globus.org