У несчастью в линуксе многие комбинации ложатся на комбинации оконного менеджера, особенно, что касается Alt/Ctrl-Fn. В итоге приходится лезть в дебри настроек и менять Alt/Ctrl например на Win.
Видимо потому, что упирается вопрос что есть сознание, и в итоге приводит к идеям вроде солипсизма. Можно строго определить "стороннего наблюдателя" как квантовую или классическую систему, но с определением "наблюдателя-себя" будут проблемы даже в классической механие. Благо, что классика постулирует существование объективного мира, не зависящего от наблюдения.
Поэтому ни одна концепция не разрешает фундаментальные "парадоксы" вроде кота Шредингера, и КД на это тоже не предендует.
По большей части все эти концепции призваны понять где корректно проводить грань между классической и квантовой физикой. Однако как говорил тот же Зурек, проблема наблюдателя не имеет решения в физическом контексте и остается областью эзотерики и спекуляций.
Как профессиональный работник я не застал те времена, но слышал, что эффективность советской производительной системы была бездонным колодцем для юмористических фельетонов Хазанова, Райкина и Жванецкого.
Основная цель статьи больше показать способы синхронизации запросов, возможно просто пример с integrity constraint violation не самый подходящий
Проблема синхронизации к Spring-у вообще не имеет отношения. Если у вас под низом rdbms, то самое натуральное — это использовать ее средства синхронизации (напр. select for update). Даже если операция ничего не сохраняет в базу, но требует консистенции, проще будет создать таблицу mutex-ов и синхронизироваться по ней. Если же база распределенная и без acid, а запросы делаются асинхронно, то тут универсального решения нет — требуется адаптировать архитектуру под преследуемые цели, и в любом случае это будет сложнее и хуже.
А пардон, где написано, что ваш сервис singleton, чтобы синхронизироваться по this? Тогда уж поставьте syncronized(MyService.class). Не будет работать в кластере.
Решение 2
Менеджмент «протухания» clientId ложится в данном случае на плечи GС.
Вообще жесть! Зачем вы вводите людей в заблуждение? Где заявлено про "протухание" и GC? String.intern() складывает строки в constant pool, который лежит в permanent generation. И скоро вместо протухания вы получите снижение производительности и как финал OutOfMemory. all: никогда так не делайте и вообще забудьте про intern()!
Решение 3
Не работает в кластере.
Решение 4
Лочить по сети N нод для каждого getUserById() — ну, ну. Кроме того, привлекается какое-то левое решение.
Мне кажется попытки сделать универсальный комбайн всегда идут в ущерб специализации
Дело не столько в универсальном комбайне, а в желании вклиниться в чуждые экосистемы, где уже устаканились другие языки и технологии. Во фронтенде есть TypeScript, на системе есть C, Go, Rust, в JVM есть как бы Java. Котлин же везде создает ощущение некоего инородного тела, и всегда его интеграция с чуждой экосистемой всегда связана с накладными расходами, сложностями и ограничениями. Хорошо, что язык смог обосноваться в экосистеме Андройда, иначе бы без сопутстствующей технологии интерес к нему быстро бы угас.
На мой взгляд Котлину сильно не хватает своего собственного стека технологий, и я не разделяю точку зрения создателей о том, что Котлин должен двигаться в направлении интеграции с уже существующими. Как пример — Flutter, который вытащил полумертвый Dart.
Смысл Agile Manifesto это как небо голубое, вода течет, солце печет… — банальные, но вцелом правильные истины. Но затем за дело берутся изобретатели различных фреймворков и методологий, превращающих разработку продукта в детскую игру в классики.
Кстати, "большинство пипла" используют ORM, а они, как правило, используют оптимистичные блокировки. В таком случае уровня изоляции read-commited более чем достаточно.
Здесь стоит поставить звездочку * и дописать внизу:
под оптимистичными блокировками подразумеваются медленный и выставленный вручную OPTIMISTIC_WRITE а не дефолтный OPTIMISTIC_READ. В противном случае optimistic lock бесполезен и дублирует проверки БД.
ORM гарантирует целостность на уровне одной entity, но не коллекций и отношений.
общий гарантированный ORM уровень изоляции со всеми блокировками не превышает уровень изоляции БД.
Во-первых идемпотентностью обладают только транзакции с уровнем serializable, а он установлен далеко не везде. Большинство пипла по дефолту работают в read-commited и уверены, что все ОК. Особо продвинутые все-таки кое-где расставляют локи вручную типа SELECT FOR UPDATE, но зачастую забывают. Так работают чуть менее чем все системы.
Ну и во-вторых, транзакции практически несовместимы с новомодным асинхронным процессингом и всякими no-blocking архитектурами и практически всегда требуют старый добрый thread-per-request pattern. А это на сегодняшний день расточительство, не везде поддерживается и вообще не модно, не стильно и не молодежно. Тут уж приходится выбирать — шашечки или ехать.
Оттрогает подача материала в типичной коучерской манере: "как стать успешным", "как заработать миллион", "как перестать быть девственником" и т.д. Какие-то портреты культовых людей, которые что-то там изобрели или заявили...
Впринципе идеи автора понятны и приемлимы, если не акцентировать на экстремально столь интерактивном поведении системы разработки. В большинстве случаев чтобы увидеть результат достаточно просто сделать рефреш страницы или перезапустить программу — это не напрягает и реализовано практически везде. И понятно, что делать большую задачу лучше мелкими итерациями, где можно было бы сразу увидеть результат.
Важно отметить, что средства разработки должны быть соответствующими, т.е. компиляция и рестарт должны занимать минимальное время, и когда оно больше пары секунд — это заведомо плохо, т.к. усложняет разработку, мотивирует делать большие итерации, ухудшает тестирование и вообще плохо влияет на ментальное здоровье девелопера. Поэтому выбирайте правильные средства разработки.
*BPMN сначала практически никогда не нужен, но потом практически всегда нужен (если мы говорим про бизнес-процессы
Вот с этим готов не согласиться. Под видом BPM часто подсовывают BPMN, а это не одно и то же. Семантику бизнес процесса можно выразить кучей способов без BPMN. Самый простой — это конечный автомат, где все действия пронумерованы, а выполнение каждого из них возвращает номер следующего действия или nil. Как программа на бейсике. Более сложной является декларативная семантика rule engines, где процесс выводится автоматически на основе правил и зависимостей. Как я уже сказал, зачастую BPM используют там, где нужно асинхронное выполнение, но это неправильно, ибо для этого есть файберы, корутины, колбеки и куча других вещей.
А BPMN во многих ситуациях является пятым колесом: вроде как и стандарт, но сам по себе ничего делать не умеет, поэтому всегда требует интеграции с низлежащими технологиями, для которых он всегда будет инородным телом в проекте. Хорошо, когда нужна визуализация и полный контроль над процессами.
Код не версионируется, это нормально.
Не сказал бы что нормально. Ибо как ни крути, львиная доля логики всега лежит в java-based activities. Если меняется процесс, меняется и логика классов. А версионировать классы ручками — занятие неблагодарное.
Camunda действительно неплохое решение в сфре BPM, но далеко не единственное. Вопрос в том действительно ли вам необходим именно BPM, и покрывает ли его функционал ваши юзкейсы.
В самом начале, при выборе инструмента, мы искали решение со следующими возможностями:
Тут вообще подходит любой движок с персистенцией, от склепаного на коленках до Activiti.
Вот что действительно бывает релевантно при подборе технологии:
BPMN: а так ли он нужен? Например если у вас преобладают автоматические процессы, всю бизнес-логика завязана на работу с данными, а процессы достаточно ограниченны поэтому BPMN тут будет только мешать.
Лекговесность движка. Стоит ли устанавливать тяжелую полнофункциональную платформу, либо ограничится легким библиотекой-движком, интегрированным на вашу платформу? В некоторых случаях движками могут являться котлиновские корутины или джавовские файберы. В большинстве случаев хватает вообще обычной state machine.
Открытость и документированность формата персистенции. Иногда возникает острая необходимость поправить данные ручками прямо "по живому".
Пользовательский веб. Позволяет пользователю выполнять ручные задачи. Не сильно ведитесь. Возможности как правило сильно ограничены и неудобны. В большинстве придется интегрировать пользовательские задачи в корпоративный портал или более общую систему. Поэтому гораздо важнее наличие API, чем веб как таковой.
Админка. Практически бесполезная вещь. Есть база данных, есть API. Мониторинг будет обычно ведется сторонними средствами.
Версионирование. Вот здесь большинство съедает собаку. Заявленное версионирование процесса — это только версионирование схемки, но не артефактов и зависимостей. То есть все ваши Java-рутины, интерфейсы, меппинги и т.д. проверсионированы не будут и при деплое войдут в конфликт со старыми процессами. Надо смотреть, может ли система упаковывать все артефакты в отдельный бандл и обеспечить их co-living, а также оставить возможность сделать деплой поверх старой версии.
Под BPM-движком все-равно должна быть какая-то платформа для интеграции сервисов. Иногда совсем не подходит под задачу.
Development & delivery. Иногда предлагаемый цикл абсолютно не подходит под методологию работы, как в случае общего репозитория процессов, когда вы привыкли деплоить отдельные бинарники.
IBM BPM — мощная платформа, которая включает богатый набор возможностей
О даа, это для меня как красная тряпка для быка! Не могу удержаться от переполняющих меня негативных эмоций, когда вижу IBM BPM. Волею богов я был наказан разрабатывать энтерпрайзщину более 10 лет на этом откровенном дерьмище. И по большей части в Integration Developer. Богатых возможностей нам чуть более чем ноль — одни ограничения. То, что можно сделать элементарно, там делаеться сложно, а для реализации простого нужно было создавать свой велосипед. BPMN прикрутили сбоку только в восьмерке, до этого был только BPEL.
К тому же эта платформа имеет довольно низкий порог входа, что позволяет начинающим разработчикам практически сразу погружаться в проект.
Да ладно? А не пугает руководство по инсталляции на 250 страниц? А 7-часовой платный курс, где Раджеш Кутраппали объясняет основы? А когда запускаешь простую вещь, а тебе в ответ несколько экранов stack trace с com.ibm.*, на которые Google выдает 0 результатов? Мотивирует, особенно новичка.
Нет вменяемого контроля версий.
Более того, Integration Developer отказывается работать со стандартными плагинами VCS. Но я все-равно все кладу на SVN.
Разработка на Java 6. Возможно, на момент написания этой статьи уже можно разрабатывать на Java 7, но в 2019 году это слабое утешение.
8.5 уже на Java 7. Мы начинали с Java 4, и до сих пор большинство кодовой базы на ней. Проблема не в Java, а в наборе библиотек Websphere, версии которых заморожены еще с 00-х, и с тех пор имеют неисправленные баги (EMF например и SDO по части сериализации).
Некоторый GUI, где можно посмотреть, что вообще с процессом происходит.
Это не GUI, а поделка, склепанная студентом на коленках в начале нулевых. Когда у вас играет 6k+ процессов в день, увидеть там что-то вообще нет никакой возможности. Благо есть API, который позволяет делать свои вебы.
IBM BPM крутится на WebSphere, в итоге разработчикам надо запасаться терпением при каждом обновлении своего модуля
WS это вообще отдельная история. Похож на старый ламповый телевизор без корпуса и ручек управления. Все настройки сзади, прямо на печатных платах. Отдельным бонусом идет Business Process Choreographer, который не дает удалить приложение, если на нем запущены процессы. Или там мусорные артефакты и байндинги, остающиеся в конфигурации после редеплоя. Иногда после манипуляций Process Server вообще отказывался запускаться, на этот случай держали "чистую" копию директории и базы.
Разработка интеграционных модулей в среде Integration Designer, которая в действительности является затюненным не в лучшую сторону Eclipse.
А редактор BPEL сделан просто отвратительно, лейаут вообще не заточен под стандартные мониторы. Редактировать процесс в крохотном окошечке, снуя туда-сюда между пропертями и ящиками — удовольствие то еще. Судя по остальным продуктам IBM создается впечатление, что они вообще не думают разработчиках — им важны лишь те, кто читает проспектики и покупает. Разрабы для них — это корпоративные плагины к их системам, компиляторы с человечьего на вебсфировский.
Нет нормальной возможности Unit-тестирования.
Вы хотите сказать, нет автоматической возможности тестирования? В понимании IBM это не и нужно. Для юнит-тестирования нужна специально обученная обезьяна, которая будет вручную деплоить артефакты и прокликивать все тесты с данными по методичке. В любом случае это выйдет дешевле.
очень демотивируют команду
Вам повезло, у вас есть команда. Наша разбежалась, не успев еще проект встать на продакшн. Найти спеца по IBM BPM практически невозможно, а обучить других с "низким порогом вхождения" не имеет смысла — они сваливают при первой возможности, не успев еще ничего сделать.
Я еще могу бросать камни в эту софтину хоть до завтрашнего утра. Что до версии 8.5 оно каждые полгода "засиралось" так, что приходилось создавать новый инстанс, работающий параллельно со старым. После крэшев иногда по непонятной причине отваливался SCA-binding, процессы не видели друг друга, и это при том, что каждый имел до десятков тысяч живых инстансов. Внятного версионирования модулей вообще нет — приходилось создавать копии модулей и деплоить их, либо вообще делать полную копию всего воркбенча. Из "богатых возможностей" я бы отметил чуть больше, чем ничего: для всего приходилось делать велосипеды и подпорки, в итоге спасла только Java, куда было вынесено большинство логики. Работы с данными вообще никакая: объекты на основе xsd и SDO, отсутствует нормальный type-safe меппинг (xslt прикрутили только в семерке). Полностью пропиетарный и закрытый state: в базе ничего ручками не подправить. Под ковром для интеграции используется малопонятная Service Integration Bus, документации к которой чуть менее, чем никакой. И что официальные бандлы продуктов, скачанные со страниц IBM тупо не устанавливаются. Также доставляет установка патчей и внутренняя борьба Installation Manager с FixPack. Про саппорт даже ничего не хочу говорить.
Чуть менее года назад поступило предложение попробовать движок Camunda для описания бизнес-процессов.
У нас было проще. За 2 недели мы переписали полностью весь функционал на голой Java. Вместо BPM движка использовали persistent storage и сериализацию. Все это было предложено клиенту за минимальную плату. Но клиент оказался дебилом.
С таким же успехом можно использовать Map<Class, Supplier>. ServiceLoader служит для поиска имплементации сервиса в classpath. Кроме того, в Java 9 это также стандартный способ для связи между модулями. В сравнении с нормальным DI он не обеспечивает:
транзитивные зависимости
AOP и проксирование
выбор имплементации сервиса
Кроме того, он завязан на classpath, поэтому когда нужно будет создать тестовый контекст с моками, вы просто замучаетесь.
Те, кто непосредственно могут производить, проиводят. Те, кто не в состоянии производить, ищут другие способы и экологические ниши в процессе распределения ресурсов. Как правило это прямое или косвенное присвоение результатов чужого труда.
Все выше перечисленные должности всегда напрямую завязаны на разработчиков, и полностью зависят от результатов его труда, тогда как между собой они слабо связаны.
Деление на аналитиков, разработчиков, архитекторов, тестировщиков, менеджеров в последние два десятка лет позволило унифицировать процессы разработки программного обеспечения, обеспечить взаимозаменяемость персонала
Специализация живых огранизмов по способу питания на продуцентов, консументов 1 и 2 порядка и редуцентов позволило формировать сложные и более устойчивые экосистемы в условиях ограниченных ресурсов. Иерархическая система компании отражает именно процесс "питания" организмов, где питательным ресурсом являются результаты работы сотрудника. В больших коллективах специализация ведет к заполнению всех экологических ниш: от растений до хищников и паразитов, а также грибов и бактерий :)
Jetty+Guice стартует за полсекунды, причем эти полсекунды отъедает именно Guice. Но это голый контейнер. Попробуйте добавить Hibernate и время взлетит сразу до 10с.
У несчастью в линуксе многие комбинации ложатся на комбинации оконного менеджера, особенно, что касается Alt/Ctrl-Fn. В итоге приходится лезть в дебри настроек и менять Alt/Ctrl например на Win.
Видимо потому, что упирается вопрос что есть сознание, и в итоге приводит к идеям вроде солипсизма. Можно строго определить "стороннего наблюдателя" как квантовую или классическую систему, но с определением "наблюдателя-себя" будут проблемы даже в классической механие. Благо, что классика постулирует существование объективного мира, не зависящего от наблюдения.
Поэтому ни одна концепция не разрешает фундаментальные "парадоксы" вроде кота Шредингера, и КД на это тоже не предендует.
По большей части все эти концепции призваны понять где корректно проводить грань между классической и квантовой физикой. Однако как говорил тот же Зурек, проблема наблюдателя не имеет решения в физическом контексте и остается областью эзотерики и спекуляций.
Как профессиональный работник я не застал те времена, но слышал, что эффективность советской производительной системы была бездонным колодцем для юмористических фельетонов Хазанова, Райкина и Жванецкого.
Проблема синхронизации к Spring-у вообще не имеет отношения. Если у вас под низом rdbms, то самое натуральное — это использовать ее средства синхронизации (напр. select for update). Даже если операция ничего не сохраняет в базу, но требует консистенции, проще будет создать таблицу mutex-ов и синхронизироваться по ней. Если же база распределенная и без acid, а запросы делаются асинхронно, то тут универсального решения нет — требуется адаптировать архитектуру под преследуемые цели, и в любом случае это будет сложнее и хуже.
А пардон, где написано, что ваш сервис singleton, чтобы синхронизироваться по this? Тогда уж поставьте syncronized(MyService.class). Не будет работать в кластере.
Вообще жесть! Зачем вы вводите людей в заблуждение? Где заявлено про "протухание" и GC? String.intern() складывает строки в constant pool, который лежит в permanent generation. И скоро вместо протухания вы получите снижение производительности и как финал OutOfMemory.
all: никогда так не делайте и вообще забудьте про intern()!
Не работает в кластере.
Лочить по сети N нод для каждого getUserById() — ну, ну. Кроме того, привлекается какое-то левое решение.
Решение 0
Единственно правильное — использовать старый добрый механизм транзакций базы данных с повтором. Например так:
https://www.baeldung.com/spring-retry
Дело не столько в универсальном комбайне, а в желании вклиниться в чуждые экосистемы, где уже устаканились другие языки и технологии. Во фронтенде есть TypeScript, на системе есть C, Go, Rust, в JVM есть как бы Java. Котлин же везде создает ощущение некоего инородного тела, и всегда его интеграция с чуждой экосистемой всегда связана с накладными расходами, сложностями и ограничениями. Хорошо, что язык смог обосноваться в экосистеме Андройда, иначе бы без сопутстствующей технологии интерес к нему быстро бы угас.
На мой взгляд Котлину сильно не хватает своего собственного стека технологий, и я не разделяю точку зрения создателей о том, что Котлин должен двигаться в направлении интеграции с уже существующими. Как пример — Flutter, который вытащил полумертвый Dart.
Смысл Agile Manifesto это как небо голубое, вода течет, солце печет… — банальные, но вцелом правильные истины. Но затем за дело берутся изобретатели различных фреймворков и методологий, превращающих разработку продукта в детскую игру в классики.
Здесь стоит поставить звездочку * и дописать внизу:
Вас намеренно ввели в заблуждение!
Во-первых идемпотентностью обладают только транзакции с уровнем serializable, а он установлен далеко не везде. Большинство пипла по дефолту работают в read-commited и уверены, что все ОК. Особо продвинутые все-таки кое-где расставляют локи вручную типа SELECT FOR UPDATE, но зачастую забывают. Так работают чуть менее чем все системы.
Более того, даже serializable-уровень в понимании некоторых производителей внезапно не гарантирует целостности и полной изоляции, ибо по сути является snapshot, а не serializable. Так что блочить придется даже в serializable.
Ну и во-вторых, транзакции практически несовместимы с новомодным асинхронным процессингом и всякими no-blocking архитектурами и практически всегда требуют старый добрый thread-per-request pattern. А это на сегодняшний день расточительство, не везде поддерживается и вообще не модно, не стильно и не молодежно. Тут уж приходится выбирать — шашечки или ехать.
Обычно, применяют следующие методы борьбы с атакой:
...
Риторический вопрос: когда уже люди, которые не умеют производить, перестанут учить тех, кто производит, тому, как им нужно работать?
Lean вообще родился в цеховой индустрии и притянут за уши к IT, и не подходит ни по одному параметру.
Оттрогает подача материала в типичной коучерской манере: "как стать успешным", "как заработать миллион", "как перестать быть девственником" и т.д. Какие-то портреты культовых людей, которые что-то там изобрели или заявили...
Впринципе идеи автора понятны и приемлимы, если не акцентировать на экстремально столь интерактивном поведении системы разработки. В большинстве случаев чтобы увидеть результат достаточно просто сделать рефреш страницы или перезапустить программу — это не напрягает и реализовано практически везде. И понятно, что делать большую задачу лучше мелкими итерациями, где можно было бы сразу увидеть результат.
Важно отметить, что средства разработки должны быть соответствующими, т.е. компиляция и рестарт должны занимать минимальное время, и когда оно больше пары секунд — это заведомо плохо, т.к. усложняет разработку, мотивирует делать большие итерации, ухудшает тестирование и вообще плохо влияет на ментальное здоровье девелопера. Поэтому выбирайте правильные средства разработки.
Вот с этим готов не согласиться. Под видом BPM часто подсовывают BPMN, а это не одно и то же. Семантику бизнес процесса можно выразить кучей способов без BPMN. Самый простой — это конечный автомат, где все действия пронумерованы, а выполнение каждого из них возвращает номер следующего действия или nil. Как программа на бейсике. Более сложной является декларативная семантика rule engines, где процесс выводится автоматически на основе правил и зависимостей. Как я уже сказал, зачастую BPM используют там, где нужно асинхронное выполнение, но это неправильно, ибо для этого есть файберы, корутины, колбеки и куча других вещей.
А BPMN во многих ситуациях является пятым колесом: вроде как и стандарт, но сам по себе ничего делать не умеет, поэтому всегда требует интеграции с низлежащими технологиями, для которых он всегда будет инородным телом в проекте. Хорошо, когда нужна визуализация и полный контроль над процессами.
Не сказал бы что нормально. Ибо как ни крути, львиная доля логики всега лежит в java-based activities. Если меняется процесс, меняется и логика классов. А версионировать классы ручками — занятие неблагодарное.
Camunda действительно неплохое решение в сфре BPM, но далеко не единственное. Вопрос в том действительно ли вам необходим именно BPM, и покрывает ли его функционал ваши юзкейсы.
Тут вообще подходит любой движок с персистенцией, от склепаного на коленках до Activiti.
Вот что действительно бывает релевантно при подборе технологии:
О даа, это для меня как красная тряпка для быка! Не могу удержаться от переполняющих меня негативных эмоций, когда вижу IBM BPM. Волею богов я был наказан разрабатывать энтерпрайзщину более 10 лет на этом откровенном дерьмище. И по большей части в Integration Developer. Богатых возможностей нам чуть более чем ноль — одни ограничения. То, что можно сделать элементарно, там делаеться сложно, а для реализации простого нужно было создавать свой велосипед. BPMN прикрутили сбоку только в восьмерке, до этого был только BPEL.
Да ладно? А не пугает руководство по инсталляции на 250 страниц? А 7-часовой платный курс, где Раджеш Кутраппали объясняет основы? А когда запускаешь простую вещь, а тебе в ответ несколько экранов stack trace с com.ibm.*, на которые Google выдает 0 результатов? Мотивирует, особенно новичка.
Более того, Integration Developer отказывается работать со стандартными плагинами VCS. Но я все-равно все кладу на SVN.
8.5 уже на Java 7. Мы начинали с Java 4, и до сих пор большинство кодовой базы на ней. Проблема не в Java, а в наборе библиотек Websphere, версии которых заморожены еще с 00-х, и с тех пор имеют неисправленные баги (EMF например и SDO по части сериализации).
Это не GUI, а поделка, склепанная студентом на коленках в начале нулевых. Когда у вас играет 6k+ процессов в день, увидеть там что-то вообще нет никакой возможности. Благо есть API, который позволяет делать свои вебы.
WS это вообще отдельная история. Похож на старый ламповый телевизор без корпуса и ручек управления. Все настройки сзади, прямо на печатных платах. Отдельным бонусом идет Business Process Choreographer, который не дает удалить приложение, если на нем запущены процессы. Или там мусорные артефакты и байндинги, остающиеся в конфигурации после редеплоя. Иногда после манипуляций Process Server вообще отказывался запускаться, на этот случай держали "чистую" копию директории и базы.
А редактор BPEL сделан просто отвратительно, лейаут вообще не заточен под стандартные мониторы. Редактировать процесс в крохотном окошечке, снуя туда-сюда между пропертями и ящиками — удовольствие то еще. Судя по остальным продуктам IBM создается впечатление, что они вообще не думают разработчиках — им важны лишь те, кто читает проспектики и покупает. Разрабы для них — это корпоративные плагины к их системам, компиляторы с человечьего на вебсфировский.
Вы хотите сказать, нет автоматической возможности тестирования? В понимании IBM это не и нужно. Для юнит-тестирования нужна специально обученная обезьяна, которая будет вручную деплоить артефакты и прокликивать все тесты с данными по методичке. В любом случае это выйдет дешевле.
Вам повезло, у вас есть команда. Наша разбежалась, не успев еще проект встать на продакшн. Найти спеца по IBM BPM практически невозможно, а обучить других с "низким порогом вхождения" не имеет смысла — они сваливают при первой возможности, не успев еще ничего сделать.
Я еще могу бросать камни в эту софтину хоть до завтрашнего утра. Что до версии 8.5 оно каждые полгода "засиралось" так, что приходилось создавать новый инстанс, работающий параллельно со старым. После крэшев иногда по непонятной причине отваливался SCA-binding, процессы не видели друг друга, и это при том, что каждый имел до десятков тысяч живых инстансов. Внятного версионирования модулей вообще нет — приходилось создавать копии модулей и деплоить их, либо вообще делать полную копию всего воркбенча. Из "богатых возможностей" я бы отметил чуть больше, чем ничего: для всего приходилось делать велосипеды и подпорки, в итоге спасла только Java, куда было вынесено большинство логики. Работы с данными вообще никакая: объекты на основе xsd и SDO, отсутствует нормальный type-safe меппинг (xslt прикрутили только в семерке). Полностью пропиетарный и закрытый state: в базе ничего ручками не подправить. Под ковром для интеграции используется малопонятная Service Integration Bus, документации к которой чуть менее, чем никакой. И что официальные бандлы продуктов, скачанные со страниц IBM тупо не устанавливаются. Также доставляет установка патчей и внутренняя борьба Installation Manager с FixPack. Про саппорт даже ничего не хочу говорить.
У нас было проще. За 2 недели мы переписали полностью весь функционал на голой Java. Вместо BPM движка использовали persistent storage и сериализацию. Все это было предложено клиенту за минимальную плату. Но клиент оказался дебилом.
С таким же успехом можно использовать Map<Class, Supplier>. ServiceLoader служит для поиска имплементации сервиса в classpath. Кроме того, в Java 9 это также стандартный способ для связи между модулями. В сравнении с нормальным DI он не обеспечивает:
Кроме того, он завязан на classpath, поэтому когда нужно будет создать тестовый контекст с моками, вы просто замучаетесь.
Те, кто непосредственно могут производить, проиводят. Те, кто не в состоянии производить, ищут другие способы и экологические ниши в процессе распределения ресурсов. Как правило это прямое или косвенное присвоение результатов чужого труда.
Все выше перечисленные должности всегда напрямую завязаны на разработчиков, и полностью зависят от результатов его труда, тогда как между собой они слабо связаны.
Специализация живых огранизмов по способу питания на продуцентов, консументов 1 и 2 порядка и редуцентов позволило формировать сложные и более устойчивые экосистемы в условиях ограниченных ресурсов. Иерархическая система компании отражает именно процесс "питания" организмов, где питательным ресурсом являются результаты работы сотрудника. В больших коллективах специализация ведет к заполнению всех экологических ниш: от растений до хищников и паразитов, а также грибов и бактерий :)
Jetty+Guice стартует за полсекунды, причем эти полсекунды отъедает именно Guice. Но это голый контейнер. Попробуйте добавить Hibernate и время взлетит сразу до 10с.