- gridrpc-wg - lists.ogf.org

Update on GridForge
by Eddy Caron 17 Sep '08

17 Sep '08

Dear GridRPC members, Documents related to data management and GridRPC are now available on GridForge http://forge.ogf.org/sf/go/projects.gridrpc-wg/docman.root.gridrpc_recommen… Regards, Eddy ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron(a)ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------

1 0

GridRPC document in v0.8
by Yves Caniou 15 Sep '08

15 Sep '08

Dear All, To make fast, I put the last version of the document in http://graal.ens-lyon.fr/~ycaniou/GridRPC/ -> http://graal.ens-lyon.fr/~ycaniou/GridRPC/GRPC_Data-0.8.pdf Soon, this will be available on the forge... The changelog is: *Added GRPC_STRING, GRPC_FILE types * Put protocols in lower caps * Keyword "LOCAL_MEMORY" is now "memory" * Added section specific to type and mode: - for mapping function (for the memory protocol) - for the container management There is still work to do at least on error management. Best Regards. .Yves. -- Yves Caniou Associate Professor at Université Lyon 1, Member of the team project INRIA GRAAL, LIP / ENS-Lyon 46 Allée d'Italie 69364 LYON Cedex 07 tel: +33 4 37 28 76 48 http://graal.ens-lyon.fr/~ycaniou/

2 1

Group rechartering
by Yusuke Tanimura 13 Jun '08

13 Jun '08

Dear all, We discussed about the recharter at the session in OGF 23. Thanks for all participants! Attachment is a revised version according to our discussion. * Download statistics of NetSolve/GridSolve is updated. * Document type of "Data Management API within the GridRPC" is changed from Recommendation to Informational. * A new planned recommendation document, "A GridRPC Model and API v2," is added to our deliverables. It is really time to finalize and send the document to the area director. Please give us any further comments within a week if you have. Best regards, ----------------------------------------------------- Yusuke Tanimura <yusuke.tanimura(a)aist.go.jp> Information Technology Research Institute, AIST 1-1-1 Umezono, Tsukuba Central 2 Tsukuba City 305-8568, Japan TEL: +81-29-862-6703 / FAX: +81-29-862-6601

2 2

New version of the API
by Yves Caniou 03 Jun '08

03 Jun '08

Dear All, First, I apologize for the delay. I have put the new version 0.7 of the document at the URL: http://graal.ens-lyon.fr/~ycaniou/GridRPC/GRPC_Data-0.7.pdf (all docs are available at http://graal.ens-lyon.fr/~ycaniou/GridRPC/) We plan to use the document itself as a presentation support. ----------------- Changelog (main features): * Correction typos * Moved types only used in given function in the section describing types * Instead of only an input URI and output URI, the grpc\_data\_storage\_info\_t type has now a NULL-terminated list of input URI and a NULL-terminated list of output URI. * grpc_data_mode_t was a bit confusing because it mixed a modification in the behavior of the standard GridRPC mechanism (return the data at the end of the computation) and the management mode of a GridRPC data. Then, - GRPC_*_RETURN values have been removed from grpc_data_mode_t - grpc_data_mode_t has been extended with the values GRPC\_UNIQUE\_VOLATILE and GRPC_UNIQUE_STICKY, which do not tolerate migration/replication of the data, for security reasons for example. - grpc_data_init() contains an argument which describes the behavior of the standardized GridRPC API: for a given handle used as an OUT arg in a solve() function, one can choose to get or not a copy of the results. Precision concerning the protocole LOCAL_MEMORY: the path is not necessarily a pointer (which was given as example) but can also be a kind of ID. Modification of grpc_data_init(): - lists of locations in URL_input and URL_output args are now given. - grpc_data_init() contains an argument which describes the behavior of the standardized GridRPC API: for a given handle used as an OUT arg in a solve() function, one can choose to get or not a copy of the results. (Already mentioned above) Modification of the prototype of grpc_data_write(): - The list of servers is replaced by a list of URI, because the protocol and the path can be different for each destination. - A list of management modes can be specified, for example to flag a data STICKY on some resources while still benefiting of aggressive copy mechanisms if some are available in the data middleware. - This function is asynchronous. Modification of the description of grpc_data_read(), which is now asynchronous. Added the grpc_data_wait() function Added 3 values-tags for the use of grpc_data_getinfo(): - GRPC_RESOLUTION_MODE to know if a copy is returned after computation. - GRPC_STATUS in order to know if a grpc data is GRPC_IN_PLACE or GRPC_TRANSFERING. - GRPC_COHERENT in order to know if the data is managed by a Data Management middleware that ensures coherency (and then, if this replica may or is up-to-date) -- should be dependent on locations. Added a new example for prefetch, and corrected the others. --------------- See you soon! .Yves. -- Yves Caniou Associate Professor at Université Lyon 1 Member of the team project INRIA GRAAL, LIP / ENS-Lyon 46 Allée d'Italie 69364 LYON Cedex 07 tel: +33 4 37 28 76 48 http://graal.ens-lyon.fr/~ycaniou/

2 1

Re: [GRIDRPC-WG] GridSolve slides
by Eddy Caron 30 May '08

30 May '08

Dear Hidemoto, Great news. We work with Frederic on them too. We have all material but we need just a couple of minutes to finalize. The last discussions with Yves, Frederic and Gaël (a PhD student who works on a data manager) implies that we think we should update the current version of the proposal. Indeed we think we should reduce the number of grid_rpc data function. That means the read and write functions don't concern the grid_rpc, they are functions for data manager not for the gridrpc. We try to reduce the API to a good structure to manage the data (same as shown at OGF'22). The data management should be delegated (as soon as possible) with this structure behind each gridrpc implementation. We hope to be ready for the next week but all nights are so short :-). Eddy Le 29 mai 08 à 01:00, Hidemoto Nakada a écrit : > Eddy. > > I've got slides on GridSolve from Keith. > ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron(a)ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------

2 1

Re: [GRIDRPC-WG] Fwd: OGF support for OGC Web Processing Service spec?
by Eddy Caron 29 May '08

29 May '08

Dear Hidemoto, Everything sounds good for me. Regards, Eddy Le 28 mai 08 à 01:51, Hidemoto Nakada a écrit : > Hi, > > BTW, I've met Yves last week and had great discussion with him. > Thanks, Yves! > >> About the presentation: >> >> How do you want to proceed ? Some points should be fixed very >> quickly >> : >> >> T1. Who gives the talk ? > Hidemoto, and Eddy >> >> T2. Who does the slides pattern ? > I'm not sure that I understand the term 'pattern', here. > But, I'll assemble all the slides into single presentation. > >> T3. Who does slides about Grid-RPC overview ? >> -> You (Hidemoto and Team) ? > will do that. > >> T4. Who does slides about Grid-RPC data management >> -> us (Yves/Gaël/Eddy) >> T5. Who does slides about Ninf ? > we will, off cource. > >> T6. Who does slides about DIET ? >> -> us (Yves/Gaël/Eddy/Frederic) >> >> T7. Who does slides about GridSolve ? >> -> Keith ? > I hope so. > >> T8. Who answer to Craig's question: GridRPC >> (Besides the >> call-response, could Data Handles be used in WPS?) >> -> > I think we can discuss in person at the OGF venue. > >> T9. This talk is in conjunction with Open Geospatial >> Consortium. Have you Geospatial application that we could show. > > no. we (the AIST) have them, but they are not related to Ninf. > > >> >> Best Regards, >> Eddy >> >> >> >> Le 27 mai 08 à 14:09, Hidemoto Nakada a écrit : >> >>> Eddy, >>> >>> How about giving presentation by both of us? >>> >>> One of us will give the Overview and Ninf or Diet >>> and the other will give the rest. >>> >>> Keith, could you give us 5-7 slides on GridSolve? >>> >>> >>> On Wed, May 14, 2008 at 5:08 AM, Eddy Caron <Eddy.Caron(a)ens-lyon.fr> >>> wrote: >>>> >>>> Dear Hidemoto, >>>> >>>> We can help you for slides. It could be >>>> >>>> Part 1. Grid-RPC overview (basic and with data management) >>>> Part 2. the overview of few Grid-RPC middleware. >>>> Ninf, NetSolve/GridSolve, DIET, Omni-RPC >>>> >>>> How many time ? >>>> >>>> Regards, >>>> Eddy >>>> >>>> Le 7 mai 08 à 04:02, Hidemoto Nakada a écrit : >>>> >>>>> All, >>>>> >>>>> We've got an invitation for a talk at the upcoming OGC-OGF >>>>> workshop at >>>>> OGF-23 from Craig, one of the co-chairs. >>>>> >>>>> I think we should give it. >>>>> >>>>> any idea? >>>>> >>>>> -hidemoto >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: <lee(a)aero.org> >>>>> Date: Wed, May 7, 2008 at 4:21 AM >>>>> Subject: Re: OGF support for OGC Web Processing Service spec? >>>>> To: lee(a)aero.org, Hidemoto Nakada <hide-nakada(a)aist.go.jp>, Yves >>>>> Caniou <yves.caniou(a)ens-lyon.fr>, s.jha(a)ucl.ac.uk, kielmann(a)cs.vu.nl >>>>> , >>>>> Andre Merzky <andre(a)merzky.net>, Andrew Grimshaw >>>>> <grimshaw(a)virginia.edu>, Steven Newhouse >>>>> <Steven.Newhouse(a)microsoft.com>, humphrey(a)cs.virginia.edu, >>>>> Geoffrey >>>>> Fox <gcf(a)grids.ucs.indiana.edu>, Christopher Smith >>>>> <csmith(a)platform.com> >>>>> Cc: Satoshi Sekiguchi <s.sekiguchi(a)aist.go.jp>, Chris Higgins >>>>> <erpl70(a)holyrood.ed.ac.uk>, George Percivall >>>>> <gpercivall(a)opengeospatial.org>, craig(a)rushg.aero.org, scumb(a)ogf.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> All, >>>>> >>>>> >>>>> As part of the upcoming OGC-OGF workshop in Barcelona at OGF-23, >>>>> I would >>>>> very much like to get a brief overview talk from (ideally ;-) the >>>>> SAGA, GridRPC, >>>>> and HPC-Basic Profile groups. >>>>> >>>>> >>>>> The OGF-23 workshop is being coordinated with the OGC Technical >>>>> Committee >>>>> meeting which is taking place the exact same days as OGF-23 but in >>>>> Potsdam, Germany. >>>>> >>>>> >>>>> Hence, while these overview talks will be presented in >>>>> Barcelona, their >>>>> primary >>>>> audience is intended to be the OGC folks who will be in Potsdam. >>>>> >>>>> >>>>> OGC represents a potential new user community for OGF grid tools >>>>> so this >>>>> is >>>>> an important opportunity. Also, the next OGC Web Services >>>>> Testbed, >>>>> OWS-6, >>>>> is still in the planning process, and what we discuss in this >>>>> workshop >>>>> could >>>>> very well be picked up for testing and demonstration by the OWS-6 >>>>> sponsors >>>>> and participants. >>>>> >>>>> >>>>> Please let me know if your group can provide an overview talk. >>>>> >>>>> >>>>> Thanks! >>>>> >>>>> >>>>> --Craig >>>>> >>>>> >>>>> >>>>> >>>>> At 12:52 PM -0800 2/29/08, lee(a)aero.org wrote: >>>>> All, >>>>> >>>>> >>>>> This request is an action that came out of this week's OGC-OGF >>>>> Collaboration workshop. >>>>> >>>>> OGC (Open Geospatial Consortium) has just announced version 1.0 >>>>> of their >>>>> Web >>>>> Processing Service. (I've forwarded the press release below.) >>>>> I've >>>>> looked at >>>>> earlier versions of this document and based on my initial >>>>> assessments, it seems >>>>> that WPS could very possibly map to: >>>>> >>>>> >>>>> 1) HPC-Basic Profile (How would WPS work w/ JSDL and BES?) >>>>> 2) GridRPC (Besides the call-response, could Data Handles be >>>>> used in >>>>> WPS?) >>>>> 3) SAGA (Much like the GridRPC package, could there be a WPS >>>>> package?) >>>>> >>>>> It would be extremely helpful to get others from each of these >>>>> groups to >>>>> make >>>>> their own assessment. WPS is a basic request-response mechanism >>>>> with >>>>> only >>>>> basic >>>>> support for managing where the data is. Depending on who you >>>>> ask, ~80% >>>>> of >>>>> the >>>>> data the human race has collected or generated is geospatial >>>>> referenced. Hence, >>>>> OGC represents a huge user base for geospatial data and, imho, >>>>> is a >>>>> natural >>>>> adjacency for grids. All insights, issues, and comments are >>>>> desired! >>>>> >>>>> I know that many of us are very busy and simply will not have >>>>> time to >>>>> read >>>>> an >>>>> 86-page document from beginning to end. But, as with many >>>>> standards >>>>> documents, >>>>> the core of the spec is presented in only about ten pages, with >>>>> the rest >>>>> of the >>>>> doc being necessary detail to clearly define the spec. Hence, >>>>> pages >>>>> 4-11 >>>>> present the WPS overview, and pages 11-48 go into more detail >>>>> about the >>>>> three >>>>> main WPS functions: GetCapability, DescribeProcess, and Execute. >>>>> >>>>> Please let me know right away if you can help with this >>>>> assessment. >>>>> I'd like to collect comments in a few weeks. >>>>> >>>>> Thanks, >>>>> >>>>> --Craig >>>>> >>>>> >>>>> >>>>> Delivered-To: lee(a)aero.org >>>>> Delivered-To: lee(a)ogf.org >>>>> Date: Fri, 22 Feb 2008 14:48:22 -0500 >>>>> From: OGC Press <announce(a)opengeospatial.org> >>>>> Organization: OGC >>>>> To: tc(a)opengeospatial.org, pc(a)opengeospatial.org >>>>> X-Virus-Status: Clean >>>>> Subject: [Tc] OGC(R) Approves Web Processing Service Standard >>>>> X-BeenThere: tc(a)opengeospatial.org >>>>> Reply-To: announce(a)opengeospatial.org >>>>> List-Id: "The Technical Committee is responsible for all aspects >>>>> of the >>>>> formal >>>>> consensus OGC specification process. " <tc.opengeospatial.org> >>>>> List-Unsubscribe: <https://mail.opengeospatial.org/mailman/listinfo/tc >>>>> >, >>>>> <mailto:tc-request@opengeospatial.org?subject=unsubscribe> >>>>> List-Archive: <https://mail.opengeospatial.org/mailman/private/tc> >>>>> List-Post: <mailto:tc@opengeospatial.org> >>>>> List-Help: <mailto:tc-request@opengeospatial.org?subject=help> >>>>> List-Subscribe: <https://mail.opengeospatial.org/mailman/listinfo/tc >>>>> >, >>>>> <mailto:tc-request@opengeospatial.org?subject=subscribe> >>>>> Sender: tc-bounces+lee=ogf.org(a)opengeospatial.org >>>>> >>>>> PRESS ANNOUNCEMENT FOR IMMEDIATE RELEASE >>>>> For information about this announcement, contact: >>>>> >>>>> Sam Bacharach >>>>> Executive Director, Outreach and Community Adoption >>>>> Open Geospatial Consortium, Inc >>>>> tel: +1-703-352-3938 >>>>> sbacharach(a)opengeospatial.org >>>>> >>>>> ----------------------------------------------------------------------- >>>>> >>>>> >>>>> Wayland, Mass., February 22, 2008 - The members of the Open >>>>> Geospatial >>>>> Consortium, Inc. (OGC) have approved version 1.0 of the OpenGIS(R) >>>>> Web Processing Service (WPS) Interface Standard. >>>>> >>>>> The WPS standard defines an interface that facilitates the >>>>> publishing >>>>> of geospatial processes and makes it easier to write software >>>>> clients >>>>> that can discover and bind to those processes. Processes include >>>>> any >>>>> algorithm, calculation or model that operates on spatially >>>>> referenced >>>>> raster or vector data. Publishing means making available >>>>> machine-readable binding information as well as human-readable >>>>> metadata that allows service discovery and use. >>>>> >>>>> A WPS can be used to define calculations as simple as >>>>> subtracting one >>>>> set of spatially referenced data from another (e.g., determining >>>>> the >>>>> difference in influenza cases between two different seasons), or >>>>> as >>>>> complicated as a hydrological model. The data required by the >>>>> WPS can >>>>> be delivered across a network or it can be made available at the >>>>> server. This interface specification provides mechanisms to >>>>> identify >>>>> the spatially referenced data required by the calculation, >>>>> initiate >>>>> the calculation, and manage the output from the calculation so >>>>> that >>>>> the client can access it. >>>>> >>>>> The OGC's WPS standard will play an important role in automating >>>>> workflows that involve geospatial data and geoprocessing services. >>>>> >>>>> The OGC(R) is an international consortium of more than 345 >>>>> companies, government agencies, research organizations, and >>>>> universities participating in a consensus process to develop >>>>> publicly >>>>> available geospatial standards. OpenGIS(R) Standards support >>>>> interoperable solutions that "geo-enable" the Web, wireless >>>>> and location-based services, and mainstream IT. OGC Standards >>>>> empower >>>>> technology developers to make geospatial information and services >>>>> accessible and useful with any application that needs to be >>>>> geospatially enabled. Visit the OGC website at >>>>> http://www.opengeospatial.org/. >>>>> >>>>> _______________________________________________ >>>>> Tc mailing list >>>>> Tc(a)opengeospatial.org >>>>> https://mail.opengeospatial.org/mailman/listinfo/tc >>>>> >>>>> >>>>> >>>>> Attachment converted: Macintosh HD:05-007r7_Web_Process#616217.pdf >>>>> (PDF /«IC») (00616217) >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> HIDEMOTO NAKADA, AIST >>>>> -- >>>>> gridrpc-wg mailing list >>>>> gridrpc-wg(a)ogf.org >>>>> http://www.ogf.org/mailman/listinfo/gridrpc-wg >>>> >>>> >>>> ---------------------------------------------------------------------------------------------- >>>> Eddy Caron. Mcf ENS Lyon >>>> ENS Lyon - LIP - Projet GRAAL >>>> 46 Allee d'Italie, 69364 Lyon Cedex 07, France >>>> E-Mail : Eddy.Caron(a)ens-lyon.fr >>>> [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron >>>> ] >>>> >>>> ------------------------------------------------------------------------------------------------ >>>> >>>> >>> >>> >>> >>> -- >>> HIDEMOTO NAKADA, AIST >> >> ---------------------------------------------------------------------------------------------- >> Eddy Caron. Mcf ENS Lyon >> ENS Lyon - LIP - Projet GRAAL >> 46 Allee d'Italie, 69364 Lyon Cedex 07, France >> E-Mail : Eddy.Caron(a)ens-lyon.fr >> [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/ >> ~ecaron ] >> ------------------------------------------------------------------------------------------------ >> >> > > > > -- > HIDEMOTO NAKADA, AIST ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron(a)ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------

1 0

Recharter?
by Yusuke Tanimura 20 May '08

20 May '08

Dear all, I am posting this email on behalf of Hidemoto. Our current chater is out of date and we are being asked to review and update the charter by GFSG. An attached file is a draft recharter document which revised to reflect some of our discussion in OGF22. I think one of the biggest changes would be to specify the time schedule for "A GridRPC Model and API for Middleware Developers" document. DIET team, could you check if this schedule is ok for you? First Draft: 2008-06 Public Comment: 2008-08 (I added) Publication: 2008-12 (I added) If there is any other description to be updted (e.g. Group Focus and Scope), please raise a discussion. Thanks, ----------------------------------------------------- Yusuke Tanimura <yusuke.tanimura(a)aist.go.jp> Information Technology Research Institute, AIST 1-1-1 Umezono, Tsukuba Central 2 Tsukuba City 305-8568, Japan TEL: +81-29-862-6703 / FAX: +81-29-862-6601

3 15

Fwd: OGF support for OGC Web Processing Service spec?
by Hidemoto Nakada 13 May '08

13 May '08

All, We've got an invitation for a talk at the upcoming OGC-OGF workshop at OGF-23 from Craig, one of the co-chairs. I think we should give it. any idea? -hidemoto ---------- Forwarded message ---------- From: <lee(a)aero.org> Date: Wed, May 7, 2008 at 4:21 AM Subject: Re: OGF support for OGC Web Processing Service spec? To: lee(a)aero.org, Hidemoto Nakada <hide-nakada(a)aist.go.jp>, Yves Caniou <yves.caniou(a)ens-lyon.fr>, s.jha(a)ucl.ac.uk, kielmann(a)cs.vu.nl, Andre Merzky <andre(a)merzky.net>, Andrew Grimshaw <grimshaw(a)virginia.edu>, Steven Newhouse <Steven.Newhouse(a)microsoft.com>, humphrey(a)cs.virginia.edu, Geoffrey Fox <gcf(a)grids.ucs.indiana.edu>, Christopher Smith <csmith(a)platform.com> Cc: Satoshi Sekiguchi <s.sekiguchi(a)aist.go.jp>, Chris Higgins <erpl70(a)holyrood.ed.ac.uk>, George Percivall <gpercivall(a)opengeospatial.org>, craig(a)rushg.aero.org, scumb(a)ogf.org All, As part of the upcoming OGC-OGF workshop in Barcelona at OGF-23, I would very much like to get a brief overview talk from (ideally ;-) the SAGA, GridRPC, and HPC-Basic Profile groups. The OGF-23 workshop is being coordinated with the OGC Technical Committee meeting which is taking place the exact same days as OGF-23 but in Potsdam, Germany. Hence, while these overview talks will be presented in Barcelona, their primary audience is intended to be the OGC folks who will be in Potsdam. OGC represents a potential new user community for OGF grid tools so this is an important opportunity. Also, the next OGC Web Services Testbed, OWS-6, is still in the planning process, and what we discuss in this workshop could very well be picked up for testing and demonstration by the OWS-6 sponsors and participants. Please let me know if your group can provide an overview talk. Thanks! --Craig At 12:52 PM -0800 2/29/08, lee(a)aero.org wrote: All, This request is an action that came out of this week's OGC-OGF Collaboration workshop. OGC (Open Geospatial Consortium) has just announced version 1.0 of their Web Processing Service. (I've forwarded the press release below.) I've looked at earlier versions of this document and based on my initial assessments, it seems that WPS could very possibly map to: 1) HPC-Basic Profile (How would WPS work w/ JSDL and BES?) 2) GridRPC (Besides the call-response, could Data Handles be used in WPS?) 3) SAGA (Much like the GridRPC package, could there be a WPS package?) It would be extremely helpful to get others from each of these groups to make their own assessment. WPS is a basic request-response mechanism with only basic support for managing where the data is. Depending on who you ask, ~80% of the data the human race has collected or generated is geospatial referenced. Hence, OGC represents a huge user base for geospatial data and, imho, is a natural adjacency for grids. All insights, issues, and comments are desired! I know that many of us are very busy and simply will not have time to read an 86-page document from beginning to end. But, as with many standards documents, the core of the spec is presented in only about ten pages, with the rest of the doc being necessary detail to clearly define the spec. Hence, pages 4-11 present the WPS overview, and pages 11-48 go into more detail about the three main WPS functions: GetCapability, DescribeProcess, and Execute. Please let me know right away if you can help with this assessment. I'd like to collect comments in a few weeks. Thanks, --Craig Delivered-To: lee(a)aero.org Delivered-To: lee(a)ogf.org Date: Fri, 22 Feb 2008 14:48:22 -0500 From: OGC Press <announce(a)opengeospatial.org> Organization: OGC To: tc(a)opengeospatial.org, pc(a)opengeospatial.org X-Virus-Status: Clean Subject: [Tc] OGC(R) Approves Web Processing Service Standard X-BeenThere: tc(a)opengeospatial.org Reply-To: announce(a)opengeospatial.org List-Id: "The Technical Committee is responsible for all aspects of the formal consensus OGC specification process. " <tc.opengeospatial.org> List-Unsubscribe: <https://mail.opengeospatial.org/mailman/listinfo/tc>, <mailto:tc-request@opengeospatial.org?subject=unsubscribe> List-Archive: <https://mail.opengeospatial.org/mailman/private/tc> List-Post: <mailto:tc@opengeospatial.org> List-Help: <mailto:tc-request@opengeospatial.org?subject=help> List-Subscribe: <https://mail.opengeospatial.org/mailman/listinfo/tc>, <mailto:tc-request@opengeospatial.org?subject=subscribe> Sender: tc-bounces+lee=ogf.org(a)opengeospatial.org PRESS ANNOUNCEMENT FOR IMMEDIATE RELEASE For information about this announcement, contact: Sam Bacharach Executive Director, Outreach and Community Adoption Open Geospatial Consortium, Inc tel: +1-703-352-3938 sbacharach(a)opengeospatial.org ----------------------------------------------------------------------- Wayland, Mass., February 22, 2008 - The members of the Open Geospatial Consortium, Inc. (OGC) have approved version 1.0 of the OpenGIS(R) Web Processing Service (WPS) Interface Standard. The WPS standard defines an interface that facilitates the publishing of geospatial processes and makes it easier to write software clients that can discover and bind to those processes. Processes include any algorithm, calculation or model that operates on spatially referenced raster or vector data. Publishing means making available machine-readable binding information as well as human-readable metadata that allows service discovery and use. A WPS can be used to define calculations as simple as subtracting one set of spatially referenced data from another (e.g., determining the difference in influenza cases between two different seasons), or as complicated as a hydrological model. The data required by the WPS can be delivered across a network or it can be made available at the server. This interface specification provides mechanisms to identify the spatially referenced data required by the calculation, initiate the calculation, and manage the output from the calculation so that the client can access it. The OGC's WPS standard will play an important role in automating workflows that involve geospatial data and geoprocessing services. The OGC(R) is an international consortium of more than 345 companies, government agencies, research organizations, and universities participating in a consensus process to develop publicly available geospatial standards. OpenGIS(R) Standards support interoperable solutions that "geo-enable" the Web, wireless and location-based services, and mainstream IT. OGC Standards empower technology developers to make geospatial information and services accessible and useful with any application that needs to be geospatially enabled. Visit the OGC website at http://www.opengeospatial.org/. _______________________________________________ Tc mailing list Tc(a)opengeospatial.org https://mail.opengeospatial.org/mailman/listinfo/tc Attachment converted: Macintosh HD:05-007r7_Web_Process#616217.pdf (PDF /«IC») (00616217) -- HIDEMOTO NAKADA, AIST

4 4

Stepping down from secretary
by Yoshio Tanaka 14 Apr '08

14 Apr '08

Dear co-chairs and all, Due to my obligation to contribute to the other OGF WGs/RGs (CAOPs WG and LoA RG) which I'm charing, I'd like to step down from the secretary of the GridRPC WG. I'd like to nominate my colleague, Dr. Yusuke Tanimura (AIST), as the incoming secretary. Please approve the change of the secretary from me to Yusuke. Sincerely, -- Yoshio Tanaka (yoshio.tanaka(a)aist.go.jp) http://ninf.apgrid.org/ http://www.apgridpma.org/

1 1

New version of the proposal of the API for GridRPC Data Management
by Yves Caniou 25 Feb '08

25 Feb '08

Dear all, ###### Summary of the session ##################### Hidemoto Nakada presented the session. The GridRPC API lity is now an OGF standard. Gaël Le Mahec presented the work performed on a proposition for GridRPC Data Management API from GRAAL's Team (Yves Caniou, Eddy Caron, Frederic Desprez and Gaël Le Mahec) Two discussions were conducted then: -1- concerning the Data Management API -2- concerning the proposition of extending the GridRPC API with array functions, in order to submit arrays of data ###### Points to discuss and improvements since the meeting ##### -1- Concerning the Data Management API There was some errors and some helpful suggestions on the slides, which have been accordingly corrected. A new version of slides can be found at http://graal.ens-lyon.fr/~ycaniou/GridRPC/OGF-21.pdf Note that similar corrections have also be made in the Data Management API proposition. Furthermore, the document has evoluted with some modifications described above. It is available at http://graal.ens-lyon.fr/~ycaniou/GridRPC/GRPC_Data-0.5.pdf Changelog is: **** Modifications . For coherence with naming convention, changed - 'grpc_DM_type_t' for 'grpc_data_type_t' - 'grpc_DM_mode_t' for 'grpc_data_mode_t' . Slides 18, 'grpc_info_type'->'grpc_info_t' . Added pointers in all functions for grpc_data_t . Slide 23, miss a ',' . Slides 28, 31, don't use NULL for grpc_data_mode_t but GRPC_VOLATILE as default (requested by all ) . Renammed 'DOUBLE' by 'GRPC_DOUBLE', 'ARRAY_OF_INT' by 'GRPC_ARRAY_OF_INT', etc. . Make all grpc_data_mode_t preceded by 'GRPC_', for example 'VOLATILE' is now 'GRPC_VOLATILE' **** Additions . Add type of diffusion, like broadcast, etc., used by software like omniStorage in grpc_data_write() **** Novelties . Use an URI for the save and load functions. A small change that leads to much more possibilities. . The grpc_data_free() functions was not well defined concerning the freeing of the data on the different available locations. We have splitted in grpc_data_unbind() and grpc_data_free() as commented in the document. . Added the GRPC_CONTAINER_OF_GRPC_DATA type for a grpc_data_t variable. . Added 2 functions grpc_data_container_add() and grpc_data_container_get() Should we include some additional functionalities? . Add a new function ? grpc_error_t grpc_data_transfer_wait(grpc_data_t* data, grpc); because some transfers can be synchronous or asynchronous... -> The user can know for sure that the data is in place. -2- Concerning the proposition of extending the GridRPC API with array functions. . The objectives of this proposition is to make possible to use array of data in one call. For example, a GridRPC call with 3 arguments could be made with a GridRPC with one array argument of 3 data. . Two points of view are discussed here: . Some of us want to provide a new additional API. . Some others find that it has some overlap with the OGF GridRPC API standard and that functionalities are/must be already included within the Data Management API. -> Both groups said that they would provide a document describing their arguments describing why a given solution is better, with an example. => Our document can be accessed through http://graal.ens-lyon.fr/~ycaniou/GridRPC/implementation_examples.pdf ------------------------------ Conclusion ---------------------------------- The OGF meeting was a great moment, with entertaining discussions. Very useful remarks have been made, that gave us a good motivation to keep on. Thank you for the stimulating discussion in Seattle. In order to make strong progress in the proposition, we suggest that people takes each point and comments it, explaining why he agrees or disagrees with a special item. The next OGF is not far now, I really apologize not to have given any news before. I hope to see all of you there. Best Regards. .Yves.

2 4