[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Question about nomenclature (interaction model)
Frank, I've been studying how to describe any number of service interaction modes but we need to converge on specific participants before I can embark on the modeling process. If we simply use "service consumer" and "service provider" as abstractions for all consumer and provider entities (humans, organizations, software agents, hardware agents, etc.) then describing the interaction modes for various message exchange patterns (MEPs) is a piece of cake. This is the approach that seems to be commonly used in the industry publications. The obvious missing link here is "service" and often you'll see service and service provider used in the same context, depending on the perspective (business or architectural). Service consumer and service provider are obviously highly overloaded terms! It seems for this RA we want to do more than continue to overload the notion service consumer [/service requester] and service provider and that we'll want to differentiate human and organizational roles from the pieces of software and/or hardware that mechanize the functionality offered by services. We could choose to leverage the distinction you and your colleagues made in the WSA or not (e.g., Requester Entity, Provider Entity, Requester Human, Provider Human, Requester Agent, Provider Agent) with the simple interaction shown on Fig 1-1. Again, "service" is notably missing but is defined in the WSA as an abstract notion whereas the agents are concrete (allowing the swapping in an out of agents but providing the same service functionality). Obviously, these notions were created to help resolve some of the obvious ambiguity surrounding the overloaded terms of requestor [consumer] and provider. Perhaps we will want to use a different nomenclature to help resolve some of these ambiguities. Hopefully, we will be able to come to converge on the terminology soon and then I'll develop the interaction models. In the meantime, I'll focus on the information and behavior model elements of this architectural view (Interaction View) focusing primarily on the former with a fair treatment of metadata. If we choose to adopt to describe this RA in terms of architectural views (and I hope we do!), then I'd suggest that the Visibility and Real World Effect sections become part of the Interaction View. Comments from the rest of the RA team on this thread are welcome. For reference purposes, a copy of the W3C WSA is available on our Kavi site at the following URL: http://www.oasis-open.org/apps/org/workgroup/soa-rm-ra/download.php/17572/wsa.pdf Regards... - Jeff
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]