[RUS-WG] [UR-WG] OGF20 Session recommendations

[Xiaoyu Chen]

Hello, Gilbert and Everyone,
 
 
          There are some comments and recommendations to OGF 20 sessions
 
          For Resource Usage Service OGF20 Session:
          1). Agenda 
              It would be considerable to have a short discussion on fault handling and access control or Configuration as well.
          2). XPath Expression
               XPath is a good candidate anchor of strucutural documents, like XML. In the context of RUS, xpath stament is mainly used for query operations.
               (e.g. RUS:extractUsageRecords). In both specification (current and proposal), extraction of usage records returns only whole URs, which results in both cons and pros. 
               cons: A large document set returned to client (network-intensive and risks in session timeout for service as well as low performance).
               pros. easy to be implemented.
 
               The two suggestions proposed in the slide are basically contradictary each other. But still is good to be put forward for discussion.
 
           3). Core RUS Specification 
               Bach processing is preferable in most applications, but performance is a big challenge. clients would like to have flexibility on processing as well as responsiveness. 
           
           4). Batch Query
                Most of applicatoins have been diverted from XML database into Relational DB for UR storage because of performance. However, the rus service interface definition is not relation DB friendly. 
                In this sense, every simple query upon relational UR storage has to explicitly transform return results into XML UR as a well-formed query result. I don't known how WS-Enumeration reduce 
                returned usage records. But add a parameter for max request size is not a good idea in that if setting maximum returned usage records as 10, for example, how to return following usage records 
                to the client, becuase each time the user query for URs, he or she always get first 10 usage records. How to put an anchor there? besides that usage repository are kept updating, and setting an 
                anchor for query seems impossible. What my options here is to let RUS query operation to return either matched URs or partial of matched URs to client, even hugh amount of data, and leaves 
                RUS client to put restrictions on how to restrict the number of usage records returned.
   
            5). Audit Information
                I don't know what is "record undo information" really means here. Do you mean usage records are failed to be proceeded? for example, extraction operations may return 10 matched usage records, but only returns 5 to the user, because of the user are not authorised to see the other five. Then the other failed returned five messages are called "undo" URs?
 
           6). How to get audit information
               Again, RUSUsageRecord schema should not be used in RUS. It undermines the UR standardization. It has been removed in RUS proposal version 1.9. Auditing information can be stored seperately and can only be reported to target manager on requests. ExtractRecordHistory or ExtractAuditInformation can be considered to enhance auditing purpose.
 
           7). Mandatory Elements
               Mandatory Elements is another issue coming from UR itself. Should mandatory elements also consider usage records extensions? But usage of extensions are deprecated as it may undermines UR standardazation. On the other hand, UR seems not powerful enough to accommodate grid usage representation, like VO information. There is no implementations available using UR without extensions. I recommend put this dicussion to UR join session as well.
 
           8). Advanced RUS 
            
               As RUS roadmap, aggregation and data replication are two possible advanced features for RUS. Aggregation is obviously important and put be put into one of the advanced features. For data replication, we need to realised whether RUS advanced specificaiton are Service Interface Definition recommendations only or possible advacned feature for RUS interfaces and low-level mechanisms. For example, Almost all relational database engines provide data replication or synchronizaiotn facilities. Data replication can be simple or complex in various aspects, real-time or after events, full replication or paritial replication and etc. From RUS Service Interface Definition (SID) perspective, Data replications can only invoked on-demand (invoking service interface operations). This results in complex configuration tasks on replica source and target, replication mechanism and even more complicated how to replicate URs between two different storages (relational DB and XML DB). 
 
             Back to aggregation, we have an aggreate usage record schema avaible on RUS work group. However how to connect it to job usage records? there are certain gaps between them, for example, the VO properties, storage properties and etc. We definitely need have a dicussion with UR and see possible solutions. 
 
         PS: Please check the attachment complentary slides. 
 
 
        Cheers!  
 
         X. Chen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ogf20-extra.ppt
Type: application/vnd.ms-powerpoint
Size: 181248 bytes
Desc: ogf20-extra.ppt
Url : http://www.ogf.org/pipermail/rus-wg/attachments/20070503/e2fa27a6/attachment-0001.ppt