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

[Farrukh Najmi <farrukh@wellfleetsoftware.com>]

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:ZNG@loc.gov] On
> Behalf Of Farrukh Najmi
> Sent: Sunday, November 25, 2007 3:05 PM
> To: ZNG@sun8.LOC.GOV
> 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