The activity information that needs to be captured for the conversation based actvity events needs to be indexed on two concepts:
(a) business context
This is termed 'business' context at the moment due to the fact that it refers to using business related information from the message contents of the messages involved in the conversation as the way to link them into a conversation instance - in BPEL terms, this represents the correlation set.
Note: possibly to make this mechanism more general purpose, this should not be called 'business' context - possibly just 'event context'? But for the purpose of discussion we will just call it 'business' context.
If we consider a BPEL process, it is possible that a business context may change through the life of a process - so a process may start by being identified by an Order Id (for example), and later be associated with a Supplier Id. The only thing that needs to occur is that at some point during the process, a message content must contain both the Order Id and the Supplier Id, as a means of linking the two ids with the same process id.
The same concept works with conversation instances - an initial id will be associated with the conversation, but not all messages associated with the conversation need to carry the same id, as long as at some point during the conversation instance the subsequent ids are defined in a message that also contains an id already associated with the conversation.
The main point is that the two or more id values, associated with the conversation instance, are unique - so the same id value cannot identify two different conversation instances.
The other way in which business contexts may be related is as parent and child conversation instances. For example, if a parent conversation is associated with an Order Id, then it may have child conversation instances associated with a composite 'business context' of Order Id:Supplier Id - so for the same Order Id, there may be multiple sub (or child) conversation instances that are associated with the order and a supplier id.
So from a db query perspective, we may want to select all of the activity events within a particular conversation instance keyed on a 'business' context. If the context is the parent context, then it should return all of the events for the parent and sub-conversations. If the query context is the child context, then possibly just return the activity events for the child?
(b) common properties
For example, if we have conversation instances associated with a trading choreography, we may want to be able to identify all of the conversation instances associated with a particular trader.
In this case, the activity events for the conversation would be pre-processed to extract relevant properties from the message content - the trader name in this case, and associated with each activity event.
So on storage in the database, it would be convenient if the property name and value could be used as an index into all of the conversation instances that have atleast one activity event with that property. So rather than being linked to the activity events, it would be nice if they could just be linked to the conversation instances in some way - but if not efficient, then references to the activity events would be next best solution, as long as the conversation instance could be derived from the activity event.
We need to examine the current activity event schema, against these requirements of being able to query based on business context or property name/value, and ensure the set of appropriate activity events (in the case of business context), or conversation ids (in the case of properties) are retrieved efficiently.
As mentioned in the previous para - possibly the best way would be to introduce the concept of a conversation id. So the 'business context' values reference a conversation id (so if more than one business context is associated with the same id), and the conversation id links to the set of activity events. Not sure yet how this would work with the sub-conversations.