Файл: Понятие прикладных протоколов и серверы приложений.pdf

Что же такое этот «бин» (bean — боб) и почему, стремительно выскочив как джин из бутылки в компьютерный мир, он уже завоевал такую популярность. Если перевести определение Sun как можно ближе к оригиналу - то «это модель для создания и развертывания серверных компонентов многократного использования, написанных на языке Java.» Продолжим вместе с Sun расплетать косу этого определения, - «компоненты - это заранее разработанные куски программного кода, которые могут быть установлены в работающие прикладные системы» [10, с. 96]. Если классы Java образуют компонентную модель для проектирования приложений в технологии Java, то Java Beans логически развивает эту модель на следующем уровне интеграции создания автоматизированных систем и абстрагирования от процесса программирования - стадии внедрения. По сути, это переход от разработки приложения под заказ из готовых программных компонентов к сборке из готовых EJB действующих компонентов. Если раньше дома складывали из кирпичей, то теперь - из комнат-секций. Слово Enterprise в названии Enterprise Java Beans означает новую ступень технических задач, стоящих перед программными приложениями. Такие задачи привычны для приложений уровня Предприятия: поддержка распределенности, службы именования, транзакций, безопасности, уведомлений-сообщений, долговременного хранения, и т.д. Неудивительно, что этот список напоминает список Служб технологии CORBA [2, с. 100].

С точки зрения разработки, EJB представляют собой Java-классы специального типа вместе с описателем-паспортом бина и параметрами среды функционирования, которые бин умеет обрабатывать. Описатель бина (Deployment Descriptor) в свою очередь представляет собой XML-файл, в котором содержатся правила, связанные с управлением бином, например, права доступа пользователей к бину. Несколько бинов могут объединяться, образуя приложения, Java-апплеты и новые бины [4, с. 86].Это видно на рисунке 5.

Рисунок 5. Контейнер Enterprise Java Beans

По технологии EJB бобы-бины размещаются в стручке - контейнере (рис. 4) На контейнер возложены обязанности по защите бинов и поддержке их взаимоотношений с внешним миром: регистрация-прописка объектов, обеспечение для них внешних интерфейсов, создание и разрушение реализаций этих объектов, охрана безопасности, управление их состояниями и координация транзакций. В технологии не определено, как конкретно должен быть реализован контейнер. Это могут быть как многопоточные процессы на отдельном сервере, в которых выполняются бины, так и законченные программные приложения, которые можно переносить, или распределять между серверами и/или процессами. Клиентские бины обрабатываются внутри виртуальных контейнеров, таких как Web-страницы, формы, составные документы, и т.д. [1, с. 130].

В технологии определены два основных типа бинов. Session Beans - сеансы клиент-серверного взаимодействия отрабатывают действия клиента, например, запись в базу данных, выполнение вычислений, и т.д. Это окна клиента в мир программных приложений [10, с. 119].

Клиентские приложения общаются с бинами через контейнер, который открывает наружу оба интерфейса бина: Home и Remote. С помощью первого открывается сеанс или находится нужный бин, а с помощью второго - осуществляется отработка действий клиента в Session или транзакционная механика обработки Entity [10, с. 160].

2.3. Серверы приложений: плюсы и минусы

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

Самое важное решение - иметь облачную или собственную серверную инфраструктуру. Хотя это может звучать как черно-белое выделение, есть много вещей, которые следует учитывать. Первый фактор - это то, насколько важно время безотказной работы для вашего бизнеса [10, с. 73].Облачные решения, как правило, стоят дороже, чем собственные, но преимущества использования облака могут значительно перевесить затраты для некоторых предприятий. Например, онлайн-бизнес, который зависит от веб-транзакций, будет считать время безотказной работы чрезвычайно важным фактором; следовательно, они, вероятно, будут готовы платить больше за облачное решение, которое может гарантировать определенный уровень безотказной работы. Другие предприятия, не зависящие от времени безотказной работы, могут больше подходить для внутренней организации [14, с. 127].

Вот некоторые плюсы и минусы облачных и внутренних серверов.

Внутренний сервер плюсы:

Нет необходимости в оборудовании или капитальных затратах. Хорошо подходит для небольших компаний, которые могут слишком быстро перерасти хранилище [1, с. 267].

Хранение может быть добавлено по мере необходимости. Решения часто предоставляются по запросу, поэтому вы платите только за то, что вам нужно.

Резервное копирование и восстановление можно инициировать из любого места, используя любой компьютер, планшет или смартфон.

Резервное копирование данных в облаке может производиться с интервалом 15 минут, что сводит к минимуму потери данных в чрезвычайных ситуациях. Небольшое время восстановления набора данных улучшено [10, с. 191].

Минусы:

Затраты на восстановление данных могут перевесить преимущества для компаний, которые не так зависят от времени безотказной работы и мгновенного восстановления [1, с. 260].

Каждая организация будет иметь ограничение на количество данных, которые могут храниться в облаке из-за доступности хранилища и стоимости.

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

Полное восстановление данных может оказаться очень трудоемким и эффективным для систем.

Модель гибридного сервера также обеспечивает компаниям большую безопасность данных. Например, с помощью гибридной модели SysGen клиенты могут создавать резервные копии своих данных на локальном сервере, а также в облачном решении. Партнер SysGen по решениям для резервного копирования Datto представляет решения нового поколения для резервного копирования, аварийного восстановления и обеспечения непрерывности бизнеса [4, с. 120].

На рисунке 6 приведен пример гибридной модели SysGen.

Рисунок 6. Пример гибридной модели SysGen

У клиента есть локальный сервер с локальным хранилищем резервных копий. Сотрудники получают доступ к своим рабочим столам, приложениям, файлам, принтерам и электронной почте из офиса, используя локальную сеть [10, с. 91].В то же время данные резервируются для избыточности в облачное решение, а электронная почта полностью размещается в облаке с помощью Hosted Microsoft Exchange [1, с. 360].Облачная конфигурация также предоставляет сотрудникам в любом месте доступ к своим рабочим столам, приложениям, файлам, принтерам и электронной почте [13, с. 136].

Вывод по главе.

Сервер приложений - это программная структура, которая предоставляет как средства для создания веб-приложений, так и серверную среду для их запуска. Сервер приложений действует как набор компонентов, доступных разработчику программного обеспечения через стандартный API, определенный для самой платформы.

3. Реализация проблем прикладных протоколов и серверов приложений на практике

3.1. Анализ ситуации на сегодняшний день

В современном интернет пространстве могут возникнуть проблемы на прикладном уровне, но большинство проблем, с которыми сталкиваются люди, возникают на других уровнях. Однако некоторые проблемы на прикладном уровне или на других уровнях (в зависимости от того, как на них посмотреть) включают такие элементы, как следующие:

–Программные ошибки, такие как приложение, которое вылетает при слишком быстрой отправке данных. Когда происходят подобные вещи, все, что вы можете сделать, это диагностировать проблему, связаться с производителем программного обеспечения, уменьшить возникновение проблем, изменив другие элементы конфигурации, или перейти на эквивалентное приложение, если оно доступно [8, с. 64].

–Неверные настройки, такие как имена хостов или адреса, которые могли измениться и не были задокументированы. Узнайте, какими должны быть правильные настройки, даже если это означает двойную проверку конфигурации клиента и сервера [7, с. 160].

–Службы связаны с неверным портом, например с запущенными службами протокола удаленного рабочего стола (RDP) или службами HTTP на нестандартных портах. Например, вы можете получить доступ к удаленному хосту, но если вы попытаетесь подключиться не к тому порту, вы не сможете подключиться [12, с. 100].

–Нередко на серверах внутреннего использования установлено несколько веб-сайтов, на которых разрешено запускать только один из них через стандартный порт HTTP, равный 80. Кроме того, некоторые ИТ-администраторы предпочитают запускать службу RDP на нестандартном порту, чтобы неавторизованные пользователи не пытались подключиться к службе RDP.

–Используемые клиентские или серверные компоненты не соответствуют опубликованным стандартам протокола. Иногда пользовательский написанный код не соблюдает опубликованные протоколы и может привести к длительным упражнениям по устранению неполадок. В одном случае проблема была выявлена ​​только путем чтения опубликованных стандартов и захвата сетевого трафика с помощью инструмента захвата сети Wireshark [10, с. 101].

3.2. Прогнозы и перспективы развития

Обслуживание старых монолитных приложений становится все более дорогим и сложным. При таком сценарии необходимо перейти к современной архитектуре на основе микросервисов, которая решит многие из вышеупомянутых проблем [4, с. 121].Некоторые из ключевых преимуществ перехода на архитектуру на основе микросервисов включают в себя:

Лучшая изоляция неисправностей; если один микросервис выходит из строя, остальные продолжат работать

Соответствующая технология может быть использована для разработки отдельных компонентов приложения.

Изменения в приложении изолированы от отдельных компонентов, поэтому не требуется дорогостоящее полное развертывание всего приложения.

Легко масштабируемые отдельные компоненты.

Упрощенный процесс DevOps благодаря использованию контейнерных технологий, таких как Dockers, Kubernetes, Istio и т. д. [15, с. 260].

Архитектура на основе микросервисов может привести к:

–Более быстрому времени выхода на рынок;

–Снижению стоимости инфраструктуры;

–Более быстрому внедрению или улучшению бизнес-функций.

Чтобы узнать больше о микросервисах, ознакомимся с методом IBM Cloud Garage.

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

Отойдите от большой единой структуры команды к более децентрализованной структуре небольших групп [11, с. 146].

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

Представьте культуру DevOps, которая способствует более тесному сотрудничеству между разработчиками, операциями и всеми остальными, кто вовлечен в поставку программного обеспечения [15, с. 294].

Эталонное монолитное приложение представляет собой простое приложение для магазина. Как и многие другие, созданные впервые дни движения Web 2.0, пользователи напрямую взаимодействуют с интерфейсом на основе браузера и управляют своей корзиной для отправки заказов. Как показано ниже, это приложение построено с использованием традиционной модели 3-уровневой архитектуры, состоящей из HTTP-сервера, сервера приложений и вспомогательной базы данных [1, с. 331].

В приложении для покупок есть товары, сгруппированные по разным категориям; пользователь может осуществлять поиск по веб-сайту, добавлять товары в корзину, а затем отправлять заказ. Приложение использует две базы данных для хранения данных приложения - данные инвентаризации продукта и данные заказа клиента. Вы можете найти более подробную информацию об архитектуре и компонентах приложения в ibm-cloud-Architecture / refarch-jee-customerorder на GitHub.

Чтобы модернизировать существующее приложение Websphere в архитектуру на основе микросервисов, нам необходимо проанализировать приложение и оценить, можно ли модернизировать приложение и оправданы ли усилия. Иногда проще и дешевле воссоздать приложение с нуля. Однако в большинстве случаев, учитывая природу приложений JavaEE, гораздо проще преобразовать его в архитектуру на основе микросервисов, чем начинать заново [2, с. 160].