Услышал сегодня мнение, что Java в чистом виде сейчас для решения бизнес-задач использовать, это как на ассемблере писать. Сейчас более подходящим является визуальное проектирование бизнес-процессов (например, через Composite Editor из Oracle SOA Suite). Бизнес-процесс описывается через BPEL, соединяем "кубики" линиями в редакторе и получаем работающий сервис.
Причина — экономия времени и денег. В итоге программирования на Java получается, допустим, 30%, а остальное — все в редакторе делаем. Получается не сколько программист, сколько инженер по конфигурации, интеграции. И со временем эта тенденция будет доминирующей, а чистые Java программисты уйдут в специфичные области, куда сейчас ушли C\C++ программисты.
Хотелось бы услышать мнения по этому поводу, на сколько обоснован такой прогноз.
T>Услышал сегодня мнение, что Java в чистом виде сейчас для решения бизнес-задач использовать, это как на ассемблере писать. Сейчас более подходящим является визуальное проектирование бизнес-процессов (например, через Composite Editor из Oracle SOA Suite). Бизнес-процесс описывается через BPEL, соединяем "кубики" линиями в редакторе и получаем работающий сервис. T>Хотелось бы услышать мнения по этому поводу, на сколько обоснован такой прогноз.
В 90-х ровно тоже самое про Smalltalk говорили. Ну и время от времени в целях пиара очередного редактора с кубиками и стрелочками то один то другой язык в разряд атавизмов переводят. На .NET например WWF для этого. Да только чё-та не выходит каменный цветок
Здравствуйте, techgl, Вы писали:
T>Сейчас более подходящим является визуальное проектирование бизнес-процессов (например, через Composite Editor из Oracle SOA Suite). Бизнес-процесс описывается через BPEL, соединяем "кубики" линиями в редакторе и получаем работающий сервис. T>Причина — экономия времени и денег.
А вы попробуйте на практике. Я когда-то участвовал в разработке BPEL IDE, и мы изучали существующие аналоги.
У меня сложилось обратное впечатление. Может быть еще переделать бизнес-процесс окажеться проще, но создать с
нуля, в визуальном редакторе, с непонятной диагностикой ошибок — нетривиальное занятие
Кодом с юнит-тестами это реально быстрее делается. Но с кодом никто не мешает запудрить логику так, что
человеку со стороны придется очень туго.
-- Главное про деструктор копирования не забыть --
Здравствуйте, Real 3L0, Вы писали:
R3>Documentum по такому принципу строит "программы": рисуется процесс и потом дописывается кодом.
Отдельные продукты — да, но насколько это можно назвать тенденцией?
Здравствуйте, techgl, Вы писали:
T>Хотелось бы услышать мнения по этому поводу, на сколько обоснован такой прогноз.
Не знаю насчёт джавы, но обо всякого рода визуальных редакторах-построителях у меня сложилось впечатление, что только самые простые вещи с ними делать проще, чем кодом. А с увеличением сложности задачи очень быстро становится так, что на "перетягивание кубиков" уходит гораздо больше времени, чем написать то же в коде. А иногда кубиками впринципе не получается это сделать, если задача совсем нестандартная.
Здравствуйте, techgl, Вы писали:
T>Хотелось бы услышать мнения по этому поводу, на сколько обоснован такой прогноз.
То о чем ты говоришь можно назвать дним словом — использование RAD-средств, или даже конкретнее — использование визуальных редакторов.
Для некоторых областей (таких как рисование ГУЯ или тех же статических бизнес-процессов) — это подходит неплохо. Однако и для этих задач дизайнеры подходят не всегда. Но для других областей нарисовать визуальный редактор трудно или вообще невозоможно. И тут код останется на всегда (ну, пока ИИ не изобретут ).
Кроме того, как бы не упрощал визуальный редактор жизнь необходимость программирвовать останется все равно.
Таким образом визуальные редакторы и другие RAD-ости — это не более чем средство упростить жизнь программиста и понять его производительность. Но чем проще будет жизнь программиста, тем более объемные задачи ему придется решать.
RAD-сный подход не единственный и далгко не самый эффективный подход пондятия производительности труда программиста. Есть ее ООП, ФП и метапрограмиирование. Они позволяют поднимать производительность труда там где дизайнер создать неудается.
Java поддерживает только ООП. Так что Java и правда на сегодня стала ассемблером-диназавром. И только лишь одни RAD-ти ей все равно не помгут. Так что очень советую, тем кто верит в RAD, взглянуть так же на современные гибридные языки Scala (для явщиков) и Nemerle (для дотнетчиков). В них не мало сдерсвт повышающих производительность труда программистов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
WWF хорош для сложных бизнес процессов, правда после некоторого низкоуровневого допиливания :)
На одном проекте хотели сделать так, чтобы аналитики используя BPEL описывали бизнес процесс, затем программисты навешивали логику и все это сдъедалось бы движком.
Вот только оказалось, что нормальный движков на .Net нет, а WWF не поддерживает BPEL.
Здравствуйте, techgl, Вы писали:
T>Услышал сегодня мнение, что Java в чистом виде сейчас для решения бизнес-задач использовать, это как на ассемблере писать. Сейчас более подходящим является визуальное проектирование бизнес-процессов (например, через Composite Editor из Oracle SOA Suite). Бизнес-процесс описывается через BPEL, соединяем "кубики" линиями в редакторе и получаем работающий сервис.
После чего программисты метерятся и переписывают это, чтоб оно работало.
Вот я сейчас занимаюсь внедрением системы, где большая часть как раз квадратиками со стрелочками в BPEL делается. Сложные процессы превращаются в Р'Льех со спящим Ктулху, изгибая пространство-время и меняя геометрию обилием стрелочек. При том, что нет никакой системы контроля версий, нормальных diff'ов и т.п.
И ещё проблема в том, что консультанты на практике пишут что угодно, но не реальные процессы.
Здравствуйте, Tesh, Вы писали:
T>WWF хорош для сложных бизнес процессов, правда после некоторого низкоуровневого допиливания T>На одном проекте хотели сделать так, чтобы аналитики используя BPEL описывали бизнес процесс, затем программисты навешивали логику и все это сдъедалось бы движком. T>Вот только оказалось, что нормальный движков на .Net нет, а WWF не поддерживает BPEL.
Да не надо допиливать, надо готовые платформы брать. BizTalk, SharePoint, CRM.
Например Shareoint позволяет использовать Visio для отражения маршрутов и SharePoint Designer для написания логики причем взаимодействие у них двусторонее. Там где не хватает возможностей SPD их можно дополнить кастом кодом. При желании можно с помощью кода провести декомпозицию workflow.
При этом это довольно кривой WF используется. С новой версией — WF4, было бы еще проще.
BizTalk хорош... для интеграции систем, использующих разные протоколы.
А если требуется что-то типа: приняли документы, выдали задачу, дождались выполнения, на ее основе выдали еще несколько — лучше уж чистый WWF с кастомными Activity.
Голая JAVA без библиотек и поддержки сторонних тулзов действительно для многих задач как ассемблер. Другое дело что DSL может и не присутствовать в явном виде , а быть например частью библиотеки
Здравствуйте, techgl, Вы писали:
T>Услышал сегодня мнение, что Java в чистом виде сейчас для решения бизнес-задач использовать, это как на ассемблере писать. Сейчас более подходящим является визуальное проектирование бизнес-процессов (например, через Composite Editor из Oracle SOA Suite). Бизнес-процесс описывается через BPEL, соединяем "кубики" линиями в редакторе и получаем работающий сервис. T>Причина — экономия времени и денег. В итоге программирования на Java получается, допустим, 30%, а остальное — все в редакторе делаем. Получается не сколько программист, сколько инженер по конфигурации, интеграции. И со временем эта тенденция будет доминирующей, а чистые Java программисты уйдут в специфичные области, куда сейчас ушли C\C++ программисты. T>Хотелось бы услышать мнения по этому поводу, на сколько обоснован такой прогноз.
Мне доводилось использовать BPEL. Так вот, его использование увеличивает время разработки в 3 раза, по сравнению с тем, как если бы писать просто на Java. Такое практически у всех наблюдается. Это на простых задачах. Когда логика становится сложной — время разработки увеличивается в 10 раз минимум. Был опыт, то, что делали раньше, надо было делать на BPEL. Оценили, что на Java сделали бы за 2 недели, вроде ничего сложного, но на всякий случай месяц поставили в сроки. В итоге провозились полгода. Малейшее изменение требований — полная жесть. Когда что то не работает, хз как смотреть — лично я не нашел ничего лучше, чем внимательно анализировать чистый XML. Так как XML хоть можно взглядом откатить, хоть как то можно diff сделать и понять что менялось, хотя б в ручном режиме. В 100 раз проще в XML все смотреть, чем щелкать по этим квадратикам и смотреть свойства, причем очень внимательно смотреть. Рефакторинг отдельная тема — практически невозможен.
В принципе, если задаться целью, я думаю вполне реально в случае использования BPEL тратить время всего в 2 раза больше по сравнению с чистой Java, но это похоже предел.
Но в случае BPEL есть одно ключевое достоинство, за счет чего он достаточно популярен в аутсорсе. Все очень просто — если сделать проект с его помощью, саппортить это смогут только те, кто это писал. Так как граблей понатыкано как на минном поле, про них надо постоянно помнить. В результате заказчику некуда будет деваться, и он купит саппорт, и проект будет долго приносить деньги аутсорсерам.
Все эти экономии доказывают только одно — скупой платит дважды и трижды. Экономим на квалификации разработчиков, говорим, что разработчики не нужны, и все будет делать аналитик — срываем все сроки, набираем черти какое количество разработчиков, черти сколько тестеров это тестирует, итого это в такую копеечку всплывает и в такие сроки, что в случае конкуренции конкуренты за это время бы все с нуля написали силами одного человека.
Здравствуйте, Cyberax, Вы писали:
C>Вот я сейчас занимаюсь внедрением системы, где большая часть как раз квадратиками со стрелочками в BPEL делается. Сложные процессы превращаются в Р'Льех со спящим Ктулху, изгибая пространство-время и меняя геометрию обилием стрелочек. При том, что нет никакой системы контроля версий, нормальных diff'ов и т.п.
Вот если бы сделали редактор, который понимал бы полностью нотацию eEPC — было бы супер.
C>И ещё проблема в том, что консультанты на практике пишут что угодно, но не реальные процессы.
Здравствуйте, Real 3L0, Вы писали:
C>>Вот я сейчас занимаюсь внедрением системы, где большая часть как раз квадратиками со стрелочками в BPEL делается. Сложные процессы превращаются в Р'Льех со спящим Ктулху, изгибая пространство-время и меняя геометрию обилием стрелочек. При том, что нет никакой системы контроля версий, нормальных diff'ов и т.п. R3>Вот если бы сделали редактор, который понимал бы полностью нотацию eEPC — было бы супер.
А смысл? Проблемы графического представления-то не исчезнут.
C>>И ещё проблема в том, что консультанты на практике пишут что угодно, но не реальные процессы. R3>Это хреновые консультанты.
А не хреновым уже самим достаёт стрелочки рисовать.
Здравствуйте, Cyberax, Вы писали:
R3>>Вот если бы сделали редактор, который понимал бы полностью нотацию eEPC — было бы супер. C>А смысл? Проблемы графического представления-то не исчезнут.
Как минимум, схема будет очень хорошо читаться. Гораздо лучше кода, как бы этот код не был написан.
Вот с редактированием — да, будут проблемы.
R3>>Это хреновые консультанты. C>А не хреновым уже самим достаёт стрелочки рисовать.
Здравствуйте, Real 3L0, Вы писали:
R3>>>Вот если бы сделали редактор, который понимал бы полностью нотацию eEPC — было бы супер. C>>А смысл? Проблемы графического представления-то не исчезнут. R3>Как минимум, схема будет очень хорошо читаться. Гораздо лучше кода, как бы этот код не был написан.
Для этого нужно просто уметь делать генерацию схем по коду. Впрочем, правильный код всё равно лучше.
В общем, без революции в удобстве использования — графическиу тулзы мастдай.
Здравствуйте, techgl, Вы писали:
T>Причина — экономия времени и денег. В итоге программирования на Java получается, допустим, 30%, а остальное — все в редакторе делаем. Получается не сколько программист, сколько инженер по конфигурации, интеграции. И со временем эта тенденция будет доминирующей, а чистые Java программисты уйдут в специфичные области, куда сейчас ушли C\C++ программисты.
Об этом уже несколько десятилетий говорят, только названия инструментов меняются
).
