OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [soa-rm-ra] [take 2] can the process model of a service use actions other than in action model?

My intent was not to take a position on stateful vs. stateless services.  Per the RM, there is shared state and we don't say where that state is kept or if it is kept in one or several places.  So in my FixVehicle example, the shared state is the existence of and the information conveyed by the estimate.  The shop may have the estimate on a piece of paper and the state is shared when they call me on the phone.  The shop does not know whether I write the information down or keep it in my head.  They do not know my internal processes for deciding whether to go ahead with the work.  I apply my business logic (whether or not there is a SOA service involved, such as looking up the current value of the car to provide input to my business logic) and inform the shop of my decision.  In this, I see shared state but no the shop needing to maintain other state information.

BTW, we religiously avoid the REST vs. SOAP debate.  Our idea is the stuff we're putting together should work for either, with it being an design decision which and what combination is appropriate for a given implementation.

As for prescriptive or descriptive, there is somewhat of a fine line.  I see the Process Model as more descriptive in setting out temporal dependencies but the details of what must be done are with the Actions.


On Jun 4, 2008, at 5:16 AM, michael.poulin@uk.fid-intl.com wrote:

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

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]