26.11.2019 08:41
vl65 16 693 Источник

Модель приложения (Avalanche — application framework for Java)


«Avalanche — application framework for Java» — реализация технологии стирающей различия
между вызовами локального и удаленного кода. Отказоустойчивость, масштабируемость,
модифицируемость, непрерывная доступность идут в комплекте приятными бонусами.

Рассмотренная в этой статье модель приложения родилась на основании собственного опыта реализации и эксплуатации различных интеграционных взаимодействий информационных систем (ИС) и прежде всего была направлена на сокращение использования различных ресурсов (финансовых, трудовых, временных и т.д.) при реализации этих интеграционных решений.

В большинстве предприятий эксплуатируются множество различных систем, автоматизирующих отдельные технологические процессы или работу отдельных структурных подразделений или отделов. В следствии чего возникает потребность организации информационного обмена между этими системами или с информационными системами смежных организаций с целью сокращения эксплуатационных расходов, исключения введения дублируемых данных и рассогласования данных в различных системах (например НСИ), уменьшения влияния человеческого фактора, сокращения временных затрат на обмен информацией.

Потребность интеграции возникает не только в специальном программном обеспечении собственной или заказной разработки, но и в «коробочных» решениях. Стоимость реализации может превосходить ожидаемое сокращение эксплуатационных издержек.

Существующие способы решения вопросов интеграции IT систем:

  • Файловый обмен данными
  • Обмен сообщениями (является разновидностью файлового обмена)
  • Интеграция на уровне модели данных, например, создания специальных объектов базы данных или хранимых процедур
  • С использованием RCP (remote call procedure) технологий, например, CORBA, RMI, SOAP, DCOM и т.д.

У всех этих способов реализации интеграционных решений есть одни и те же недостатки: трудоемкость реализации и модификации, низкая повторность использования, необходимость решения вопросов отказоустойчивости, невозможность работы в режиме разноверсионности в процессе установки изменений, трудоемкость эксплуатации и поддержание эксплуатационной документации в актуальном состоянии.

Результатом поиска альтернативы существующим решениям была сформулирована идея преобразования модели MVC (MODEL — VIEW — CONTROLLER) в модель MVFA (MODEL — VIEW — FUNCTION — APPLICATION), разбив CONTROLLER на два программных слоя FUNCTION и APPLICATION между которыми может быть размещена сеть передачи данных (СПД).



Разбиение на функции внутри контролера присутствует в той или иной степени во всех современных IT-системах, особенно, если разработка выполнена с использованием объектно-ориентированных языков программирования. А выделение этих функций в отдельный программный слой решает задачу их повторного использования другими IT-системами.

Выделение в отдельный программный слой объектов «приложение» стандартизирует обращение не только к собственным функциям, но и функциям других систем, что стирает все различия в вызовах «своих» и «чужих» функций.

Для реализации модели MVFA предложена следующая программная модель:

  1. Функция (Function), любой объект имеющий методы реализации какой либо функциональности ;
  2. Адаптер (Adapter), декларируемый объект не имеющий реализации. Этот объект обеспечивает связь объектов «приложение» с локальными или удаленными функциями. Для доступа к удаленным функциям используется объект «интерфейс»;
  3. Коннектор (Connector), обеспечивает доступ к локальным функциям удаленных объектов с помощью объектов «публикация»;
  4. Публикация (Publish), публикует локальную функцию в коннекторе;
  5. Интерфейс (Interface), обеспечивает обращение адаптеров к удаленным функциям;
  6. Приложение (Application), выполняет преобразование данных между представлением и функцией/функциями, также может выступать в роли «функции» для других объектов «приложения».



Пара «интерфейс» — «коннектор» образуют канал передачи данных по какому либо протоколу между различными системами или различными узлами одной системы. Реализованный канал должен иметь способность пропускать требуемые объемы данных.

Существуют специализированные реализации «интерфейсов», не имеющих парных элементов «коннектор», например — интерфейс высокой доступности, который позволяет создавать отказоустойчивые информационные системы. Основное назначение интерфейса высокой доступности — это перенаправление нагрузки на дублирующие узлы при планов или вне плановом отключении одного из узлов системы.

Рассмотренная модель MVFA реализована в программном продукте «Avalanche — application framework for Java», который относится к категории middle ware и предназначен для создания программных кластеров или отказоустойчивых информационных систем высокой доступности.

Конечно, как и у любой технологии, «Avalanche — application framework for Java» имеет некоторые ограничения:

  1. Любые объекты (типы), декларируемые в адаптерах (входные и возвращаемые параметры), могут быть переданы по сети, а следовательно эти объекты должны реализовывать интерфейс java.lang.Serializable. Локальные объекты вызываются напрямую, без использования операций чтения и записи в поток.
  2. Не все объекты могут быть переданы по сети. Например, объекты состояние или работоспособность которых зависят от конфигурации узла системы, где они были созданы. К таким объектам можно отнести объекты, реализующие спецификацию javax.sql.DataSource
  3. Дублирующие узлы системы должны размещаться на разных аппаратных средствах.
  4. Дублирующие узлы системы не должны выключаться (обслуживаться) одновременно.

Пример простого приложения описан в статье — Первое приложение (Avalanche — application framework for Java)

Комментарии (16)


  1. lair
    26.11.2019 11:57
    #20931876

    Рассмотренная в этой статье модель приложения родилась на основании собственного опыта реализации и эксплуатации различных интеграционных взаимодействий информационных систем (ИС) и прежде всего была направлена на сокращение использования различных ресурсов (финансовых, трудовых, временных и т.д.) при реализации этих интеграционных решений.
    [...]
    Существующие способы решения вопросов интеграции IT систем:
    [...]
    Результатом поиска альтернативы существующим решениям была сформулирована идея...

    Подождите-подождите. Давайте прямо сразу определимся: вы решаете задачу разработки одной системы, или задачу интеграции нескольких различных систем?


    1. vl65 Автор
      26.11.2019 14:06
      #20932546

      Сразу обе. Задачи сходны между собой.


      1. lair
        26.11.2019 14:18
        #20932590

        И вас не капли не смущает, что в случае интеграции различных систем у вас намного меньше контроля над платформой, на которой разработаны интегрируемые системы, и даже над протоколом интеграции?


        Проще говоря, вам могут поставить задачу на интеграцию с готовой системой, которая умеет только json-over-HTTP. Согласитесь, это гигантское различие по сравнению с "я могу написать свою систему на любой удобной мне платформе и соединить любым удобным мне образом"?


        1. vl65 Автор
          26.11.2019 14:27
          #20932648

          Так подобные вопросы возникают и сейчас, без этого решения, когда возникает вопрос интеграции между системами. Одни разработчики начинают утверждать, что json "пуп земли", другие "мы тут специально создали хранимую процедуру для третьей системы, пользуйтесь ей". В результате, разработчиков приходиться "мирить" заказчику, выбрав один из предложенных вариантов. И этот выбор не всегда оптимальный.


          1. lair
            26.11.2019 14:36
            #20932704

            Так подобные вопросы возникают и сейчас, без этого решения

            А это не важно. Важно, что задача интеграции нескольких систем сильно отличаются от задачи написания одной системы, поэтому давайте вы определитесь, о какой задаче вы говорите.


            1. vl65 Автор
              26.11.2019 14:44
              #20932760

              Занимаюсь сразу обеими задачами, они одинаковы. Одна задача, является частным случаем другой.


              1. lair
                26.11.2019 14:51
                #20932810

                Your words, not mine.


                Ну давайте начнем с простого вопроса. Вот надо решить типовую задачу интеграции: есть существующий интернет-магазин, на PHP, он должен отсылать каждый новый заказ в разрабатываемую вами бэк-офис-систему, когда заказ обработан, она должна уведомлять интернет-магазин. Интернет магазин умеет слать уведомления на заданный HTTP-адрес в виде JSON, уведомления от других систем принимает по фиксированному адресу тоже в виде JSON. Схема JSON фиксирована интернет-магазином.


                Как ваша модель приложения поможет решить эту задачу, и в чем выигрыш по сравнению с "обычной" реализацией (естественно, под обычной реализацией мы пониманием нормально спроектированную систему, удовлетворяющую DIP)?


                1. vl65 Автор
                  26.11.2019 15:08
                  #20932910

                  Ваш пример не удачный, PHP мало что умеет и "предложить" ему что вне его рамок, думаю дело гиблое. Но и в этом случае, вариантов решений много.
                  Например, можно написать специализированный коннектор (в терминах Avalanche — application framework for Java).


                  <connector class="my.package.JSONСonnector" ...
     <publish name ... />
</connector>

                  Реализовать класс приложения


                  <application class="my.package.JSONApplication" service="true" ...
     ...
</application>

                  Вариантов много


                  1. lair
                    26.11.2019 15:15
                    #20932942

                    Ваш пример не удачный

                    Что значит — неудачный? Это реальный случай из жизни, часто встречающаяся задача в интеграции. Я же не зря спросил, какую задачу вы решаете.


                    Например, можно написать специализированный коннектор

                    Я и в случае обычного приложения могу написать специализированный интеграционный код. В чем мне польза от вашей модели?


                    1. vl65 Автор
                      26.11.2019 15:32
                      #20933062

                      "Не удачный" — не видел больших корпоративных систем на PHP. Отдельные небольшие задачи, что когда называлось АРМами — да сколько угодно. Не это не является проблемой, интегрироваться можно и вашей задачей.


                      Польза, далее реализованная интеграция доступна "везде"


                      1. lair
                        26.11.2019 15:34
                        #20933074

                        "Не удачный" — не видел больших корпоративных систем на PHP

                        А я и не говорю про корпоративные системы, я говорю про интернет-магазин. Вы про Magento не слышали?


                        Польза, далее реализованная интеграция доступна "везде"

                        Что значит "везде"? Поясните на примере.


  1. lair
    26.11.2019 15:37
    #20933092

    Раз вы решили говорить о проектировании приложения (а не только и исключительно интеграции), то у меня опять-таки есть стартовый вопрос:


    Результатом поиска альтернативы существующим решениям была сформулирована идея преобразования модели MVC (MODEL — VIEW — CONTROLLER) в модель MVFA (MODEL — VIEW — FUNCTION — APPLICATION), разбив CONTROLLER на два программных слоя FUNCTION и APPLICATION между которыми может быть размещена сеть передачи данных (СПД).

    Пожалуйста, дайте определения используемым вами в вашей модели понятиям Model, View, Function, Application и покажите типичные направления потоков данных и последовательностей вызова.


    (ну, знаете, как Фаулер делает в описании MVC… который, кстати, не является моделью построения приложений)


    1. vl65 Автор
      29.11.2019 10:12
      #20944902

      Определения VIEW и MODEL идентичны определениям MVC


      FUNCTION — выдает команды манипулирования моделью данных и получает результат этого манипулирования или изменяет состояние элементов системы.


      APPLICATION — интерпретирует действия пользователя или по изменениям состояния элементов системы и оповещает функции о необходимости изменения модели или состояния системы.


      Элемент APPLICATION может манипулировать множеством элементов FUNCTION.


      Элемент APPLICATION может выступать в роли FUNCTION для других элементов FUNCTION, таким образом можно создавать сложную иерархическую структуры объектов.


      1. lair
        29.11.2019 10:18
        #20944922

        Определения VIEW и MODEL идентичны определениям MVC

        Какого MVC? Лучше приведите используемые вами конкретно определения, это будет намного проще, нежели сначала искать "правильное" сторонее определение.


        И сразу еще один вопрос: вы упоминаете некое "состояние элементов системы". Что это такое? Почему оно вынесено отдельно, а не является частью одного из ваших понятий M-V-F-A?


  1. Gokudera
    27.11.2019 13:27
    #20936938

    Походу то что они предлагают = апач-камеловские ендпоинты собственной реализации.


    1. vl65 Автор
      27.11.2019 14:02
      #20937128

      Внешняя схожесть есть, но только внешняя. Идеологически подходы совершенно разные.