Моя работа связана с приложением разчитывающим логистику по заказам. Технически — это работа программиста бизнес логики. Использование нузкоуровневых языков типа С++, VB и т.п. не особенно эффективно, так как обычно новые бизнес модели содержат достаточно много однородной логики. Логично выглядит стремление к использованию CASE средств, позволяющих облегчить и ускорить процесс внесения изменений и дополнений в бизнесс логику. А скорость как известно — деньги.
Вот и моё руководство задумалось над использованием визуальных редакторов и CASE систем. Одному из моих коллег поставили задачу по определению наиболее подходящего инструмента. Он как истинный програмер выделил 3 пункта в своем исследовании:
1. домашнее решение
2. BizTalk
3. WebMethods
Последние два исследовались по причине наличия лецензии и сильного желания руководства использовать что то из них. Не буду вдаваться в подробности, т.к. в конце как обычно было принято политическое решение. Будем использовать WebMethods.
На этого монстра было потрачено много времени и сил нашей и пары соседних комманд по переводу старого кода на «новые рельсы». К сожалению, эру CASE встретили мы с WebMethods 6.xx и был он невероятно глючный и не стабильный, тяжелый и недоделанный. Следующие версии тоже не принесли желаемого облегчения. Я закончил знакомство с этим решением где-то на 7-мой версии.
Плюсы можно наити в рекламе на их сайте. Я приведу лишь недостатки WebMethods, с которыми мы жили 2-3 года:
— Установка продукта и кастомного кода (поддерживать все новые и новые среды просто мучение), так как нет централизованного хранилища кода.
— Доскуп к документации аля Оракл через спецальный сайт с платным аккаунтом.
— Проблемы с поддержкой со стороны производителя (сколько часов просидели мы слущая как очередной индус зачитывает нам текст из документации и не отвечает на вопросы о текущей проблеме).
Ну и самое основное:
— из рук вон плохая/глючная поддержка кластерности ( как я сказал, даже нет централизованного хранилища для кода).
— не подходит для реал тайм обработки бизнес процессов в силу текущей архитектуры.
— брокер сообщений, это вообще песня. Это так называемый сингл поинт оф фалче. Если плохо брокеру — плохо всем. Хочешь лечить брокер — пусть бизнес отдохнет.
Последний пункт они советуют лечить установкой отдельных кластеров для критичных бизнес функций. Что мягко говоря удручает.
Промучавшись с WebMethods и имея простои доходящие до суток, руководство решило избавиться от этого CASE решения и на горизонте замаячил новый кандидат Oracle SOA. По сути, тот же WebMethods, только вид сбоку. Архитектура до боли знакома, но плюс ко всему Оракл попытался в своем решении совместить свои старые наработки с покупными. И вот мы имеем две разные шины, кучу разношерстных редакторов и полностью расстерявшихся начинающих SOA девелоперов. Признаться честно, после того как я познакомился с SOA поблииже, WebMethods показался уже не таким уж и плохим. В нем хотя бы инструменты разработчика и концепция были более менее доработаны для маломальски нормальной работы.
Посетив Oracle конференцию в Лондоне, мне и моему коллеге очень сильно захотелось отговорить ближайщее руководство от очередного безумного шага. Но что мы могли предложить в замен? Как не странно, все генниальное (ну или хотя бы хорошее) — просто. Решение пришло само и откуда не ждали. Все началось с того, что срочно избавляясь от WebMethods (в виду непредсказуемых отказов), код переписывался на C#. Было много, очень много однотипных шагов в различных бизнес сценариях. Не долго думая, в моей команде было принято решение использовать конечные автоматы для связывания шагов. Почему не WF? По нескольким причинам. Это решение рассматривалось как временное (на подходе новая серебрянная пуля от начальства), не хотелось писать полноценного хоста для WF, редактор WF в то время оставлял желать лучшего и, наконец, не было достаточного опыта использования WF в системах с большим траффиком сообщений. Вообщем, побоялись.
Практически сразу же от конечных атвоматов пришлось отказаться. Они не позволяют описать в компактном виде выполнение параллельных операций. Нам на помощь пришли сети Петри. Спасибо альмаматер. Сети Петри оказались тем решением для нашего проекта, которое позволило на всегда (надолго?) забыть о сторонних CASE продуктах.
Бесплатный редактор генерирующий PNML нашли довольно быстро. Pipe 2.5. И дело пошло. Создали свою версию брокера сообщений. Помятуюя о WebMethod, наш брокер был клиентом, встраиваемый в каждый сервис общающийся с шиной сообщений. Это обеспечило независимость всех операций друг от друга. Так сказать, каждый сам смотрел в шину и доставал для себя сообщения. Это позволило сделать шаги полностью независимыми, что увеличило стабильность и масштабируемость.
Самое вкусное выяснилось, после внедрения первых нескольких бизнес процессов в продакшен. Оказалось:
— PNML легко конвертируеться с SVG, а значит показать диаграмы с текущим сосоянием заказов стало делом техники. Более того, стало возможным диагностики сразу тысяч проблемных ордеров, что раньше было не возможно по анализу логов. К сожалению WebMethods до сих пор не позволяет делать такой анализ (или я ошибаюсь?).
— Введение графических описаний, сделало бизнес процессы самоописываемыми. Сколько раз мне задавали вопрос бизнес и тестировщики: “Какие бизнес стадии должен пройти ордер такого типа”, “Почему завис наш ордер в тесте или продакшене”. Отсылая к документации, приходилось так же рассказывать об изменениях не включенных в документацию. Либо вообще все обьяснять с самого начала, так как документ никто не создал (знаю, знаю, у вас все бизнес процессы описаны, код прокомментирован, баги пофикшены). Теперь же они сами могли понять, где их заказ остановился и какие шаги ожидаються дальше. Так сказать, повышение визибилити на лицо.
— После нескольких итераций (накопились практически все использемые бизнесом атомарные операции), программирование заменилось рисованием диаграмм. На то что занимало как миниум пол дня, стало уходить 30 — 40 минут.
Это стало неоценимым опытом для нашей комманды.
Вот и моё руководство задумалось над использованием визуальных редакторов и CASE систем. Одному из моих коллег поставили задачу по определению наиболее подходящего инструмента. Он как истинный програмер выделил 3 пункта в своем исследовании:
1. домашнее решение
2. BizTalk
3. WebMethods
Последние два исследовались по причине наличия лецензии и сильного желания руководства использовать что то из них. Не буду вдаваться в подробности, т.к. в конце как обычно было принято политическое решение. Будем использовать WebMethods.
На этого монстра было потрачено много времени и сил нашей и пары соседних комманд по переводу старого кода на «новые рельсы». К сожалению, эру CASE встретили мы с WebMethods 6.xx и был он невероятно глючный и не стабильный, тяжелый и недоделанный. Следующие версии тоже не принесли желаемого облегчения. Я закончил знакомство с этим решением где-то на 7-мой версии.
Плюсы можно наити в рекламе на их сайте. Я приведу лишь недостатки WebMethods, с которыми мы жили 2-3 года:
— Установка продукта и кастомного кода (поддерживать все новые и новые среды просто мучение), так как нет централизованного хранилища кода.
— Доскуп к документации аля Оракл через спецальный сайт с платным аккаунтом.
— Проблемы с поддержкой со стороны производителя (сколько часов просидели мы слущая как очередной индус зачитывает нам текст из документации и не отвечает на вопросы о текущей проблеме).
Ну и самое основное:
— из рук вон плохая/глючная поддержка кластерности ( как я сказал, даже нет централизованного хранилища для кода).
— не подходит для реал тайм обработки бизнес процессов в силу текущей архитектуры.
— брокер сообщений, это вообще песня. Это так называемый сингл поинт оф фалче. Если плохо брокеру — плохо всем. Хочешь лечить брокер — пусть бизнес отдохнет.
Последний пункт они советуют лечить установкой отдельных кластеров для критичных бизнес функций. Что мягко говоря удручает.
Промучавшись с WebMethods и имея простои доходящие до суток, руководство решило избавиться от этого CASE решения и на горизонте замаячил новый кандидат Oracle SOA. По сути, тот же WebMethods, только вид сбоку. Архитектура до боли знакома, но плюс ко всему Оракл попытался в своем решении совместить свои старые наработки с покупными. И вот мы имеем две разные шины, кучу разношерстных редакторов и полностью расстерявшихся начинающих SOA девелоперов. Признаться честно, после того как я познакомился с SOA поблииже, WebMethods показался уже не таким уж и плохим. В нем хотя бы инструменты разработчика и концепция были более менее доработаны для маломальски нормальной работы.
Посетив Oracle конференцию в Лондоне, мне и моему коллеге очень сильно захотелось отговорить ближайщее руководство от очередного безумного шага. Но что мы могли предложить в замен? Как не странно, все генниальное (ну или хотя бы хорошее) — просто. Решение пришло само и откуда не ждали. Все началось с того, что срочно избавляясь от WebMethods (в виду непредсказуемых отказов), код переписывался на C#. Было много, очень много однотипных шагов в различных бизнес сценариях. Не долго думая, в моей команде было принято решение использовать конечные автоматы для связывания шагов. Почему не WF? По нескольким причинам. Это решение рассматривалось как временное (на подходе новая серебрянная пуля от начальства), не хотелось писать полноценного хоста для WF, редактор WF в то время оставлял желать лучшего и, наконец, не было достаточного опыта использования WF в системах с большим траффиком сообщений. Вообщем, побоялись.
Практически сразу же от конечных атвоматов пришлось отказаться. Они не позволяют описать в компактном виде выполнение параллельных операций. Нам на помощь пришли сети Петри. Спасибо альмаматер. Сети Петри оказались тем решением для нашего проекта, которое позволило на всегда (надолго?) забыть о сторонних CASE продуктах.
Бесплатный редактор генерирующий PNML нашли довольно быстро. Pipe 2.5. И дело пошло. Создали свою версию брокера сообщений. Помятуюя о WebMethod, наш брокер был клиентом, встраиваемый в каждый сервис общающийся с шиной сообщений. Это обеспечило независимость всех операций друг от друга. Так сказать, каждый сам смотрел в шину и доставал для себя сообщения. Это позволило сделать шаги полностью независимыми, что увеличило стабильность и масштабируемость.
Самое вкусное выяснилось, после внедрения первых нескольких бизнес процессов в продакшен. Оказалось:
— PNML легко конвертируеться с SVG, а значит показать диаграмы с текущим сосоянием заказов стало делом техники. Более того, стало возможным диагностики сразу тысяч проблемных ордеров, что раньше было не возможно по анализу логов. К сожалению WebMethods до сих пор не позволяет делать такой анализ (или я ошибаюсь?).
— Введение графических описаний, сделало бизнес процессы самоописываемыми. Сколько раз мне задавали вопрос бизнес и тестировщики: “Какие бизнес стадии должен пройти ордер такого типа”, “Почему завис наш ордер в тесте или продакшене”. Отсылая к документации, приходилось так же рассказывать об изменениях не включенных в документацию. Либо вообще все обьяснять с самого начала, так как документ никто не создал (знаю, знаю, у вас все бизнес процессы описаны, код прокомментирован, баги пофикшены). Теперь же они сами могли понять, где их заказ остановился и какие шаги ожидаються дальше. Так сказать, повышение визибилити на лицо.
— После нескольких итераций (накопились практически все использемые бизнесом атомарные операции), программирование заменилось рисованием диаграмм. На то что занимало как миниум пол дня, стало уходить 30 — 40 минут.
Это стало неоценимым опытом для нашей комманды.