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: The many faces of Action


To Checkpoint 1: I agree assuming that message exchange includes ALL Participants and  ALL messages of the Interaction, i.e. consumer, provider and all sub-providers (services that are engaged by the first service, or services engaged by a service-process), if necessary

Checkpoint 2: I am not on board with you on this point.
I do not see how Process Model is saying the service has to receive a first message before it is prepared to receive the second message gets concluded from the Process Model characterizes the temporal relationships and temporal properties of actions and events associated with interacting with the service
TEMPORAL relationships and properties are here because they relate to concrete interaction with the service; next interaction may have its own relationships and properties for the same Action (e.g. different message XML Schema or namespace may be used in the message to the same service interface operation). 
I do not like when a service dictates me any dependencies between messages. If my test detects such dependency, I report it as a bug. Properly designed service must handle concurrent requests to all of its public operations. Otherwise, we are talking about coupling consumer with services and about stateful services (neither SOAP not REST camps will support this)
Nevertheless, I accept an Initiating Activity notion because any service operation invocation results in an initial activity (for engaged service operation) regardless from invocations of other service operations (Activities)

Checkpoint 3: it is clear to me and I agree with conclusions

Checkpoint 4: I agree with Ken on Action vs. message. I think this a reasonable interpretation.

To the Q1:
I do not think we need a common parent class for Action and Joint Action. I do not see a confusion here: Joint Action includes an Action as service expected activity, i.e. service interface operation in a jargon,   and an Actions against service performed by the consumer. Simple and clear.

- Michael


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