RE: [soa-rm] [issue:07-23 and 07-24] Tighten definitions of "data resource" and "processing resource"

["Chiusano Joseph" <chiusano_joseph@bah.com>]

Forgetting temporarily about noise and confusion (which can be overcome
by logic): 

Does it make sense for us to make such a distinction? What it be
valuable for our specification? Is it too concrete for an RM?

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 9:13 AM
> To: SOA-RM
> Subject: Re: [soa-rm] [issue:07-23 and 07-24] Tighten 
> definitions of "data resource" and "processing resource"
> 
> There is definitely terminology that is more commonly 
> accepted such as "service" as opposed to "data service". I 
> think some of this discussion becomes very noisy and 
> confusing if too many terms are being introduced at once. 
> It's alot easier to take it one step at a time.
> 
> On 5/26/05, Chiusano Joseph <chiusano_joseph@bah.com> 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
> > > >
> > >
> >
>