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.