Minutes attached. Gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050110/en/1 -- Andreas Savva OGSA Teleconference - January 10, 2005 ====================================== * Participants Dave Berry (NeSC) Abdeslem Djaoui (RL) Ian Foster (ANL) Andrew Grimshaw (UVa) Bill Horn (IBM) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Tom Maguire (IBM) Mark Morgan (UVa) Takuya Mori (NEC, ANL) Andreas Savva (Fujitsu) Dave Snelling (Fujitsu) Ravi Subramaniam (Intel) Jem Treadwell (HP) Jay Unger (IBM) Minutes: Andreas Savva * January 5 minutes approved with no changes * Basic profile draft review Very early draft uploaded to Gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/OGSA_Basic_Profile_dra... - Fairly close in structure to profile template. It is an early draft and incomplete. - Some discussion at the beginning on extensibility and why interoperability does not apply. - Includes Addressing, Resource, Resource Lifetime, Service Group, Base Faults. - Addressing: Reference properties: - If there is a policy extensibility it must be the first one - Sender cannot construct the EPR (might be problematical; how to check) - Signatures? - Which version of WS-Addressing is used or is WS-Addressing discussed in generic terms? - Statements assume the version submitted to W3C. - WS-Addressing statements relate only (/mainly) to EPRs - (Message information and faults not fleshed out (MIH)) - Should Resource be included in the basic profile. Does the resource access pattern preclude 'generic' web services? - Need clarification of client using OGSA (what it can expect) vs service that is in OGSA (what it must provide and how). - An 'ogsa service' must be one that implements the profile (or parts of the profile) in the defined manner. - As such web services are not precluded; but they will not be 'ogsa services' - This is a point for further discussion and it was agreed that a section to address this issue should be added: What the client has to understand and what is required of services that participate. - For example the client would have to understand EPRs - The second point is what this document is describing - Is everything included in the profile or are more additions planned? - Still incomplete. For example, base notification will probably be added. - How about protocols? - This basic profile is an extension of the WS-I basic profile. As such, what is included in the WS-I basic profile is also included here. - Note that there is no a requirement to implement everything in the profile. Often the statements are of the form: "if something is done it must be done this way" so if something is not implemented all the related statements do not apply. - For example, UDDI: no requirement to use but if used then it must be used in the way that the WS-I basic profile describes - Also note that the OGSA basic profile does not (cannot) reduct/remove restrictions from the WS-I profile. - As a general description approach see R1003: - WS-I allows for optional QName for wsdl:service; an instance that the ogsa profile might want to impose a stricter restriction. - It was agreed that this is ok as a technique (and defering agreement on content for now) - Should the basic profile also include security? - Different thoughts of how to include security. It might be too complex to include it at this moment. - Perhaps do a base profile and a security base profile separately first and then talk about how they should be used together. - Agreed that the numbering used in the document is confusing. Need to come up with a clearer method. ** 1.12 Resource embodiment Again here it might be a good idea to separate the requirements on the clients and services. ** 1.14 Get resource property Set or Query are not included. As an example, at a later point 'query' might be included as an option. The profile could then mandate what is required for this functionality, if provided. In other words, the original specification allows support for many query languages, but the profile could state that as minimum support for XPath version x.y.z must be provided. (Without precluding different or extended query mechanisms on properties.) ** 1.16 Scheduled Termination - Different levels of compliance are also possible. For example, suppose that 'Scheduled termination' must be supported. It could be supported by providing the operation but returning a fault, or it could be supported and implemented according to some optional method described in the original specification. - In other words, all the profile typically says is that the operation must return a valid response (and valid responses are according to the original specification). - Again it might be possible to place more restrictions on the required semantics than what the original spec intended. But the original spec might have been defined the way it was for certain reasons. Care is needed. ** 1.17 Mandates SGs for collections - Phrasing seems overly restrictive; might want to allow for other mechanisms to provide the semantics of the collection - Clarified that statement relates to "if service groups are implemented" it is not intended to preclude other mechanisms for collections. ** Other In general, note that restrictions in the original specifications still apply. - Any Missing functionality? - Naming: It should be part of a base profile even though there are no hard standards yet. - 'Base' here refers more to the maturity of the specifications rather than their place in the architecture. - Renewable References: not much progress yet. There was a proposal to push it into WS-Addressing group in W3C. Not sure how it will evolve. - Providing required resource properties definition and metadata on them - e.g., mandate the WSRF optional metadata on resource properties themselves? - WSDM - Not sure if it will be part of the basic profile. May be one level up. But some parts of it might belong at a lower level: e.g., identity. ** Next steps: Tom has the pen. He will pass it to Dave S tomorrow. Next time to review this draft: Next Wednesday Jan. 19 ** Proposal to draw up a list of all relevant standards and references to them to make it easy to read up and follow the discussion. Ravi volunteered to do a first draft. * Next F2F agenda https://forge.gridforum.org/projects/ogsa-wg/document/agenda_for_2005_Feb_me... - Hotel in question is Westin (O'Hare Airport) - Andrew to follow up with hotel reservation - (Might want to have the conference room for an extra day at the end for a separate (non-OGSA) meeting) - Add Ravi to the list of participants - Main topic is Basic profile discussion. Current schedule proposal splits this discussion across 2 days. - Agreed that it would be more efficient to keep the Basic profile discussion on the same day and split the day into a discussion of the different sections of the profile - So Monday is dedicated to the base profile exclusively: Work out the detailed schedule later on - Tuesday: move on to other topics: EMS, Data, Naming - Proposal to have EMS & Data refactoring before the EMS & Data profile discussion - Is there enough representation from the Data team? - Andrew and Mark will be attending. - Dave B cannot make it. He will raise the issue on the Data call this week. - What is the difference between session (5.2) and the earlier EMS session? Discussion of the architecture versus the profile. - Proposal to discuss the EMS profile on the next EMS call agenda: Discuss which standards should be included. * GGF13 session schedule update Reference: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/01/msg00009.html Proposal for Information services to share the Resource Management section - There has been some interest from INFO-D group to make a presentation to the OGSA-WG; maybe 20 minutes. No specifics yet. - Consensus that it would be ok to make the RM session a shared session for this purpose if necessary. Work out the details later. * Next call - Review of OGSA version 1.0 and Glossary drafts (final review if possible) - Hiro, Andrew, Dave S will not be available (GFSG F2F) - Jem can only attend for the first hour - Andreas to send out agenda; this is likely to be a short call.