The session quickly covered the Spec with very few minor changes and/or comments. Then we discussed the future of BES. The following are the notes that were taken about the discussion. Future BES additions, extensions,etc. What information model should be used to represent the container Consistent way of exposing types of JSDL Application can support. How do we expose the information so a scheduler can chose the container? Query for Activities based on attributes both static and dynamic When JSDL adds different Application types BES needs to handle this. For example an mpi jobs may change the state model or how many activities are returned from a createActivityFromJSDL. Can we make a generic state model that can handle all new application types that JSDL could have. Does the state model need to change for reservation? How is the activity bound to the reservation? Advanced Execution Service Reservation System (WS-Agreement) maybe add makeReservationFromJSDL Scheduling constraint policies on BES container Example is stop accepting activities for a period of time or when the load is at something etc. Outside groups need to do Activity Management Interface should be defined Management interface for OGSA services should be defined. WSDM ? Workflow Execution Service? Resource Utilization of the execution element that the container represents. QOS and capacity * Andrew Grimshaw raised the need of an interop fest. GridSAM (William Lee) and Mark Morgan (UoV) agreed to provide public endpoints. Mark Morgan has 'ogsa_run' .NET client for testing. GridSAM will provide an all java client. * Steven N. mentioned Chris Smith will bring up a query on the need of a 'Holding' state in the overall status. This will be raised in the public comments. * Steven N.: The states in BES are aligned with those in CIM. SAGA is looking at the BES state diagram. * William L. & Andreas S.: Can the client request any state changes? Yes. If the state change cannot be satisfied or illegal, the appropriate negative response would be returned. * Activity interface is out of scope. A BES profile document will mandate the JSDL application type to be allowed and the activity interface to be made available. * Steve L. commented that WS-I rendering can use WSRF BaseFault. Darren P. replied that for political reason the WSI rendering should be free from any WSRF artifacts. * Mark M. suggested we should have the ability to express advance reservation, scheduling constraints, utilization. * William L. suggested we should have the ability to express the JSDL optionalities a BES service supports. For example, POSIXApplication, file staging bindings. * NAREGI is using BES with extension in JSDL to handle advance reservation. * Stephen P. raised the question of whether it makes sense to expose resource utilization in the information model. Donal expresses concern in whether this is in scope for a 'BASIC' execution service. Stephen P. thinks this might raise false expectation. * Steve McGough suggested there's a need for querying job based on attributes. * Ali A. commented whether the generic state model can support other JSDL application types (e.g. Web Services). Can we abstract it further? Darren Pulsipher Darren Pulsipher Owner Email: mailto:darren@pulsipher.org darren@pulsipher.org IM: darren_pulsipher (Yahoo) Professional Profile http://www.linkedin.com/pub/0/8a8/115 Pulsipher Site http://www.pulsipher.org Ovoca http://maps.google.com/maps?q=&hl=en See who we know in common https://www.linkedin.com/e/wwk/2212001/ Want a signature https://www.linkedin.com/e/sig/2212001/ like this?