[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] [issue:07-23 and 07-24] Tighten definitions of "data resource" and "processing resource"
Joe, Thanks for the suggested wording. It provides a bit more clarity and I also agree with some later comments about some of the details needing more tweaking. However, I point out that the distinction was not introduced as a fundamental definition of service but (1) as a definition of resources as something distinct from services (and I refer you to Frank's discussion of resources and in particular the distinction between name, link (not sure that term is right), and representation) and (2) in the discussion of metadata as part of an illustration of how what is exposed as metadata in the service description depends on the resource it accesses, its consumer, and the context of its use. I believe that a fundamental part of our description of SOA is that many capabilities must deal on the fly with varied descriptions. It is not enough to sweep it under the rug to say it makes our life easier if we all agree ahead of time so we'll ignore the real need. BTW, recall I initially sent the wrong version of the section 2.1 write-up to Matt and that was included in draft 07. I sent the corrected version to Matt on 23 May (it became issue 2) and it was distributed to the list. If you have questions on that section, please see the real version because some dangling pieces included as a parking lot for ideas were never meant to see the light of day. Ken On May 26, 2005, at 8:54 AM, Chiusano Joseph wrote: > Agreed - but we should also note case in which there is no commonly > accepted terminology (or perhaps no terminology at all). I see part of > our effort as creating terminology where it makes sense, and also > adopting existing terminology where it makes sense. > > Joe > > Joseph Chiusano > Booz Allen Hamilton > Visit us online@ http://www.boozallen.com > > >> -----Original Message----- >> From: John Harby [mailto:jharby@gmail.com] >> Sent: Thursday, May 26, 2005 8:15 AM >> To: SOA-RM >> Subject: Re: [soa-rm] [issue:07-23 and 07-24] Tighten >> definitions of "data resource" and "processing resource" >> >> IMHO, it would be a mistake to introduce additional >> terminology and classifications while we are still working on >> those which are commonly accepted. >> >> On 5/26/05, Peter F Brown <peter@justbrown.net> wrote: >>> Joe: >>> >>> 1. I agree that the terminology needs tightening up, and I'll be >>> proposing specific terminology revisions as issues later this week, >>> taking on board your and others comments. I'm really >> grateful for your >>> extensive comments that highlight many of the inevitable >> inconsistencies. >>> 2. Your clarifications on these issues would be compatible >> with both >>> definitions of a service that I intend to submit as issues >> to the list >>> later this week [1] ...but... >>> 3. I'm a little nervous about the idea of introducing >> "-oriented" as a >>> descriptor, as in "data-oriented service" and "process-oriented >>> service" If a "data-oriented service" is only providing data read >>> functionality why does that make it more data-oriented than a >>> "process-oriented service" that may commit/update/delete >> data? I think >>> the issues of data and process are orthogonal. >>> I'd be happier talking about data objects and process >> objects that are >>> invoked and used by services. >>> 4. On a more fundamental level, I'm not sure that the whole >>> distinction data/process is useful as implying two "families" of >>> service: both of the scenarios are services, one that reads and >>> manipulates data from a data resource; the other which might >>> ultimately commit/update/delete data. But surely these are >> just policy >>> issues regarding how the service can invoke and use the >> resource (the data) in the context of a particular contract? >>> 5. I do not agree, within your text on a data-oriented >> service, that >>> "it should be noted that such processing does not consitute a >>> process-oriented service" Why not? If the service >> transparency is such >>> that such processing can be seen by the service requestor, >> it may be >>> that at some future stage, that this specific processing be >> invoked as >>> part of another orchestrated service. It is not the >> distinction data >>> or process oriented that is useful, but the distinction based on >>> resource use that I find useful, and that I think is a policy issue. >>> >>> -Peter >>> >>> [1] Service >>> >>> a) A behavior or set of behaviors [PFB1] offered by one entity for >>> use by another according to a policy and in line with a service >>> description.b) The use by one entity of a resource made >> accessible by >>> another entity [PFB2] ________________________________ >>> >>> >>> >>> [PFB1]"Bahviour" not defined >>> >>> >>> [PFB2]Alternative definition >>> ________________________________ >>> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] >>> Sent: 15 May 2005 18:14 >>> To: SOA-RM >>> Subject: [soa-rm] [issue:content] draft 07, sect2.1.3.1, line 338, >>> Tighten definitions of "data resource" and "processing resource" >>> >>> >>> >>> >>> <current> >>> >>> I don't believe that the definitions presented beginning >> with line 338 >>> accurately capture the distinct differences between data-oriented >>> services (using terminology suggested in earlier issue) and >>> process-oriented services. For example, line 338 states that a data >>> resource (data-oriented >>> service) "accepts a request and returns a value or set of values in >>> response". A processing resource (process-oriented service) >> does the >>> same - it accepts a request to execute a task/process (a >> process being >>> comprised of multiple tasks), and - more often than not - returns a >>> value or set of values in response. For example, consider a >> process in >>> which a manufacturer orders several widgets from a supplier - the >>> supplier will accept a request from the manufacturer, and then >>> eventually send a response that will either confirm that >> the order has >>> been placed, or that the inventory is not available at that time. >>> >>> </current> >>> >>> >>> >>> <suggested> >>> >>> Recommend considering these definitions: >>> >>> >>> >>> A data-oriented service is a service whose sole function is >> to provide >>> a set of data upon request, given certain criteria that are >> passed as >>> part of the request. The primary processing that a data-oriented >>> service performs is to locate the set of data requested, >> and to either >>> return that data or convey that the data could not be found or >>> accessed. Therefore, the extent of processing for a data-oriented >>> service is minimal compared to other types of services.A >> data-oriented >>> service may perform processing necessary to produce the requested >>> data, such as calculations. In doing so, it may invoke one or more >>> process-oriented services, or perform such processing itself (it >>> should be noted that such processing does not consitute a >>> process-oriented service). Invocation of a data-oriented service, >>> unlike other types of services, never results in a change >> in the state >>> of the environment within the reach of the service. That is, >>> invocation of a data-oriented service will not result in a >> decrease in >>> inventory in a factory, a transfer of money from a bank to >> a business, >>> etc. An example of a data-oriented service would be a >> stock quote service that accepts a ticker symbol and returns >> a stock quote. >>> >>> >>> >>> A process-oriented service is a service that performs a task or a >>> process upon request that may results in a change in the >> state of the >>> environment within the reach of the service. For example, >> invocation >>> of a process-oriented service may result in a decrease in >> inventory in >>> a factory, a transfer of money from a bank to a business, or a >>> notification of subscribed parties of a certain message. In >> order to >>> carry out its request, a process-oriented service may invoke one or >>> more other process-oriented services, and/or a >> data-oriented service >>> (for example, to invoke the data-oriented service to >> perform a calculation). >>> >>> </suggested> >>> >>> >>> >>> <notes> >>> >>> I know that there is sometimes a fine line between these 2 types of >>> services >>> - I endeavored to differentiate them as clearly as possible. >>> >>> </notes> >>> >>> >>> Kind Regards, >>> Joseph Chiusano >>> Booz Allen Hamilton >>> Visit us online@ http://www.boozallen.com >>> >> >> ------------------------------------------------------------------------ ------------------ Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]