OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: FW: OASIS/SRU: Operation Parameter


 
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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]