GGF12 - OGSA-WG #2 DESIGN TEAM (Information services)
Sep 21  10:30am-12pm
Speakers: Abdeslem Djaoui, Bill Horn, Andrew Grimshaw
Minutes: Junichi Toyouchi, Hiro Kishimoto
--------------------------------------------------------------------------

1. Status report on Information Services: Abdeslem Djaoui
   - Report overview:
     - v1 Information Service
       - Scenarios: Directory service, Logging, Allocating Grid
         resources
       - Capabilities: Naming, Discovery, Message delivery,
         Monitoring, Logging
    - Basic Information Systems: 3 patterns: Notification, Logging,
      Directory /Naming
    - Active Members: B.Horn, A.Grimshaw, H.Kishimoto, S.Fisher,
      A.Djaoui
    - Related WGs: Logging BoF, InfoD, How about ISP groups (CGS,
      etc.)?
    - Activites since GGF11
      - Naming: AG
      - Architecture discussion
      - Extending infoD specs to cover discovery/monitoring/message
        delivery capabilities
    - Outline of v2 work: Logging service, Producer/Consumer service,
                          Registry?  Schema?  Naming?
    - Schedule until GGF13: 
      - Overall architecture, V2 service specifications
        - ISP groups' requirements/capabilities covered in OGSA V1? 
        - Relationship to WSDM monitoring/discovery/schema
      - V2 service specifications: bottom-up approach

 - Q&A
        Q. Appropriate Mechanism ?  Who is the user?
        A. Applications. User should be able to publish/retrieve data.
        Q. Monitor/Scheduler can use this ?
        A. Yes can be used for all scenarios.
        Q. Why applications (e.g. Oracle) need to use this.
        A. Applications means either middleware services or end user
           applications. 
        Q. Reference implementation existing?
        A. We own one relational implementation. Discovery/Monitoring/Logging
        Q. OGSA-DAI ?
        A. Difference in semantics. more stringent ??

2. OGSA-Naming #1: Andrew Grimshar
 - Presentation overview:
   - Terms: Resource/Abstract resource name/Human name/
            Resource address/Resource identity/Binding scheme/Bind
            time
   - Why names?
     - Transparencies:
       location/migration/failure/replication/scalability, and so on
    - Distributed naming is a well-understood area-properties
       Unique/provide identity/comparable/location portable/widely adopted/ 
       Scalable-high performance/extensible/dynamic binding
    - Two level schemes: Human name -> address, abstract name -> address
    - Three level schemes: human-> abstract name -> Address
       In OGSA contexts and information services are human names
    - Many schemes in the past: DNS, LOIS, SGNP, OGSI GSH, WS-addressing, ...
    - Our problem is not so much technical as political
       What about MS,HP, IBM: WS-addressing?
       Put together technical case
       at Toronto reference implementation proposed
       late November, draft 

       Every SDOs and industrial players, e.g. IBM, HP, MS, DMTF,
       OASIS, WSDM, need naming service for distributed computing and
       they are under developing their own naming services. Since it
       is so important, it is not easy to agree on single naming
       services.

       Rough consensus: Attaching statement about "check it if ok or
       not" to Andrew's naming document and take it to them.

       A.I. Andrew will update his doc and sends it out to the list (DONE).

  - Q&A and Comments
     Q. timeline ? Who is the target?  DMTF?
     A. Send it to all people.  Make sure our view of naming is not wrong.
        Place it on the Gridforge for member reviews.
          Human       ->      Abstract Name         ->     Address (Endpoint) 
                     (Level we want to deal with)   1-1, 1-n, m-1, n-m
     Q. Is WS-RF OK for abstract name ?
     A. Endpoint to locators.
     C. abstract name - address binding needs to be dynamic & scalable
        and rebinding for failure
     C. Human readable / Human friendly aspects. 

3. OGSA Logging Service BoF: Bill Horn
 - Presentation overview:
   - Three committed parties needed. General agreement to start WG.
   - Taxonomy: messaging/publish-subscribe/intermediary/DBMS
   - Design Session Summary: Requirements/Relationship with other OGSA
     services. 
   - Usecases: Problem Determination
   - Relationship with other OGSA services: Usage metering / Security
                                            / Messaging fabric / Event
                                            Policy
   - Best practice: Jakarta common Logging/CORBA Log
   - Logger System Requirements: Abstraction of legacy log system/
                   Persistency / Sequential I/O / Ordering of log
                   records / Broker / Read cursor / Robustness /
                   Merged log / Synchronous/Asynchronous log
   - OGSI compliant log system
  
  - Q&A 
     Q. Stateful cursor is log service ?
     A. Browse session enables walkthrough of logs.
     Q. Reference implementation exists ?
     A. Not yet. That's what we want. partially done.