Мне кажется основной плюс Amazon-она в почасовой оплате. Вряд ли вам надо будет крутить такой инстанс постоянно, а вот запустить его на день — что бы по быстрому провести как-то расчет — пожалуйста — и стоить будет не так дорого
вы наверное путаете jBPM3 (который интегрировался со Spring-ом через spring-modules) и jBPM4 — у него все хорошо (уверяю вас как человек эту интеграцию использовавший).
В этом плане в Activiti ничего нового нет.
BPEL изначально создан для оркестрации веб-сервисов — там в принципе отсуствует понятие «user task» — что делает его неприменимум для реализации workflow (как вы выше сказали workflow чаще всего используется для «организации работы персонала в компании»). Плюс BPEL слишком технический — с трудом представляю себе бизнес аналитика описывающего бизнес-процесс на BPEL. То есть — по сути это язык выполнения — своего рода ассемблер.
BPMN — это уже язык более высокого уровня — он не исключает bpel — например тот же Intalio использует BPMN для моделирования (кстати — их моделер — построеный тоже на базе Eclipse на порядки лучше того что было в jBPM, что есть сейчас в Activiti — и им еще расти и расти!) и транслирует его в BPEL для выполнения в Apache ODE. да — остается проблема — а как же пользователи (которых нет в BPEL) — для этого приходится извращаться и добавлять BPEL4PEOPLE
Я это к чему — что BPMN и BPEL все таки немного разные вещи и один другого не убивает — один это язык моделирования, другой — выполнения (хотя некоторые как jBPM и Activiti выполняют BPMN напрямую)
В Intalio (базируется на Apache ODE) экземпляры старых версий продолжат работать — но как описано в старой версии процесса (новая версия будет использовать только для новых экземпляров)
так же как и в jBPM — то есть у одного process definition может быть несколько версий. Но каждый process instance привязан к конкретной версии process definition. В случае если деплоится новая версия — предыдущие process instance продолжают жить «по старому».
Насколько я знаю автоматически upgrade процесса на новую версию не разруливается — делается в «ручном режиме» — и если честно — не знаю что бы это поддерживал (intalio точно не поддерживает и советует делать процессы как можно короче по времени исполнения)
Как например это использовалось в EmForge — предположим bug-tracking система. В каждом проекте ошибки обрабатываются по своему — в одном проекте ошибку вносит пользователь, потом тестер проверяет воспроизводится или нет, потом manager назначает на разработчика и на релиз в котором ошибка будет исправлена, потом разработчик исправляет, тестер тестирует, а релиз-инженер включает фикс в выпускаемый проудукт. А в другом проекте где нет и manager-а, ни тестера ни релиз-индеженера все баги вылются в одну кучу, разработчики берут баги из кучи, исправляют и закрывают.
Все это workflow — и если написать систему (как тот же EmForge) где администратор может описывать процесс под конкретный проект — то получаем гибкий bug-tracking адаптируемый под нужды и процессы проекта.
Да вопрос не в том что бы лишнего не тащить — с этим как раз Lazy успешно справляется. А вот что бы максимум данных за один запрос вытянуть.
Например — надо вывести список из ста сущностей, у каждой есть связанная сущность, которая тоже участвует в выводе.
Если вы сделаете по умолчанию, то hibernate сгенерирует один запрос для селекта 100 сущностей, а потом еще 100 запросов для селекта 100 связанных сущностей. Получаем 101 sql запрос.
А можно было бы один SQL с join-ом обойтись. Вот теперь и объясняйте Hibernate что вам все сразу надо вытянуть. Это можно сделать — но просто так как в hibernate sql запрятан глубже — не всегда это очевидно
Причем select-ы — это одно. А представим кучу entity с кучей связей one-to-many, many-to-many, вот вы все это меняете, а потом говорите flush();
Какие SQL запросы пойдут в базу? Какие insert-ы и update-ы? Тут уже значительно меньше возможностей для tuning-а
Да и select-ы — надо же всегда следить, что бы при выводе на странице табличных данных для каждой строки не шли отдельные селекты для подсасывания связанных сущностей — то есть надо играться с fetch-ами и пр. Все это можно сделать — но все это требует времени.
Я сам предпочитаю использовать JPA или Hibernate, но просто хотел сказать что и iBatis имеет право на жизнь и есть случаи когда он может быть предпочтительней — и это в случаях когда вам надо четко контролировать как и где вы используете базу. Но опять-таки — по моему мнению Activiti к таким случаям не относится
Можно, но то что делает Hibernate «по умолчанию» очень далеко от идеала с точки зрения «суровых ораклистов». Просто на HSQL вы не напишете действительно сложный запрос причем так как вам надо со всеми нюансами. А везде писать native sql query — так получится практически тот же iBatis
Вам никогда не приходилсоь видеть изумленные глаза ораклистов типа «Нафига вам оракл если вы долбите его усредненными хибернетовскими запросами»? То есть, если разработка идет «от базы» — когда сначала разрабатывается база определенной структуры и вам важно какая это структура и какие запросы идут в базу, а java — это так — «тоненькая надстройка» просто что бы куда-то вывести данные — в этом случае тот контроль над SQL который дает iBatis — будет самое то. Потому как iBatis по сути дела это облагороженный JDBC (наверное JDBC как раз и должен быть как iBatis). Понятное дело, что и Hibernate можно оттьюнить что бы он слал именно те запросы что надо — просто в таком случае процесс может быть боле долгим и мучительным.
«Каждая поганка в лесу к чему нибудь да предназначена» (с) Леший из «Домовенка Кузи». Есть задачи в которых iBatis может быть лучше Hibernate — это в перую очередь когда идет разработка над существующей базой, или когда разработка идет «от базы». Но мне не показалось что Activiti относится к таким случаям
Что-то я не помню русифицированного newton-а. Если не ошибаюсь — Парагон сделал вообще все распознование текста на ньютоне, а там оно работало огого как — мне кажется до сих пор интерфейс ньютона при работе с рукописным текстом никто не смог переплюнуть
У меня ни под OpenSolaris, ни под Ubuntu, ни под FireFox, ни под Chrome (хром только в Ubuntu — под солярку его нету) Видео никогда не было (и сейчас нет) — хотя анонс про поддержку видео видел давно.
Может поэтому и группового чата не видел?
«не очевидно как вернуть груп-чат после закрытия окна» — ну для длительных чатов правильней использовать Wave — как мне кажется
А так — поболтали и закрыли. Если что надо — в истории чатов это осталось
чаще всего такая задача решается копи-пастом с предыдущего проекта и подгонкой под текущий. Практически у каждого я думаю есть набор болванок «веб-проект на спринге», «веб-проект на jsf & ejb» — и прочее.
roo генерит такую-же болванку — но да — достаточно навороченную — одни аспекты чего стоят
Как у любой другой конструктор, Roo хорош для «стандартных» задач, но с его помощью не получиться сгенерить приложение решающее что-то нестандартное.
Хотя — в результате работы Roo — вы получаете вполне стандартный проект основанный на maven — и дальше его можно «пилить» руками без использования Roo
Пощупать — к сожалению сейчас никуда не могу выложить — но — с точки зрения «конечного пользователя» — там щупать особо и нечего — простейший CRUD — все-таки данный пример больше инетересен с точки зрения изучения кода, который получился при генерации.
В этом плане в Activiti ничего нового нет.
BPEL изначально создан для оркестрации веб-сервисов — там в принципе отсуствует понятие «user task» — что делает его неприменимум для реализации workflow (как вы выше сказали workflow чаще всего используется для «организации работы персонала в компании»). Плюс BPEL слишком технический — с трудом представляю себе бизнес аналитика описывающего бизнес-процесс на BPEL. То есть — по сути это язык выполнения — своего рода ассемблер.
BPMN — это уже язык более высокого уровня — он не исключает bpel — например тот же Intalio использует BPMN для моделирования (кстати — их моделер — построеный тоже на базе Eclipse на порядки лучше того что было в jBPM, что есть сейчас в Activiti — и им еще расти и расти!) и транслирует его в BPEL для выполнения в Apache ODE. да — остается проблема — а как же пользователи (которых нет в BPEL) — для этого приходится извращаться и добавлять BPEL4PEOPLE
Я это к чему — что BPMN и BPEL все таки немного разные вещи и один другого не убивает — один это язык моделирования, другой — выполнения (хотя некоторые как jBPM и Activiti выполняют BPMN напрямую)
Насколько я знаю автоматически upgrade процесса на новую версию не разруливается — делается в «ручном режиме» — и если честно — не знаю что бы это поддерживал (intalio точно не поддерживает и советует делать процессы как можно короче по времени исполнения)
Все это workflow — и если написать систему (как тот же EmForge) где администратор может описывать процесс под конкретный проект — то получаем гибкий bug-tracking адаптируемый под нужды и процессы проекта.
Например — надо вывести список из ста сущностей, у каждой есть связанная сущность, которая тоже участвует в выводе.
Если вы сделаете по умолчанию, то hibernate сгенерирует один запрос для селекта 100 сущностей, а потом еще 100 запросов для селекта 100 связанных сущностей. Получаем 101 sql запрос.
А можно было бы один SQL с join-ом обойтись. Вот теперь и объясняйте Hibernate что вам все сразу надо вытянуть. Это можно сделать — но просто так как в hibernate sql запрятан глубже — не всегда это очевидно
Какие SQL запросы пойдут в базу? Какие insert-ы и update-ы? Тут уже значительно меньше возможностей для tuning-а
Да и select-ы — надо же всегда следить, что бы при выводе на странице табличных данных для каждой строки не шли отдельные селекты для подсасывания связанных сущностей — то есть надо играться с fetch-ами и пр. Все это можно сделать — но все это требует времени.
Я сам предпочитаю использовать JPA или Hibernate, но просто хотел сказать что и iBatis имеет право на жизнь и есть случаи когда он может быть предпочтительней — и это в случаях когда вам надо четко контролировать как и где вы используете базу. Но опять-таки — по моему мнению Activiti к таким случаям не относится
Может поэтому и группового чата не видел?
А так — поболтали и закрыли. Если что надо — в истории чатов это осталось
roo генерит такую-же болванку — но да — достаточно навороченную — одни аспекты чего стоят
Хотя — в результате работы Roo — вы получаете вполне стандартный проект основанный на maven — и дальше его можно «пилить» руками без использования Roo
Пощупать — к сожалению сейчас никуда не могу выложить — но — с точки зрения «конечного пользователя» — там щупать особо и нечего — простейший CRUD — все-таки данный пример больше инетересен с точки зрения изучения кода, который получился при генерации.