Open Grid Forum 33 Lyon, France September 20, 2011 Minutes for three GRAAP-WG sessions ----------------------------------- GRAAP session #1 - IPR - For main content, please refer to the slides: https://forge.gridforum.org/sf/go/doc16334?nav=1 - Welcome - Update since OGF32 - State of the WG - State of the documents - WS-Agreement Negotiation implementation (plans) - Plans for RESTful rendering - Other topics - Update since last OGF Mainly worked on the WS-Agreement Negotiation spec changes resulting from last call - State of the WG Chairs: Need to re-activate the mailing list to get people more actively participating in the work All: Need to update the list of implementations of WS-Agreement on the gridforge pages on the page with the List of Implementations of OGF standards All: Need to add sections on WS-Agreement and WS-Agreement Negotiation on the Resource Center page (specification summaries) Discussion about organising a small workshop dedicated to WS-Agreement and WS-Agreement Negotiation issues covering the whole SLA lifecycle All: Need more microspecs of domain specific term languages for making interoperability easier. The two informational documents started during OGF31 should be completed and sent to the editor before the next OGF. Carlos MŸller (University Valencia) started with a repository of use-cases in the context of the ADA tool(see http://193.147.175.241/ada/). More contributions from other implementations welcome. Chairs: Resume the biweekly (most probably short) phone conferences All: Need a second chair that replaces Jim Pruyne - State of the documents WS-Agreement errata ready, waiting for the editor to assign a GFD number WS-Agreement Negotiation ready, waiting for the new GFD number of WS-Agreement to update the references in the spec Both documents should be published at the end of OGF33. - WS-Agreement Negotiation implementation (plans) Currently there is one implementation in the WSAG4J framework (Oliver) A second was announced to be done at the University of Delft. - Plans for RESTful rendering See discussion in the second session - Other topics discussed Carlos suggests adding mechanisms making SLAs more temporal expressive (microsepc?) - Start preparing the experience doc for WS-Agreement Negotiation - two code independent implementations required - interoperability scenario to be defined - organise a template repository - Storage description in SLAs (GLUE?) - Costs in SLAs - response time and availability in SLAs - Oliver proposes a document with a general description how the language works and a second part with an OGF rendering for one eco-system as example, plugin in other standards (JSDL, byteIO), + the OPTIMIS rendering - A description of how to map high level SLA models (like the one of SLA@SOI) to low level constructs of WS-Agreement and how to design SLAs on a higher level would be beneficial. Chair: Ask list about challenges the members would like to propose, like using a little template provided by the group in a concrete implementation, etc. + GRAAP session #2 - IPR - For main content, please refer to the slides: https://forge.gridforum.org/sf/go/doc16335?nav=1 - Brief presentation of work planned/recently on RESTful rendering started at University of Dortmund - Discussion - Planning Discussion about the approach using the Restlet framework since there are known problems. Probably start with an overview on frameworks and decide then. Chairs: Initiate gathering requirements regarding the RESTful rendering, e.g. scope, depth, functionality... All: The three approaches (see slides) should be evaluated and then - probably based on the initial TU Dortmund implementation presented during OGF32 - combined end complemented if necessary (based on the requirements). The most critical point is probably the URL mapping (4th point of the TU Dortmund slide). Also, how resources are rendered constantly. Main discussion was on how to start and to which degree the RESTful rendering should be driven: - A rpc-type approach processing a full WS-Agreement seems to be feasible without bigger problems. Would deliver a fast solution but without making much use of RESTful technology. - Alternatively, an incremental RESTful definition of an agreement with each step realised using e.g. http could be specified. One approach could be starting with the rpc-type and once this is completed doing the incremental definition whereas the level to which the RESTfulness is applied has to be discussed and controlled during the specification/implementation. Chairs: post both alternatives to the list and ask for comments. If there is a use-case/request for the incremental approach we will do it. Chairs: Ask list about priorities for RESTful rendering, term languages (microspecs), mapping higher level languages to WS-Agreement, then define actions based on the result