[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]