Discussion points re UML and Execution Scenarios

[Matthew Moran <matthew.moran@deri.org>]

Hi,

During the last phone conference, several issues were raised for 
discussion in the context of the UML diagrams provided in the the 
execution scenarios document [1]. Here's a list of points that were raised:

(1) The UML diagrams reflect a concrete architecture rather than a 
reference architecture. SEE is motivated to provide a reference 
architecture so the data flow should not contain labels related to 
specific SWS ontologies (WSMO, WSML, WSMO4j) or to activities or actions 
that correspond to concrete architecture designs (e.g. parser and, to 
some extent the Communication Manager)

(2) The UML diagrams should be constructed in a modular way so that 
reusable, composable modules can be created. For example, one module for 
discovery, one module for service invocation etc.

(3) The activites should be represented as Goals. We agreed this before.

(4) Modelling the notion of a context identifier, as the mechanism for 
identifying a unique instance of a running execution scenario, is not 
necessary in the Activity diagrams. This should be left to the design of 
concrete architectures.

(5) Discovery (in WSMO) is now being considered in three phases - goal 
refinement, abstract service discovery and service discovery. How will 
this be reflected in the UML?

(6) Is it necessary to include the communication manager necessary?

(7) The dashed line used to highlight the part of the UML corresponding 
to the control and data flow of the execution scenario, has a specific 
semantics in UML activity diagrams and should be dropped.

(8) The need for an execution manager activity

(9) Loops are not represented e.g. there may be several service 
invocations in one goal-based execution

Agreements: (1), (2), (3), (5), (7), (9)

More discussion: (4), (6), (8), (9)


----------------------------------------------------------------
Discussion
----------------------------------------------------------------

(4) Modelling a Context Identifier

My concern is that we should include in the model support for 
asynchonous communication. I agree that the 'context' in the UML is a 
bad idea as it suggests a concrete implementation. Do we make sure that 
the conceptual model allows for the identification of conversations 
between service requesters and providers and include an activity that is 
responsible for channeling incoming messages, as part of asynchronous 
conversations, to the correct conversation?

(6) Communication Manager

I think we need to show something that receives messages from outside 
SEE and 'unpacks' them into events inside SEE. Equally, I think we need 
something that takes events from inside SEE and 'packs' them into 
messages that are sent out. This is really all the CommunicationManager 
activity is doing in the UML at the moment.

(8) Need for an Execution Manager

An activity to start execution scenarios and route incoming messages to 
correct 'conversations'?

[1] 
http://www.oasis-open.org//apps/org/workgroup/semantic-ex/download.php/22394/200702_SEE-Execution%20Scenarios-v08.doc 



Matt