OGSA Teleconference April 01, 2004 ================================== * Participants Dave Berry (NeSC) Bill Horn (IBM) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Abdeslem Djaoui (RL) Andreas Savva (Fujitsu) Frank Siebenlist (ANL) David Snelling (Fujitsu) Latha Srinivasan (HP) Ravi Subramaniam (Intel) Jem Treadwell (HP) Jeffrin Von Reich (HP) Minutes: Andreas Savva * Early Discussion ** Approved March 29 minutes - no comments * OGSA infrastructure dependence Participants were asked to express opinions (even if just to agree!) to the list early. Tentative deadline for decision is next week. Consensus that the group should not spend excessive time discussing this topic. There was already consensus on the last call on doing a concrete mapping and leaning towards WSRF. There have been one or two negative opinions on the ML. Not clear if people on the list have looked at last call's minutes. Action: Notetaker (Andreas) to send out an email (on the same thread as existing ones) referring to the minutes of last week as well as this week's mentioning that we had this discussion. Discussion: - The OGSA doc will not really have any normative WSRF stuff in it (no normative wsdl). - Using or not WSN is a different decision from using WSRF. (WSN is an interface.) - WS-N could be taken as a start for whatever text we put in section 6. - Rendering problem will become more important when we come round to expressing interfaces, e.g., whether to use the WS-Resource pattern or not. - WS specs are in flux, e.g., WSDM etc and our assumed dependences. Proposal: Follow a top down approach and only make rendering decisions when absolutely necessary. Discussion: - Comparison with Corba (1); if the low level stuff are not nailed down it makes it harder to build things on top (higher level services). Andrew also pointed out this problem last time. - In principle the group agrees on infrastructure independence and rendering the spec using WSRF (for concreteness) and then making an abstract one. - (Comment: This has been more or less the group's position since the Sep. 2003 interim meeting. Initially stated wrt OGSI.) - Main problem is programming paradigm; we don't necessarily have to do the abstraction step; people can remap (easily?) Today's consensus: 1. Use WSRF as concrete infrastructure until GGF11 - While publicly stating and keeping in mind that this rendering may not be the only one 2. 'Do' a more abstract document later if necessary - Maybe it is not OGSA-WG's job to do multiple mappings. Discussion: - Interoperability is something that should be addressed at some point. - To address when someone does wsdl expression of interfaces. - How should the structure/interface/state in the OGSA document be expressed? e.g., UML, wsdl, or something else. - Bill has been advocating UML to identify interfaces etc Action: Bill to do strawman of how interfaces should be represented in section 6. Do UML a step above a normative WSRF (resource) expression. Deadline is next Wednesday call (April 7). * Document reorganization Hiro sent out an outline of proposed changes to the list. Main proposal is to split current "Taxonomy" chapter into "Functions" and "Taxonomy." - "Functions" to cover things like PE, Provisioning, etc. Functions may be using an overlapping set of services. - For example PE architecture explanation would go in "Functions". Specific PE services would still be detailed in Ch.6 Consensus that "Functions" is an overloaded term. Maybe use "Capabilities," or some other term? - Granularity question: What are the criteria for grouping things? - E.g., Logging: It is not just a service but a collection of interfaces. Any service can choose to implement one or more of those interfaces. There would still be a section 6 grouping.... But it is not at the same level as PE so it would not appear under Functions. - On the other hand should PE also have a section 6 that groups all PE interfaces? (No) - Some confusion over people's usage of terminology, especially the usage of the terms 'service' and 'interface'. - (Ravi) Service and interface difference: Interface is a capability that may be combined with other interfaces; while service is an entity that may be implementing multiple capabilities; also implies some kind of running entity. Action: Hiro to check Feb 2004 (SD) minutes again, especially Jeff Frey's comments on service and interface. - Granularity question (cont) - Hiro's proposal seems to imply a hierarchy like + interface (ch6) + collection of interfaces (ch6) + 'Functions' (or 'profile', 'groupings', 'solutions to a problem', ...) - PE is more of a profile (collection of services that come together to perform a task) or maybe even use case - At one end we have use cases, at the other the interfaces. Then how the interfaces are put together to address the use case. - So whether division and partition of interfaces is good enough or not can be seen by how well they can be used to solve a given problem. - WS-N is an example of an exercice in composability; trying to get the most out of a base set of interfaces Proposed approach (Ravi) - Step 1: Doing groupings to solve certain specific problems, e.g, PE. - Step 2: Do iteration to see what are the commonalities between different groupings Other proposals - Rather than spending time thinking about the taxonomy spend more time working on earlier chapters (2,3). (And perhaps do some taxonomy work in parallel as things become clearer.) - Revisit UC document and review what services (and how) are used. - UC document is now under review of Area Directors. Once it makes it into public review try to get people outside the group to read and comment on it. Confirm that the group is thinking about the right problems. - Comment: Tier-2 document was pulled back from the Editor. Action: Hiro to flesh out the document outline a bit more and recirculate. * AOB Europe went into summer time this week. US goes into summer time next week. (No change in Japan.) *** Teleconference times and dates are changing next week. *** Action: Jeffrin to make sure that Monday's teleconf setup is for the correct time. Action: Hiro to update gridforge OGSA home page with new times and call information No time for Information services discussion in this call. Action: Hiro to reschedule information services. (Abdeslem is not available next week.) Ravi will not be able to attend next Wednesday.