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
