[issue:07-23 and 07-24] Tighten definitions of "data resource" and "proc

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.

[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

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>

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>

Visit us online@ http://www.boozallen.com

soa-rm message