Привет! Вот пока не придумал как бы их именно удобно реализовать, а не просто по стандарту. То что видел, вроде у trisotech, было не юзабельным. Но мысль. Меня не покидает, одежды доберёмся до этих вопросов)

@@BPMN2ru , я бы делал частную реализацию как на 212 странице Cтандарта (там где начинается описание DataInput). И делать обязательными источник и потребителя этих DataObject. Единственная сложность -- это навороченный механизм маппинга, описанных в DataAssociation. В своей версии я его упрощу и унифицирую с механизмом маппинга свойств. Думаю и для вас это будет подходящим стартом. Основное преимущество DataObject перед Property, что он также имеет время жизни области действия (scope), но его видно на диаграмме и не нужно лазить по атрибутам объектов. С точки зрения реализации, на первый взгляд, они не сложнее свойств, также будут нужны маппинги между ними и входными/выходными значениями активностей. А дальше уже процедура маппинга либо успешно свяжет, либо срубится с ошибкой по недостаточности данных.

@@BPMN2ru , на сон грядущий пришла мысль в голову, что все наследники ItemAwareElements (DataObject, Property, DataInput, DataOutput) имеют через своего предка ссылку на ItemDefinition, который собственно и хранит данные. Получается, что в случае, если они будут ссылаться на один и тот же ItemDefinition, обмен данными между ними будет проистходить мгновенно. Единственное, что должно приниматься в учет -- это DataState используемого ItemAwareElemnt. А DataState должен контролироваться объектом, который в теме про область видимости (scope) -- какой-то ScopeController. Если все организовать таким образом, то приходим к унификации и простоте маппинга передаваемых между узлами процесса (ввод/вывод), данными процесса (объекты данных) и свойствами узлов процесса и самого процесса.

Так уже есть, camunda и не java языки видос называется

@@BPMN2ruспасибо, пошел смотреть