Again my apologies but I am not familiar with these 2 terms and their
distinction. I am guessing that SRW is a SOAP based search service while
SRU is a HTTP GET based Search service. If that is correct then IMHO
Search-WS should define its core interface with an HTTP GET (RESTful)
binding and then map the same binding to SOAP where a set of WSDL files
describe a uniform interface as defined by a small number of resource
independent operations (e.g. create, read, update, delete - actual names
may vary but you get the spirit of the idea). This is relatively
straight-forward and simple a spec task.
IOW, expressing a ROA based service in SOAP is just a stylized use of
SOAP that restricts the operations to a minimal resource independent
uniform interface.
BTW, going the other direction and expressing an AOA based service in a
REST interface is much messier as all operations will need to be modeled
as resources / algorithms.
Ray Denenberg, Library of Congress wrote:
> 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 <mailto:>
> *To:* Ray Denenberg <mailto:>
> *Cc:*
> <mailto:>
> *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: <mailto:>
> > 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
>
>
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
