[RUS-WG] RUS Core Specification Proposal-query operations

[Xiaoyu Chen]

Hello, RUS Team:

Rosario wrote:
>1) IDL + renderings (as long as we don't have the renderings we can also
keep the spec's wsdl up-to-date)
It think IDL renderings can be delayed until as least we agree on service interface definitionswithout considering configuration and access control (except UserUnauthorisedFault) recommendations.
>2) Full integration of/compliance to XPath
Given aggreement on full XPath compliant RUS::Extraction, i will give a breif review on query-specific service interface defintions:
2.1 RUS::extractUsageRecords
      This operation allows query usage records according to XPath search term.
      Input: search criteria expression as XPath;
      Output: A list of returns;
                    OpeationResult;
      Faults: RUSUserNotAuthorisedFault; RUSInvalidInputFault; RUSInternalFault;
      Issues: This operation allows flexible query on returning partial usage information. e.g. A user only queries the charge information of his or her jobs, how to validate the returned usage records. 
      Potential Solutions:
                       Option 1: does not validate returns at all, and the list of returns;
                       Option 2: restrict the output returns to OGF-UR records with urf:RecordIdentity as a mandatory element. However, the specification does not clarify how to put urf:RecordIdentity into returns and leaves implementations to decide. For example, the implementation of RUS::extractUsageRecords might check XPath input and append XPath statement with urf:RecordIdentity to be renturn implicitly. In this sense, the output of this operations should return a list of usage records.
     
2.2   RUS::extractRecordIds
       This operation helps clients to obtain record identities according to XPath search term.
       Input: search criteria expression as XPath;
       Output: A list of record identities (string);
                      OperationResult;
       Faults: RUSUserUnauthorisedFault; RUSInvalidInputFault; RUSInternalFault;
 
2.3   RUS::extractSpecUsageRecords (new Proposal)
        This operation allows queries of usage record using recordId as search key;
        Input: a list of recordIds as strings;
        Output: A list of usage records;
        Faults: RUSUserUnauthorisedFault; RUSRecordNotFoundFault; RUSInternalFault;
        
*********RUS Fault List and Semantics***************
Current Version
It seems a little bit weird to have both RUSRecordId and OperationResult element seperately, 'cos implementors more concerns about the service performance, while the specification tries to put more elements on the SOAP message. 
Moreover, the operationResult element introduces more RUS faults: NonExistent, Duplicate, PermissionDenied (sound like same as RUSUserNotAuthorisedFault?).
So as a summary, the current release of OGF-RUS specfiication (1.7) throws Faults as following:
Fault Id

Semantics

Target SID

NonExistent

The target usage records to be operated upon cannot be found.

RUS::incrementUsageRecordPart

RUS::deleteSpecificRecords

Duplicate

The target usage records to be operated upon exist and do not allowed to be updated.

RUS::insertUsageRecords

Invalid

The number of records that were rejected as not conforming to ur schema or mandatory list configuration. 

(Doesnot the invalid XPath statement as input fall into this category?)

RUS::insertUsageRecords

(RUS::extractRUSUsageRecords?

Or RUS::extractUsageRecords <version 1.9>?)

RUS::ProcessingFault 

An internal error has occurred

ALL SIDs

RUS::UserNotAuthorisedFault

& PermissionDenied

The user is not authorised to perform target operations or has not right to operate on certain usage records.

ALL SIDs

 
Thus in version 1.9, the specification get rid of the RecordIdList element and combine the RUS faults into operationResult element only.
Fault Id

Semantics

Target SID

RUS::RecordNotFoundFault

The target usage records to be operated upon cannot be found.

RUS::ModifySpecUsageRecords

RUS::deleteSpecUsageRecords

RUS::extractSpecUsageRecords

RUS::DuplicateFault

The target usage records to be operated upon exist and do not allowed to be updated.

RUS::insertUsageRecords

RUS::InvalidFault

The invalid inputs faults including invalid usage records inputs unvalidated with OGF-UR or mandatory element list  as well as invalid xpath expression (important for implemenation that requires restriction on xpath expression as input for query).

RUS::insertUsageRecords

RUS::extractUsageRecords

RUS::ProcessingFault 

An internal error has occurred

ALL SIDs

RUS::UserNotAuthorisedFault

The user is not authorised to perform target operations or has not right to operate on certain usage records.

ALL SIDs

 
Besides the faults are well-structured by extesions from an abstract genral faults. (for more information refer to proposed RUS spec. 1.9).
 
As with operationResult, each operation should return an operation status docuemnt to the user to indicates execution status and fault details (recordId-fault mapping). The operationResult document is refined as well in the proposal. [important: there is no RUSRecordIdList available anymore]
 
 
*********OGF20 Issues***************************
We have a long discussion about RUS extration operations in terms of complex XPath and "BIG" returns. The proposed solutions by OGF20 are to have a RUSQueryTooComplexFault, which seems important for full XPath compatible input for extraction. However, does this really fit into the clarification within the specification???
 
Again for a big returns, there are many solutions to deal with. like OGSA-DAI, which maintains the results within memory and allows the client to query chucks of data with many sessions. But Do you think a seperate fault for "TooBigResutlsFault" can be put into the specification, 'cos for some grid project, which deploys RUS implementation at site-level and operates on relatively same number of usage records. Or a RUS implementation only allows operations upon aggregate usage records. This fault will not thrown for these implementations at all. I can understand why people in OGF 20 proposal various solutions for this, because they are thinking from implementor perspectives. But for specification, we can only recommend implemenations but not supposed to specify solutions. 
 
So my proposed solutions are: 
Put the "RUSQueryTooComplexFault" into  RUS::InvalidFault category;
Put "TooBigResultsFault" into some defined faults (do you have any recommendataions? );
Besides, do you remember the Fault schema in spec. v1.9 proposal allows custom defined RUS faults, but this would undermise standardisation and it is implementation's reponsibility to consider how to extends RUS faults for their custom implementations. 
 
More topcis are coming soon.....
 
Also, do you think it is more praticle to have a regular RUS teleconference organised for detailed discussion, say every friday?
 
Cheers!
 
X. Chen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 16393 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/rus-wg/attachments/20070518/78ebdba1/attachment-0001.bin