Чем больше добавите, тем меньше надежность — плодите точки отказа, усложняете диагностику отказа, не управляете всеми элементами системы, балансировщики не все данные через себя способы пропустить.
В предложенном решении — система управляема, состояние всех каналов контролируется и если канал "не исправен", то запрос сразу перенаправляется на другой узел или, если нет резервных узлов, ошибка сразу возвращается без ожиданий истечения разных TCP соединений. Это не просаживает производительности системы для пользователей при проблемах в ее распределенной среде.
В моем примере нет упоминаний о REST и SOAP сервисах. Мои ссылки на эти сервисы были опубликованы в ответ на ваши вопросы. Почему то упорно хотели сравнивать описанное в статье решение с этими сервисами.
Определения VIEW и MODEL идентичны определениям MVC
FUNCTION — выдает команды манипулирования моделью данных и получает результат этого манипулирования или изменяет состояние элементов системы.
APPLICATION — интерпретирует действия пользователя или по изменениям состояния элементов системы и оповещает функции о необходимости изменения модели или состояния системы.
Элемент APPLICATION может манипулировать множеством элементов FUNCTION.
Элемент APPLICATION может выступать в роли FUNCTION для других элементов FUNCTION, таким образом можно создавать сложную иерархическую структуры объектов.
Вы зациклились на вопросах REST и SOAP сервисов, которые не имеют никакого отношения описанному в статье решению, но могут быть использованы для реализации функционала приложения с использованием этого решения.
Вызов по HTTP удаленного объекта — на удаленном узле должен "присутствовать" коннектор c именем http-connector, в котором опубликована функция info. Локальная функция не нужна.
Опять вы путаете "кислое с пресным". Не можете Вы раскладывать все "по полочкам". Валите все "в кучу" и потом не понимаете, что с этой "кучей" делать. Еще не хватает вашего заявления для полной картины, что рассмотренное в статье решение все же не позволяет лететь на Марс.
Ну то есть вашего решения недостаточно?
Что же означал комментарий выше:
Еще раз — эта фраза относится к внешнему ПО по отношению к решению, описанному в статье !!!
В комментарии выше относится к этому же внешнему ПО. В этом внешнем ПО можно использовать аннотации Java, которые по своей сути являются встроенной в код конфигурацией. Этот подход (встроенной в код конфигурации) я отвергаю.
… просто два разных приложения? Или что-то другое?
Разные конфигурации создают разные приложения разного назначения. Решение, рассмотренное в статье, позволяет создавать любое приложение, в любом сочетании из пунктов ниже:
GUI приложение
WEB приложение
Кластерное приложение
распределенное приложение
отказоустойчивые приложения
приложения непрерывной доспности
фоновый процесс операционной системы
SOAP, REST и прочие приложения
и т.д. и т.п. (все определяется вашей фантазией, вашими требованиями и вашими желаниями)
Для REST-сервиса меняется код класса, конфигурация не затрагивается.
Пример SOAP сервиса сделан на более ранних реализациях спецификации SOAP (API). Под более свежей спецификацией JAX-WS, думаю потребовалось бы, тоже пометь только аннотации класса.
По сути — аннотация, встроенная в код конфигурация. Что мне очень не нравиться. Из-за этого приходиться править исходный код, а не конфигурационный файл чтобы переключиться на другой протокол.
чем балансировать балансировщики — это тоже точка отказа
все узлы ваши — предложенное решение предназначено для создания распределенных или кластерных приложений
Перед вашими глазами
Чем больше добавите, тем меньше надежность — плодите точки отказа, усложняете диагностику отказа, не управляете всеми элементами системы, балансировщики не все данные через себя способы пропустить.
В предложенном решении — система управляема, состояние всех каналов контролируется и если канал "не исправен", то запрос сразу перенаправляется на другой узел или, если нет резервных узлов, ошибка сразу возвращается без ожиданий истечения разных TCP соединений. Это не просаживает производительности системы для пользователей при проблемах в ее распределенной среде.
а балансировщик кто будет от сбоев "балансировать"?
А в распределенных одноранговых системах сколько вам балансировщиков понадобиться?
Так где связь то между функций DemoFunction и HttpAdapter
В моем примере нет упоминаний о REST и SOAP сервисах. Мои ссылки на эти сервисы были опубликованы в ответ на ваши вопросы. Почему то упорно хотели сравнивать описанное в статье решение с этими сервисами.
Приведите код "работоспособной" функции и код который ее использует хотя бы.
Ваше решение (на вскидку):
Определения VIEW и MODEL идентичны определениям MVC
FUNCTION — выдает команды манипулирования моделью данных и получает результат этого манипулирования или изменяет состояние элементов системы.
APPLICATION — интерпретирует действия пользователя или по изменениям состояния элементов системы и оповещает функции о необходимости изменения модели или состояния системы.
Элемент APPLICATION может манипулировать множеством элементов FUNCTION.
Элемент APPLICATION может выступать в роли FUNCTION для других элементов FUNCTION, таким образом можно создавать сложную иерархическую структуры объектов.
Вы зациклились на вопросах REST и SOAP сервисов, которые не имеют никакого отношения описанному в статье решению, но могут быть использованы для реализации функционала приложения с использованием этого решения.
Да. Пример же рассмотрен (в общем виде) в статье.
Но можно и продублировать
Начальная конфигурация вызова локальной функции
Вызов по HTTP удаленного объекта — на удаленном узле должен "присутствовать" коннектор c именем http-connector, в котором опубликована функция info. Локальная функция не нужна.
Отделите "кислое" от "пресного" и логика будет у вас перед глазами.
Демонстрация проекта
Ролик готовился для выступления на конференции, звука нет. Комментировался во время доклада.
Опять вы путаете "кислое с пресным". Не можете Вы раскладывать все "по полочкам". Валите все "в кучу" и потом не понимаете, что с этой "кучей" делать. Еще не хватает вашего заявления для полной картины, что рассмотренное в статье решение все же не позволяет лететь на Марс.
Пример вызовов по различным протоколам с использованием решения описанном в статье
Локальный вызов
info.getInfo();
Вызов по RMI
info.getInfo();
Вызов по HTTP
info.getInfo();
и т.д. и т.п.
Попробуйте найти отличие.
В данном случае, мы с вами в равном положении, я не могу взять ваши две строчки и проверить работоспособность вашего примера.
Еще раз — эта фраза относится к внешнему ПО по отношению к решению, описанному в статье !!!
В комментарии выше относится к этому же внешнему ПО. В этом внешнем ПО можно использовать аннотации Java, которые по своей сути являются встроенной в код конфигурацией. Этот подход (встроенной в код конфигурации) я отвергаю.
Разные конфигурации создают разные приложения разного назначения. Решение, рассмотренное в статье, позволяет создавать любое приложение, в любом сочетании из пунктов ниже:
В публиковать библиотеки в репозиторий дурной тон
Надо трогать зашитую в код конфигурацию. Это особенность используемых библиотек для реализации примера, а не рассмотренного мной решения.
Все библиотеки в открытом доступе, кроме библиотек avalanche*.jar.
Интересует?
Для REST-сервиса меняется код класса, конфигурация не затрагивается.
Пример SOAP сервиса сделан на более ранних реализациях спецификации SOAP (API). Под более свежей спецификацией JAX-WS, думаю потребовалось бы, тоже пометь только аннотации класса.
По сути — аннотация, встроенная в код конфигурация. Что мне очень не нравиться. Из-за этого приходиться править исходный код, а не конфигурационный файл чтобы переключиться на другой протокол.