Так подобные вопросы возникают и сейчас, без этого решения, когда возникает вопрос интеграции между системами. Одни разработчики начинают утверждать, что json "пуп земли", другие "мы тут специально создали хранимую процедуру для третьей системы, пользуйтесь ей". В результате, разработчиков приходиться "мирить" заказчику, выбрав один из предложенных вариантов. И этот выбор не всегда оптимальный.
Любая технология имеет какие либо ограничения и, несмотря на их наличие, они же используются. Учитывая эти ограничения, можно построить систему так, что любые объекты системы можно растащить на любое число узлов. ResultSet, например, можно передать на любой узел системы, хотя он тоже привязан узлу создания экземпляра класса. Для этого достаточно создать собственный класс "обертку", реализующий этот интерфейс.
Использовать для этих целей конфигурацию приложения очень удобно и в первую очередь для эксплуатирующего подразделения! Возникло требование — отключили никого не спрашивая, никому не обращаясь. Возникло требование — подключили. Риск внести ошибку или "сломать" ИС минимальный.
"Удобство эксплуатации" для меня имеет существенно более высокий приоритет чем "удобство реализации" (удобство кодирования для программиста).
Неа, нельзя. Если в приложении заранее не заложена такая возможность — и нет, не с помощью вашего транспорта, а на уровне архитектуры, — то не получится такого счастья.
Рассмотренное решение реализует модель MVFA (Model — View — Function — Application), которая и предоставляет несколько иной взгляд на архитектуру приложения
Про архитектуру коснусь чуть позднее.
Зато какие перспективы оно открывает вашему приложению, если не Вам лично, то вашему заказчику уж точно. Запустил он ваше приложение и радуется. Но время идет, интенсивность использования приложения растет, объемы хранения данных тоже увеличиваются. И в один "прекрасный" момент приложение начинает упираться в производительность аппаратной платформы. Что делать заказчику? Покупать новое более мощное железо? А можно взять и растащить приложение на множество узлов, поменяв его конфигурацию. И снова у заказчика наступит "век счастья".
Сейчас модно говорить о виртуализации серверов, когда на одном физическом сервере запускается множество виртуальных.
Рассмотренная технология предлагает другую виртуализацию, когда информационная система запускается на множестве виртуальных или физических серверах, объединяя их аппаратные ресурсы, т.е. аппаратные ресурсы вашей системы уже ни чем не ограничены.
Это уже дело вашей фантазии как Вы реализуете эту функциональность. Например, 2 года назад, в одном из своих приложений подобным образом была отключена часть утратившей актуальность функций, находящееся в эксплуатации с 2007 года. Приложение, при старте "видит" список объектов в своей конфигурации и на основании этого списка строит пользовательский интерфейс. Отключение одного из элементов в конфигурации привело и к изменению в пользовательском интерфейсе, все связанные с этим элементом пункты меню "чудесным образом" пропали.
А зачем? При вносе изменений прямо в ПО есть риск внести какую то ошибку? Есть. Для изменения ПО необходимо наличие IDE? Необходимо. И т.п. и т.д. Этот процесс гораздо сложнее и "дороже".
Напомню, предложенная технология стирает различия в вызовах локального и удаленного кода. Для этой технологии не имеет значения место исполнения функции. А уж по реализацию шедуллера я вообще молчу. Если лень самому "изобретать", то можно воспользоваться готовым из большого множества OpenSource.
Диагностика все же больше зависит не от средств проверки кода, а от информативности и однозначности сообщений в файлах журналов системы, которые позволяют быстро устанавливать причину ошибки. Мне нравиться информативность и однозначность сообщений в большинства СУБД. В своих системах предпочитаю реализовывать подобный подход.
Функция может быть заказана любому разработчику или быть реализована программистами заказчика, т.е. небольшие изменения можно вносить в рамках текущего бюджета.
"Ручной ввод" он же куда сохраняет результаты свой работы, из конфигурации исключаем функцию "ручного ввода" и включаем функцию "загрузки с сайта" с сохранением "в то же место".
Согласитесь, что процесс изменения конфигурации все же более простоя задача по сравнению изменение программного кода, которое в том числе так же может потребовать и изменения конфигурации.
Пишется новая "функция" и меняется конфигурация системы. Эксплуатируемое ПО не изменяется и, в случае какой либо "неудачи" новой функции, легко может быть возращено в эксплуатацию.
При использовании RMI код "привязан" к только к протоколу RMI. В предложенном решении код изолирован от протокола, что позволяет использовать практически любой известный протокол. Эксплуатирующая организация может изменить его в любой момент по своим собственным соображениям. Заметьте, выбор протокола ни как не сказывается на вашем коде. И в этом решении RMI не переизобретен, а, по сути, усовершенствован.
Второе, предложенное решение как раз и раскладывает все "по полочкам". И это называется "модифицируемостью" — простотой модификации промышленной системы. Каждый программный слой выполняет только свою функцию. Бизнес логика постоянно меняется. Предложенное решение позволяет IT подразделению заказчика более гибко реагировать на требование бизнеса, а не ждать "у моря погоды", когда будут выделен бюджет на модификацию ПО для удовлетворения "неожиданно" возникших новых требований или изыскивать другие "обходные" решения, например: — "Вы нам сделаете сейчас, а оплатим мы вам из бюджета следующего года".
Рассмотренная технология позволяет создавать приложения высокой производительности, хотя бы тем, что можно добавлять по своему усмотрению неограниченное число узлов. На GitHub (ссылка в конце статьи) опубликован простой пример каскадной функции, которая "распределяет" нагрузку между множеством узлов, с которых вызывается метод getInfo().
В рамках простого приложения этот хаб относится к фремворку, который позволяет это делать. В отличии от того же REST, SOAP и прочих технологий здесь нет «лишних» преобразований при передаче данных между узлами системы, что при всех прочих равных возможностей будет показывать пусть небольшую, но все же большую производительность.
Предложенное решение значительно упрощает этот процесс, предоставляя для использования готовую функциональность.
Изменение конфигурации — это не изменение ПО. Конфигурация — переменная составляющая. ПО — неизменная составляющая.
Так подобные вопросы возникают и сейчас, без этого решения, когда возникает вопрос интеграции между системами. Одни разработчики начинают утверждать, что json "пуп земли", другие "мы тут специально создали хранимую процедуру для третьей системы, пользуйтесь ей". В результате, разработчиков приходиться "мирить" заказчику, выбрав один из предложенных вариантов. И этот выбор не всегда оптимальный.
Минимальный по сравнению с внесением изменений в ПО
Любая технология имеет какие либо ограничения и, несмотря на их наличие, они же используются. Учитывая эти ограничения, можно построить систему так, что любые объекты системы можно растащить на любое число узлов. ResultSet, например, можно передать на любой узел системы, хотя он тоже привязан узлу создания экземпляра класса. Для этого достаточно создать собственный класс "обертку", реализующий этот интерфейс.
Сразу обе. Задачи сходны между собой.
Использовать для этих целей конфигурацию приложения очень удобно и в первую очередь для эксплуатирующего подразделения! Возникло требование — отключили никого не спрашивая, никому не обращаясь. Возникло требование — подключили. Риск внести ошибку или "сломать" ИС минимальный.
"Удобство эксплуатации" для меня имеет существенно более высокий приоритет чем "удобство реализации" (удобство кодирования для программиста).
Если у кого то не получилось, из этого не следуют, что это нельзя реализовать.
Рассмотренное решение реализует модель MVFA (Model — View — Function — Application), которая и предоставляет несколько иной взгляд на архитектуру приложения
Про архитектуру коснусь чуть позднее.
Зато какие перспективы оно открывает вашему приложению, если не Вам лично, то вашему заказчику уж точно. Запустил он ваше приложение и радуется. Но время идет, интенсивность использования приложения растет, объемы хранения данных тоже увеличиваются. И в один "прекрасный" момент приложение начинает упираться в производительность аппаратной платформы. Что делать заказчику? Покупать новое более мощное железо? А можно взять и растащить приложение на множество узлов, поменяв его конфигурацию. И снова у заказчика наступит "век счастья".
Сейчас модно говорить о виртуализации серверов, когда на одном физическом сервере запускается множество виртуальных.
Рассмотренная технология предлагает другую виртуализацию, когда информационная система запускается на множестве виртуальных или физических серверах, объединяя их аппаратные ресурсы, т.е. аппаратные ресурсы вашей системы уже ни чем не ограничены.
Это уже дело вашей фантазии как Вы реализуете эту функциональность. Например, 2 года назад, в одном из своих приложений подобным образом была отключена часть утратившей актуальность функций, находящееся в эксплуатации с 2007 года. Приложение, при старте "видит" список объектов в своей конфигурации и на основании этого списка строит пользовательский интерфейс. Отключение одного из элементов в конфигурации привело и к изменению в пользовательском интерфейсе, все связанные с этим элементом пункты меню "чудесным образом" пропали.
А зачем? При вносе изменений прямо в ПО есть риск внести какую то ошибку? Есть. Для изменения ПО необходимо наличие IDE? Необходимо. И т.п. и т.д. Этот процесс гораздо сложнее и "дороже".
Напомню, предложенная технология стирает различия в вызовах локального и удаленного кода. Для этой технологии не имеет значения место исполнения функции. А уж по реализацию шедуллера я вообще молчу. Если лень самому "изобретать", то можно воспользоваться готовым из большого множества OpenSource.
Диагностика все же больше зависит не от средств проверки кода, а от информативности и однозначности сообщений в файлах журналов системы, которые позволяют быстро устанавливать причину ошибки. Мне нравиться информативность и однозначность сообщений в большинства СУБД. В своих системах предпочитаю реализовывать подобный подход.
Функция может быть заказана любому разработчику или быть реализована программистами заказчика, т.е. небольшие изменения можно вносить в рамках текущего бюджета.
"Ручной ввод" он же куда сохраняет результаты свой работы, из конфигурации исключаем функцию "ручного ввода" и включаем функцию "загрузки с сайта" с сохранением "в то же место".
Согласитесь, что процесс изменения конфигурации все же более простоя задача по сравнению изменение программного кода, которое в том числе так же может потребовать и изменения конфигурации.
Пишется новая "функция" и меняется конфигурация системы. Эксплуатируемое ПО не изменяется и, в случае какой либо "неудачи" новой функции, легко может быть возращено в эксплуатацию.
При использовании RMI код "привязан" к только к протоколу RMI. В предложенном решении код изолирован от протокола, что позволяет использовать практически любой известный протокол. Эксплуатирующая организация может изменить его в любой момент по своим собственным соображениям. Заметьте, выбор протокола ни как не сказывается на вашем коде. И в этом решении RMI не переизобретен, а, по сути, усовершенствован.
Второе, предложенное решение как раз и раскладывает все "по полочкам". И это называется "модифицируемостью" — простотой модификации промышленной системы. Каждый программный слой выполняет только свою функцию. Бизнес логика постоянно меняется. Предложенное решение позволяет IT подразделению заказчика более гибко реагировать на требование бизнеса, а не ждать "у моря погоды", когда будут выделен бюджет на модификацию ПО для удовлетворения "неожиданно" возникших новых требований или изыскивать другие "обходные" решения, например: — "Вы нам сделаете сейчас, а оплатим мы вам из бюджета следующего года".
Постараюсь раскрыть эту тему в следующей статье.
Рассмотренная технология позволяет создавать приложения высокой производительности, хотя бы тем, что можно добавлять по своему усмотрению неограниченное число узлов. На GitHub (ссылка в конце статьи) опубликован простой пример каскадной функции, которая "распределяет" нагрузку между множеством узлов, с которых вызывается метод getInfo().
DemoCascadeFunction