dmitrygusevИ если честно, я не могу представить себе каким образом по одной ветке одновременно несколько токенов может проходить? Возможность такой конструкции (см. приложенный файл) - это один из моментов, который вроде бы действительно неясен из спецификации.
На мой взгляд, это скорее можно, чем нельзя. Впрочем, я не удивлюсь, если в более чем 300-страничной спецификации Вы найдете обоснование того, что это недопустимо.

dmitrygusevp.s. Видимо я зря привел пример с Java, с программированием этот номер здесь не прошел :) А зря... Вы привели слишком примитивный пример, попробуйте добавить параллельность. Ну хоть так: java-процесс запускается и разветвляется на два потока (thread), в которых выполняется один и тот же или разные методы. При этом у каждого свое завершение на своей строчке кода и в свой момент времени, но если не вызывать System.Exit(), процесс не закончится, пока не завершатся оба потока.

А насчет End Event продолжение следует...

fedotxxlВопрос по XOR объединяющему гетвею. Если у меня есть несколько параллельных потоков, то каким образом я могу дождаться одного, запустить следущую актвиность без опаски, что мои оставшиеся параллельные активности доберутся до запущенной. Я думал, что XOR объединяющий гетвей это делает - ждет одного токена и блокирует остальные. Но судя по всемя я ошибался... авторAn exclusive merge gateway is actually redundant, since if the sequence
flows into the gateway represent exclusive alternative paths, the uncontrolled flow (without
the gateway) means the same thing, and if the sequence flows in are not exclusive
alternatives, the exclusive gateway is illegal.
Этот вопрос тоже не решается спецификацией BPMN, остается уповать на здравый смысл и более опытных коллег. Цитату Вы привели из Брюса?

Вот здесь есть обзор wf-паттернов, с точки зрения реализуемости в BPMN:
On the Suitability of BPMN for Business Process Modelling . Ваша ситуация называется "WCP9 Дисриминатор". И реализация ее с помощью XOR-слияния не предлагается.

fedotxxlИ ещё вопросик - что будет, если у меня есть задача, в неё приходит токен, задача запускается. Варианты:
1. Задача успевает исполниться, а потом в неё приходит другой токен
2. Задача не успевает исполниться и в неё приходит другой токен
Из того, что токен уже "пришел" (сначала первый, потом второй), я заключаю, что вопрос "дискриминации" решен в пользу ее отсутствия, и токены входят в задачу независимо. А значит и исполняться задача будет для каждого токена совершенно независимо. И вообще, исполняться будет не задача , а экземпляр задачи , собственный для каждого токена.
BPMN1.0,стр.67Note – If the Task has multiple incoming Sequence Flow, then this is considered uncontrolled flow. This means that when a Token arrives from one of the Paths, the Task will be instantiated. It will not wait for the arrival of Tokens from the other paths. If another Token arrives from the same path or another path, then a separate instance of the Task will be created.

АБ VlP2008а какие задачи Вы имеете в виду? Если рисовать BPMN-модели, чтобы обсуждать, утверждать и вешать на стену, то скорее всего BPMN вообще не нужен, есть и более простые "нотации". А если задача заключается в разработке графической модели исполняемого процесса, тогда Вы ну никак не обойдетесь без "нюансов". Я имел в виду разработку модели исполняемого процесса. А замечание мое сводится к тому, что среди нюансов, без которых не обойтись в практической деятельности, будет больше нюансов реализации конкретной BPMS, чем нюансов стандарта BPMN. Но ведь "нюансы реализации конкретной BPMS" можно вынести на диаграмму разве что в виде комментариев. А если все нюансы скрывать, то легко дойти до диаграммы из единственной активности "Выполнить процесс". Полагаю, что это противоречит основной цели БПМН: BPMN1.0,стр.1The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation.
Все бизнес-аспекты должны быть отражены на диаграмме, а нюансы реализации конкретной BPMS - нет. Параллельность (асинхронность) выполнения каких-то задач - аспект, вполне понятный с точки зрения бизнеса. Возможность завершения одной из параллельных задач - тоже. Если в том же процессе еще не выполнена другая параллельная задача, понятно, что процесс еще не заканчивается. Однако, и ситуация, когда при определенных условиях нужно прервать все незаконченные задачи процесса и завершить его принудительно - тоже вполне реальна.

dmitrygusev VlP2008Вы привели слишком примитивный пример, попробуйте добавить параллельность. Ну хоть так: java-процесс запускается и разветвляется на два потока (thread), в которых выполняется один и тот же или разные методы. При этом у каждого свое завершение на своей строчке кода и в свой момент времени, но если не вызывать System.Exit(), процесс не закончится, пока не завершатся оба потока.
Ну это просто, например...
Ну так если закомментировать вызов System.exit(0), каждый поток закончится абсолютно самостоятельно (у каждого потока свой "конец"), но процесс завершится только после того, как закончатся оба, а точнее, все трое - родитель и два дочерних потока.

Кстати, кроме None End Event и Terminate есть еще куча других End Event, которые также как none происходят по каждому входящему токену, но не посто молчат, а еще и, например, передают сообщение, генерируют ошибку, требуют компенсации и т.п. Вопрос: когда на одной из параллельных веток End Event требует отправить сообщение, а на другой - None End Event, но она еще не закончилась, будет сообщение отправлено сразу по завершению 1-й ветки или оно будет отложено до завершения процесса? Я думаю, будет отправлено сразу. Но процесс еще не закончился. А когда закончится 2-я ветка, завершится процесс и управление наконец перейдет к родителю - процессу или системе.

Аналогия с данным java-примером такая: два дочерних потока вместе составляют процесс с двумя параллельными ветками. Родитель ждет, пока закончатся оба (t1.join();t2.join();), но каждый из двух парллельных потоков "процесса" завершается самостоятельно и по времени и по смыслу (действию).

АБ VlP2008Но ведь "нюансы реализации конкретной BPMS" можно вынести на диаграмму разве что в виде комментариев. А если все нюансы скрывать, то легко дойти до диаграммы из единственной активности "Выполнить процесс". Полагаю, что это противоречит основной цели БПМН: BPMN1.0,стр.1The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation.
Все бизнес-аспекты должны быть отражены на диаграмме, а нюансы реализации конкретной BPMS - нет. Параллельность (асинхронность) выполнения каких-то задач - аспект, вполне понятный с точки зрения бизнеса. Возможность завершения одной из параллельных задач - тоже. Если в том же процессе еще не выполнена другая параллельная задача, понятно, что процесс еще не заканчивается. Однако, и ситуация, когда при определенных условиях нужно прервать все незаконченные задачи процесса и завершить его принудительно - тоже вполне реальна. Извините, я Вас не понимаю. Мы говорим о процессе, который будет рисоваться или исполняться? Если второе, то вы будете рисовать его в конкретной BPMS, и пользоваться при этом не абстрактно-стандартным BPMN, а тем, что называется BPMN в данной конкретной системе. Т.е. диалектом, в котором будут свои собственные нестандартные расширения, ограничения и нюансы. Практически все производители говорят, что поддерживают BPMN, но вы бы видели тот "BPMN"!

Никакого противоречия целям BPMN тут нет - пусть это будет диалект, не на 100% стандартный, но он вполне может быть общим языком для людей бизнеса, аналитиков и айтишников. Избежать "нюансов конкретной BPMS" можно только если вы собираетесь только рисовать. Но это не BPM, по определению.
Только рисование меня не интересует. Я хочу исполнять нарисованное. Но и рисовать и исполнять хотелось бы как можно ближе к стндарту. По крайней мере, при наличии отступлений от стандарта они должны быть зафиксированы с указанием оснований. Без понимания самого стандарта это невозможно. К сожалению, он сам допускает разное понимание/толкование по многим моментам. Но по вопросам, описанным однозначно, изменения допустимы только в пределах, указанных в самом стандарте - на той же 1-й и еще 2-й страницах спецификции. Там однозначно указно, что ДОЛЖНО соблюдаться, если объявляется соответствие стандарту, а что можно расширять по своему усмотрению. Исходя из этого, вопрос топика никак нельзя отнести к области расширений, а значит и к реализации конкретной BPMS. Но неясные аспекты по этому вопросу в стандарте есть. Поэтому правильнее сначала хотя бы попытаться уточнить смысл стандарта по конкретному вопросу, и только потом отдавать его на откуп конкретной реализации.

АБ VlP2008рисовать и исполнять хотелось бы как можно ближе к стндарту Боюсь, это идеализм. При выборе BPMS приходится учитывать множество факторов, и точность следования стандартам среди них конечно присутствует, но врядли вес этого фактора превысит в итоге 5%. Главными факторами обычно являются цена, платформа, присутствие вендора. (Форрестер периодически выпускает таблички сравнения, с весами, баллами, комментариями к этим баллам и итоговыми суммами.) Да, это в точку, идеализм я за собой замечал. Но влияние точности следования стандарту на продажи, по-моему, реально еще меньше, чем 5%. Может как-то еще влияет сам факт соответствия (или заявление производителя о нем), но степень соответствия - 60% или 80% - вряд ли. Кто из покупателей "найдет 6 или 8 отличий" от 300-страничной спецификации?
Лично я продажами не занимаюсь, мое дело - сделать продукт лучше не только с точки зрения продаваемости. Мы (это я от имени своей компании) со своими заказчиками строим многолетние отношения, которые обычно с продажи только начинаются. А дальше приходится и внедрять, и учить, и дорабатывать и т.п. Объем доработок собственными силами хотелось бы минимизировать, переложив на заказчика как можно большую часть изменений бизнес-логики, но это возможно, только если будет достигнут оптимальный компромисс между простотой использования инструмента, с одной стороны, и богатством его возможностей - с другой. Достижение этого компромисса - сложная задача, в одиночку посильная только для гения. Но решить ее коллективными усилиями надежда есть. И если коллектив опытных специалистов уже много лет над этим работал, что выразилось в публикации стандарта, то почему же нам не воспользоваться результатами?

АБТак что когда начнете заниматься чем-то реальным, а не академическим, придется Вам разбираться уже в основном не со стандартом, а с диалектом. А мы уже давно начали. Правда конкретными объемами продаж пока похвастаться не могу, мы только выпускаем на рынок 1-ю версию продукта (workflow-подсистему в рамках давно существующей СЭД).