EMS Architecture Scenarios v1.0+

Where should we go next with EMS Architecture Scenarios? The original document (http://www.ogf.org/documents/GFD.106.pdf) considered scenarios relating to job execution at a known endpoint, an endpoint selected through RSS type mechanisms, and execution requiring post/pre deployment steps. Open Issues (as I see them!): 1. Progress on defining EPS (as part of RSS) has been slow and AFAIK there has not been much progress towards its submission into the document process. There is however a draft from April of the specification and from June of WSDL/XSD files - http://forge.gridforum.org/sf/go/projects.ogsa-rss-wg/docman.root.current_dr.... This may not matter as work has progressed on the content of RSS - namely the information model and the activity in the GLUE-WG. 2. Review of GLUE information model. The BES specification defined some minimal requirements we should ensure that these have been taken on board by the GLUE-WG team - see http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/HomePage . Do we need more concrete scenarios from EMS to drive this... or are the GLUE scenarios sufficiently comprehensive? 3. Files (or more generally data?). The scenarios say nothing about file movement. The DMI-WG has progressed since then and has generated some scenarios that could for into a revision of this document. The latest draft (http://forge.gridforum.org/sf/docman/do/listDocuments/projects.ogsa-dmi-wg/d...) and the some use cases (http://forge.gridforum.org/sf/go/doc14666?nav=1 and http://www.ogf.org/OGF19/materials/505/Including%20Data%20in%20Simple%20Job%...) are a starting point. Even some sequence diagrams (see https://forge.gridforum.org/sf/sfmain/do/downloadAttachment/projects.rm-wg/w... and https://forge.gridforum.org/sf/sfmain/do/downloadAttachment/projects.rm-wg/w...) from RM/GLUE discussions that should be reviewed for diffs against the current scenarios. 4. Deployment and Provisioning. Are ACS and CDDLM dead? Should we refactor around work in the Reference Model WG and experience on lightweight deployment experience from UVa and GenesisII (BTW - I'm sure there are other groups who could contribute here). Generally, having scenarios in the current version of the document using specs that are not developing and/or not going to be adopted is a concern to me. There is IMHO a clear benefit in having these sequence diagrams to inform other groups & incorporate their thinking into a single cohesive document. This should be one of our principals for future versions - not to expand into a massive sequence diagram repository but to keep a narrow focus on incremental scenarios in the EMS space. This would be a useful reference for many groups and help to show how the work going on in individual WGs fits together. Steven PS - Many thanks to the those who's documents, emails and thoughts have been collected here!

Hi Steve, Steven Newhouse wrote:
[...] Generally, having scenarios in the current version of the document using specs that are not developing and/or not going to be adopted is a concern to me. There is IMHO a clear benefit in having these sequence diagrams to inform other groups & incorporate their thinking into a single cohesive document. This should be one of our principals for future versions – not to expand into a massive sequence diagram repository but to keep a narrow focus on incremental scenarios in the EMS space. This would be a useful reference for many groups and help to show how the work going on in individual WGs fits together.
I agree to that. It would also actually help keeping scope creep out of the involved Working Groups. I am not a UML guy, but I was wondering whether it is possible to draw/incorporate some sort of interface boundary between the "umbrella" EPS sequence diagrams, and the sequence diagrams that clearly belong to the WGs that solve a specific problem, i.e. OGSA-DMI, OGSA-BES, OGSA-RSS (which actually covers two topics w/ interfaces - CSG and EPS). This would vice versa keep the scope of EMS to some sort of "glue" sticking all the individual parts together. Regarding your initial list of 4 topics, I would consider #2, #3 and #4 prime topics of EMS 1.0+, and #1 more of an issue for the OGSA-RSS group, which needs some man power here I guess. Cheers, Michel

Hi Steven and Michel,
This would be a useful reference for many groups and help to show how the work going on in individual WGs fits together.
I agree to that. It would also actually help keeping scope creep out of the involved Working Groups.
Sound great. Could we have some time to discuss this topic at the F2F? Does Tuesday evening (e.g. 5:30-6pm) work for you guys? Thanks, ---- Hiro Kishimoto -------- Original Message -------- Subject: Re:[ogsa-wg] EMS Architecture Scenarios v1.0+ From: Michel Drescher <Michel.Drescher@uk.fujitsu.com> To: Steven Newhouse <Steven.Newhouse@microsoft.com> Cc: "ogsa-wg@ogf.org" <ogsa-wg@ogf.org> Date: 2007/08/09 18:53
Hi Steve,
Steven Newhouse wrote:
[...] Generally, having scenarios in the current version of the document using specs that are not developing and/or not going to be adopted is a concern to me. There is IMHO a clear benefit in having these sequence diagrams to inform other groups & incorporate their thinking into a single cohesive document. This should be one of our principals for future versions – not to expand into a massive sequence diagram repository but to keep a narrow focus on incremental scenarios in the EMS space. This would be a useful reference for many groups and help to show how the work going on in individual WGs fits together.
I agree to that. It would also actually help keeping scope creep out of the involved Working Groups.
I am not a UML guy, but I was wondering whether it is possible to draw/incorporate some sort of interface boundary between the "umbrella" EPS sequence diagrams, and the sequence diagrams that clearly belong to the WGs that solve a specific problem, i.e. OGSA-DMI, OGSA-BES, OGSA-RSS (which actually covers two topics w/ interfaces - CSG and EPS). This would vice versa keep the scope of EMS to some sort of "glue" sticking all the individual parts together.
Regarding your initial list of 4 topics, I would consider #2, #3 and #4 prime topics of EMS 1.0+, and #1 more of an issue for the OGSA-RSS group, which needs some man power here I guess.
Cheers, Michel
------------------------------------------------------------------------
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg

Hiro, Steve, I'm all in for that. Cheers, Michel Hiro Kishimoto wrote:
Hi Steven and Michel,
This would be a useful reference for many groups and help to show how the work going on in individual WGs fits together.
I agree to that. It would also actually help keeping scope creep out of the involved Working Groups.
Sound great. Could we have some time to discuss this topic at the F2F? Does Tuesday evening (e.g. 5:30-6pm) work for you guys?
Thanks, ---- Hiro Kishimoto
-------- Original Message -------- Subject: Re:[ogsa-wg] EMS Architecture Scenarios v1.0+ From: Michel Drescher <Michel.Drescher@uk.fujitsu.com> To: Steven Newhouse <Steven.Newhouse@microsoft.com> Cc: "ogsa-wg@ogf.org" <ogsa-wg@ogf.org> Date: 2007/08/09 18:53
Hi Steve,
Steven Newhouse wrote:
[...] Generally, having scenarios in the current version of the document using specs that are not developing and/or not going to be adopted is a concern to me. There is IMHO a clear benefit in having these sequence diagrams to inform other groups & incorporate their thinking into a single cohesive document. This should be one of our principals for future versions – not to expand into a massive sequence diagram repository but to keep a narrow focus on incremental scenarios in the EMS space. This would be a useful reference for many groups and help to show how the work going on in individual WGs fits together.
I agree to that. It would also actually help keeping scope creep out of the involved Working Groups.
I am not a UML guy, but I was wondering whether it is possible to draw/incorporate some sort of interface boundary between the "umbrella" EPS sequence diagrams, and the sequence diagrams that clearly belong to the WGs that solve a specific problem, i.e. OGSA-DMI, OGSA-BES, OGSA-RSS (which actually covers two topics w/ interfaces - CSG and EPS). This would vice versa keep the scope of EMS to some sort of "glue" sticking all the individual parts together.
Regarding your initial list of 4 topics, I would consider #2, #3 and #4 prime topics of EMS 1.0+, and #1 more of an issue for the OGSA-RSS group, which needs some man power here I guess.
Cheers, Michel
------------------------------------------------------------------------
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
participants (3)
-
Hiro Kishimoto
-
Michel Drescher
-
Steven Newhouse