[RUS-WG] Artifact changed: Doc Change Response

[Gilbert Netzer]

Hello everyone,

please also see the tracker artifact artf5887 which is actually the request
for using WS-Enumeration for queries. We should posts comments there to
keep the trackers in scope and easier to follow.

I will add the comment to the tracker there to continue the discussion there.

Best Regards
Gilbert Netzer


SourceForge Administrator wrote:
> artf5934: Doc Change Response
> 
> Modified on 07/05/2007 by Xiaoyu Chen
> 
> Comment was added:
> Hello, everyone:
> 
> It's great to get your comments finally. I got some problems when composing OGF-RUS specification version 1.9. There are some points:
> 
> 1). Rosario said, we should concentrate on some changes agreed based on version 1.7 with agreed comments, such as removing RUS-UR wrapper. But the main difference for version 1.9 is targeted removing RUS-UR. Do you mean leaving the RUS operations as what they are? If it is the case, then i will update the version 1.7. 
> 
> 2). Regarding RUS operations, the reason i got stucked somehow is an important signal from stakeholders about query operation. 
> "The RUS specificaiton is hard to be conformed only if the query operations providing reliable extraction of usage records based on following contexts:
> first of all, as a specification, it should gives implementation guides to solve potential problems and makes reliable recommendataions. Which means, the specification should protect the RUS server from being crashed when returning large amount of data."
> We agree to propose a "RUSTooComplexFault". However this never really solves returning huge-data to the client. Some implementation strongly requires a "steam" type return for stateful connection to the database. They request the complex queries always return what user asked even taking longer time. However, this would not work through Web service, which is stateless essentially and will throw session out error if taking too long time to get SOAP response message back. 
> 
> So i reviewed OSGA-DAI, WS-DAI, WS-Enumeration, WS-Context and other relevant specification and implementations. There is still no satisfiable solutions for this issue from the perspective of service interface definitions. OSGA-DAI provides an implementation-specific service interface, which is more or less like the operation defined in the WS-Enumeration specification:
> 
> GetFully Operation
> Inputs: 
> The name of a session known to a data service resource. 
> The name of an open output stream known to the session. 
> The session name and stream name are expected to be conjoined with a colon (:). 
> Outputs: 
> Data - a string, a chunk of valid XML or a byte array. 
> 
> GetNBlocks Operation
> Inputs: 
> The name of a session known to a data service resource. 
> The name of an open output stream known to the session. 
> The session name and stream name are expected to be conjoined with a colon (:). 
> The number of blocks of data to be retrieved. 
> Outputs: 
> A block of data - a string, a chunk of valid XML or a byte array. 
> 
> Gilbert proposed the WS-Enumeration, and define a new operation for returning "wsen:EnumreationContext" type. That could be a solution. However, how to integrate the WS-Enumeration datatype and operations into RUS operations is another issue. 
> * import WS-Enumeration WSDL within the RUS WSDL?
> * define a new context data type for enumeration context within the RUS WSDL?
> 
> Respond by visiting:
> http://forge.gridforum.org/sf/go/artf5934
> 
> ---------------------------------------------------------------------
> Artifact details:-
> 
> Project: RUS-WG
> Tracker: Doc Change Request
> 
> Group: 
> Status: Open
> Category: 
> Customer: 
> Priority: 2
> Assigned To: No user
> Reported in release: none
> Fixed in release: none
> Estimated Hours: 0
> Actual Hours: 0
> 
> Description: As a pre-release changes according to public comments and OGF20. The following changes are intended to be made for version 1.9.
> 1. Abstract and Introduction are rephrased for generic expression instead of gMarket or MCS-RUS implementation specific. But gMarket will be put into the added section, "example usage scenarios", as a use case. Other use cases including usage policing and banking service that access URF through RUS.
> 
> 2. Configuration (Normative)
> there will be only mandatory usage record element while leaving access control to security section. The configuration is extended to support attribute based configuration as well aligned with URF extension frameowrk. Although this feature might undermine interoperability, it is worthwhile to allow URF extension propreties to be specified but with similar clarification as URF extension framework. However, restriction on value as what Rosario proposed will not considered in the specificaiton and leaves implementations to support this feature. Again RUS has close relationship with OGF URF and should support what feature URF would possibly provide. 
> 
> 3. Usage Record Representation will be full OGF-UR compatible.
> 
> 4. Fault Framework (Normative)
>     A complex Type used as a common data type for all RUS faults.
>     <xsd:complexType name="RUSFaultType">
>         <xsd:sequence>
>             <xsd:element name="errorCode" type="xsd:string" minOccurs="1" maxOccurs="1"/>
>              <xsd:element name="rusAction" type="xsd:string" minOccurs="0" maxOccurs="1" />
>              <xsd:element name="recordId" type="xsd:string" maxOccurs="1" minOccurs="0" />
>              <xsd:element name="description" type="xsd:string" minOccurs="0" maxOccurs="1" />
>         </xsd:sequence>
>        <xsd:complexType>
> The definition of this general fault type gives flexibility on both operations and fine-granularity usage record fault handling. 
> 
> Clarification on RUS faults and corresponding errorCodes:
> - RUSProcessingFault: RUS server-side internal processing error [errorCode: INTERNAL_PROCESSING_ERROR];
> -RUSDuplicateFault: trying to insert usage record(s) already exist(s) [errorCode: DUPLICATE_USAGE_RECORD]
> -RUSUserNotAuthorisedFault: user not authorised to pexecute rus operation (on particular usage record)[ErrorCode: USER_NOT_AUTHORISED]
> -RUSNotExistentFault:trying to process usage records not existent [ErrorCode: USAGE_RECORD_NOT_EXISTENT]
> -RUSTooComplexFault: try to process complex operation or huge amount of usage records that exceeds service's capacity [ErrorCode:TOO_COMPLEX_OPERATION]
> -RUSInputFault: trying to process operations with invalid input statement or invalid usage records [ErrorCode: INVALID_INPUT]
> 
> 5. Operation Result 
> There is no "recordIdList" element specified in version 1.7 based on following consideration:
> 1). RUSId not existent anymore;
> 2). Only error message will be returned to client;
> 3). the "recordIdList" element requires client to memorise recordId properties in sequence. However, it is impossible for client to known exact sequence when submitting a batch of usage records. 
> Accordingly the operation results should provide the overall operation result as well as error information.
> Therefore:
> <xsd:element name="operationResult">
>    <xsd:complexType>
>         <xsd:sequence>
>         <xsd:element name="totalProcessed" type="xsd:boolean" />
>         <xsd:element name="processed" type="xsd:unsigned-long">
>         <xsd:element ref="RUSDuplicateFault" minOccurs="0" maxOccurs="unbounded" />
>         <xsd:element ref="RUSUserNotAuthorisedFault" minOccurs="0" maxOccurs="unbounded" />
>         <xsd:element ref="RUSTooComplexFault" minOccurs="0" maxOccurs="unbounded" />
>         <xsd:element ref="RUSProcessingFault" minOccurs="0" maxOccurs="unbounded" />
>         <xsd:element ref="RUSInputFault" minOccurs="0" maxOccurs="unbounded" />
>         <xsd:element ref="RUSNotExistentFault" minOccurs="0" maxOccurs="unbounded" />
>        </xsd:sequence>
>     </xsd:complexType>
> </xsd:element>
> 
> 6. Service Interface Definition
> The SID defined in the specification allows batch processing by default. However, the implementation might restrict this capacity by throwing "RUSTooComplexFault". For example, an implementation would like to restrict inserting single usage record per transcation. When a client submitting multiple usage records as parameter to RUS insert service interface, then a RUSTooComplexFault will be thrown. 
> 
> There are two new service interfaces being defined:
> 1). RUS::ListUsageRecordHistory
>      This is the only operation that restrict the transaction on single usage record for querying record modification history.
>      Input: RecordId
>      Output: RecordHistory Element
>      Faults: RUSUserNotAuthorisedFault
>                 RUSProcessingFault
> 2). RUS::ListAssignedRoles
>      allows the user to obtain assigned roles relating to the user identity (i.e. userDN). The definition of this operation explicitly requires the implementation providing role-based access control mechanism.
>      INPUT:user id;
>      Output: a list of valid roles assigned to the user
>      Faults: RUSProcessingFault
> 
> 7. Security and Authorisation
>     Clarification on Role-baed access control (RBAC) and fine-granuarlity access control over usage records. 
> 
> As OGF-RUS roadmap, the document will be available soon (by the end of June). Please give some feedbacks on aforementioned points. 
> 
> 
> 
> 
> 
> 
>