[RUS-WG] tracker updates

[Xiaoyu Chen]

hello, Gilbert:
 
I cannot add comments there because of low authority as a normal member? That's way i start a new tracker! Could administrators updates my status and assign relatively high authority to add comment threads?
 
many thanks!
 
School of Engineering and Design
Mobile: Mobile: ++44(0)7871876894
X. Chen

________________________________

From: Gilbert Netzer [mailto:noname at pdc.kth.se]
Sent: Thu 7/5/2007 15:47
To: Xiaoyu Chen
Cc: Mailing List for RUS-WG
Subject: Re: [RUS-WG] tracker updates



Hi again,

some observations about the RUS query operation and WS-Enumeration, I also
add that to the tracker artf5887.

After having another quick look at the WS-Enumeration to refresh my memory,
I think the following things should be true:

The WS-Enumeration defines all the operations that are needed to get the
results out of a given enumeration (Pull,GetStatus) and to manage the
lifetime of the enumeration (Renew,Release,EnumerationEnd). These
operations are already defined, so we should have to redefine them.

The Enumerate method is optional and can be replaced by an equivalent
method that returns a Enumerate response message.

In the Enumerate response message, a <wsa:ReplyTo> element can be specified
which should then be used for any operations on that enumeration.

This gives two possibilities:

1 Use the same endpoint reference as the RUS.
In this case the implementor will have to also provide the WS-Enumeration
defined methods in the RUS service. However they should be in the wsen
namespace so the RUS spec should not be affected.

2 Use a different endpoint reference
Now the endpoint is different, so this should not affect RUS at all.

In any case we however need the Enumerate response from the WS-Enumeration
spec and I would think that we should import it from their schema and not
copy-paste it, if that is possible, to avoid inconsequences.

The interesting question would be if we could define a query method that
can either return the whole result (if it is small) in a response message
the we define or a Enumerate response message (if it is a large result set)
according to the WS-Enumerate specification. If that is possible I would
vote using only a single method, although it makes life harder for the
client because that needs to be able to handle the complexity.

If that is not possible, I would suggest to import (reference in the
specification) the Enumerate operation from the WS-Enumerate spec as it
seems to provide the features we would like (XPath as search/filter
expression).

But then again I am not sure if that works like I outlined above, I am not
that good with wsdls so please tell me if I am right or wrong about the
import things.

Best Regards
Gilbert

Xiaoyu Chen wrote:
> 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?
> 
> 
> School of Engineering and Design
> Mobile: Mobile: ++44(0)7871876894
> X. Chen
> --
>   rus-wg mailing list
>   rus-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/rus-wg