Draft 0.1 of the technical Strategy Document.

Folks, Here is the initial draft I promised last week based on our agreement around the outline. Sorry for the slight delay, I had no network access over the weekend. Here is the todo list: 1) Tuesday I go on Holiday and will probably not have email access, but you never know. 2) Geoffery has the pen, so send all change suggestions to the list and let Geoffery add them to the document. 3) There are outstanding actions (highlighted in yellow in the document) for Steven and Chris. Send text to Geoffery via the list. 4) This document will be presented to the BoD on the 24th. Geoffery: Make sure Mark L has the latest version on Wednesday night! 5) The following is the status section for this document: This is a DRAFT document. The contents at this time DO NOT yet reflect the consensus view of the Technical Strategy Committee. It is being provided to gain input and feedback with respect to the structure and type of content, e.g. is this document fit for purpose? Feedback on the technical content is NOT expected at this early stage of development. Eventually, distribution will be unlimited, but for the time being, distribution is limited to the Technical Strategy Committee (TSC), the Board of Directors (BoD), and the Grid Forum Steering Group (GFSG). 6) Mark PLEASE make sure the BoD read this paragraph at least. I am not happy showing documents outside of any group with so little time to generate consensus. 7) Mark also lead the BoD to provide comments as requested, e.g. wrt fit for purpose rather than technical content. The later needs more time. There is now a GF project for the TSC. I have put the document under Drafts and attached it here. In future, let's try to limit attachments. https://forge.gridforum.org/sf/projects/tsc -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

Here is a quick comment from the "owner of pen" Looking at table 1, it seems to me that it might be better to present as current emphasis (adding OGSA-DAI -- I am not certain why this is left out) and discuss how we add standards work to meet industry needs. It reads a little like a fixed agenda at moment and thats fine if Industry requests this agenda but not so good if board requests additional areas of emphasis. Putting on my "eScience hat", I would suggest that OGF can offer more than standards to Industry. We can also offer the world's experts to guide strategy. For example, I just spent a day and a half with a group from one of the Big Pharma companies. This group has already fully adopted web services but for moment at least new standards are not their priority (they view field as still experimental) but rather Grid strategy for knowledge management. I would suggest adopting a broader view in document encompassing all OGF functions (standards, enterprise, eScience) David Snelling wrote:
Folks,
Here is the initial draft I promised last week based on our agreement around the outline. Sorry for the slight delay, I had no network access over the weekend. Here is the todo list:
1) Tuesday I go on Holiday and will probably not have email access, but you never know.
2) Geoffery has the pen, so send all change suggestions to the list and let Geoffery add them to the document.
3) There are outstanding actions (highlighted in yellow in the document) for Steven and Chris. Send text to Geoffery via the list.
4) This document will be presented to the BoD on the 24th. Geoffery: Make sure Mark L has the latest version on Wednesday night!
5) The following is the status section for this document:
This is a DRAFT document. The contents at this time DO NOT yet reflect the consensus view of the Technical Strategy Committee. It is being provided to gain input and feedback with respect to the structure and type of content, e.g. is this document fit for purpose? Feedback on the technical content is NOT expected at this early stage of development. Eventually, distribution will be unlimited, but for the time being, distribution is limited to the Technical Strategy Committee (TSC), the Board of Directors (BoD), and the Grid Forum Steering Group (GFSG).
6) Mark PLEASE make sure the BoD read this paragraph at least. I am not happy showing documents outside of any group with so little time to generate consensus.
7) Mark also lead the BoD to provide comments as requested, e.g. wrt fit for purpose rather than technical content. The later needs more time.
There is now a GF project for the TSC. I have put the document under Drafts and attached it here. In future, let's try to limit attachments.
https://forge.gridforum.org/sf/projects/tsc
-- Take care:
Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE
+44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)
------------------------------------------------------------------------
_______________________________________________ tsc mailing list tsc@ogf.org http://www.ogf.org/mailman/listinfo/tsc
-- : : Geoffrey Fox gcf@indiana.edu FAX 8128567972 http://www.infomall.org : Phones Cell 812-219-4643 Home 8123239196 Lab 8128567977 : SkypeIn 812-669-0772 with voicemail, International cell 8123910207

Geoffery, On 21 Aug 2006, at 15:26, Geoffrey Fox wrote:
Here is a quick comment from the "owner of pen" Looking at table 1, it seems to me that it might be better to present as current emphasis (adding OGSA-DAI -- I am not certain why this is left out) and discuss how we add standards work to meet industry needs.
Agreed. The spec name is actually WS-DAI (OGSA-DAI in the UK project's name). They have a bunch of stuff already in the pipeline ready for publication, which may be why I left them off. BUT since our roadmap includes implementation and deployment, WS-DAI is still far from finished. The pen is yours, please add WS-DAI and the two language specs, relational (WS-DAIR) and XML (WS-DAIX) database. If you can adapt one of the use cases (or add one) to include WS-DAI that would help, as this is probably necessary eventually.
It reads a little like a fixed agenda at moment and thats fine if Industry requests this agenda but not so good if board requests additional areas of emphasis.
We need to tread the narrow road here, but describing our process of creating this roadmap is probably necessary. Can you add a section about this? It can be "To Be Done" if you like or you can include an N step bullet list: gather stakeholder input, gather resource reports from chairs, draft updated version, socialize, redraft, and publish. Or something like this. Then later we can refine it.
Putting on my "eScience hat", I would suggest that OGF can offer more than standards to Industry. We can also offer the world's experts to guide strategy. For example, I just spent a day and a half with a group from one of the Big Pharma companies. This group has already fully adopted web services but for moment at least new standards are not their priority (they view field as still experimental) but rather Grid strategy for knowledge management. I would suggest adopting a broader view in document encompassing all OGF functions (standards, enterprise, eScience)
I thought about this and that's why all the statements about the "other work" of OGF are there. I think something more of possible/ necessary, but I'm not sure how to describe it in language that can be consumed by the folks expecting this document. Ideas from you and Robert welcome. Fell free to add a section, if only a place holder. Remember, anything goes in this draft as long as the note about no consensus yet stays in. I've asked Mark to make sure the BoD know that this is very much work in progress. Thanks for taking the pen Geoffery.
David Snelling wrote:
Folks,
Here is the initial draft I promised last week based on our agreement around the outline. Sorry for the slight delay, I had no network access over the weekend. Here is the todo list:
1) Tuesday I go on Holiday and will probably not have email access, but you never know.
2) Geoffery has the pen, so send all change suggestions to the list and let Geoffery add them to the document.
3) There are outstanding actions (highlighted in yellow in the document) for Steven and Chris. Send text to Geoffery via the list.
4) This document will be presented to the BoD on the 24th. Geoffery: Make sure Mark L has the latest version on Wednesday night!
5) The following is the status section for this document:
This is a DRAFT document. The contents at this time DO NOT yet reflect the consensus view of the Technical Strategy Committee. It is being provided to gain input and feedback with respect to the structure and type of content, e.g. is this document fit for purpose? Feedback on the technical content is NOT expected at this early stage of development. Eventually, distribution will be unlimited, but for the time being, distribution is limited to the Technical Strategy Committee (TSC), the Board of Directors (BoD), and the Grid Forum Steering Group (GFSG).
6) Mark PLEASE make sure the BoD read this paragraph at least. I am not happy showing documents outside of any group with so little time to generate consensus.
7) Mark also lead the BoD to provide comments as requested, e.g. wrt fit for purpose rather than technical content. The later needs more time.
There is now a GF project for the TSC. I have put the document under Drafts and attached it here. In future, let's try to limit attachments.
https://forge.gridforum.org/sf/projects/tsc
-- Take care:
Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE
+44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)
_______________________________________________ tsc mailing list tsc@ogf.org http://www.ogf.org/mailman/listinfo/tsc
-- : : Geoffrey Fox gcf@indiana.edu FAX 8128567972 http:// www.infomall.org : Phones Cell 812-219-4643 Home 8123239196 Lab 8128567977 : SkypeIn 812-669-0772 with voicemail, International cell 8123910207
-- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

Another quick comment: In the introduction, there's a nice taxonomy of grid types... 2. Enterprise Grids: These Grids are in most ways as complex technically as Collaboration Grids and involve the complete dynamic life cycle of service deployment, provision, management, and decommissioning as part of their normal operation. However, the multiple domains are either absent or highly integrated, at least at a political level. These are the, frequently heterogeneous, production Grids of major data centers. ... one of the envisioned use cases for Enterprise Grids is Utility Computing, where there are many individual political/security domains and application types deployed on an infrastructure that is managed with grid protocols. In this case, there are multiple domains sitting on top of an integrated domain, which provides a different sort of world entirely. We should try to capture this, as well. chris

Application Provisioning Job submission, and indeed any sort of workload manager, implies the ability to discover, describe, provision and manage the lifetime of an appropriate application code onto an identified computing resource. In many instances, this can be done at a very high level, but some scenarios will require very specific descriptions at the application layer. This, in turn, may place requirements for a specific operating system and version, possibly implying a certain patch level and hardware requirements. EGA's Reference Model describes the overall flow of activity involved in provisioning a high-level component and decomposing the required work into accessible quanta: ACS and CDDLM are specific proposals/WGs that attack the problems of describing and managing the lifetime of specific applications.

Here is an edit including comments we got I apologize if I messed up! Maybe we should let Mark have the pen as he interacts with the board Chris Kantarjiev wrote:
Application Provisioning
Job submission, and indeed any sort of workload manager, implies the ability to discover, describe, provision and manage the lifetime of an appropriate application code onto an identified computing resource. In many instances, this can be done at a very high level, but some scenarios will require very specific descriptions at the application layer. This, in turn, may place requirements for a specific operating system and version, possibly implying a certain patch level and hardware requirements.
EGA's Reference Model describes the overall flow of activity involved in provisioning a high-level component and decomposing the required work into accessible quanta: ACS and CDDLM are specific proposals/WGs that attack the problems of describing and managing the lifetime of specific applications. _______________________________________________ tsc mailing list tsc@ogf.org http://www.ogf.org/mailman/listinfo/tsc
-- : : Geoffrey Fox gcf@indiana.edu FAX 8128567972 http://www.infomall.org : Phones Cell 812-219-4643 Home 8123239196 Lab 8128567977 : SkypeIn 812-669-0772 with voicemail, International cell 8123910207

Application Provisioning
Job submission, and indeed any sort of workload manager, implies the ability to discover, describe, provision and manage the lifetime of an appropriate application code onto an identified computing resource. In many instances, this can be done at a very high level, but some scenarios will require very specific descriptions at the application layer. This, in turn, may place requirements for a specific operating system and version, possibly implying a certain
All, Geoffrey handed me the pen in his recent email, but given the workload associated with GGF18, I am not sure I have the time at the moment to do much justice so apologize in advance for the quick thoughts. Board-of-Directors Feedback: We recently held our first board meeting and all members were very supportive of the TSC and the project associated with producing an ongoing OGF Technical Strategy and Roadmap Document. In fact, the board encouraged us to continue with deliberate focus on two projects that have great synergy with each other. 1. Grid & Distributed Computing Landscape Project: This project will be championed by our Marketing function in conjunction with a key industry analyst over the next several months. The purpose is to clarify the role of grid and OGF within the broader distributed computing industry. 2. OGF Technical Strategy & Roadmap Project: This project is being championed by the TSC in conjunction with the other functions and key OGF stakeholders. The purpose is to produce a living document to articulate direction and priorities and align OGF technical directions and priorities with stakeholder requirements. As you can see, both documents are highly synergistic and can be thought of as "the big picture" and "the technical strategy" associated with enabling the "big picture". Regarding the TSC-led project, I want to reiterate a few simple points. I have also attached some quick (and half-baked) comments to the document Geoffrey sent my way. Repeatable Process: This document is an "integrating mechanism" that allows the organization to align with key stakeholders. As such, it needs to be built into a repeatable process. The contents in this document allow the organization to interlock and communicate with key stakeholders over and over and over again in a standard way. It will be utilized in the following anticipated ways: 1. At every OGF major event content from this document must be ready to review with: (a) The board; (b) the "requirement forums; (c) Platinum and Gold members as part of our Membership Program; (d) with the community-at-large. 2. At every OGF major event, content from this document will be utilized in keynotes, highlighted in our newsletter and utilized by marketing to articulate our progress and showcase our value. 3. Contents from this document will be utilized to provide our technical leaders with tangible justification to solicit technical support for critical group activities Repeatable "Models". We need to agree on an overall segmentation for types/categories of grids and relate "stakeholder-oriented" use cases to this segmentation. One of the problems that we are having is that everyone has their favorite model for describing things. However, we need to start from the user-end of the equation and agreed upon a set of models. (1) Grid Segmentation Model; (2) Archetype Use Case Models; (3) Service Models; etc. If we cannot do this as an organization, we will probably remain fragmented in our alignment, execution and communication. Thanks for continuing to move this forward. Mark Mark Linesch: Open Grid Forum (OGF): Hewlett Packard 281-514-0322 (Tel): 281-414-7082 (Cell) mark.linesch@hp.com : linesch@ogf.org -----Original Message----- From: tsc-bounces@ogf.org [mailto:tsc-bounces@ogf.org] On Behalf Of Geoffrey Fox Sent: Wednesday, August 23, 2006 6:08 PM To: Chris Kantarjiev Cc: tsc Subject: Re: [tsc] Draft 0.1 of the technical Strategy Document. Here is an edit including comments we got I apologize if I messed up! Maybe we should let Mark have the pen as he interacts with the board Chris Kantarjiev wrote: patch level
and hardware requirements.
EGA's Reference Model describes the overall flow of activity involved in provisioning a high-level component and decomposing the required work into accessible quanta: ACS and CDDLM are specific proposals/WGs that attack the problems of describing and managing the lifetime of specific applications. _______________________________________________ tsc mailing list tsc@ogf.org http://www.ogf.org/mailman/listinfo/tsc
-- : : Geoffrey Fox gcf@indiana.edu FAX 8128567972 http://www.infomall.org : Phones Cell 812-219-4643 Home 8123239196 Lab 8128567977 : SkypeIn 812-669-0772 with voicemail, International cell 8123910207

Mark's note and today's TSC discussion lead me to resend something I penned during our original round of agenda- and document-bashing:
The terms "grid" and "grid computing" have a long, storied, and somewhat checkered past. The term has gotten quite muddy. Articles like
http://weblog.infoworld.com/gridmeter/archives/2006/07/a_broader_scope.html
draw this in sharp relief.
We should take advantage of this inflection point to recapture the mindshare around "grid", by setting and stating goals crisply.
I assert that grid computing is utility computing, on a range of hardware, in a range of architectures - it's not just HPC computing, stealing cycles from one another's supercomputers any more. (Nor is it, really, about cycle recovery from desktops or embarrassingly parallel applications like SETI@Home. Those are interesting, they got the term out into the marketplace of ideas, but we're not going to be developing organizational strategy around those.)
Grid computing is about these things:
- infrastructure virtualization - resource pooling & sharing - self monitoring & improvement - dynamic resource provisioning - highest quality of service
OGF's goals and the TSC's strategic roadmap need to capture all this.
I'll suggest again (probably for the last time :-) that this list, or something like it, is a good place to start our highest-level discussions of what OGF is trying to do. Work can be segmented, models built, use cases partitioned and gaps found by picking and choosing from these items as needed. Obviously, not all of our potential grid segments or archetypical use cases need all of these - but I think that every stakeholder cuts through several of them, so it might be an interesting place to start forging our message (both marketing and technical). Best, chris

I agree that utility computing is a (the) major focus of much of industry Grids and indeed of Enterprise sessions at OGF18. OGSA has through BES made major progress here. However for eScience, such Grids are interesting but probably not as popular in as "Data Deluge"/"Information"/"Collaboration" Grids as used in MyGrid, BIRN, LEAD, SERVOGrid etc. Even industry has interest in latter type of Grids. See Bio-IT April 2006 with John Reynders of Eli Lilly talking on Integrative Informatics. He would in OGF parlance consider "data management" as key issue. DoD spends $30B on IT a year and considers Global Information Grid/Net Centric Computing as future. The 9 core DoD Net Centric Enterprise Services are focused far more on data than computing. So I deduce its a diverse evolving world; we need to be inclusive in general discussions but precise on particular things we do. Chris Kantarjiev wrote:
Mark's note and today's TSC discussion lead me to resend something I penned during our original round of agenda- and document-bashing:
The terms "grid" and "grid computing" have a long, storied, and somewhat checkered past. The term has gotten quite muddy. Articles like
http://weblog.infoworld.com/gridmeter/archives/2006/07/a_broader_scope.html
draw this in sharp relief.
We should take advantage of this inflection point to recapture the mindshare around "grid", by setting and stating goals crisply.
I assert that grid computing is utility computing, on a range of hardware, in a range of architectures - it's not just HPC computing, stealing cycles from one another's supercomputers any more. (Nor is it, really, about cycle recovery from desktops or embarrassingly parallel applications like SETI@Home. Those are interesting, they got the term out into the marketplace of ideas, but we're not going to be developing organizational strategy around those.)
Grid computing is about these things:
- infrastructure virtualization - resource pooling & sharing - self monitoring & improvement - dynamic resource provisioning - highest quality of service
OGF's goals and the TSC's strategic roadmap need to capture all this.
I'll suggest again (probably for the last time :-) that this list, or something like it, is a good place to start our highest-level discussions of what OGF is trying to do. Work can be segmented, models built, use cases partitioned and gaps found by picking and choosing from these items as needed.
Obviously, not all of our potential grid segments or archetypical use cases need all of these - but I think that every stakeholder cuts through several of them, so it might be an interesting place to start forging our message (both marketing and technical).
Best, chris _______________________________________________ tsc mailing list tsc@ogf.org http://www.ogf.org/mailman/listinfo/tsc
-- : : Geoffrey Fox gcf@indiana.edu FAX 8128567972 http://www.infomall.org : Phones Cell 812-219-4643 Home 8123239196 Lab 8128567977 : SkypeIn 812-669-0772 with voicemail, International cell 8123910207

Geoffrey, In table 1... * ByteIO is a WS interface specification and probably fits better in the File Movement use case. * I'd add DRMAA into the GirdAPI section. Its a produced specification with interop reports coming in from the Applications area. Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Mob:+44(0)7920489420 Tel:+44(0)23 80598789 Director, Open Middleware Infrastructure Institute-UK (OMII-UK) c/o Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK

Steven, Agreed, although I think of ByteIO as an API, albeit for WS clients only. No problem moving it though. I like adding DRMAA. On 22 Aug 2006, at 08:28, Steven Newhouse wrote:
Geoffrey,
In table 1...
* ByteIO is a WS interface specification and probably fits better in the File Movement use case. * I'd add DRMAA into the GirdAPI section. Its a produced specification with interop reports coming in from the Applications area.
Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Mob:+44(0)7920489420 Tel:+44(0)23 80598789 Director, Open Middleware Infrastructure Institute-UK (OMII-UK) c/o Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK
_______________________________________________ tsc mailing list tsc@ogf.org http://www.ogf.org/mailman/listinfo/tsc
-- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

I'm still trying to figure out what to say about application provisioning APIs, but in the mean time, allow me to interject that as well as File Movement, we need to say something about storage provisioning. In fact, I'd argue that File Movement is a special case of a much more general data provisioning area of focus. It isn't always a case of moving the data as much as it might be an opportunity to connect the data on one particular storage device to the appropriate computing resources, while managing access rights and security. For example (quoting from the EGA doc, http://www.gridalliance.org/imwp/idms/popups/pop_download.asp?ContentID=7945): ... • Find an appropriately sized storage container of the correct access type (Fibre Channel (FC), iSCSI, NFS, CIFS), possibly using best-fit logic • Secure the container so that only the requester can write to it and read from it • Set up the needed switching between the requester and the storage • Set up a VLAN or Fibre Channel mask to establish security and prevent accidents • Engage any needed over-the-wire or at-rest cryptographic security mechanisms • Hand the client back an address to use for the data container Data provisioning typically requires at least three steps: initial population, keeping the data in sync, and cleaning up the data when it is no longer needed. If the container must be populated with an initial data set from somewhere, additional work is required. There may be an opportunity to use cloning technology to greatly enhance the efficiency of the copy operation. After the initial provisioning step, the data may needed to be frequently snapshotted and/or replicated for Disaster Recovery (DR), RPO/RTO or other purposes. At the end of the job, results may need to be copied elsewhere to a location of the client's specification. In addition, all temporary copies of any data may need to be securely shredded when the user or application is done with the container and its offspring. Yet the user's desire is simple: a data container conforming to some service level that the system has previously advertised. ... The GGF efforts in this area have, as far as I can tell, been focused on the assumption that the data is over there, and now I want it right here, and the only way to do that is to move it all. I think our strategy document needs to deal with a more complex data and storage world than that, although certainly not all at once. Resources have to be discovered, provisioned, managed, and offered with certain SLAs. OGF has partnerships with some standards orgs that have products in this space (SNIA SMI-S, DMTF CIM). Of course, data provisioning decomposes into storage provisioning, which is a huge can of worms (EGA pretty much burned up everyone who tried their hand at this ... ) chris
participants (6)
-
Chris Kantarjiev
-
Chris Kantarjiev
-
David Snelling
-
Geoffrey Fox
-
Linesch, Mark
-
Steven Newhouse