[ogsa-bes-wg] Updates to document

[Peter G Lane]

Some questions/comments...

I'm concerned about this term "container" as used in the document. This
is very confusing as this term is already used to refer to the web
service hosting infrastructure (i.e. Tomcat, GT's "standalone
container", or figure 1's "service container").

In section 2 under the "Naming" bullet. What exactly is being named?

Is the last bullet under section 2 saying that a BES-compliant service
cannot support logical file names? Does this include converting file
paths to, say, GridFTP URLs that might differ in the file path with
respect to the GridFTP server? Does this mean that variables cannot be
used in file paths?

I don't know much about WS-Names (anybody have a pointer to documents?),
but it seems problematic for interoperability that in section 3 the
method of exposing metadata about the AED type used is deliberately left
up to the implementation. This makes it impossible to automatically find
this information without either a defacto standard or some mapping of
implementation to metadata discovery method. Why not at least specify
how this metadata is discovered? A standard resource property would do
it.

I have issues with the hardware and software resource properties. Do
these describe the capabilities of the machine the service is running on
or a cluster/SMP machine sitting behind the service? If the former, this
is only useful if the activity runs on the same machine as service and
seems like it should be optional. Also, what about the metadata
describing the cluster or SMP machine? If the latter, then it is
limiting in that a cluster may have machines with different OS, CPU
configuration, available memory, architecture, etc...

In section 5.1.1 I find the IsAcceptingNewActivities RP rather useless.
The client will find out just as easily if the service is accepting new
activties depending on whether a NotAcceptingNewActivities fault is
thrown or not. Checking the RP first both creates an extra WS operation
call and cannot be guaranteed since there is a potential race condition
between when the RP value is returned and the submission call is sent.
If there was some negotiation protocol incorporated into BES I might buy
this, but otherwise I don't see the point.

In section 6.1, I feel it's superfluous to suffix the operation name
with "FromJSDL". Are there plans to support something other than JSDL?
If not, why not just make this "CreateActivity"?

Section 6.1.1: "Document" suffix seems also superfluous. Of course it's
a document. What else would it be? Also, I don't see why
"createInSuspendedState" needs to be outside the JSDL document. This
should be an extension to JSDL especially considering that the state
model doesn't have a base "suspended" state. So if a service doesn't
support suspended state extensions, this flag is meaningless.

Section 6.1.2: absolutely unique idempotence IDs are impossible to
guarantee. I'm of the opinion that these should be valid only for the
life of a job. Besides being ridiculous to assume that the service
should keep track of these IDs to make sure it is never ever used again,
doing so serves no real purpose.

Section 6.1.3: If there is an optional subscription request element in
the input, then there needs to be an optional subscription reference
element either in the output (preferred to avoid an RP query round trip)
or a resource property.

6.1.4: The names of the fault types isn't consistent. Either suffix with
"Fault" or don't.

Spelling typo in section 6.2, page 19, 1st paragraph: "proceeding" ->
"preceding".

6.2: I would prefer that the "*Status" elements not have "state" and
"laststate" attributes but instead have two child elements "state" and
"lastState" (or something similarly named). These elements would in turn
have a child element that has a well defined (i.e. in this document)
enumerated state representing one of the states in the general state
diagram (i.e. New, Pending, Running, Canceled, Failed, or Finished) and
one optional xsd:anyType element (or just an xsd:any) that specifies the
state extension if one exists (i.e. StageIn, Suspended, etc...). At very
least something needs to be changed to account for the new state model.

6.3: I was liking the new state model until I saw this operation. I
don't like this idea at all of allowing the user to monkey with the
state machine directly. I would be much happier if there were specific
operations to inject specific inputs that the state machine should
consider. The state machine should never be open to direct manipulation,
but instead should decided for itself what state and when to transition
to that state based on the current state and events. At *very* least
this operation should have a fault that means "too bad, I'm not doing
that". If the desire is to allow for, say, reseting of the job back to
New so that it will run again or canceling without destroying the job,
then specific operations can be added to the spec as is. Since
sub-states like "suspended" are treated as extensions now, a
"SuspendActivities" operation would seem more appropriate as an
extension as well.

6.4 and 6.5: Could someone provide a use case for wanting to start and
stop the acceptance of new activities via the WS interface.

6.6: This should be a resource property not a new operation.

I'm already commenting past page 20, so I'll stop here. One last
observation, though. I noticed that this document makes no attempt at
defining an activity resource. Is this intentionally out of scope?

Peter

On Mon, 2006-05-22 at 14:58 -0400, Andrew Grimshaw wrote: 
> All,
> 
> I have done the updates to the document discussed in the last two
> phone calls, and in the EMS meeting in Japan.
> 
> At a high level this includes modifications to adopt text/issues from
> the ESI document and the HPC profile working document. Note that this
> is NOT a final document.
> 
>  
> 
> These changes revolve around:
> 
> 1: Changing CreateActivityFromJSDL to 
> 
> a)    take additional optional arguments, specifically notification
> arguments and an “idempotent” argument lifted from ESI.
> 
> b)    An extension to JSDL suggested in ESI to support libraries
> 
> 2: Adding a resource information model section. Originally to be from
> 4.1 of the ESI document – but post discussion with Snelling, Stokes,
> et al a modified 4.1.
> 
> 3: State model. This is one of the biggest jobs. At GGF in Japan the
> HPC profile group introduced a nice, simple, extensible state model
> that would allow supporting a variety of state machines while still
> allowing basic clients to understand what they were getting. After
> discussions with many people I have decided to adopt that simpler
> state model. CLEARLY THIS WILL NEED DISCUSSION BY INTERESTED PARTIES.
> I AM NOT TRYING TO PULL A FAST ONE.  I have taken the text verbatim
> from the HPC profile paper. Note that I do not yet have permission
> from their lawyers – so we may need to yank this and retype the same
> info. I hope not.
> 
> 4: Refer to managedjob “type” of EPR, just as we refer to “WS-Name”
> “type” of EPR. 
> 
>  
> 
> I have not even tried to modify the WSDL and renderings. Once we
> decide on the rest of the content we can do that. So don’t read past
> page 20!
> 
>  
> 
> I am not sure of the status of the weekly call this week.  I will
> synch with Darren and Steven and send mail tomorrow.
> 
>  
> 
> I’m also including some slides from the discussion of BES in the EMS
> session.
> 
>  
> 
> A
> 
>  
> 
> Andrew Grimshaw
> 
> Professor of Computer Science
> 
> University of Virginia
> 
> 434-982-2204
> 
> grimshaw at cs.virginia.edu
> 
>  
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3720 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060522/b8b060c4/attachment.bin