This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf3341?nav=1&selectedTab=comments at Sun, 06 Nov 2022 15:12:18 GMT SourceForge : artf3341: (98) Develop a mechanism for service data redirection

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Search Tracker
Project: OGSI-WG     Trackers > OGSI Post V1.x > View Artifact
Artifact artf3341 : (98) Develop a mechanism for service data redirection
Tracker: OGSI Post V1.x
Title: (98) Develop a mechanism for service data redirection
Description:
From the draft 1 mailing list:

From: Karl Czajkowski <karlcz@isi.edu>
Date: Thu Dec 12, 2002  20:08:35 Europe/London
To: ogsi-wg@gridforum.org
Subject: [ogsi-wg] find service data "links" in service data values?
Reply-To: ogsi-wg@gridforum.org

As I mentioned on the call yesterday, I think there would be value in
defining a simple link-like element to represent a remote
gsdl:FindServiceData query.  This element could appear in "partial"
service data values returned by a registry or indexing service to
signal to the client that it should issue another query for more
information, perhaps redirecting to another data source.  Any number
of such redirections could occur in one result, and redirected
results could also contain redirections.

I realize web technology already has some ways of doing this, simply
by including URIs or URLs (real links) in a result, but I would think
there is value in an OGSI-standardized expression of the remote query:

    <gsdl:findServiceDataRedirection>
        <gsdl:locator .../>
	<-- query expression -->
    </gsdl:findServiceDataRedirection>

This puts all responsibility for storing the redirection state in the
client, and is robust in terms of GSR renewal.  It is also great for
situations where you would want to direct a client to information to
which it might have priveleged access (while the index or registry
might not)---the client binds to the target service and is subject to
authorization based on its own identity.

At the same time, the client does not have to understand the query
expression, but only needs to envelope it properly to send to the
follow-up query.  The source sending the redirection element will be
doing potentially expression-language specific transformations as part
of its own query processing, e.g. path rewriting in an XQuery or XPATH
based expression.

A redirection-capable client SHOULD issue the encoded query and
"merge" the resulting service data values into the existing result,
e.g. construct the union of the new results and the containing service
data values sequence.  If the client does not understand the
redirection element, it COULD remove it and proceed with the partial
results from the initial response.

In general, I think the redirection processing would insert the
resulting <gsdl:serviceDataValues/> in place of the redirection, or
consider it an error if the enclosing type cannot hold a service data
values element at that point. But for the case where the enclosing
element is also a service data values element, I think we can define a
rewrite of:

    <gsdl:serviceDataValues>

       <gsdl:serviceData name=A/>

       <gsdl:serviceDataValues>

           <gsdl:serviceData name=B/>

       </gsdl:serviceDataValues>
    </gsdl:serviceDataValues>

to the collapsed set:

    <gsdl:serviceDataValues>

       <gsdl:serviceData name=A/>

       <gsdl:serviceData name=B/>

    </gsdl:serviceDataValues>

without loss of meaning.  There might be other reasonable rewrite
rules, but I do not think they need to be specified in OGSI unless
they affect the interpretation of results from specific operations in
the GS Spec.

I think this feature could be specified in a relatively contained way,
and I'd like to see it in the version 1 specification. Comments?


karl
 .
Submitted By: David Snelling
Submitted On: 05/28/2003 10:15 AM EST
Last Modified: 09/26/2005 3:53 AM EST
Closed: 09/26/2005 3:53 AM EST

Status / Comments Change Log Associations Attachments  
Status  
Group: * Service Data
Status:* Closed
Category: * Issue for Discussion
Customer: *
Priority: * 3
Assigned To: * David Snelling
Reported in Release: *
Fixed in Release: *
Estimated Hours: * 0
Actual Hours: * 0
issue_type: * normal
resolution: *
Comments
David Snelling: 09/26/2005 3:53 AM EST
  Comment:
Mass Update
  Action: Update
artifact_status changed from Open to Closed
close_date changed from - to 2005-09-26 09:53:30
David Snelling: 05/28/2003 10:15 AM EST
  Action: Create


 
 
 
< Previous
 
 
Next >
 


The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf3341?nav=1&selectedTab=comments at Sun, 06 Nov 2022 15:12:18 GMT