Have just created a feature request for Savara2 related to this: https://issues.jboss.org/browse/SAVARA-164
Currently Savara does not persist any activity information. The service validators simply publish 'service tracker' activity information to a JMS topic for access by the Eclipse based monitoring tool. This is used primarily for diagnostic purposes, to ensure the service implementations are correctly behaving according to a choreography description.
However in Savara 2 we will be looking to persist and analyse the activity information, and leverage process mining tools such as ProM.
One approach would be for the realtime activity information to be generated and distributed using a standard format, such as BPAF or XES.
However BPAF does not seem to be widely used (i.e. ProM does not support it) and XES is more of a log representation - not intended for reporting individual activity events published to interested subscribers in realtime.
So a format such as XES would be useful to import into process mining tools, but is not necessarily ideal for realtime use. So the jira is a feature request for exporting relevant activity information to the XES format.
Therefore the current thought is to have an internal activity model that is appropriate for Savara's needs, and then export to other formats as appropriate.
I am not very clear on the 'Component Activity' and 'Interaction Activity', as you stated on the design note, I was always thinking of Interaction Activity can be drieved from the component Activity, I know you've said sometimes the related component activity information can be hidden.
Can I see the 'Component Activity' as the 'process definition', and the 'interaction activity' as the 'process instance'? Maybe it is better that you can add example format for the component activity and interaction activity for the understanding?
For Savara, we mainly are interested in interactions - i.e. when messages are sent/received from different systems. So we need to monitor the communication mechanisms, such as an ESB or web services stack.
As an example, when monitoring the web service stack (which means any client/service - not just BPEL processes), we don't have any indication of what application client or component may be sending or receiving the information. So all we can report is the details of the message and the source/destination information. So this is the reason for the separate InteractionActivity event.
Components, such as RiftSaw, will be reporting their own activity information, which may or may not be useful for Savara to also analyse. However these activity events are related to a distinct component and in some cases instance id. This information can be recorded in the ComponentActivity type events.
However we can't just rely on deriving interaction information from certain component types (such as RiftSaw) as then we would miss out on interaction information associated with general web services etc.
So as a concrete example, we may have a jax-ws web service (A) deployed to the app server that calls a BPEL process (B) also deployed to the app server.
(A) receives a message from a web service client, which gets picked up by a handler and reported as an InteractionActivity (note there is no component info available, just the destination URL and optionally a service type). (A) then decides to invoke another web service (B) - which happens to be a BPEL process. The send from (A) and the receive at (B) are both registered as InteractionActivity events as they are detected by the jaxws handlers. When the message is received by (B), a BPEL process instance is started recording ComponentActivity events related to the process instance lifecycle. In terms of the ODE engine, these events are reported as variable assignments, not directly linked to the activity events that indicate a communication construct (e.g. receive/invoke/reply).
So hopefully this explains why there are different types of event - although I am open to discussion.
Main point is that we can't rely on process engines to provide all the activity information we need to derive the interactions, as in many cases the components that interact with are not processes.