Minutes including Alain's notes are attached. Best regards Wolfgang -- Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) Schloss Birlinghoven, D-53754 Sankt Augustin, Germany Tel: +49 2241 14 2258 Fax: +49 2241 14 42258 http://www.scai.fraunhofer.de "Heut ist nicht so kalt wie gestern, trotzdem dass heut kaelter ist" Minutes from Feb. 7, 2005 Teleconference Attendees --------- Takuya Araki Toshiyuki Nakata Wolfgang Zeigler Heiko Ludwig Asit Dan Alain Andrieux Karl Czajkowski Agenda ------ GGF session confirmed for March 16, 1:30 p.m. - 3 p.m. Working through the comments: #1, Changing Offers: After short discussion based on the material Toshi added to this track on the gridforge web-page, and previous discussions on this subject the participants agreed. Decission taken: The example mentioned in the spec is wrong, offers are not expected to change. The wsdl has to be corrected #2, Asynchronous Operations: Toshi: we need asynchronous messaging if the creation of an agreement takes long time to come back from the factory Heiko: according to WSDL specs we would do specify the asynchronicity at the binding level of the factory service specification, not at the port type level. Karl: then we need negotiation again! Asynch is like a very thin layer of negotiation. We would have a different port type: an asynchronous factory to compose with what exists already in the spec if we think binding level is not enough. A messageId like in GRAM would provide a mechanism to recover from the absence of response after the creation message is sent to the factory. In GRAM, if the user does not obtain a response within a timeout delay he chose, s/he/it can choose to decide to retry the submission by using the same message ID. If the job has been created already with that message ID, the factory does not create another job resource but simply returns the EPR (again). In WS-Agreement we could apply this concept instead of asynchronous notifications by having the client/initiator re-issue the same message to the factory, with the same message ID, after a delay chosen by the client. Note: messageID is a concept designed in WS-Addressing in order to detect duplicate messages. Karl will provide the mailing list with information on different ways to handle this problem examined in the context of GT4 implementation. Decission taken: Further discussion to prepare a decission should happen on the mailing list. #3, Related Agreement: Decission taken: Introduces too much complexity into the spec, related agreements are dropped from the spec for the moment. A short discussion after this decission (about probably shifting this kind of features into the (domain specific) context raised other questions like what is a domain, isn't the compatibility reduced when adding too much domain specific issues.., These questions could not be discussed as time for the telecon was over but need a final clarification. Discussions on certain aspects of the spec seem to be difficult as at this stage implementation experience is missing and also interoperability tests between different implementations.