This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/go/projects.ggf-editor/discussion.rec_ogsa_basic_execution_service.topc4070 at Sun, 06 Nov 2022 09:02:43 GMT SourceForge : Post

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Project: Editor     Discussion > REC:OGSA Basic Execution Service v 1.0 > Nordugrid/KnowARC comments on draft: main suggestion to clarify the Bes-Activity Port-type > List of Posts
Forum Topic - Nordugrid/KnowARC comments on draft: main suggestion to clarify the Bes-Activity Port-type: (2 Items)
View:  as 
 
 
Nordugrid/KnowARC comments on draft: main suggestion to clarify the Bes-Activity Port-type
NorduGrid Collaboration and the Knowarc EU project welcomes the public 
comment draft (http://www.ogf.org/Public_Comment_Docs/Documents/Apr-2007/ogsa-bes-v33.pdf)
of the OGSA Basic Execution Service version 1.0. The BES specification is one of the key OGF documents the next 
generation Advanced Resource Connector (ARC middleware) will support and implement. Please find our comments below:


==Major conceptual question: Please clarify the role of the BES-Activity port-type==

The specification presents three port-types for the BES interface: 

1) BES-Management with Stop/StartAcceptingNewActivities operations

2) BES-Factory with CreateActivity, GetActivityStatuses, TerminateActivities,
GetActivityDocuments, GetFactoryAttributesDocument operations

3) BES-Activity with GetStatus, Terminate, GetDocument,
GetActivityAttributesDocument operations.

From the current draft it seems as if the BES-Activity port-type have not yet been
completely defined or going to be removed/obsoleted. Table 1 on page 6 lists the above three
operations of the Bes-Activity port while later, on page 22, Section 2.2 states
that "No operations are defined for the BES-Actvity port type." Furthermore,
there is no WSDL available for the BES-Activity in the Appendices (Appendix F
states "none needed").

We recommend that the final version of the BES specification should be 
made consistent wrt. the role of the BES-Activity port-type, either fully remove this 
port-type or provide complete definition on the same level as the BES-Factory
port-type.

If the BES-Activity port type will be decided to be kept we'd like to read
recommendations (use cases?) how this port type is supposed to be used in view of
its the obvious overlap with the Factory port type: The Terminate, GetDocument,
GetStatus BES-Factory operations all have their conterpart operations within the
Factory port-type, you can almost do the same thing through the two port-types concerning 
activity management.

If the support for application steering is the main idea behind the BES-Activity port then
the port should offer operations enabling this use case.

Furthermore, we'd like to get a clarification on what the prefered method is to obtain 
detailed job information (jobattributes) suppose the BES-Activity port would be depreciated.
The GetActivityDocuments operation of the factory port is "natural" candidate, however using
JSDL documents and schema to decribe detailed actual "job snapshot" may not be in line with 
the original purpose of the GetActivityDocuments operation, not to mention
the limitations the JSDL may show when it comes to the description of active jobs within
a BES. Maybe there is a need of GetActivityAttributesDocument operation on the BES-Factory port 
level as well?


==Extensions Nordugrid will implement and would like to see as part of BES==

- It would be nice to have possibility to have job state changes which do not
fit into BES job flow on request of client to be allowed. That would make 
system more flexible and allow e.g. for resuming jobs which failed due to 
external reasons. We propose a ChangeActivityStatus operation for the
BES-Factory.

- The state model currently used within the Advanced Resource Connector will
require the extension of the simple BES model (Pending/Running/Failed/Finshed/Terminated).
Our extension will follow the "State specialization" instructions.
However, there is one ARC state difficult to map to the BES model:
jobs which are not available any longer on the computing service but were served
some time ago (within a grace period) enter into the "DELETED" state. 
Something similar would be nice to have as part of the basic state model.

- It would be nice to have a standard way of being able to request 
operations on all the activities served by the BES without explicitly 
listing all the EPRs. Example: GetActivityStatuses on all the activities
served by the BES. Within the GUG...
View Full Message
Re: Nordugrid/KnowARC comments on draft: main suggestion to clarify the Bes-Activity Port-type
> ==Major conceptual question: Please clarify the role of the BES-Activity port-
> type==

The BES-Activity is an optional and undefined mechanism in this specification for manipulating directly an activity 
running in a BES container rather than using the operations that can operate on mutiple EPRs provided by the BES factory
 port types.

> From the current draft it seems as if the BES-Activity port-type have not yet 
> been
> completely defined or going to be removed/obsoleted. 

This has been clarified. Table 1 has had the activity port type removed and it has been combined with the BES Activity 
section on page 22 and moved to the optional extension section to make it clear this is not part of the core 
specification. Appendix F has been removed.

> If the BES-Activity port type will be decided to be kept we'd like to read
> recommendations (use cases?) how this port type is supposed to be used in view
>  of
> its the obvious overlap with the Factory port type: The Terminate, GetDocument
> ,
> GetStatus BES-Factory operations all have their conterpart operations within 
> the
> Factory port-type, you can almost do the same thing through the two port-types
>  concerning 
> activity management.

The BES container manages groups of activities. The BES-Activity port type (if implemented) allows individual activties 
to be managed.

> Furthermore, we'd like to get a clarification on what the prefered method is 
> to obtain 
> detailed job information (jobattributes) suppose the BES-Activity port would 
> be depreciated.

The GetActivityDocuments is the recommended way to find out about the activity that was started. Detailed information 
beyond the state of the activity would have to be oibtained through an implementation of the BES-Activity port type in 
this container.
 
> ==Extensions Nordugrid will implement and would like to see as part of BES==

These are interesting issues and introduce use cases that have not been considered to date. Including them in V1.0 of 
BES would probably not be an ideal solution. Working these up as extensions for BES 1.0 + would be a very valuable 
contribution. It would be intersting to see if these would then be implemented elsewhere.


> ==Further comments==

> - All over the document the numbering of the sections, section headers should 
> be
> checked (e.g. page 20 misses GetActivityDocuments section header)

Fixed.
 
> - page 6, top paragraph: "For illustrative purposes, we specify in Appendix I 
> the
> WSRF Resource Properties type definitions that map naturally to BES attributes
> "

These have not been contributed by any WSRF implementation AFAIK.

> - page 14, Section 5: wrong reference is given for the normative renderings 
> presented in
> the Appendices (Appendix C is bes-activity and not management)

Empty Appendices removed and references checked and updated.

> - page 15, second paragraph: it may be helpful to strictly stick to the
> terminology used in the normative schema when talking about attributes. 
> The schema defines BasicResourceAttributes and FactoryResourceAttributes.
> With the term "BES specific attributes" the paragraph most probably refers to
> the latter (FactoryResourceAttributes).

Fixed.

> - page 16, Section 6.1.7: "bes:" namespace is not defined. It should be 
> corrected
> as "bes-factory:"

Fixed.

> - page 19, Section 1.2.2 GetActivityStatuses: "request the status of zero or 
> more
> activities" shouldn't it be one or more?

Fixed.

> - page 19, Section 1.2.2.2, last paragraph" 
> ... from New to Finished will be transitioned through even though there
> is no underlying specified activity ..."

Fixed.

> - page 20, 1.2.3.1: The input of TerminateActivities is a vector of zero or
> more EPRs. What is the motivation behind allowing the...
View Full Message

 
 


The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/go/projects.ggf-editor/discussion.rec_ogsa_basic_execution_service.topc4070 at Sun, 06 Nov 2022 09:02:43 GMT