Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 38
Вообще iBatis создает такую кучу геморроя, что страшно делается. Я-то всегда был большим сторонником JPA именно из-за его простоты, но по сравнению с iBatis Hibernate — это как букварь по сравнению с учебником по Haskell…
Ну я и говорю, по сравнению с JPA Hibernate выглядит трудным. Но все-таки у него не приходится в иксэмэлях писать sql…
Ну, в Hibernate есть вполне удобный Criteria API и свой удобный HQL.
Блин.
А писать что-то в xml — как-то не кошерно помойму. Так что скорее правильно сказать, что меня пугает все вместе.
А еще я пишу в нетбинс и для JPA он умеет от базы автоматически генерировать все базовые сущности и все необходимые запросы…
А еще нынче появился Spring Roo, который делает разработку софта связанного с базами данных вообще легким и непринужденным, что на Hibernate, что на JPA
А писать что-то в xml — как-то не кошерно помойму. Так что скорее правильно сказать, что меня пугает все вместе.
А еще я пишу в нетбинс и для JPA он умеет от базы автоматически генерировать все базовые сущности и все необходимые запросы…
А еще нынче появился Spring Roo, который делает разработку софта связанного с базами данных вообще легким и непринужденным, что на Hibernate, что на JPA
В третьей версии iBatis-а, которая теперь MyBatis, поддерживаются аннотации. SQL теперь пишется в них.
«Каждая поганка в лесу к чему нибудь да предназначена» (с) Леший из «Домовенка Кузи». Есть задачи в которых iBatis может быть лучше Hibernate — это в перую очередь когда идет разработка над существующей базой, или когда разработка идет «от базы». Но мне не показалось что Activiti относится к таким случаям
А можете поподробнее рассказать (а еще лучше статью написать :))? Я, видимо, недостаточно знаком с темой…
Вам никогда не приходилсоь видеть изумленные глаза ораклистов типа «Нафига вам оракл если вы долбите его усредненными хибернетовскими запросами»? То есть, если разработка идет «от базы» — когда сначала разрабатывается база определенной структуры и вам важно какая это структура и какие запросы идут в базу, а java — это так — «тоненькая надстройка» просто что бы куда-то вывести данные — в этом случае тот контроль над SQL который дает iBatis — будет самое то. Потому как iBatis по сути дела это облагороженный JDBC (наверное JDBC как раз и должен быть как iBatis). Понятное дело, что и Hibernate можно оттьюнить что бы он слал именно те запросы что надо — просто в таком случае процесс может быть боле долгим и мучительным.
Так ведь в хибере можно не только Criteria API пользоваться, но и HQL! А при желании даже SQL, но зато каой удобной он делает работу с сущностями…
Можно, но то что делает Hibernate «по умолчанию» очень далеко от идеала с точки зрения «суровых ораклистов». Просто на HSQL вы не напишете действительно сложный запрос причем так как вам надо со всеми нюансами. А везде писать native sql query — так получится практически тот же iBatis
Причем select-ы — это одно. А представим кучу entity с кучей связей one-to-many, many-to-many, вот вы все это меняете, а потом говорите flush();
Какие SQL запросы пойдут в базу? Какие insert-ы и update-ы? Тут уже значительно меньше возможностей для tuning-а
Да и select-ы — надо же всегда следить, что бы при выводе на странице табличных данных для каждой строки не шли отдельные селекты для подсасывания связанных сущностей — то есть надо играться с fetch-ами и пр. Все это можно сделать — но все это требует времени.
Я сам предпочитаю использовать JPA или Hibernate, но просто хотел сказать что и iBatis имеет право на жизнь и есть случаи когда он может быть предпочтительней — и это в случаях когда вам надо четко контролировать как и где вы используете базу. Но опять-таки — по моему мнению Activiti к таким случаям не относится
Какие SQL запросы пойдут в базу? Какие insert-ы и update-ы? Тут уже значительно меньше возможностей для tuning-а
Да и select-ы — надо же всегда следить, что бы при выводе на странице табличных данных для каждой строки не шли отдельные селекты для подсасывания связанных сущностей — то есть надо играться с fetch-ами и пр. Все это можно сделать — но все это требует времени.
Я сам предпочитаю использовать JPA или Hibernate, но просто хотел сказать что и iBatis имеет право на жизнь и есть случаи когда он может быть предпочтительней — и это в случаях когда вам надо четко контролировать как и где вы используете базу. Но опять-таки — по моему мнению Activiti к таким случаям не относится
Ну, в его праве на жизнь я не сомневаюсь. Иначе он не развивался бы и им не пользовалось такое количество народу :)
Мне просто по роду деятельности приходится раотать с самыми разными базами — sqlite, Линтер. мускуль, постгри, оракл… Конечно, я не знаю тонкосстей оракла, все мои «расширенные» познание оракла ограничиваются синтаксическим сахаром для джойнов…
А насчет fetch — мне показалось, что jpa как-то весьма грамотно с ним работает, так что все лишнее начинает вытягиваться только когда нужно.
Мне просто по роду деятельности приходится раотать с самыми разными базами — sqlite, Линтер. мускуль, постгри, оракл… Конечно, я не знаю тонкосстей оракла, все мои «расширенные» познание оракла ограничиваются синтаксическим сахаром для джойнов…
А насчет fetch — мне показалось, что jpa как-то весьма грамотно с ним работает, так что все лишнее начинает вытягиваться только когда нужно.
Да вопрос не в том что бы лишнего не тащить — с этим как раз Lazy успешно справляется. А вот что бы максимум данных за один запрос вытянуть.
Например — надо вывести список из ста сущностей, у каждой есть связанная сущность, которая тоже участвует в выводе.
Если вы сделаете по умолчанию, то hibernate сгенерирует один запрос для селекта 100 сущностей, а потом еще 100 запросов для селекта 100 связанных сущностей. Получаем 101 sql запрос.
А можно было бы один SQL с join-ом обойтись. Вот теперь и объясняйте Hibernate что вам все сразу надо вытянуть. Это можно сделать — но просто так как в hibernate sql запрятан глубже — не всегда это очевидно
Например — надо вывести список из ста сущностей, у каждой есть связанная сущность, которая тоже участвует в выводе.
Если вы сделаете по умолчанию, то hibernate сгенерирует один запрос для селекта 100 сущностей, а потом еще 100 запросов для селекта 100 связанных сущностей. Получаем 101 sql запрос.
А можно было бы один SQL с join-ом обойтись. Вот теперь и объясняйте Hibernate что вам все сразу надо вытянуть. Это можно сделать — но просто так как в hibernate sql запрятан глубже — не всегда это очевидно
Вгляд?
Не могу ничего сказать про удобство разработки с iBatis и c Activity пока не знаком, но, после перехода на iBatis c Hibernate, Alfresco WCM стал работать не порядок быстрее. Мне тот релиз спас проект, т.к. были жуткие проблемы с производительностью.
Простите за темность, но что такое workflow framework и зачем он нужен. Даже родная википедия умалчивает. Если не сложно расскажите подробнее use case, можно отправить и к мануалам только со сылочками пожалуйста.
Что-то вроде этого, только надо абстрагироваться от BPEL и WebServices: habrahabr.ru/blogs/soabpm/47538/
Это слишком абстрактно, понять как это применять очень мне сложно. Из введения я уяснил что существует концепция бизнесс-процесса.
Помимо этого, как я понял, существует язык стандартизации сервисов (BEPL, BPM). Фактически сервис можно считать модулем выполняющим какую-то свою задачу, неким черным ящиком (например программа написаная на Java, которая фиксирует время прихода — ухода работника с работы), способ взаимодействия с которым как раз и описывается через стандартизирующий язык.
После того как мы имеем n-реализованных модулей, мы можем в более абстрактной среде, возможно визуальной, устанавливать взаимосвязи между этими модулями реализуя бизнесс процесс.
На примере расчета з/п: сервис определяющий кол-во часов потраченных на работу -> сервис определения ставки -> сервис определения премии -> сервис перевода денег на счет работника. Задача бухгалтера зайти на сайт и нажать кнопку выплаты зарплаты :)
Такое мое примитивное представление, и если это так, то в моей концепции workflow framework это способ стандартизировать взаимодействие сервисов. Т.е. это язык стандартизации и различные способы организации цепочки вызовов. Это так? А если это так, не понятно причем тут hibernate, spring и прочие, в моей концепции workflow framework как раз ничего о них не ведает, все возложено на сервисы.
Примеры бизнес-процессов: обработка входящего письма, обработка исходящего документа, ознакомление с документом, создание шестеренки, расчет заработной платы для сотрудника, оформление отпуска, оформление командировки и т.д.
Помимо этого, как я понял, существует язык стандартизации сервисов (BEPL, BPM). Фактически сервис можно считать модулем выполняющим какую-то свою задачу, неким черным ящиком (например программа написаная на Java, которая фиксирует время прихода — ухода работника с работы), способ взаимодействия с которым как раз и описывается через стандартизирующий язык.
После того как мы имеем n-реализованных модулей, мы можем в более абстрактной среде, возможно визуальной, устанавливать взаимосвязи между этими модулями реализуя бизнесс процесс.
На примере расчета з/п: сервис определяющий кол-во часов потраченных на работу -> сервис определения ставки -> сервис определения премии -> сервис перевода денег на счет работника. Задача бухгалтера зайти на сайт и нажать кнопку выплаты зарплаты :)
Такое мое примитивное представление, и если это так, то в моей концепции workflow framework это способ стандартизировать взаимодействие сервисов. Т.е. это язык стандартизации и различные способы организации цепочки вызовов. Это так? А если это так, не понятно причем тут hibernate, spring и прочие, в моей концепции workflow framework как раз ничего о них не ведает, все возложено на сервисы.
Ваше представление в целом верно.
Единственное, BEPL это не язык стандартизации сервисов, а стандартизированный язык описания взаимодействия между сервисами. По сути — один из путей реализации Workflow Framework.
В общем случае, workflow framework не обязан взаимодействовать именно с сервисами, он может взаимодействовать, например, со спринговыми бинами.
Конкретно с Activiti не работал, зачем там Hibernate не знаю. Возможно для хранения внутренних состояний описываемых в Activiti бизнес-процессов. Могу ошибаться.
Единственное, BEPL это не язык стандартизации сервисов, а стандартизированный язык описания взаимодействия между сервисами. По сути — один из путей реализации Workflow Framework.
В общем случае, workflow framework не обязан взаимодействовать именно с сервисами, он может взаимодействовать, например, со спринговыми бинами.
Конкретно с Activiti не работал, зачем там Hibernate не знаю. Возможно для хранения внутренних состояний описываемых в Activiti бизнес-процессов. Могу ошибаться.
Как например это использовалось в EmForge — предположим bug-tracking система. В каждом проекте ошибки обрабатываются по своему — в одном проекте ошибку вносит пользователь, потом тестер проверяет воспроизводится или нет, потом manager назначает на разработчика и на релиз в котором ошибка будет исправлена, потом разработчик исправляет, тестер тестирует, а релиз-инженер включает фикс в выпускаемый проудукт. А в другом проекте где нет и manager-а, ни тестера ни релиз-индеженера все баги вылются в одну кучу, разработчики берут баги из кучи, исправляют и закрывают.
Все это workflow — и если написать систему (как тот же EmForge) где администратор может описывать процесс под конкретный проект — то получаем гибкий bug-tracking адаптируемый под нужды и процессы проекта.
Все это workflow — и если написать систему (как тот же EmForge) где администратор может описывать процесс под конкретный проект — то получаем гибкий bug-tracking адаптируемый под нужды и процессы проекта.
Теоретически Workflow — это конечный автомат. Не более, не менее. Описывается набором своих состояний и действиями которая, которые нужно совершить при переходе от одного состояния к другому. Чаще всего представляется графически как ориентированный граф, где узлы — определенные действия (activity), а связи — условия переходов (transitions). Иногда используется обратная схема, где узлы — это устойчивые состояния, а связи — действия для перехода от одного состояния к другому. Можно обойтись вообще без графа, создав матрицу состояний. Можно использовать декларативный язык, что делают различные Rule Engines.
Технически Workflow Engine обеспечивает выполнение конечного автомата (процесса). Одно важное отличие от обычной программы это то, что workflow как правило ориентирован НА ДЛИТЕЛЬНОЕ выполнение БОЛЬШОГО числа процессов, когда основное время процесс находится в состоянии ожидания внешнего события. Для этого Workflow Engine умеет сохранять состояние процесса и восстанавливать при необходимости. Таким образом основа любого Workflow — это асинхронное выполнение.
Чаще всего Workflow используется для организации работы персонала в компании, а также его взаимодействия для решения типовой для компании задачи (бизнес процессы). Бизнес процесс — это своего рода конвейер. Для этого Workflow предоставляет интерфейс пользователя для решения типовой задачи (формочка), а также специфический тип узлов, называемый human task.
Для описания процессов были созданы стандарты BPEL, BPMN и другие. Для связи Workflow с другими системами в расово верных системах используют стандарты SOA и соответственно WebServices для описания интерфейсов. Основная идея, чтобы дяденька-бизнесаналист мог мышкой думать как у него будут работать люди, а индийский программист потом вместо фигаринья быдлокода, также мышкой подцеплял сервисы и делал меппинг данных. Реально же от такого «содрудничества» нанимают еще штат обезьян, чтобы на продакшне решали проблемы и ставили подпорки.
Технически Workflow Engine обеспечивает выполнение конечного автомата (процесса). Одно важное отличие от обычной программы это то, что workflow как правило ориентирован НА ДЛИТЕЛЬНОЕ выполнение БОЛЬШОГО числа процессов, когда основное время процесс находится в состоянии ожидания внешнего события. Для этого Workflow Engine умеет сохранять состояние процесса и восстанавливать при необходимости. Таким образом основа любого Workflow — это асинхронное выполнение.
Чаще всего Workflow используется для организации работы персонала в компании, а также его взаимодействия для решения типовой для компании задачи (бизнес процессы). Бизнес процесс — это своего рода конвейер. Для этого Workflow предоставляет интерфейс пользователя для решения типовой задачи (формочка), а также специфический тип узлов, называемый human task.
Для описания процессов были созданы стандарты BPEL, BPMN и другие. Для связи Workflow с другими системами в расово верных системах используют стандарты SOA и соответственно WebServices для описания интерфейсов. Основная идея, чтобы дяденька-бизнесаналист мог мышкой думать как у него будут работать люди, а индийский программист потом вместо фигаринья быдлокода, также мышкой подцеплял сервисы и делал меппинг данных. Реально же от такого «содрудничества» нанимают еще штат обезьян, чтобы на продакшне решали проблемы и ставили подпорки.
а сталкивался ли кто-нибудь в продакшене с droolsflow? чем он каридально отличается от jbpm4?
У меня вопрос — как у него с версионированием? Т.е. запущено N экземпляров бизнес-процесса, затем в бизнес-процесс вносятся изменения. Будут ли продолжаться выполняться уже запущенные экземпляры или нет?
так же как и в jBPM — то есть у одного process definition может быть несколько версий. Но каждый process instance привязан к конкретной версии process definition. В случае если деплоится новая версия — предыдущие process instance продолжают жить «по старому».
Насколько я знаю автоматически upgrade процесса на новую версию не разруливается — делается в «ручном режиме» — и если честно — не знаю что бы это поддерживал (intalio точно не поддерживает и советует делать процессы как можно короче по времени исполнения)
Насколько я знаю автоматически upgrade процесса на новую версию не разруливается — делается в «ручном режиме» — и если честно — не знаю что бы это поддерживал (intalio точно не поддерживает и советует делать процессы как можно короче по времени исполнения)
> Родная интеграция со Spring-ом
Прошу прощения, где это родная интеграция со спрингом в jBPM 4? По-моему на офсайте лежит ссылка на левый мануал от одного чувака, который смог прикрутить jbpm к спрингу, и то версии 2.5. Нормального бандла для 3.0 до сих пор не существует в природе (оно и понятно). В свое время это меня остановило.
jBPM убил jPDL и ужасный плагин для начертания процессов. Работать неудобно и отвратно. Нужно раньше было смотреть в сторону BPMN (BPEL изначально был мертворожденный), хотя бы тулзы сторонних разработчиков можно было бы использовать. Сам по себе движок JBPM неплохой, достаточно простой и расширяемый. Но в Activi есть все, что так не хватало — интергация со спрингом, BPMN 2.0 и неплохой дизайнер процессов.
Прошу прощения, где это родная интеграция со спрингом в jBPM 4? По-моему на офсайте лежит ссылка на левый мануал от одного чувака, который смог прикрутить jbpm к спрингу, и то версии 2.5. Нормального бандла для 3.0 до сих пор не существует в природе (оно и понятно). В свое время это меня остановило.
jBPM убил jPDL и ужасный плагин для начертания процессов. Работать неудобно и отвратно. Нужно раньше было смотреть в сторону BPMN (BPEL изначально был мертворожденный), хотя бы тулзы сторонних разработчиков можно было бы использовать. Сам по себе движок JBPM неплохой, достаточно простой и расширяемый. Но в Activi есть все, что так не хватало — интергация со спрингом, BPMN 2.0 и неплохой дизайнер процессов.
вы наверное путаете 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 напрямую)
В этом плане в 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 напрямую)
Да знаю я этот мануал от Andries Inzé. Есть куча способов засандалить движок jBPM в программу на спринге. Я говорю о Spring 3.0 dm — сервере. У меня на нем вся ESB построена (Apache Camel). Вобщем что до сих пор ищется, это: Opensource BPMN с визуальными средствами моделирования и OSGI-deployment.
Что мне было нужно, так это бандлить процессы в отдельные OSGI-модули, имеющие свой цикл жизни и поддерживающие нативно версионность. Для этого необходимо было иметь jBPM, запакованный в OSGI-модуль с API доступным на уровне OSGI-сервисов. Тем не менее, прототип был состряпан и даже вроде работал. Однако начальство сделало ошибочную ставну на Websphere.
Хорошо, что есть автоматические конвертеры BPMN в BPEL, а то в нашем проекте все делается вручную: аналисты используют Tibco Studio BPMN, а программисты переписывают BPEL на WebSphere. Однако схема конвертации BPMN в BPEL обладает одним существенным недостатком: зачастую администратор хочет видеть наглядно что произошло с его процессом и где он в данный момент находится. А машинно-сгенерированный BPEL будет сильно отличаться от модели процесса.
Что мне было нужно, так это бандлить процессы в отдельные OSGI-модули, имеющие свой цикл жизни и поддерживающие нативно версионность. Для этого необходимо было иметь jBPM, запакованный в OSGI-модуль с API доступным на уровне OSGI-сервисов. Тем не менее, прототип был состряпан и даже вроде работал. Однако начальство сделало ошибочную ставну на Websphere.
Хорошо, что есть автоматические конвертеры BPMN в BPEL, а то в нашем проекте все делается вручную: аналисты используют Tibco Studio BPMN, а программисты переписывают BPEL на WebSphere. Однако схема конвертации BPMN в BPEL обладает одним существенным недостатком: зачастую администратор хочет видеть наглядно что произошло с его процессом и где он в данный момент находится. А машинно-сгенерированный BPEL будет сильно отличаться от модели процесса.
>Надеюсь изложенная тут информация поможет вам в выборе workflow движка для >следующего проекта, хотя я сейчас, если честно, теряюсь какой же выбор правильный.
После проверки
www.mvnbrowser.com/artifacts-search.html?search=jbpm
лично для меня пока ответ очевиден. Поддержка Мавена для activiti никакая:
www.mvnbrowser.com/artifacts-search.html?search=activiti
Т.е. пока Баянс не освоил прогрессивных средств разработки можно о его светлом гении забыть, т.к. минимальный upgrade вылbется в огромную Ж с «поиском нужных JARs».
Для jbpm ребята уже Continuous Integration заточили, что (для меня) о многом в плане качества говорит.
PS
поразителная любовь к «неЛёгким путям»! 19 MB! Yet Another BlackBox.
После проверки
www.mvnbrowser.com/artifacts-search.html?search=jbpm
лично для меня пока ответ очевиден. Поддержка Мавена для activiti никакая:
www.mvnbrowser.com/artifacts-search.html?search=activiti
Т.е. пока Баянс не освоил прогрессивных средств разработки можно о его светлом гении забыть, т.к. минимальный upgrade вылbется в огромную Ж с «поиском нужных JARs».
Для jbpm ребята уже Continuous Integration заточили, что (для меня) о многом в плане качества говорит.
PS
поразителная любовь к «неЛёгким путям»! 19 MB! Yet Another BlackBox.
ан нет — таки мавен изначально запланирован. Беру свой наезд обратно.
надо копнуть поглубже. Спасибо за статью.
надо копнуть поглубже. Спасибо за статью.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Первый взгляд на Activiti