[ogsa-wg] RE: Modeling State: Technical Questions

[Steve Loughran]

I have this theory, it's #2 of my "silly but possibly valid theories":-

	Any technology other than an RDBMS that implements a SELECT statement 
is inherently over-complex

I would cite SLPv2 and that EJB query language [1] as two examples to 
back up my claim, with UDDI lurking nearby. I also note that it is badly 
escaped SQL select statements that are a primary attack point into 
custom HTTP apps, and even more often, custom SOAP endpoints [2]. There 
is something about the "let's do a SELECT" operation that gets people 
excited, but you soon end up with something that is hard to implement, 
test and interop test against, or you have to hand it off to a real DB 
underneath. Yes, bits of XPath fall in to this category too.

If we are going to have select statements, at least be rigorous about 
requiring quotes around strings, for security reasons:

“where (jobid = 'urn:guid:364') or (jobid = 'urn:guid:401')”


-steve

[1] http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBQL5.html
[2] http://ws.apache.org/axis/java/security.html

Paul Watson wrote:
> 
> 
> Ian,
> 
>  
> 
> I agree that this is good progress. So let’s bank that and see if we can 
> we can agree on one more thing, and then I’ll ask a question.
> 
>  
> 
> Considering your list of abilities (a, b & c) below, do we agree that in 
> terms of expressiveness, the ordering is:
> 
>  
> 
> c>b>a
> 
>  
> 
> i.e. using approach c, a client can request operations on:
> 
>   a) single jobs: “where (jobid = urn:guid:364)”
> 
>   b) sets of jobs: “where (jobid = urn:guid:364) or (jobid = urn:guid:401)”
> 
>  
> 
> If there is agreement on this, then we could move on to discussing why 
> it is felt necessary to provide more than just c for the job submission 
> service.
> 
>  
> 
> Regards
> 
> Paul
> 
>  
> 
> Ian wrote…
> 
>>Savas:
> 
>>   
> 
>>It seems that we are in agreement, then, that we want the ability to:
> 
>>   
> 
>>a) Request operations on individual jobs identified by some sort of "jobid"
> 
>>   
> 
>>b) Request operations on sets of jobs identified by a user-supplied list 
> of "jobids"
> 
>>   
> 
>>c) Request operations on sets of jobs identified by more abstract criteria
> 
>>   
> 
>>We also agree that (as I expressed in the email that started this 
> discussion) such >requests can be expressed in a few different ways, 
> with somewhat different >characteristics.
> 
>>   
> 
>>That's progress I hope.
> 
>>   
> 
>>Ian.
> 
>  
> 
> * From: * Ian Foster [mailto:foster at mcs.anl.gov]
> *Sent:* 05 April 2005 17:59
> *To:* Savas Parastatidis; Steve Loughran
> *Cc:* Mark McKeown; Karl Czajkowski; Dennis Gannon; Samuel Meder; 
> ogsa-wg; dave.pearson at oracle.com; gray at microsoft.com; 
> humphrey at cs.virginia.edu; grimshaw at virginia.edu; aherbert at microsoft.com; 
> gcf at indiana.edu ; mark.linesch at hp.com; Frank Siebenlist; Tony Hey; Dave 
> Berry; Paul Watson
> *Subject:* RE: [ogsa-wg] RE: Modeling State : Technical Questions
> 
>  
> 
> [I'm feeling increasingly bad about sending email to all of the people 
> CCed here, who may not be interested in these issues at all but got 
> addressed by Tony long ago...]
> 
> Savas:
> 
> It seems that we are in agreement, then, that we want the ability to:
> 
> a) Request operations on individual jobs identified by some sort of "jobid"
> 
> b) Request operations on sets of jobs identified by a user-supplied list 
> of "jobids"
> 
> c) Request operations on sets of jobs identified by more abstract criteria