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

[John Harby <jharby@gmail.com>]

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

This is false. If we had 100 threads going on about 100 terms this
would rapidly become unmanageable. Many people are frustrated trying
to keep up with this as it stands.


"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?"

It may very well make sense but it is a subclassing of service and
probably should be addressed once the parent has been defined and that
definition accepted.


On 5/26/05, Chiusano Joseph <chiusano_joseph@bah.com> wrote:
> 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
> > > > >
> > > >
> > >
> >
>