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 -----
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: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
--------------------------------------------------------------------- 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
|