[take 2] can the process model of a service use actions other than in action model?

[michael.poulin@uk.fid-intl.com]

please, find my comments in the text.

>OK, so now I'm ready to change my mind, at least a bit.  Here's the flow of logic (with an attempt to be agnostic to what exactly is an Action until Frank finishes his write-up):

>Process Model for a service consists of the temporal dependence among public Actions.  A service can have an internal process that includes other actions, including consuming others services through their public Actions.  If an Action with respect to a service is used only in the context of private actions by the service, it may be made public through its Action Model (for possible other use) but does not have to be.

M.P. Good stuff

>Process Model description includes:
- what public Actions are used
- how to access the logic for combining the Actions

M.P. This is a dangerous area. I will comment on it at the end of the message

 >Functionality: The set of business needs satisfied by some set of real world effects.  Functionality may be expressed through a textual description or through reference to any defined taxonomy of functions or similar vocabulary.

M.P. Accepted de-facto alredy

 >Invoking a service involves an initiating activity that kicks off a Process Model or the receiving service action if the process is merely using the single action.  [I agree with Michael that at this point I don't see the need for making single Actions into processes.]

 >An example of a service whose functionality requires consumer interaction with multiple Actions:  The business function of interest is FixVehicle.  The Process for getting a car fixed is to bring the car to the repair shop and leave a description of the problem.  (For the initiating step, the endpoint is the drop-off slot; the protocol is the car in the parking lot and the envelope with the problem description and the car key inside the envelope then dropped in the slot; the information model semantics and structure is the form on the envelope and the key in the envelope; the policy is a call with an estimate before work is started.)  This initiates action on the part of the shop.  The RWE from this action will be an estimate for the needed work.  Upon receiving the estimate, the customer must follow up by initiating action through the EstimateResponse action that initiates DoWork or NoWork private actions, where the latter two are not part of the public Action Model.  One RWE independent of the response is the car will be returned to the owner but whether a RWE is also the car is repaired depends on the payload to EstimateResponse.  Note: whether FixVehicle is accomplished through one service with multiple actions or multiple services each providing some subset of needed actions depends on design decisions.

M.P. Please, see my comments at the end of the message.

 >For a process with multiple actions, one must be identified as the initiating action.  The other are merely for information until the process get to the point where these are next up in the queue.

M.P. Please, see my comments at the end of the message.

>Functionality must point to its corresponding Process Model or, if only a single Action is involved, the Action that initiates the activity that leads to the RWE satisfying the Functionality.

Here is my comment on the Process Model described by Ken:

1. There is a strong tendency in the industry toward treating services as stateless providers. This does not prevent a service from keeping its own internal state but not the state which includes consumers state. However, aforementioned Process Model description may be understood as a stateful service because it includes consumer activities against public services Actions in a sequence. We can ask now: 'Who/what controls consumers activities to be used in proper order, at least?'

2.  I have no objections against stateful services but they are in minority. The Process Model, thus, addresses stateless services (majority) via a single-Action Process Model only. This seems as disproportional  too much efforts for just a few cases.

3. Aforementioned Process Model is good for description of INTERNAL organisation of the services that implement business process. In this case, a Mediator or Dispatcher entity orchestrates invocation of public services Actions in correct order. The outcome of such service is the RWE expected by the consumer while the consumer acts only once  against the the initiating action.

4. The Process Model may be described as a guideline to the consumers to explain them how to use public services Actions to gain RWE but the Process Model cannot be prescriptive in this case.

-	Michael