OGSA Teleconference - 31 August 2006 ==================================== * Participants: Hiro Kishimoto (Fujitsu) Andrew Grimshaw (University of Virginia) Mark Morgan (University of Virginia) Andreas Savva (Fujitsu) Michel Drescher (Fujitsu) David Snelling (Fujitsu) David Berry (NeSC) Stephen Davey (NeSC) Minutes: Michel Drescher ** Minutes review ** - 10 August 2006: Minutes incomplete; Takuya will send out a revised version to Andreas Savva who will merge them with his minutes. AI-0831a: Andreas Savva to send out merged minutes. - 28 August 2006: Approved. ** Action Item Review ** - AI-0828a: Postponed - AI-0228b: Postponed, Takuya will update minutes 10 August - AI-0828c: Closed. Hiro asked Greg Newby abut the doc status but got no answer. Instead, Joel Replogle stated the docs are in the pipeline, and will be published before GGF18 - AI-0817a: Postponed until GGF18 - AI-0817b: Closed. First draft sent to OGSA ML. - AI-0810a: Ongoing. Several updates sent to the relevant lists and waiting for updates. Finished scenario version pendding. - AI-0803e: Ongoing No progress. - AI-0803f: Ongoing No progress. - AI July F2F Ravi: Ongoing. - AI July F2F Andreas: Ongoing. Reply not completed yet. ** OGSA F2F meeting agenda update ** - Joint EMS/Data session, and HPCP session on Thursday - RSS session will be moved to Thursday - Formal Group Diner at Mikes house on Thu evening (~ 10 people attending), result from the Zoomerang survey - Additional Group Diner propably likely on Friday night - coordination with Jay needed ** EMS scenarios ** - AI-0831b: Hiro to send CDDLM & CDL working copies to Andreas as they are slightly different from the versions in this draft - Andreas walks the attendees through the EMS Architecture Scenarios document, draft 10 - section 4.1: This scenario is (currently?) not normative. Donal's comment on the list is that "the JS updates the IS" is incorrect. Andreas agrees, but is not sure which entity should update the registry. - AI-0831c: Andreas to update secction 4.1 of the EMS Architecture scenarios - section 4.2: - Application version is not mentioned in this section and needs to be added. - AI-0831d: Anderas to add the Application Version in section 4.2 of the EMS Arch Scenarios - AI-0831e: Andreas to talk to ACS working group for refining this scenario. - The group discusses Donal's comment on the mailing list (31 Aug, 14:20) whether the JM has to rewrite the JSDL document after deployment, but before submission - Donal and Andreas agree to talk offline on this issue - The group discusses A Grimshaw's question why there is a requirement that the JSDL document needs be rewritten by the JM - Andrew Grimshaw: The various services involved in EMS should - if needed - rewrite the submitted JSDDL document in order to get it closer and closer to the actual execution. It should be the responsibility of the service to rewrite according to the service it offers, and not by another entity that then ought to understnad what that service did - A Grimshaw proposes to introduce RNS names to EMS, particularly section 4.2 - There is still controvercy on this issue, and more advanced scenarios will attempt to solve this issue. - AI-0831f: Andreas to look up RNS and probably update the EMS Arch Scenarios document - Next review isof the document is at GGF18, EMS session ** Joint EMS & Data scenarios ** - Dave Berry sent a Parameter Scan scneario to the OGSA ML (30 Aug 19:37) - Dave walks the group through the scenario diagram - Donal: Through JSDL one can explicitly request the data being deleted ("jsdl:DeleteOnTermonation" element) - Mark Morgan suggests an alternative view on this: - Reuse specs that are already or almost already out there - This modifies the data transfer service sub-set (using RNS and "copy") - Suggests to use existing specs as much as possible - Dave Berry: The Transfer Service mentioned in the diagram may be a ByteIO service or OGSA-DMI or else. - The scenario is agreed upon in the group - The transformation of thee scenarios into concrete implementations leaves room for implementers to use certain specifications - Hiro: The asymmetry between input data and output data in relation to the BES container is irritating - Dave Berry: This is actually an artifact of the scenario editing and not intended to show real asymmetry - AI-0831g: Dave Berry to revise the joint Data/EMS scenario and add sequence diagrams including implementation variations, i.e. ByteIO, by GGF18 - "Result data" and "Output data" are synonymous, as are "Input data" and "boundary condition data". - AI-0831h: Mark Morgan and Andrew Grimshaw: provide an outline sequence how BES, ByteIO, RNS, etc. are combined together at University of Virginia ** ACTION ITEMS ** AI-0831a: (A Savva) Merge and publish minutes for the call on 10 August 2006 AI-0831b: (H Kishimoto) Send CDDLM & CDL working copies to Andreas as they are slightly different from the versions in this draft AI-0831c: (A Savva) Update/rewrite secction 4.1 of the EMS Architecture scenarios AI-0831d: (A Savva) Add the Application Version in section 4.2, paragraph 4, of the EMS Arch Scenarios AI-0831e: (A Savva) Talk to ACS working group for refining this scenario. AI-0831f: (A Savvva) Research RNS and probably update the EMS Arch Scenarios document AI-0831g: (A Savva) List of open issues, scenarios and refinements for the EMS Arch Scenarios document AI-0831h: (M Morgan, A Grimshaw) Provide an outline sequence how BES, ByteIO, RNS, etc. are combined together at University of Virginia