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: [take 2] can the process model of a service use actions other than in action model?

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.

Process Model description includes:

- what public Actions are used

- how to access the logic for combining the Actions

 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.

 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.

 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.

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.


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]