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...