· Security design. I would argue that this is a WS binding issue and is out of scope of
· Interface for directly controlling/manipulating an activity once it has been created. Yes, I was concerned about this as well but never said anything. Generic operations for manipulating or introspecting activities (i.e. factory operation that takes an activity ID) can be useful, but I definitely agree that there should be an activity service interface with operations that imply the activity via the EPR. · Extensibility:
· Given that BES has bought into the notion of an extensible activity state diagram, it needs to also normatively define how clients can learn of the extensions that a given BES service supports. Is that something that will be added to the BES specification? Or will the specification point to some other place where notions of extensibility are defined more generically? (Personally, I’d vote for the former approach.) Good point. I'd also prefer adding something explicitly to the spec. · Is the “base case” for BES now fig.2, which shows states of {new, pending, running, canceled, failed, finished}?
· Previously included states, such as Execution-Pending, will presumably be defined in suitable extension profiles? My understanding is that this kind of thing is out of scope of the spec. I would assume that if there were any defacto standards being used in the community that this would at most be a separate OGSA-BES WG spec. · Given that suspension is no longer in the base design, presumably the createInSuspendedState parameter to CreateActivityFromJSDL should disappear? Yes, this is something I picked on as well. It should be a JSDL extension anyway, but certainly this becomes mandatory if suspension is an interface extension. · RequestActivityStateChange: I believe this operation will pose challenges in an extensible design. The current design is imperative by nature: it specifies an explicit state to move an activity to. However, a client who does not know of all the extensions that a BES service implements may not know how to pick the appropriate state to transition to. It seems better to introduce a more declarative approach in which clients specify “actions” they wish to occur, such as ‘CancelActivity’. This approach would allow the BES service to make the appropriate state transition in response to a desired action requested by a client. Yes, this is what I argued as well albeit from a slightly different angle. · Information model:
· JSDL seems to inherently be focused on describing a single job or a single computational resource. For example, it has no notion of describing all the differing compute nodes of a (heterogeneous) compute cluster. By incorporating JSDL elements into the BES information model it seems that BES is foreclosing the ability to describe things like compute clusters. This issue also effects what can get returned from GetActivityJSDLDocuments. If I’m wrong about this, then it seems like it would be worth having an explicit explanation about how to achieve this functionality somewhere in the specification. I think I complained about this here as well. Certainly I've complained to the JSDL people and the ESI people about this. The JDSL
· Is there any notion of specifying that all compute nodes should have the same value for some attribute (e.g. CPU architecture, CPU speed, NIC card)? This seems to be missing from the JSDL specification, but seems very important for BES if it is to support things like compute clusters. This relates to my last comment. All these related specs have assumed
All this leads to the question of whether BES will have a notion of extending the information model that is supplied. If so, then that leads to the question of what the base case should be and whether it should include a smaller set of things than is currently listed in the spec. Good point. · These operations seem to require a different set of authorization credentials than the other interface operations since they should be invoked by system administrators rather than random users. How will that work, given that these operations are in the same WSDL as the other operations? Wouldn’t this argue for moving these operations to a separate system management interface? This is why I suggested that security was out of scope. The Globus Toolkit, for example, has no problems specifying different security
On Jun 5, 2006, at 5:19 PM, Marvin Theimer wrote: the spec. I think the best that could be said would be that some sort of security is implied since the implementation has to be able to differentiate between users. people answered something about keeping it simple for now. My guess is that people see it for the daunting task it is an prefer not to address it. I'm not criticizing anyone for this. It's just my take on the problem. that the node composition is homogenous. parameters for different operations. It's all proprietary configuration, though, and probably should be. That said, I believe I said something similar to this in my original comments on the spec. This sort of thing feels to me as well like it shouldn't be in a basic execution service and should be an implementation detail as to whether the management interface is exposed as well as the BES interface.
· Given that BES seems to have bought into the notion of extensibility, should the base case be a “non-array” one? For example, currently if you want to handle a fault for a RequestActivityStateChange operation on a single activity you need to look inside the returned array of results to see if a fault infoset was returned. All the exception handling machinery that modern tooling provides can’t get used because RequestActivityStateChange never returns an actual fault message (as compared to a fault infoset for the appropriate array elements that are returned. Good point, and more reason to have a separate activity interface. · Since JSDL documents are self-describing, a BES service can figure out by inspection whether the job description infoset parameter to CreateActivityFromJSDL is JSDL or something else. This would seem to imply that naming the operation CreateActivity would lose no information and would allow for transparent extension to other job description infoset simply by using them (assuming they are self-describing). Yes! I argued to chop the suffix as well, but this makes the point better. · Container attributes that I have questions about:
· LocalResourceManagerType: where do these get defined normatively? I would argue against explicitly defining values for this. It eliminates much of the flexibility the implementation has in terms of what local resource managers it can support. · Job Credential Service and File Credential Service: these imply a specific security model. Given that security is undefined in the BES spec, is this appropriate – especially given the rather vague definition of both? I think the simple statement that some sort of security is required should be sufficient to justify generic EPR properties.
Peter