Комментарии 333
реализация технологии стирающей различия между вызовами локального и удаленного кода
Не увидел ни одного теста производительности в статье.
Тогда почему хаб "высокая производительность"?
Так это утверждение вроде бы нуждается в доказательстве, разве нет?
Значит, в рамках простого приложения этот хаб указан безосновательно.
который позволяет это делать.
Это утверждение нуждается в доказательстве.
В рамках простого приложения этот хаб относится к фремворку,
Поймите: вот я открываю хаб, вижу там вашу статью, захожу в нее — а там про производительность ни одного (полезного) слова.
Если этот вопрос за рамками этой статьи, то эта статья — за рамками хаба "Высокая производительность". О чем, собственно, я сразу и написал.
Рассмотренная технология позволяет создавать приложения высокой производительности, хотя бы тем, что можно добавлять по своему усмотрению неограниченное число узлов. На GitHub (ссылка в конце статьи) опубликован простой пример каскадной функции, которая "распределяет" нагрузку между множеством узлов, с которых вызывается метод getInfo().
реализация технологии стирающей различия между вызовами локального и удаленного кода.
Никогда такого не было и вот опять?
Признайтесь, как вы решили проблему обледенения chatty vs chunky?
А тут мало того, что напиши remotable bean, зарегистрируй его в конфиге, так еще и интерфейс ручками там же свяжи.
Ради всего святого — зачем?
На мой взгляд, вынос параметров в конфигурационный файл — это «правило хорошего тона».
«Зачем?» — ограничено только вашей фантазией. Допустим, что нужно 100% зарезервировать функционал DemoFunction. Что для этого нужно? Опубликовать DemoFunction на множестве узлов и поменять конфигурацию системы. Все. Допустим, что Вам нужно поймать событие вызова метода getInfo() класса DemoFunction. Создаете «каскадную» функцию, которая вызывает DemoFunction и отдает результат DemoApplication попутно выполнив требуемые Вам действия и меняете конфигурацию. Допустим изменился технологический процесс и часть функций вашей информационной системы потеряла актуальность. Для вывода из эксплуатации этой часть достаточно убрать ее из конфигурации системы.
Допустим изменился технологический процесс и часть функций вашей информационной системы потеряла актуальность. Для вывода из эксплуатации этой часть достаточно убрать ее из конфигурации системы.
И информационная система магически перестанет вызывать эту "часть системы"?
Благодаря описанной в посте технологии? Что случится при обращении к first.jsp при такой конфигурации?
Значит, эта часть мотивации неактуальна.
Это уже дело вашей фантазии как Вы реализуете эту функциональность. Например, 2 года назад, в одном из своих приложений подобным образом была отключена часть утратившей актуальность функций, находящееся в эксплуатации с 2007 года. Приложение, при старте "видит" список объектов в своей конфигурации и на основании этого списка строит пользовательский интерфейс. Отключение одного из элементов в конфигурации привело и к изменению в пользовательском интерфейсе, все связанные с этим элементом пункты меню "чудесным образом" пропали.
Это уже дело вашей фантазии как Вы реализуете эту функциональность
… и, возможно, я найду более простой и надежный способ реализовать эту функциональность. Что лишний раз говорит нам, что, может быть, конфиги-то и не так хороши, как кажется?
Использовать для этих целей конфигурацию приложения очень удобно и в первую очередь для эксплуатирующего подразделения! Возникло требование — отключили никого не спрашивая, никому не обращаясь. Возникло требование — подключили. Риск внести ошибку или "сломать" ИС минимальный.
"Удобство эксплуатации" для меня имеет существенно более высокий приоритет чем "удобство реализации" (удобство кодирования для программиста).
Использовать для этих целей конфигурацию приложения очень удобно
Конфигурацию приложения в общем понимании? Да. Конфигурацию, как вы ее подаете? Не обязательно.
Риск внести ошибку или "сломать" ИС минимальный.
Минимальный из каких вариантов?
Минимальный по сравнению с внесением изменений в ПО
Я еще раз повторю: внесение изменений в конфигурацию — это и есть внесение изменений в ПО, поэтому ваше противопоставление бессмысленно.
Изменение конфигурации — это не изменение ПО. Конфигурация — переменная составляющая. ПО — неизменная составляющая.
Изменение конфигурации — это не изменение ПО.
Почему это?
Какая для конечного пользователя разница, что было изменено, если наблюдаемое им поведение программы поменялось?
Представьте на минуту, что речь идет не о компилируемых языках, а о чем-нибудь вроде Python.
Разница огромная! Для изменения конфигурацию достаточно любого текстового редактора. Для приведенного примера достаточно закомментарить или удалить секцию конфигурации. А что нужно для внесения изменений ПО, потрудитесь описать.
Для изменения конфигурацию достаточно любого текстового редактора.
Я не зря написал про Python. Для внесения изменений достаточно того же самого текстового редактора.
Или вот возьмите AWS Lambda (или API Gateway, не важно): когда я там что-то меняю — это изменение настройки или ПО? И как вы отличаете одно от другого?
Разница огромная!
Напомню вопрос: "Какая для конечного пользователя разница". Разве он вообще видит, каким редактором вы пользовались для внесения изменений?
Не важно, какой язык Вы используете, важно трудаемкость процесса. Сколько строк кода Вам потребуется вычистить в случае отключения какой то части системы? Вы уверены, что сможете сделать это без ошибок? А вам не приходилось слышать, что "этот код написан очень давно и никто толком не помнит как он работает и лучше его не трогать"?
Не важно, какой язык Вы используете, важно трудаемкость процесса.
И почему вы утверждаете, что для конфигурации она меньше?
Сколько строк кода Вам потребуется вычистить в случае отключения какой то части системы?
В правильно спроектированной системе? Одну.
Вы уверены, что сможете сделать это без ошибок?
Нет, конечно. Но и человек, правящий конфигурацию, не может быть в этом уверен.
А вам не приходилось слышать, что "этот код написан очень давно и никто толком не помнит как он работает и лучше его не трогать"?
А вам не приходилось слышать "эта строчка в конфигурации написана очень давно, и лучше ее не трогать"?
Конфигурацию может поправить любой специалист.
У Вас такой не найдется
Может. 100% выполнить эту операцию без ошибки.
Не приходилось! А мое утверждение — постоянно, когда речь заходит о какой либо модификации кода находящегося в эксплуатации достаточно долгое время. От разных разработчиков, разных контор.
Конфигурацию может поправить любой специалист.
Код может поправить любой специалист.
У Вас такой не найдется
Не найдется чего, простите?
Может. 100% выполнить эту операцию без ошибки.
Если он может, то и я могу. Удалить одну строчку кода — просто.
Не приходилось!
Вам повезло. А мне приходилось, и неоднократно.
В промышленных системах править исходный код, где цена ошибки может принести огромные убытки? Любого просто не подпустят! А править конфиг может (и это его обязанность) администратор системы.
Вы себе противоречите. Сначала вы говорите, что конфигурацию может поправить любой специалист, потом говорите, что любого не подпустят.
Но в любом случае: в промышленной системе степень ответственности и допуска при правке системы не отличается для кода и конфигурации — что одно, что другое попадает в деплоймент-систему, оттуда выкатывается на стейджинг, оттуда же — на продакшн.
Администратор не программист, в его обязанностях нет пункта править код информационной системы.
Во-первых, что напишут в обязанности, то и будет.
Во-вторых, править конфигурацию тоже может не входить.
В-третьих, в его обязанности входит удостовериться, что работает, и выкатить, а кто и как внес изменение — не важно.
А главное, все это не имеет никакого отношения к тому, является ли изменение конфигурации изменением ПО.
Наши разные взгляды на обязанности администратора системы выходят за рамки рассматриваемой теме
И именно поэтому вы не можете использовать "обязанности администратора системы" как аргумент в пользу конфигурации вместо кода.
Что, в свою очередь, снова возвращает нас к утверждению, что и изменение конфигурации, и изменение кода являются изменением ПО (не то что бы обязанности администратора на это как-то влияли).
Моя точка зрения остается неизменной — изменение конфигурации не является изменением ПО. Для меня ваши аргументы не убедительны. Давайте закроем эту тему, она не относится к теме публикации.
Для меня ваши аргументы не убедительны.
… однако опровергнуть их вам не удалось.
Давайте закроем эту тему, она не относится к теме публикации.
Да нет, напрямую относится. Если из вашего решения выкинуть конфигурацию, что останется?
А Вы доказать вашу правоту не можете. И кто из нас прав?
Понимаете ли, в чем дело… это вы предлагаете некую технологию, утверждая, что она лучше, удобнее и бла-бла-бла. Вам и доказывать, что это так.
Совершенно верно — гораздо лучше и гораздо удобнее. Доказано практикой. Не сталкивались вы с подобными проблемами, не можете осознать преимущества подобного подхода.
Доказано практикой.
Чьей практикой? Конкретные примеры, исследования, case studies — в студию.
Не сталкивались вы с подобными проблемами
Какими "подобными"?
Чьей практикой?
многолетней практикой эксплуатации распределенных систем
Какими "подобными"?
с проблемами эксплуатации распределенных систем
многолетней практикой эксплуатации распределенных систем
Я, мне кажется, спрашивал чьей.
с проблемами эксплуатации распределенных систем
Вы этого знать не можете, и, как следствие, ошиблись.
ответил ниже
Вы этого знать не можете, и, как следствие, ошиблись.
Тогда странно слышать от Вас некоторые вопросы, при наличии опыта то.
В 2003 году развернул свою первую распределенную систему — реального времени. Масштаб развертывания — вся страна (напомню, у нас много часовых поясов). Система находится в эксплуатации до сих пор. Узлов системы много. С тех пор многократно менялось ПО системы. Происходила миграция узлов на другие аппаратные средства. Узлы меняли свою дислокацию на территории страны. И ни разу не было зафиксировано ни одно сбоя по причини ошибок установки ПО или изменения конфигурации узлов. "Косяки" при обслуживании БД были, проблемы связи — были, внесенные ошибки в отдельную функциональность — были, проблемы со смежными системами, влияющими на работоспособность — были.
Ну то есть вы опираетесь в качестве доказательства на свою собственную практику?
"опыт ошибок трудных"
… и вас это не смущает, я понял.
Я вам честно скажу: при выборе между вашим опытом эксплуатации распределенных систем и аналогичным опытом Google я выберу Google.
Существует немало технологий, которые в свое время активно продвигались в том числе лидирующими на рынке IT — компаниями и о которых сейчас ни вспоминает. Так что лидеры IT рынка тоже ошибаются.
Вы предлагаете мне считать, что вероятность того, что вы ошибаетесь, меньше, чем вероятность того, что — раздельно друг от друга — ошибаются Google и Хамбл/Фарли (ну и, очень скромно, мой опыт тоже)?
Я когда-то в одно щачло поднял интеграционную платформу с таким низким уровнем вхождения, что типовые скрипты служба поддержки клиентов сама разрабатывала и внедряла чуть ли не копипастя с известного. и объем редко превышал сотню строк.
На мой взгляд, вынос параметров в конфигурационный файл — это «правило хорошего тона».
Параметров — да. А связывание классов — это уже ответственность слоя бизнес-логики. Был бы у вас целевой класс имплементором удаленного интерфейса — можно было бы применять autodiscovery. Постойте-ка… Но это же RMI!
А вы мало того, что RMI переизобретаете (в функциональном смысле), так еще и смешиванием слоев даете возможность разработчику выстрелить себе в ногу.
Не надо так, пожалуйста.
При использовании RMI код "привязан" к только к протоколу RMI. В предложенном решении код изолирован от протокола, что позволяет использовать практически любой известный протокол. Эксплуатирующая организация может изменить его в любой момент по своим собственным соображениям. Заметьте, выбор протокола ни как не сказывается на вашем коде. И в этом решении RMI не переизобретен, а, по сути, усовершенствован.
Второе, предложенное решение как раз и раскладывает все "по полочкам". И это называется "модифицируемостью" — простотой модификации промышленной системы. Каждый программный слой выполняет только свою функцию. Бизнес логика постоянно меняется. Предложенное решение позволяет IT подразделению заказчика более гибко реагировать на требование бизнеса, а не ждать "у моря погоды", когда будут выделен бюджет на модификацию ПО для удовлетворения "неожиданно" возникших новых требований или изыскивать другие "обходные" решения, например: — "Вы нам сделаете сейчас, а оплатим мы вам из бюджета следующего года".
Предложенное решение позволяет IT подразделению заказчика более гибко реагировать на требование бизнеса, а не ждать "у моря погоды", когда будут выделен бюджет на модификацию ПО
Реагировать на требования без модификации ПО? Ну то есть пришел бизнес и говорит "хочу, чтобы курс валют теперь брался из сервиса ЦБРФ, а не вбивался руками", и?..
Пишется новая "функция" и меняется конфигурация системы. Эксплуатируемое ПО не изменяется и, в случае какой либо "неудачи" новой функции, легко может быть возращено в эксплуатацию.
Во-первых, кто пишет эту новую функцию, если бюджета нет?
Во-вторых, пусть даже ее напишут, как вы замените ручной ввод на регулярную загрузку из внешнего сервиса без соответствующей заранее предусмотренной точки расширения?
А в-третьих, и в самых важных, когда вы говорите "эксплуатируемое ПО не изменяется", вы лукавите. Конфигурация — такая же часть эксплуатируемого ПО, как и код, и изменения в ней должны проходить тот же самый цикл при развертывании; с практической точки зрения нет (не должно быть) разницы, выкатываете вы изменения в коде или изменения в конфигурации.
Проще говоря, нет никакой практической разницы (кроме используемого для изменения набора инструментов) между тем, описаны ваши привязки в конфигурации или в коде.
Функция может быть заказана любому разработчику или быть реализована программистами заказчика, т.е. небольшие изменения можно вносить в рамках текущего бюджета.
"Ручной ввод" он же куда сохраняет результаты свой работы, из конфигурации исключаем функцию "ручного ввода" и включаем функцию "загрузки с сайта" с сохранением "в то же место".
Согласитесь, что процесс изменения конфигурации все же более простоя задача по сравнению изменение программного кода, которое в том числе так же может потребовать и изменения конфигурации.
Функция может быть заказана любому разработчику или быть реализована программистами заказчика, т.е. небольшие изменения можно вносить в рамках текущего бюджета.
Ну так что же мешает внести их прямо в ПО?
"Ручной ввод" он же куда сохраняет результаты свой работы, из конфигурации исключаем функцию "ручного ввода" и включаем функцию "загрузки с сайта" с сохранением "в то же место".
Гм. А как вы из удаленно выполняющейся "функции" получите доступ к "тому же месту"?
(Я даже не спрашиваю, как вы собираетесь вызывать это по расписанию)
Согласитесь, что процесс изменения конфигурации все же более простоя задача по сравнению изменение программного кода
Нет, не соглашусь. Для кода обычно доступно больше средств проверки, чем для конфигурации.
А зачем? При вносе изменений прямо в ПО есть риск внести какую то ошибку? Есть. Для изменения ПО необходимо наличие IDE? Необходимо. И т.п. и т.д. Этот процесс гораздо сложнее и "дороже".
Напомню, предложенная технология стирает различия в вызовах локального и удаленного кода. Для этой технологии не имеет значения место исполнения функции. А уж по реализацию шедуллера я вообще молчу. Если лень самому "изобретать", то можно воспользоваться готовым из большого множества OpenSource.
Диагностика все же больше зависит не от средств проверки кода, а от информативности и однозначности сообщений в файлах журналов системы, которые позволяют быстро устанавливать причину ошибки. Мне нравиться информативность и однозначность сообщений в большинства СУБД. В своих системах предпочитаю реализовывать подобный подход.
Вот только при вашем способе есть ещё больше способов внести какую-то ошибку.
При вносе изменений прямо в ПО есть риск внести какую то ошибку? Есть.
… такой же, как при написании "функции" отдельно.
Для изменения ПО необходимо наличие IDE? Необходимо.
… так же, как и для написания "функции" отдельно.
Этот процесс гораздо сложнее и "дороже".
Нет, почему бы? Он точно такой же, как при написании "функции" отдельно.
Единственная разница в том, где вы пишете привязки — в коде или в конфигурации. И я бы не стал утверждать, что в конфигурации это гарантированно проще и дешевле.
Напомню, предложенная технология стирает различия в вызовах локального и удаленного кода. Для этой технологии не имеет значения место исполнения функции.
Это еще надо доказать.
В частности, как вы обеспечите из "функции", выполняемой на другом сервере, доступ к тому же самому хранилищу, что и из "функции", выполняемой локально?
А уж по реализацию шедуллера я вообще молчу.
Нет, ну зачем же. Расскажите нам, как вы добавите функциональность шедулера в приложение, в котором нет соответствующей точки расширения, без его модификации.
Диагностика все же больше зависит не от средств проверки кода, а от информативности и однозначности сообщений в файлах журналов системы, которые позволяют быстро устанавливать причину ошибки.
В смысле — рантайм сообщений? Так это дважды поздно. Меня интересует проверка на этапе разработки, если не получится — на этапе сборки, если и это не получится — на этапе тестирования.
В своих системах предпочитаю реализовывать подобный подход.
… а я в "своих" системах предпочитаю реализовывать подход, при котором максимальное число ошибок обнаруживается до запуска приложения.
В логе будет зафиксировано предупреждение
SYS0103W Экземпляр класса "ru.funsys.demo.avalanche.DemoAdapterr" узла <adapter> не создан (класс не найден).
Используемая система логирования достаточно гибкая, можно настроить вывод в отдельный лог для событий отдельного экземпляра объекта (такого решения ни где нет).
Сообщения информативны и однозначны.
В промышленных системах система диагностики "многоярусная", ошибка находиться и устраняется.
Преимущества в другом — готовый сервис для создания распределенных масштабируемых систем.
Кстати, сколько бы узлов в распределенной системе не было бы, любая ошибка будет зафиксирована и в вызываемом узле и доставлена и зафиксирована в вызывающий узел. А уж как ей распорядится вызывающий узел — это дело программного кода системы. Анализировать и сопоставлять логи на множестве узлов не нужно.
При инициализации приложения на узле системы еще нет ни каких вызовов, нет объекта куда можно возвращать ошибку. Все приложения без исключений в этом состоянии все пишут в лог
Вот только некоторые ошибки можно ловить до инициализации приложения на узле системы. А вы даже не пытаетесь этого делать.
Все без исключения ошибки инициализации ловятся. Если заметили выдается предупреждение, а не сообщение об ошибке. То есть данная вид ошибок классифицирован, как не критическая ошибка и система может далее загружаться.
Все без исключения ошибки инициализации ловятся.
… на этапе инициализации.
А я говорю про более ранний этап.
На каком? На этапе написания кода? Код не изменялся, ловить там нечего!
На каком?
Написания конфигурации, сборки пакета или развертывания пакета.
Пакет собран и развернут, конфигурация внешний объект по отношению в собранному и развернутому пакету. Тем более речь идет о системе с множеством узлов и у каждого узла может быть собственная индивидуальная конфигурация. ПО везде одинаковое, а конфигурация везде разная. Будете ваши пакеты под каждый узел собирать? А если их 40 штук? А завтра заказчик захочет 1000 иметь? Что будете делать?
конфигурация внешний объект по отношению в собранному и развернутому пакету.
Это противоречит практикам стабильного развертывания. Вы Хамбла/Фарли не читали?..
Будете ваши пакеты под каждый узел собирать?
Конечно. Это же очень просто.
А если их 40 штук? А завтра заказчик захочет 1000 иметь? Что будете делать?
Версионнику более-менее все равно, хранить один файл конфигурации, 40 или 1000.
Простите за прямой вопрос: а как вы меняете конфигурацию в продакшн-системах?
Это противоречит практикам стабильного развертывания. Вы Хамбла/Фарли не читали?..
В промышленных системах непрерывной доступности не нужно быстрое развертывание. Там нужна плановость и управляемость, а так же свобода действий эксплуатирующей организации, что она по своему усмотрению могла менять конфигурацию исходя из текущих потребностей. Вы же когда меняете конфигурацию СУБД к ее производителю не обращаетесь, чтобы он вам собрал новый пакет СУБД исходя из ваших потребностей.
Простите за прямой вопрос: а как вы меняете конфигурацию в продакшн-системах?
В продакшен, а каких же еще?
В промышленных системах непрерывной доступности не нужно быстрое развертывание.
А я где-то что-то сказал про быстрое развертывание?
Там нужна плановость и управляемость
А чтобы была управляемость, нужна повторяемость, а чтобы была повторяемость, конфигурация должна быть зафиксирована.
Вы же когда меняете конфигурацию СУБД к ее производителю не обращаетесь, чтобы он вам собрал новый пакет СУБД исходя из ваших потребностей.
Нет, я обращаюсь к тому, кто отвечает за развертывание этого участка (это могу быть и я сам), и он собирает новый пакет.
В продакшен, а каких же еще?
Я спросил как вы это делаете. Ну, по шагам, в смысле.
Так как же вы меняете конфигурацию системы в продакшн?
Да в продакшен, на пассивных узлах — узлах не несущих нагрузки. После внесения изменений в конфигурацию и проверки функционирования узла он возвращается в систему.
Я уточню еще раз, вдруг я неправильно понял: вы просто меняете (руками, в редакторе или копированием) файлы конфигурации на узлах системы, не несущих нагрузки?
Эту операцию выполняют администраторы, либо они сами знают что хотят изменить, либо выполняю данные рекомендации.
Но операция все равно та, которую я описал — ручное изменение конфига на узле?
Изменения, как правило не значительные, добавить строчку, удалить строчку или изменить значение атрибута.
Не важно, какие изменения, просто ответьте на прямой вопрос: да, меняют руками, или нет, меняют как-то иначе?
Давно ответил, в любом текстовом редакторе. Да, меняют руками. Я "за" более простые схемы эксплуатации, если можно не использовать в эксплуатации дополнительное ПО, то значит его НЕ НУЖНО использовать. Это понижает требования к сменному персоналу. В критической ситуации какой сотрудник будет ее устранять предсказать невозможно. У сменного персонала сотни разных систем в зоне ответственности.
Подводя итог, я вижу следующее:
- 1000 экземпляров.
- Настраиваются вручную.
- У каждого, потенциально, своя уникальная конфигурация.
И это всё как бы надёжно работает?
Да вас вообще даже близко подпускать к построению архитектуры нельзя!
работает
И совершенно не важно, как Вы доставляете конфигурацию до узла системы, Вы ее все равно будете корректировать в ручную — конфигурация каждого узла уникальна.
Конечно, важно. Во-первых, надо избегать уникальных конфигураций в таких масштабах, во-вторых, даже если все конфигурации уникальны, версионирование и автоматическая доставка дает нам уверенность, что как бы мы не поменяли конфигурацию, мы легко можем ее откатить обратно.
С версионностью нет проблем
Правда? И как же вы обеспечиваете версионность конфигураций, которые правятся вручную в текстовом редакторе на продакшн-серверах?
Так же как и ваше система версионности, создается копия файла. При желании могут вставляется соответствующий комментарий. Это не существенный вопрос и выходит за рамки темы.
Так же как и ваше система версионности, создается копия файла.
Меня смущает "так же". Я бы понял, если бы вы сказали "файл хранится в системе управления версиями" (хотя тут у меня были бы другие вопросы), но что означает "так же"? Где создается копия файла? Кем? Можно ли изменить конфигурацию, не создавая копию файла.
Это не существенный вопрос и выходит за рамки темы
Это существенный вопрос, потому что он (всегда) является одним из ключевых в дискуссии "конфигурация или код", а это именно то, что мы здесь обсуждаем.
Вам остается только поверить мне на слово. Архитектура система разработана так, что хранить копии конфигурационных файлов не нужно — восстановить предыдущую конфигурацию элементарно.
Вы ушли от темы статьи.
Вам остается только поверить мне на слово.
Зачем мне это? Я предпочту работать с решениями, где не надо верить на слово, а все можно проверить.
Архитектура система разработана так, что хранить копии конфигурационных файлов не нужно
Мы говорим про конкретную технологию, предлагаемую вами в статье. И как там это "разработано"?
хранить копии конфигурационных файлов не нужно
Вы только что писали "создается копия файла".
Вы ушли от темы статьи.
Нет. Подавляющая часть статьи о том, как можно прописать привязки в комментариях. Я, как и некоторые другие комментаторы, считаю, что это плохо и неправильно. Следовательно, дискуссия, почему это неправильно — по теме статьи.
При передаче изменений, требующих внесения изменения в конфиг — есть стандартная рекомендация, сделать копию файла. Но если по каким либо причинам она не будет сделана, ни какой трагедии не произойдет. Система в целом останется в рабочем состоянии.
При передаче изменений, требующих внесения изменения в конфиг — есть стандартная рекомендация, сделать копию файла.
Рекомендация — это то, что люди могут проигнорировать.
Особенно хорошо эта рекомендация сочетается с утверждением "Архитектура система разработана так, что хранить копии конфигурационных файлов не нужно".
Но если по каким либо причинам она не будет сделана, ни какой трагедии не произойдет. Система в целом останется в рабочем состоянии.
В общем случае это утверждение заведомо ложно.
жаль. что тут нет смайликов.
Отключение одного узла системы, даже на длительное время — на работоспособности системы не отражается. Не сделали резервной копии и не сделали — нет трагедии.
Да вас вообще даже близко подпускать к построению архитектуры нельзя!
Это не Вам судить.
В системе заложены функции самовосстановления после сбоя, система сама справляется со сбойными ситуациями и восстанавливает свою работу, когда это становиться возможным. Система сама принимает решения по переключению на дублирующие узлы.
Так что работает НАДЕЖНО и не требует постоянного "присмотра"
Это не Вам судить.
Почему, кстати? Вы же судите о том, в чем у меня был опыт или не был? А мы так же можем судить о том, можно ли, по нашему мнению, подпускать вас к проектированию крупных систем. Конечно, никто к этому мнению прислушиваться (или даже выслушивать его) не обязан — до тех пор, пока речь не идет о системах под нашим присмотром — но высказать мы его вполне можем.
Это, если вкратце, очень плохо. Именно потому, что "у сменного персонала сотни разных систем в зоне ответственности" — вероятность человеческой ошибки увеличивается в разы, особенно когда вы "понижаете требования к сменному персоналу". Намного выгоднее — с точки зрения надежности — уменьшать число требуемого персонала за счет автоматизации, и повышать их квалификацию.
У ручных изменений много недостатков, но два самых важных — это высокая вероятность человеческой ошибки и невозможность автоматического отката в заведомо рабочее состояние.
И да, вернемся к вашему примеру. Вот у вас есть кластер из тысячи узлов (масштабируемость/отказоустойчивость). Вам надо поменять на всем кластере одну настройку. Сколько усилий на это уйдет, и какова вероятность ошибки? А теперь внезапно выяснилось, что настройку менять было не надо, и надо весь кластер откатить обратно. Сколько усилий, какова вероятность ошибки?
Сменный персонал не лазит в конфиги от скуки
А я, вроде бы, и не говорил ничего про скуку. Это рутинная работа по обслуживанию.
Сменный персонал должен иметь возможность внести изменения в конфиг в случае какой то аварии, требующей вмешательства и то, если ему дали такую рекомендацию. ВСЕ! На этом его функции заканчиваются.
Во-первых, а что тогда с плановыми изменениями?
Во-вторых, опыт показывает, что даже в случае аварии изменения лучше проводить по стандартной процедуре, потому что это упрощает дальнейшие действия.
При плановых изменениях все прописано — что делать, как откатывать. С этим нет проблем.
"Все прописано" — это хорошо, но кто это делает?
А если "нет проблем" — то, наверное, нет проблем и ответить на мои комментарии, потому что они в полной мере применимы к плановым обновлениям.
(Удивительно, конечно. Мы занимаемся автоматизацией процессов, потому что машины в среднем лучше следуют инструкциям, нежели люди, но при этом отказываемся видеть, что регламент обновления — это такая же инструкция, которую так же можно автоматизировать.)
Автоматизировать можно все! Лететь на Марс можно хоть сейчас — только сейчас это очень дорого стоить!
Есть экономическая целесообразность. Если текущий процесс не требует затрат, зачем "изобретать велосипед" и вносить в системы еще один узел, который требует опять же какого резервирования, сам подвержен вероятным сбоям и за этим узлом кому то тоже нужно приглядывать?
только сейчас это очень дорого стоить!
Лететь на Марс, возможно, "очень дорого". Автоматизировать доставку ПО — не очень.
Если текущий процесс не требует затрат, зачем "изобретать велосипед"
Никто не предлагает изобретать велосипед, есть готовые работающие решения.
А зачем? Затем, что вы получаете стабильный и воспроизводимый процесс изменения системы. Вы знаете, в каком состоянии система сейчас, и почему, когда и кем была внесена та или иная настройка.
В каком-то смысле это вопрос того же толка, что и "зачем нужно управление версиями кода". Правда, а зачем?
готовое решение или нет, для системы это "изобретение велосипеда", который "в нужный момент" может оказаться не доступен — сломался, обслуживается, недоступен и т.д.
для системы это "изобретение велосипеда"
Конечно, нет. "Изобретение велосипеда" — это вполне конкретный антипаттерн, подразумевающий повторное придумывание уже существующей функциональности. Я же предлагаю взять готовое.
который "в нужный момент" может оказаться не доступен — сломался, обслуживается, недоступен
С равным успехом в нужный момент может не оказаться доступа к продакшн-серверу.
Я повторю свой вопрос: зачем нужно управление версиями кода? Текущий процесс не требует затрат, в нужный момент система управления версиями (и сборщик) могут оказаться недоступными… зачем?
С точки зрения системы — это именно именно велосипед. При этом — велосипеда, повышающего вероятность отказа системы!
Сравнили тоже версионность кода и конфига! Конфиг в течении жизненного цикла меняется не существенно. Изменения конфига редкая операция и, как правило, меняются какие то значения атрибутов, добавляются или удаляются какие строки.
Изменения исходника может затронуть весь файл. И таких файлов тьма тьмущая. И таких изменений может быть каждый день, несколько раз на дню.
С точки зрения системы — это именно именно велосипед.
Докажите это утверждение.
Конфиг в течении жизненного цикла меняется не существенно.
В течение жизненного цикла чего?
Изменения конфига редкая операция
Это утверждение в общем случае неверно. Особенно оно неверно в контексте предлагаемого вами "не хватает ресурсов — переразвернули на кластере и поправили конфиг".
Изменения исходника может затронуть весь файл. И таких файлов тьма тьмущая. И таких изменений может быть каждый день, несколько раз на дню.
Изменения конфига может затронуть весь файл. И таких конфигов тьма тьмущая. И таких изменений может быть каждый день, несколько раз на дню.
Это, заметим, реальная история из того, чем я занимаюсь прямо сейчас. Того, что вы называете "конфигом", по объему больше, чем программного кода, и меняется оно интенсивнее.
Есть одна система многолетней эксплуатации, вы предлагаете другую. Что из этого вытекает? (Оставлю это Вам на размышление.)
"жизненного цикла" эксплуатации системы
Да ежедневно и ежечасно только и вносят изменения в конфиги из "нехватки" ресурсов.
Подражая Вам могу изречь следующее — у Вас плохая система, которая требует каждый раз изменения всего конфига. Теперь понятно, почему Вы постоянно боретесь с "ветряной мельницей"
Есть одна система многолетней эксплуатации, вы предлагаете другую. Что из этого вытекает?
Что у существующей есть видимые мне недостатки.
"жизненного цикла" эксплуатации системы
В таком случае, это утверждение в общем случае неверно.
Да ежедневно и ежечасно только и вносят изменения в конфиги из "нехватки" ресурсов.
Вы про эластичное масштабирование не слышали?
у Вас плохая система, которая требует каждый раз изменения всего конфига
Вы ничего не знаете про мою систему (что видно из ошибочного суждения "требует каждый раз изменения всего конфига"), поэтому ваше суждение необосновано.
Что у существующей есть видимые мне недостатки.
Это ложное утверждение.
В таком случае, это утверждение в общем случае неверно.
Это ложное утверждение.
Вы ничего не знаете про мою систему (что видно из ошибочного суждения "требует каждый раз изменения всего конфига"), поэтому ваше суждение необосновано.
Про то, что Вы написали при обсуждении, у меня сложилось впечатление, что ваша работа "носить воду в ступе".
Это ложное утверждение.
А теперь докажите это высказывание.
Про то, что Вы написали при обсуждении, у меня сложилось впечатление, что ваша работа "носить воду в ступе".
… ошибочное.
Извините, заниматься ежедневной работой изменения множества конфигураций, часть из которой полностью изменяется — робота не создающая полезного продукта.
Это все равно, что художник, который каждый свой день начинает писать одну и ту же картину заново.
Дискуссия на эту тему закрыта.
Извините, заниматься ежедневной работой изменения множества конфигураций, часть из которой полностью изменяется — робота не создающая полезного продукта.
А заниматься ежедневной работой изменения множества кода, часть из которого полностью изменяется — это работа, создающая полезный продукт?
Это все равно, что художник, который каждый свой день начинает писать одну и ту же картину заново.
Это называется "эскизы".
Еще раз — речь идет о конфигурациях системы, а не ее исходных кодах. Если втащили конфигурации в исходные коды — это отвратительное решение
Носите "воду в ступе" и далее. Всего хорошего. Дискуссия закрыта!
Еще раз — речь идет о конфигурациях системы, а не ее исходных кодах.
Почему ежедневное изменение одного текстового файла — это полезная работа, а другого — нет? На основании какого формального критерия вы проводите это разделение?
Операция изменения конфигурации узла — разовая операция. Она может потребоваться раз в месяц, раз в полгода, раз в год или вообще никогда не потребуется ее выполнять.
Вы занимаетесь ежедневным изменением конфигурации, как я понимаю, в следствии изменения кода — это глупость! И еще утверждаете, что это верх совершенства.
Операция изменения конфигурации узла — разовая операция. Она может потребоваться раз в месяц, раз в полгода, раз в год или вообще никогда не потребуется ее выполнять.
Операция изменения кода — разовая операция. Она может потребоваться раз в месяц, раз в полгода или вообще никогда не потребуется ее выполнять.
И еще утверждаете, что это верх совершенства.
Нет, не утверждаю (в противном случае вы легко можете найти цитату, где я это утверждаю, не правда ли?)
Но я задал вам вопрос:
почему ежедневное изменение одного текстового файла — это полезная работа, а другого — нет? На основании какого формального критерия вы проводите это разделение?
И вы снова на него не ответили.
Не пишите глупости.
Я их и не пишу, в общем-то (обратное тоже было бы несложно продемонстрировать). Может быть, если ваша же возвращенная вам фраза кажется вам глупостью — что-то не так с вашей фразой?
Вы откровенно занимаетесь троллингом. Не надо.
Отнюдь. Я задаю вопросы, цель которых — продемонстрировать мою точку зрения (на правильный процесс управления конфигурацией и развертыванием, и, как следствие, на архитектуру приложения). А вы от них уходите (вероятно, потому что у вас нет на них удобного вам ответа, но это, конечно, мое допущение).
Вы решаете свою частную задачу, возможно думаете, что решаете ее правильно. Ну и решайте ее как Вам угодно.
Ну так и вы в процессе написания своего фреймворка решали свою частную задачу, однако почему-то решили поделиться своим фреймворком с общественностью. Не вижу причин, почему я не могу поделиться с общественностью своими взглядами на архитектурные принципы, заложенные в ваш фреймворк, и их применимость для задач, о которых я что-то знаю.
Простой тест, кстати.
Это код или конфигурация? (только сразу объясните, почему)
{
"StartAt": "select-task",
"States": {
"select-task": {
"Type": "Choice",
"Choices": [
{
"Variable": "$.startAt",
"StringEquals": "describe-endpoint",
"Next": "describe-endpoint"
},
{
"Variable": "$.startAt",
"StringEquals": "deploy-model",
"Next": "deploy-model"
}
],
"Default": "train"
},
"train": {
"Type": "Task",
"Resource": "arn:aws:states:::sagemaker:createTrainingJob.sync",
"Parameters": {
"TrainingJobName.$": "$.inputs.TrainingJob.TrainingJobName",
"Tags.$": "$.inputs.Tags",
"AlgorithmSpecification.$": "$.inputs.TrainingJob.AlgorithmSpecification",
"RoleArn.$": "$.inputs.TrainingJob.RoleArn",
"ResourceConfig.$": "$.inputs.TrainingJob.ResourceConfig",
"HyperParameters.$": "$.inputs.TrainingJob.HyperParameters",
"StoppingCondition.$": "$.inputs.TrainingJob.StoppingCondition",
"InputDataConfig.$": "$.inputs.TrainingJob.InputDataConfig",
"OutputDataConfig.$": "$.inputs.TrainingJob.OutputDataConfig"
},
"ResultPath": "$.outputs.TrainingJob",
"Next": "deploy-model"
},
"deploy-model": {
"Type": "Task",
"Parameters": {
"Model": {
"ModelName.$": "$.inputs.Model.ModelName",
"Tags.$": "$.inputs.Tags",
"ExecutionRoleArn.$": "$.inputs.Model.ExecutionRoleArn",
"PrimaryContainer": {
"ModelDataUrl.$": "$.outputs.TrainingJob.ModelArtifacts.S3ModelArtifacts",
"Environment.$": "$.inputs.Model.Environment",
"Image.$": "$.inputs.Model.Image"
}
},
"EndpointConfig": {
"EndpointConfigName.$": "$.inputs.EndpointConfig.EndpointConfigName",
"Tags.$": "$.inputs.Tags",
"InitialInstanceCount.$": "$.inputs.EndpointConfig.InitialInstanceCount",
"InstanceType.$": "$.inputs.EndpointConfig.InstanceType"
},
"Endpoint": {
"EndpointName.$": "$.inputs.Endpoint.EndpointName",
"Tags.$": "$.inputs.Tags"
}
},
"ResultPath": "$.outputs.Deployment",
"Next": "describe-endpoint"
},
"describe-endpoint": {
"Type": "Task",
"Parameters": {
"EndpointName.$": "$.outputs.Deployment.Endpoint.EndpointName"
},
"ResultPath": "$.Endpoint",
"Next": "check-endpoint-status"
},
"check-endpoint-status": {
"Type": "Choice",
"Choices": [
{
"Variable": "$.Endpoint.EndpointStatus",
"StringEquals": "InService",
"Next": "endpoint-deployed"
},
{
"Or": [
{
"Variable": "$.Endpoint.EndpointStatus",
"StringEquals": "Creating"
},
{
"Variable": "$.Endpoint.EndpointStatus",
"StringEquals": "Updating"
}
],
"Next": "wait-check"
}
],
"Default": "fail"
},
"wait-check": {
"Type": "Wait",
"Seconds": 60,
"Next": "describe-endpoint"
},
"endpoint-deployed": {
"Type": "Succeed"
},
"fail": {
"Type": "Fail"
}
}
}это некоторый аналог файла pom.xml, используемого maven для сборки проекта. В конфигурации эксплуатируемой системы ни то ни другое не имеет какого либо отношения. Путаете кислое с пресным.
это некоторый аналог файла pom.xml, используемого maven для сборки проекта.
Нет. Ну то есть вообще нет, ни в каком месте. Этот пример не имеет никакого отношения к сборке, и используется в ходе штатной эксплуатации одной из разрабатываемых мной систем.
Так это код или конфигурация?
И что, ваша работа и заключается в постоянном и ежедневном изменении этого файла?
Не ежедневном, а тогда, когда меняется соответствующий процесс. Сейчас вот AWS выкатили multi-model hosting — будем править соответствующим образом.
Но вы так и не ответили на вопрос: это код или конфигурация?
не вижу ответа на мой вопрос. Вопрос напомнить?
Напомните.
не проблема
И что, ваша работа и заключается в постоянном и ежедневном изменении этого файла?
Нет, моя работа не заключается в постоянном и ежедневном изменении этого файла.
Ваша очередь: это код или конфигурация?
напишите статью
Ээээ… нет.
Если у вас нет ответа на этот вопрос, мне придется считать, что ваше разделение между кодом и конфигурацией — произвольно (проще говоря, "как мне хочется"), а, следовательно, никакой формальной логики за вашими построениями "конфигурацию надо делать вот так, а не так как код" — просто нет.
Ваше решение осуждать бессмысленно, оно здесь не опубликовано. Опубликуйте, по обсуждаем.
А я не предлагаю обсуждать мое решение, я задаю конкретный вопрос к вашей методологии работы с кодом и конфигурацией: такой файл надо считать кодом или конфигурацией?
… потому что это вы утверждаете, что изменение конфигурации не является изменением ПО. Вот мне и интересно: изменение этого файла — это изменение ПО, или нет?
Хорошо. Тоже конкретный встречный вопрос. Облегчу даже Вам задачу, подскажу, пример из фрагмента кода статьи
/**
* Определение поля для хранения экземпляра адаптера
*/
private DemoAdapter info;Это про инициализированная переменная или нет?
Понятия не имею, я не настолько хорошо знаком с терминологией Java.
Мне продублировать ваш ответ на ваш вопрос?
Откуда ж я знаю, подходит этот ответ к вашей ситуации, или нет?
Ваш ответ на мой вопрос отлично отвечает на ваш вопрос. Дублировать этот ответ, как я понимаю, не надо.
Ага, то есть вы говорите, что вы понятия не имеете, является мой пример кодом или конфигурацией, и вы не настолько знакомы с терминологией Java. Окей, так и запишем (это хорошо сочетается с тем, как вы сначала уверенно отписались, что "это некоторый аналог файла pom.xml").
Отойдем на шаг дальше. Вот у меня есть описание некоего рабочего процесса (workflow), которое никогда не при каких условиях не может быть поправлено конечным пользователем системы. От чего зависит, считать это описание кодом или конфигурацией?
Очень не хватает тут смайликов.
Статью в студию.
Повторюсь, смысла в статье нет, мы с простыми вопросами разобраться не можем.
Вы задаете вопрос, образно, что в черном ящике.
Мое видение описано в статье, где ваше?
Вы задаете вопрос, образно, что в черном ящике.
Ну так если вам не хватает информации для ответа на вопрос — вы спросите, я отвечу.
Мое видение описано в статье, где ваше?
В этой цепочке комментариев.
И, кстати, ваше видение того, что считать кодом, а что — конфигурацией, и, что важнее, почему, в статье не описано.
Уже десть раз попросил, статью в студию
"статья в студию" — это не вопрос. Я же не понимаю, чего вам не хватает для ответа.
Хорош, дискуссия уже давно потеряла какой либо конструктивный характер.
Окей, в полном соответствии с логикой выше придется признать: ваше разделение между кодом и конфигурацией — произвольно (проще говоря, "как мне хочется"), а, следовательно, никакой формальной логики за вашими построениями "конфигурацию надо делать вот так, а не так как код" — просто нет. Как следствие, утверждение "изменение конфигурации не явлется изменением ПО" — необосновано. Как следствие, утверждения, что изменения конфигурации менее рискованны, чем изменения в коде — тоже необоснованы.
Ура, что и требовалось доказать.
в статье все расписано, читайте и найдете ответы на ваши вопросы.
Нет, не расписано. Там нет ответа на вопрос, почему изменение конфигурации не является изменением ПО.
(если есть, вы легко можете его процитировать)
Программный код, в общем случае, не привязан к предметной области и среде выполнения. В разных средах выполнения один и тот же программный код может использовать разные конфигурации. Программный код в "чистом виде" переносим из одной среды выполнения в другую.
Конфигурация одной среды выполнения может быть не приемлема для этого же программного кода в другой среде выполнения. Конфигурация не переносима из среды в среду.
Поэтому программный код должен быть отделен от конфигурации приложения. Если программный код смешан с конфигурацией он теряет переносимость.
Программный код, в общем случае, не привязан к предметной области
То есть как это? Я бы понял "может быть не привязан", но часто привязан же.
среде выполнения
То есть любой код, который ожидает конкретную БД, автоматически перестают быть программным кодом?
Программный код в "чистом виде" переносим из одной среды выполнения в другую.
Может быть, но не обязательно. Попробуйте перенести "в чистом виде" систему, написанную для веб-сервера, в мобильное приложение.
Конфигурация не переносима из среды в среду.
Это тоже не всегда так. Иногда вполне себе переносима (например, если мы говорим о конфигурации модулей приложения).
Это, собственно, на примере доступа к БД видно. Вот есть приложение, оно умеет работать с двумя СУБД — MySQL и Oracle. Во-первых, оно не переносимо в среду выполнения, где стоит MS SQL. Во-вторых, конфигурация, которая говорит "для MySQL использовать этот адаптер, а для Oracle — вон тот", прекрасно переносима между всеми средами. И поэтому ваш формальный критерий между тем, что является кодом, а что конфигурацией, здесь работает плохо.
Но, что важнее, это не все отвечает на вопрос, почему изменение конфигурации не является изменением ПО.
Я описал в общем виде.
СУБД в "коробке" программный код? Да. Привязан к предметной области? Нет.
Установили, сконфигурировали, создали таблицы предметной области — создали конфигурацию в среде выполнения. Если это все (весь сервер с установленной СУБД и БД) выдернуть и поставить, условно, из Газпрома Роскосмосу. Будет это работать? Нет. Сервер конечно включиться и СУБД запуститься. Но даже подключиться к нему будет нельзя, как минимум надо сетевой интерфейс переконфигурировать.
Но если сервер и СУБД переконфигурировать, базу снести и создать другую — создать новую конфигурацию, то будет.
Я описал в общем виде.
Ну вот как раз в общем виде это и не верно. В частных случаях, иногда — да.
СУБД в "коробке" программный код? Да. Привязан к предметной области? Нет.
На самом деле, привязан, просто ее предметная область — управление БД. Но даже если не вдаваться в эти тонкости, разработанная на заказ система управлением предприятия привязана к предметной области? Да. Программный код?
Установили, сконфигурировали, создали таблицы предметной области — создали конфигурацию в среде выполнения.
А теперь посмотрим на это с точки зрения приложения, которое с этой СУБД взаимодействует. Ему нужны таблицы, и именно такие. Для него код, создающий эти таблицы — конфигурация или код?
Но если сервер и СУБД переконфигурировать, базу снести и создать другую — создать новую конфигурацию, то будет.
В чем, в таком случае, отличие между конфигурацией и данными?
СУБД само по себе имеет какую то ценность? Нет и управлять ей нечем, если БД предметной области не будет.
Первоначально, большинство программ разрабатывается на заказ. Затем результат и требования от разных заказчиков анализируется и предметная область отделяется от программного кода. Результат предлагается другим заказчикам. Так появились ОС (Билл Гейтс первую свою ОС по заказу IBM сделал), СУБД, брокеры сообщений и много чего другого.
СУБД само по себе имеет какую то ценность?
Конечно.
Первоначально, большинство программ разрабатывается на заказ.
Прекрасно. В этом случае привязаны ли они к предметной области?
Затем результат и требования от разных заказчиков анализируется и предметная область отделяется от программного кода.
Совершенно не обязательно.
(У меня создается ощущение, что все направление domain-driven design прошло мимо вас.)
Но предположим. Чем в этом случае становится отделенная от программного кода "предметная область"?
Ну не хватает мне смайликов ...
Я высказал свою точку зрения, ваши реплики к ней это уже частности.
Ваша точка зрения — она и выше была высказана. От того, что вы ее высказали, она более аргументированной не становится, к сожалению.
Вы уже второй день постоянно задаете один и тот же не относящийся к "делу" (статье) вопрос. Все время сваливаетесь на какие частности. Хватит. Не судьба так не судьба.
Дело как раз в том, что вопрос про разделение кода и конфигурации имеет прямое отношение к вашей статье. Если из нее убрать конфигурацию — что останется-то?
Останется код, которому можно "подать" при запуске совершенно другую конфигурацию и таким образом получить совершенно другую информационную систему.
Останется код, которому можно "подать" при запуске совершенно другую конфигурацию
Вот видите, конфигурация осталась. Если ее выкинуть, это получится обычный загрузчик кода, который без конфигурации бесполезен для конечного пользователя.
(Позднее связывание, плагинные архитектуры — имя им легион.)
Вы, однако, утверждаете, что получение "другой информационной системы" путем подачи на вход загрузчика конфигурации менее рисковано, чем получение "другой информационной системы" путем подачи на вход загрузчика кода.
Почему?
Я что то пропустил? Мы уже ведем речь о загрузчике кода?
Мы ведем речь о вашем фреймворке. Который, если верить вашему описанию:
код, которому можно "подать" при запуске совершенно другую конфигурацию и таким образом получить совершенно другую информационную систему.
фактически, загрузчиком (не только, конечно) и является (занятно, кстати, как это функционально отличается от описания в посте).
И, собственно, в самом начале дискуссии было озвучено, что связывание компонентов через конфигурацию — не самая лучшая идея. Вы, однако, утверждаете, что это уменьшает риски по сравнению со связыванием компонентов через код. Почему?
Вам нужно почитать статьи о загрузчиках Java.
Динамическое связывание классов во время выполнения — да на этом построена вся идеология среды выполнения JVM.
Вам нужно почитать статьи о загрузчиках Java.
Зачем бы? Я не делал о них никаких утверждений.
Динамическое связывание классов во время выполнения — да на этом построена вся идеология среды выполнения Java.
Тем более не понятно, что нового в функциональности "можно "подать" при запуске совершенно другую конфигурацию и таким образом получить совершенно другую информационную систему".
Собственно, в каком-то широком смысле так работает любая среда выполнения. И… что?
Вы только что проиллюстрировали мой тезис, что вся ваша идея крутится вокруг конфигурации.
А теперь объясните, почему вы считаете, что ваша конфигурация приносит меньше риска, нежели:
app.ExposeSoap()и
app.ExposeRest()О каких рисках идет речь?
И что за код тут опубликован?
Статью в студию, я не телепат, чтобы по обрывкам кода догадываться, что под ним подразумевается.
О каких рисках идет речь?
О тех, о которых вы говорили выше: "Риск внести ошибку или "сломать" ИС минимальный."
И что за код тут опубликован?
Альтернативный вашему вариант "сказать" системе, что мы хотим выставлять ее сервисы как REST или как SOAP.
я не телепат, чтобы по обрывкам кода догадываться, что под ним подразумевается.
Я, знаете, тоже не телепат, чтобы понять, что будет в результате применения ваших конфигураций. Приходится верить вам на слово, что будет SOAP-сервис или REST-сервис. Вот и вам придется поверить мне на слово, что если поместить первую строку в соответствующее место определенного файла, то будет SOAP-сервис, а если туда же поместить вторую — то будет REST-сервис.
При готовой конфигурации, риск отсутствует.
Я опять что то пропустил? И мы уже перешли на обсуждение альтернатив публикаций SOAP и REST сервисов? И какое отношение ваши фрагменты кода имеют к распределенным средам?
При готовой конфигурации, риск отсутствует.
Ну так и при готовом коде риск тоже отсутствует.
И мы уже перешли на обсуждение альтернатив публикаций SOAP и REST сервисов?
Это был ваш пример, вообще-то.
И какое отношение ваши фрагменты кода имеют к распределенным средам?
Самое что ни на есть прямое. Один из способов конфигурации микросервисов.
Хорошо, говорил. Но если Вы привели мои слова, то вспомните к чему они относились? Они относились к корректировке файла конфигурации. В этих то примерах что править? Тут нет ни одного "переменного" параметра. Править нечего, следовательно внести ошибку невозможно. Если только намерено испортить конфигурационный файл.
У меня хоть есть весь исходный успешно выполняемый код на GitHub. У Вас вообще ни чего нет. Обрывки непонятно чего, непонятно откуда. Я же верю Вам на слово.
В этих то примерах что править? Тут нет ни одного "переменного" параметра.
Вот была "конфигурация" для REST. Мы теперь хотим заменить на SOAP. Что нужно править в файле конфигурации? Желательно вот прямо в виде инструкции: такой-то текст заменить на такой-то.
(это, повторюсь, ваш пример)
Кстати, в конфигурации нет кода, публикующего сервисы. Более того, и в примерах кода вы не найдете строк публикации сервисов. Это делается внутри используемых сторонних библиотек. То есть сравнивать ваш код и конфигурационные файлы просто не корректно.
Это разные конфигурации, править ни чего не нужно. Можно конечно слить оба примера и конфигурации в одно приложение, если очень хочется.
А что если я усложню задачу! Условный заказчик очень хочет RMI протокол использовать, ну или его "брата" CORBA. И в придачу на почтовые запросы отвечать.
Подробную пошаговую инструкцию опубликуете вашего примера.
Кстати, в конфигурации нет кода, публикующего сервисы.
А откуда же берутся сервисы?
То есть сравнивать ваш код и конфигурационные файлы просто не корректно.
Да нет, корректно. Мой код ведь тоже не публикует сервисы сам, за это отвечают используемые библиотеки.
Это разные конфигурации, править ни чего не нужно.
Так как же перейти из состояния REST в состояние SOAP? Или вы просто имели в виду, что это два вообще разных приложения?
Подробную пошаговую инструкцию опубликуете вашего примера.
- разработать адаптер для протокола X
- добавить адаптер в стартап:
app.ExposeX
- Изменить у REST-класса аннотации
- Добавить библиотеки реализующие спецификацию JAX-WS
… это все в конфигурации делается? Можете все-таки показать, как изменяется конфигурация, когда вы решаете перейти с предоставления REST на предоставление SOAP для одного и того же сервиса?
Для REST-сервиса меняется код класса, конфигурация не затрагивается.
Пример SOAP сервиса сделан на более ранних реализациях спецификации SOAP (API). Под более свежей спецификацией JAX-WS, думаю потребовалось бы, тоже пометь только аннотации класса.
По сути — аннотация, встроенная в код конфигурация. Что мне очень не нравиться. Из-за этого приходиться править исходный код, а не конфигурационный файл чтобы переключиться на другой протокол.
То есть получается, что нельзя просто взять и поменять REST-сервис на SOAP в конфигурации, надо трогать код?
Надо трогать зашитую в код конфигурацию. Это особенность используемых библиотек для реализации примера, а не рассмотренного мной решения.
Надо трогать зашитую в код конфигурацию.
Ну то есть вашего решения недостаточно?
Что же означал комментарий выше:
Подали эту конфигурацию и получили SOAP-сервис
Подали эту и уже REST-сервис имеем
… просто два разных приложения? Или что-то другое?
Ну то есть вашего решения недостаточно?
Что же означал комментарий выше:
Еще раз — эта фраза относится к внешнему ПО по отношению к решению, описанному в статье !!!
В комментарии выше относится к этому же внешнему ПО. В этом внешнем ПО можно использовать аннотации Java, которые по своей сути являются встроенной в код конфигурацией. Этот подход (встроенной в код конфигурации) я отвергаю.
… просто два разных приложения? Или что-то другое?
Разные конфигурации создают разные приложения разного назначения. Решение, рассмотренное в статье, позволяет создавать любое приложение, в любом сочетании из пунктов ниже:
- GUI приложение
- WEB приложение
- Кластерное приложение
- распределенное приложение
- отказоустойчивые приложения
- приложения непрерывной доспности
- фоновый процесс операционной системы
- SOAP, REST и прочие приложения
- и т.д. и т.п. (все определяется вашей фантазией, вашими требованиями и вашими желаниями)
Первое приложение (Avalanche — application framework for Java)