OGSA Teleconference May 24, 2004 ================================ * Participants Sachiko Wada (Ascade) Ravi Subramaniam (Intel) Latha Srinivasan (HP) Andreas Savva (Fujitsu) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu) Bill Horn (IBM) Abdeslem Djaoui (RL) Minutes: Andreas Savva * Early Discussion ** May 5 Minutes correction - no comments, approved ** May 17 Minutes - no comments, approved ** May 19 Minutes - no comments, approved * GGF11 Update - All session changes have been reflected on the online GGF11 schedule. (Some detailed information may be missing from the last session). Hiro will followup. - Fred proposed switching the DMTF UC-WG cross WG meeting on June 8 with the Data design team session on June 9. (In order to combine the two cross WG sessions: UC-WG and WSDM-TC.) - The proposal was rejected because the Data design team session would then clash with the Grid File System WG session. * Information Services (IS) review - Draft posted to list: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/05/msg00076.html - Reviewed by section ** Objective - "Uniform view & query language" - Not sure what is being proposed here - It is more of a discovery requirement - Might be better to reword or move further down - "Each OGSA system" - The term "system" gives a somewhat implementation feel to the text - Replace system with 'service' - (Not clear if 'service' is right either) - Bill and Hiro have a number of other minor comments Action: Bill and Hiro to mark up document and send back to Abdeslem Action: Abdeslem to produce a new draft addressing the points raised in the review. ** Models - Producer/Consumer - Discovery is part of IS, and there are different types of discovery, but the text here should not be focused on Discovery - "If the consumers know in advance..." - Problem determination logging UC: Might know the producer but would not access directly. - 'producer' is used in a general sense, could be the intermediary (e.g., logging system) - Reword to make this point clearer - (There is more slant on Discovery in this section) - Discovery provides minimal information; post-discovery returns more copious information. Are both of these scenatios covered by the same mechanisms? - Ravi raised a Broadcast example: discovery is not an initial step - Still would need to discover broadcast group - No, might be pre-configured and in some promiscuous mode - Not interested in the producer just the information stream - Proposed that the text should cover 2 more cases 1. passive case (not going out to seek/discover things) 2. pre-configured - But are the interfaces different or not? Do not want to end up assuming lots of 'things' that can not be described. - Do we dissallow these cases? - Something like 'sniffing packets' is out of scope. Only when it comes to publishing that information does it come in scope of the Information services. - A P2P scenario is at the bottom of the broadcast scenario used by Ravi. - Proposal to make clear that there is no centralised information directory. - The text does not assume a centralised directory and P2P is mentioned later on - Might be better to make statements more declarative - And de-emphasize the discovery need (mention as option) - This is what the text should say and if it does not it should be fixed. - And do not have to go to the producer to get the information - Data Model/Query languages - "XML model should be supported" : - Some discussion on whether OGSA is prescriptive on XML or not - Prescriptive in that the 'envelope' must be XML but not necessarily the data (that is the intent of the text; might not be clearly expressed) - Metadata model - Why are events called out in particular here? - Some conflict between title and the explanation - The text is much more specifically about events - Event definition here is different from the Glossary definition - In this text it is "metadata associated with information" that may be closer to "message" instead - "metadata ...describing structure" - Metadata may also describe properties, usage, etc - Bill proposed to make the metadata section disappear by merging it other sections of the document - Metadata is data; depending on usage it may be just data or metadata - The text should be structured differently to make it clearer. - Also need a glossary definition - Ravi gave a 'blob of data' scenario to describe metadata - Data and association - Might have - Tight binding: metadata as one with data - Looser binding: e.g., through some kind of association service - Proposal to add this kind of discussion here was rejected. (It seems out of scope.) - WSRF connection: Use similar mechanism to model? - The structure and title names used here is the one decided at the F2F. - In conclusion it looks more like a change in title to something like "Event schema" might be more appropriate rather than addressing Metadata issues in detail. ** Example scenarios - Directory - UDDI example might not be appropriate. It is a concrete example that people can understand but it is not specifically grid. - Other examples of directories: DDNS, LDAP, MS Active direcotyr, yellow pages ... - But all these are legacy. - Need to be careful how these are presented; and describe the motivation for something new in a better way. - Inband/Outband discussion - UDDI updates are done out of band (same as DNS) - Might want to add a dynamic example (GMA is added for this reason) - But GMA example is too broad/specialized - "...static information" - Proposal to remove this phrase. It is not essential to Directory explanation. - Static/dynamic has two meanings here: - Data (changing data or not: low or high rate of change) - Entry (add/remove data) - Might want to tease the meaning of this out some more: (- Scenario driving directory is different than GMA directory - Consumer-side doesn't seem to be different - Internally it is different - Historical perspective: Using LDAP required knowing the types of queries in advance - Could build monitoring system using it but it would be somewhat limited.) - Message brokering - WS-notification reference should be added here - This section should go into use case like scenarios, e.g., problem determination, monitoring, etc. - So the level seems to be different than what is expected. - Logging - Bill to add text - GMA Monitoring example - "OGSA information/monitoring" - Are the services in this section doing monitoring or are they information services? - Abdeslem thinks that there is no difference between monitoring and information (except a timestamp on the monitoring data, i.e., some extra information and/or semantics) - (Ravi) Semantics are added when information is consumed - Is the information system also a monitoring system (or is that behaviour something added)? - (Abdeslem) It is also a monitoring system - Might need to rewrite this scenario to show that information services can also be used to do monitoring and that this section is about monitoring ** Producer/consumer patterns - Agreed to remove DBMS from Fig. 1 Action: Bill to produce a new Fig. 1 ** Functional Capabilities - Text is making distinction between service and resource discovery. It might cause problems/confusion so the two sections should be merged. - "Monitoring tools" - Seems a bit out of place - How infomration is used but not part of the services - Agreed to remove it - Need to show what are the functional capabilities - Rather than "Distributed logging" need the functions that can enable it. - Bill repeated his position that he does not think that everything can be lumped together into a super-general producer/consumer interface. (It can in the abstract but not when coming down to a concrete interface definition.) - Mediation query planning - What is the concrete interface? plan_query vs query - But are these interfaces really different? eg. is format different? - Also how about multiple query mechanisms, or types of queries? With reference to OGSI (and probably WSRF), there was a "find service data" but the the door was left open to add other query methods/formats. - Query and interface seem to be in scope but the query planning part seems to be somewhat out of scope. - Proposal for Query - Some basic types supported - And mechanism to find what is supported - Extensibility (to add more) - And check whether we already have all this courtesy of WSRF. ** Interactions with OGSA - Is there some minimal set that can be assumed or do we call everything out in each section (e.g. WSRF, Agreement, etc) - There is an infrastructure section in the OGSA document. Perhaps everything that is listed there can be assumed by default (but may not be used by all services in all capabilities). - Agreed that the "Interactions with OGSA" section should talk about higher level (not infrastructure) services ** Other discussion - What does "Capability" mean? - Ravi's definition is that "Capability is interface, semantics and behaviour" - (Hiro added that Capability in the OGSA Capability section encompasses more than one service; a 'function' supported by a number of (interacting) services.) Action: Jem to add definition of Capability in the glossary.