Koen, "koen.aers(a)jboss.com" wrote : I think that message flow and associations are typical constructs that are used by a business analist. I am not sure they are that important to the execution. | They are valuable modelling constructs. But we have to define wether they mean anything at runtime and if so, we have to create a logical story for those other link types. "koen.aers(a)jboss.com" wrote : Of course if message flows are added to the GPD at some point in time and the GPD is to operate on the same model as the runtime engine, it would make sense to add these capabilities to the core model. | The model used by the GPD is second to the real issue here. First we have to define if other link types make sense, second we have to get a crystal clear picture of what the other link types mean at design time and at runtime (if they have any runtime implications at all). Only after that story, we'll see if and how the GPD model is going to cope with this. "koen.aers(a)jboss.com" wrote : As for the question what a message flow would mean in jPDL, I think it could be used to somehow limit the visibility of the variables contained in this flow to all the nodes that are connected by the flow. If you have a document that has to be passed from one node to another and the analyst wants to model this graphically, the main thing is that the document is produced (entered) in one activity and consumed (available) in the other activity. I don't think that we should be considering to limit the visibility of all other variables in the process. The runtime impact of data-links then becomes quite thin. It only specifies that the data item is required input in the source activity... But the runtime is not why we would add this. We would add this for the business user to be able to create better models. Would you think that such a construct is usefull for business users ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982913#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...