Re: [search-ws] FW: OASIS/SRU: Operation Parameter

Ok, to ask the question more directly: 
 The philosophy you expressed would argue for including the operation 
parameter in SRW but not SRU. How do we reconcile this?

 

--Ray

 

 

  
----- Original Message ----- 

  
From: 
  Farrukh Najmi 

  
To: Ray Denenberg 

  
Cc:  
  

  
Sent: Sunday, November 25, 2007 5:44 
  PM

  
Subject: Re: [search-ws] FW: OASIS/SRU: 
  Operation Parameter

  

I am not sure I understand the distinction between SRW and 
  SRU. To me 
they are just SOAP and REST bindings to the same abstract 
  interface.
IMHO, We can build Search-WS with an ROA based abstract 
  interface and 
map it to  a REST interface and a SOAP 
  interface.

BTW it is much easier to map a ROA service to REST *and* 
  SOAP than to 
map a AOA service to REST.

Fortunately, I think 
  Search-WS fits ROA better than AOA so we can have 
both a REST and SOAP 
  interface. It would have been messier if AOA was a 
better fit for 
  Search-WS.

Ray Denenberg wrote:
>  
> Farrukh -- 
  thanks for posting this.  But the question it raises for me is
> 
  how do we reconcile SRW with SRU, if SRU is best modeled as ROA and 
  SRW
> (based on SOAP) is best modelled as AOA?
>
> 
  --Ray
>
> -----Original Message-----
> From: SRU (Search and 
  Retrieve Via URL) Implementors [mailto:] On
> Behalf Of 
  Farrukh Najmi
> Sent: Sunday, November 25, 2007 3:05 PM
> To: 
> Subject: Re: 
  OASIS/SRU: Operation Parameter
>
> (
> Resending after 
  fixing an important typo between ROA and AOA below Please
> ignore 
  previous version.
> )
>
> Rob Sanderson 
  wrote:
>   
>> On Wed, 2007-11-14 at 10:06 -0500, Ray 
  Denenberg, Library of Congress
>> wrote:
>>   
  
>>     
>>> There is a proposal to 
  eliminate the operation parameter, 
>>> incorporating it instead 
  in the base url, in some fashion. The reason 
>>> for the proposal 
  is that this parameter is not consistent with 
  REST
>>>       
> 
  principles.
>   
>>>     
  
>>>       
>>  
  
>>
>> REST is not the be all and end all of web 
  services.
>>
>> Practically speaking it makes it slightly 
  harder to implement as a 
>> single cgi script becomes out of the 
  question.  I don't see any 
>> practical 
  advantage.
>>
>> So, unless someone can explain why this is 
  a good idea without saying 
>> "because REST says 
  so"...
>>
>> -1
>>   
  
>>     
>
> Like most things this is 
  not a black and white issue and there are
> trade-offs that need to be 
  considered. Let me try and summarize briefly...
>
> Broadly 
  speaking, there are two architectural approaches to design 
  services:
>
> 1. Resource-Oriented services
> 2. 
  Activity-Oriented services
>
> In a Resource-oriented architecture 
  (ROA) the resources or data objects
> are the focus while the operations 
  or activities you perform on the
> resources remain fixed no matter what 
  type of resource one is dealing
> with. SQL is an example of a ROA where 
  the fixed interface is define by
> SELECT, INSERT, DELETE, UPDATE 
  operations. Another example is REST where
> the fixed operations are 
  defined by the GET, POST, PUT, DELETE
> operations of the HTTP 
  protocol.
>
> In an Activity-oriented architectures (AOA), the 
  focus is on the
> operations or activities you perform rather than the 
  resources that are
> the target of the operations or activities. SOAP is 
  an example of a AOA
> (sometimes referred to as Service Oriented 
  Architecture or SOA).
>
> The benefit of ROA is that the 
  architecture is completely unaffected as
> the information model / 
  resources are expanded to meet new requirements.
> No new operations are 
  required when new resource types are added. No
> interface changes are 
  needed. No protocol extensions are needed.
>
> The benefit of a 
  AOA is that it is better suited to modeling an activity
> such as a 
  banking transaction or medical activity such as a prescription
> 
  order.
>
> So which is better? It depends upon the requirements of 
  the application.
>
> If the application is focused more on 
  resources, resources are what keep
> growing unbounded and resources are 
  more relevant to clients, then ROA
> is a better fit. Examples of ROA in 
  practice are Amazon, del.icio.us,
> Flickr, Safari etc.
>
> 
  However, if the application is focused primarily on activities or
> 
  operations, activities grow more than resources and activities are 
  more
> significant than resources to the client, then AOA is a better 
  fit.
>
> IMHO, Search-WS fits in the first category where the 
  number of
> operations are fairly fixed, number of resources are 
  unbounded and it is
> resources and not operations that are more 
  significant to clients. Thus
> an ROA is a better fit for 
  Search-WS.
>
> In an ROA the center of the universe is the 
  resource and not the
> activity or operation. The basic tenet is that 
  operations are fixes and
> resources are unbounded. Modeling operations 
  in such an architecture is
> counter to ROA.
>
> This is the 
  basic argument why modeling *any* operation in *any* form
> (including 
  but not limited to operation parameter) in search-ws protocol
> is not 
  desirable, and that whenever possible, we should model resources
> or 
  algorithms and not operations within the search-ws protocol.
>
> 
  Of course, if one can make a convincing argument that Search-WS is an
> 
  activity-oriented service then the argument would be to model 
  operations
> in the protocol and not resources. Does anyone believe that 
  Search-WS is
> an is an activity-oriented service rather than a 
  resource-oriented service?
>
>   

-- 
  
Regards,
Farrukh Najmi

Web: http://www.wellfleetsoftware.com

---------------------------------------------------------------------
To 
  unsubscribe from this mail list, you must leave the OASIS TC that
generates 
  this mail.  You may a link to this group and all your TCs in 
  OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php