К видам серверов приложений архитектуры application server для организации кис не относятся
Презентацию к данной лекции Вы можете скачать здесь.
5.1. Архитектура информационных систем
5.1.1. Общие сведения
Современные программные приложения и информационные системы достигли такого уровня развития, что термин " архитектура " в применении к ним уже давно не удивляет. Грамотно построить информационную систему, эффективно и надежно функционирующую не проще, чем сконструировать и возвести современное многофункциональное здание [1].
Когда речь заходит об "архитектуре информационной системы", обычно не возникает недостатка в определениях. Есть даже Web-сайты, которые собирают такие определения [2].
Рассмотрим определение "архитектуры информационной системы", которое дают различные источники:
- Архитектура – это организационная структура системы [3].
- Архитектура информационной системы – концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы [4].
- Архитектура – это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы [5].
- Архитектура – это набор значимых решений по поводу организации системы программного обеспечения, набор структурных элементов и их интерфейсов, при помощи которых компонуется система, вместе с их поведением, определяемым во взаимодействии между этими элементами, компоновка элементов в постепенно укрупняющиеся подсистемы, а также стиль архитектуры , который направляет эту организацию – элементы и их интерфейсы, взаимодействия и компоновку [6].
- Архитектура программы или компьютерной системы – это структура или структуры системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними [7].
- Архитектура – это структура организации и связанное с ней поведение системы [8]. Архитектуру можно рекурсивно разобрать на части, взаимодействующие посредством интерфейсов, связи, которые соединяют части, и условия сборки частей. Части, которые взаимодействуют через интерфейсы, включают классы, компоненты и подсистемы.
- Архитектура программного обеспечения системы или набора систем состоит из всех важных проектных решений по поводу структур программы и взаимодействий между этими структурами, которые составляют системы [9]. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Проектные решения предоставляют концептуальную основу для разработки системы, ее поддержки и обслуживания.
Хотя определения несколько отличаются, можно заметить немалую степень сходства. Например, большинство определений указывают на то, что архитектура связана со структурой и поведением, а также только со значимыми решениями, может соответствовать некоторому архитектурному стилю, на нее влияют заинтересованные в ней лица и ее окружение, она воплощает решения на основе логического обоснования.
Под архитектурой программных систем будем понимать совокупность решений относительно [1, 10]:
- организации программной системы;
- выбора структурных элементов, составляющих систему и их интерфейсов;
- поведения этих элементов во взаимодействии с другими элементами;
- объединение этих элементов в подсистемы;
- архитектурного стиля , определяющего логическую и физическую организацию системы: статические и динамические элементы, их интерфейсы и способы их объединения.
Архитектура программной системы охватывает не только ее структурные и поведенческие аспекты, но и правила ее использования и интеграции с другими системами, функциональность, производительность, гибкость, надежность, возможность повторного применения, полноту, экономические и технологические ограничения , а также вопрос пользовательского интерфейса.
По мере развития программных систем все большее значение приобретает их интеграция друг с другом с целью построения единого информационного пространства предприятия. Как можно видеть из вышеприведенных определений интеграция является важнейшим элементом архитектуры .
Для того чтобы построить правильную и надежную архитектуру и грамотно спроектировать интеграцию программных систем необходимо четко следовать современным стандартам в этих областях. Без этого велика вероятность создать архитектуру , которая неспособна развиваться и удовлетворять растущим потребностям пользователей ИТ. В качестве законодателей стандартов в этой области выступают такие международные организации как SEI (Software Engineering Institute), WWW (консорциум World Wide Web), OMG (Object Management Group), организация разработчиков Java – JCP (Java Community Process), IEEE (Institute of Electrical and Electronics Engineers) и другие.
Рассмотрим классификацию программных систем по их архитектуре :
- Централизованная архитектура ;
- Архитектура "файл-сервер" ;
- Двухзвенная архитектура "клиент-сервер" ;
- Многозвенная архитектура "клиент-сервер" ;
- Архитектура распределенных систем ;
- Архитектура Веб-приложений ;
- Сервис-ориентированная архитектура .
Следует заметить, что, как и любая классификация, данная классификация архитектур информационных систем не является абсолютно жесткой. В архитектуре любой конкретной информационной системы часто можно найти влияния нескольких общих архитектурных решений.
Далее подробно рассмотрим особенности каждой архитектуры .
5.1.2. Централизованная архитектура
Централизованная архитектура вычислительных систем была распространена в 70-х и 80-х годах и реализовывалась на базе мейнфреймов (например, IBM-360/370 или их отечественных аналогов серии ЕС ЭВМ), либо на базе мини-ЭВМ (например, PDP-11 или их отечественного аналога СМ-4) [11]. Характерная особенность такой архитектуры – полная "неинтеллектуальность" терминалов . Их работой управляет хост-ЭВМ.
Достоинства такой архитектуры [11, 12]:
- пользователи совместно используют дорогие ресурсы ЭВМ и дорогие периферийные устройства;
- централизация ресурсов и оборудования облегчает обслуживание и эксплуатацию вычислительной системы;
- отсутствует необходимость администрирования рабочих мест пользователей;
Главным недостатком для пользователя является то, что он полностью зависит от администратора хост-ЭВМ. Пользователь не может настроить рабочую среду под свои потребности – все используемое программное обеспечение является коллективным.
Использование такой архитектуры является оправданным, если хост-ЭВМ очень дорогая, например, супер-ЭВМ .
Классическое представление централизованной архитектуры показано на рис. 5.1.
Рис. 5.1. Классическое представление централизованной архитектуры
Центральная ЭВМ должна иметь большую память и высокую производительность, чтобы обеспечивать комфортную работу большого числа пользователей.
Все приложения, работающие в такой архитектуре , полностью находятся в основной памяти хост-ЭВМ. Терминалы являются лишь устройствами ввода-вывода и таким образом в минимальной степени поддерживают интерфейс пользователя.
5.1.3. Архитектура "файл-сервер"
Файл-серверные приложения – приложения, схожие по своей структуре с локальными приложениями и использующие сетевой ресурс для хранения программы и данных [13].
- Функции сервера: хранения данных и кода программы.
- Функции клиента: обработка данных происходит исключительно на стороне клиента.
Классическое представление информационной системы в архитектуре "файл-сервер" представлено на рис. 5.2.
Рис. 5.2. Классическое представление архитектуры "файл-сервер"
Организация информационных систем на основе использования выделенных файл-серверов все еще является распространенной в связи с наличием большого количества персональных компьютеров разного уровня развитости и сравнительной дешевизны связывания PC в локальные сети [14].
Конечно, основным достоинством данной архитектуры является простота организации. Проектировщики и разработчики информационной системы находятся в привычных и комфортных условиях IBM PC в среде MS-DOS, Windows или какого-либо облегченного варианта Windows Server. Имеются удобные и развитые средства разработки графического пользовательского интерфейса, простые в использовании средства разработки систем баз данных и/или СУБД.
Достоинства такой архитектуры [12, 13, 14]:
- многопользовательский режим работы с данными;
- удобство централизованного управления доступом;
- низкая стоимость разработки;
- высокая скорость разработки;
- невысокая стоимость обновления и изменения ПО.
- проблемы многопользовательской работы с данными: последовательный доступ, отсутствие гарантии целостности;
- низкая производительность (зависит от производительности сети, сервера, клиента);
- плохая возможность подключения новых клиентов;
- ненадежность системы.
Простое, работающее с небольшими объемами информации и рассчитанное на применение в однопользовательском режиме, файл-серверное приложение можно спроектировать, разработать и отладить очень быстро [14]. Очень часто для небольшой компании для ведения, например, кадрового учета достаточно иметь изолированную систему, работающую на отдельно стоящем PC. Однако, в уже ненамного более сложных случаях (например, при организации информационной системы поддержки проекта, выполняемого группой) файл-серверные архитектуры становятся недостаточными.
5.1.4. Архитектура "клиент-сервер"
Клиент-сервер ( Client-server ) – вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг (сервисов), называемых серверами, и заказчиками услуг, называемых клиентами [15]. Нередко клиенты и серверы взаимодействуют через компьютерную сеть и могут быть как различными физическими устройствами, так и программным обеспечением.
Первоначально системы такого уровня базировались на классической двухуровневой клиент-серверной архитектуре (Two- tier architecture). Под клиент-серверным приложением в этом случае понимается информационная система, основанная на использовании серверов баз данных .
Схематически такую архитектуру можно представить, как показано на рис. 5.3 [16].
Рис. 5.3. Классическое представление архитектуры "клиент-сервер"
На стороне клиента выполняется код приложения, в который обязательно входят компоненты, поддерживающие интерфейс с конечным пользователем, производящие отчеты, выполняющие другие специфичные для приложения функции.
Клиентская часть приложения взаимодействует с клиентской частью программного обеспечения управления базами данных, которая, фактически, является индивидуальным представителем СУБД для приложения.
Заметим, что интерфейс между клиентской частью приложения и клиентской частью сервера баз данных , как правило, основан на использовании языка SQL. Поэтому такие функции, как, например, предварительная обработка форм, предназначенных для запросов к базе данных, или формирование результирующих отчетов выполняются в коде приложения.
Наконец, клиентская часть сервера баз данных , используя средства сетевого доступа, обращается к серверу баз данных , передавая ему текст оператора языка SQL.
Посмотрим теперь, что же происходит на стороне сервера баз данных . В продуктах практически всех компаний сервер получает от клиента текст оператора на языке SQL.
- Сервер производит компиляцию полученного оператора.
- Далее (если компиляция завершилась успешно) происходит выполнение оператора.
Разработчики и пользователи информационных систем, основанных на архитектуре "клиент-сервер", часто бывают неудовлетворены постоянно существующими сетевыми накладными расходами, которые следуют из потребности обращаться от клиента к серверу с каждым очередным запросом. На практике распространена ситуация, когда для эффективной работы отдельной клиентской составляющей информационной системы в действительности требуется только небольшая часть общей базы данных. Это приводит к идее поддержки локального кэша общей базы данных на стороне каждого клиента.
Фактически, концепция локального кэширования базы данных является частным случаем концепции реплицированных баз данных. Как и в общем случае, для поддержки локального кэша базы данных программное обеспечение рабочих станций должно содержать компонент управления базами данных – упрощенный вариант сервера баз данных , который, например, может не обеспечивать многопользовательский режим доступа. Отдельной проблемой является обеспечение согласованности (когерентности) кэшей и общей базы данных. Здесь возможны различные решения – от автоматической поддержки согласованности за счет средств базового программного обеспечения управления базами данных до полного перекладывания этой задачи на прикладной уровень.
Преимуществами данной архитектуры являются [12, 15]:
- возможность, в большинстве случаев, распределить функции вычислительной системы между несколькими независимыми компьютерами в сети;
- все данные хранятся на сервере, который, как правило, защищен гораздо лучше большинства клиентов, а также на сервере проще обеспечить контроль полномочий, чтобы разрешать доступ к данным только клиентам с соответствующими правами доступа;
- поддержка многопользовательской работы;
- гарантия целостности данных.
- неработоспособность сервера может сделать неработоспособной всю вычислительную сеть;
- администрирование данной системы требует квалифицированного профессионала;
- высокая стоимость оборудования;
- бизнес логика приложений осталась в клиентском ПО.
При проектировании информационной системы, основанной на архитектуре "клиент-сервер", большее внимание следует обращать на грамотность общих решений. Технические средства пилотной версии могут быть минимальными (например, в качестве аппаратной основы сервера баз данных может использоваться одна из рабочих станций). После создания пилотной версии нужно провести дополнительную исследовательскую работу, чтобы выяснить узкие места системы. Только после этого необходимо принимать решение о выборе аппаратуры сервера, которая будет использоваться на практике.
Увеличение масштабов информационной системы не порождает принципиальных проблем. Обычным решением является замена аппаратуры сервера (и, может быть, аппаратуры рабочих станций, если требуется переход к локальному кэшированию баз данных). В любом случае практически не затрагивается прикладная часть информационной системы.
Архитектуру корпоративных информационных систем можно рассматривать с разных позиций.
Функциональная архитектура КИС определяет состав функциональных подсистем и комплексов задач, обеспечивающих реализацию бизнес-процессов. В соответствии с функциональной архитектурой формируются организационные компоненты КИС, в первую очередь, это сеть коммуникаций, рабочие станции (автоматизированные рабочие места, АРМ) конечных пользователей и серверная подсистема сети, и указывается их взаимодействие.
Информационно-технологическая архитектура включает в себя аппаратно-программную платформу реализации КИС, организационную форму базы данных, архитектуру и топологию компьютерной сети, средства телекоммуникации, комплекс технических средств обработки данных. Определяется информационно-технологическая архитектура КИС используемыми программными и техническими средствами, в том числе средствами телекоммуникаций и средствами построения баз данных.
Компьютерные сети являются неотъемлемой и важнейшей частью КИС. Они во многом обусловливают ее архитектуру.
На сегодняшний день сложились типовые информационнотехнологические структуры КИС и соответствующие структуры ККС. Назовем их.
Централизованная обработка данных (рис. 9.1), когда на одном компьютере установлены и функционируют средства:
- 1) пользовательского интерфейса, обеспечивающие интерактивный режим работы пользователя (в том числе и «средства презентации данных»);
- 2) содержательной обработки - программы приложений;
- 3) организации и использования баз данных.
Рис. 9.1. Взаимосвязи основных компонентов системы централизованной обработки данных
Файл-серверная распределенная обработка данных (рис. 9.2): на рабочей станции находятся средства пользовательского интерфейса и программы приложений, на сервере хранятся файлы базы данных.
Клиент-серверная двухуровневая распределенная обработка данных (рис. 9.3): на рабочей станции находятся средства пользовательского интерфейса и программы приложений (рабочие станции относятся к категории «толстых клиентов»), на сервере баз данных хранятся СУБД и файлы базы данных. Рабочие станции (клиенты) посылают серверу запросы на интересующие их данные, сервер выполняет извлечение и предварительную обработку данных. По сравнению с предыдущим вариантом существенно уменьшается трафик сети и обеспечивается прозрачность доступа всех приложений к файлам базы данных.
Рис. 9.2. Взаимосвязи основных компонентов файл-серверной сети
і іе редач а файлов
Рис. 9.3. Взаимосвязи основных компонентов двухуровневой клиент-серверной сети
Клиент-серверная многоуровневая распределенная обработка данных (рис. 9.4): на рабочей станции находятся только средства пользовательского интерфейса, на сервере приложений - программы приложений, а на сервере баз данных хранятся СУБД и файлы базы данных.
Рис. 9.4. Взаимосвязи основных компонентов трехуровневой клиент-серверной сети
Серверы выполняют всю содержательную обработку данных, рабочие станции являются «тонкими клиентами», и на их месте могут использоваться NET PC - «сетевые компьютеры». Если серверов приложений и серверов баз данных в сети несколько, то сеть становится клиент-серверной многоуровневой.
Наличие выделенных уровней в технологической структуре делает возможным варьирование аппаратных и программных средств для реализации структурных составляющих информационно-технологической архитектуры ККС: выбор операционных систем, СУБД, интерфейсов пользователей, серверов и рабочих станций.
Наиболее традиционна для информационных систем масштаба предприятий пока двухзвенная архитектура клиент-сервер. Если логика прикладной части системы достаточно сложна, то такой подход порождает проблему «толстого» клиента, когда каждая рабочая станция должна обладать достаточным набором ресурсов для прикладной обработки данных. С целью повышения общей эффективности системы применяется трехзвенная архитектура клиент-сервер, которая сегодня становится для ККС доминантной. В ней, кроме клиентской части и сервера базы данных, добавляется промежуточный сервер приложений. На стороне клиента выполняются только интерфейсные действия, а вся логика обработки информации поддерживается в сервере приложений.
Базовыми компонентами информационной системы, необходимыми для решения первоочередных задач, выступают следующие серверные и клиентские программные продукты:
S: Схема соединений узлов сети называется _____________ сети.
+: топологией -: протоколом -: доменом -: маркером
S: OLTP ( OnLine Transaction Processing ) - это:
-: режим оперативной обработки транзакций
+: режим пакетной обработки транзакций
-: время обработки запроса пользователя
S: Реляционная база данных представляет собой…
-: последовательный набор данных
+: совокупность связанных между собой таблиц
S: Совокупность связанных данных, правила, организации которых основаны на общих
принципах описания, хранения и манипулирования данными, называется…
-: пакетом прикладных программ
S: Совокупность средств, методов и персонала для организации хранения информации в
компьютерной среде называется.
S: Специальным образом организованное хранение информационных ресурсов в виде
интегрированной совокупности файлов, обеспечивающее удобное взаимодействии и
быстрый доступ к данным называется…
S: Модель, при которой на первом уровне может находиться несколько элементов,
связанных не только вертикальными связями, но и горизонтальными, называется…
S: Модель данных, напоминающая по своему строению дерево, называется…
S: Основополагающим элементом построения базы данных является.
S: Наиболее широко применяемая сегодня модель построения баз данных -
S: Основным элементом хранения информации в базе может быть…
S: Объединение нескольких таблиц в рамках одной базы данных осуществляется с
S: Поиск в реляционной базе данных производится с помощью…
S: Базы данных, реализующие сетевую модель, представляют зависимые данные в виде…
+: наборов записей и связей между ними
S: В состав базы данных входят…
-: базовые, рабочие и файлы связи
-: базовые файлы и файлы связи
S: Базы данных — это:
+: информационные структуры, хранящиеся во внешней памяти
-: программные средства, позволяющие организовать информацию в виде таблиц
-: программные средства, обрабатывающие табличные данные
-: программные средства, осуществляющие поиск информации
-: информационные структуры, хранящиеся в оперативной памяти
S: Неотъемлемой частью любой информационной системы является
- программа созданная в среде разработки Delphi
- возможность передавать информацию через Интернет
- программа, созданная с помощью языка программирования высокого уровня
S: В настоящее время наиболее широко распространены системы управления базами
S: СУБД Oracle, Informix, Subase, DB 2, MS SQL Server относятся к + реляционным
S: Какая база данных состоит из нескольких, возможно пересекающихся или даже
дублирующих друг друга частей, хранимых в различных ЭВМ вычислительной сети?
Сервер приложений - это сервер, на котором размещены приложения.
Фреймворки сервера приложений - это программные фреймворки для создания серверов приложений. Инфраструктура сервера приложений предоставляет как средства для создания веб-приложений, так и серверную среду для их запуска.
Каркас сервера приложений содержит комплексную модель уровня обслуживания. Он включает в себя набор компонентов, доступных разработчику программного обеспечения через стандартный API, определенный для самой платформы. Для веб-приложений эти компоненты обычно работают в той же среде, что и их веб-сервер (-ы), и их основная задача - поддерживать создание динамических страниц. Тем не менее, многие серверы приложений сделать больше , чем создания веб - страниц: они реализуют такие услуги, как кластеризация, отказоустойчивость и балансировка нагрузки , так что разработчики могут сосредоточиться на реализации бизнес - логики .
В случае серверов приложений Java сервер ведет себя как расширенная виртуальная машина для запуска приложений, прозрачно обрабатывая подключения к базе данных с одной стороны и, часто, подключения к веб-клиенту с другой.
Другие варианты использования этого термина могут относиться к службам, которые предоставляет сервер, или к компьютерному оборудованию, на котором эти службы выполняются.
СОДЕРЖАНИЕ
История
Этот термин первоначально использовался при обсуждении ранних систем клиент-сервер , чтобы отличать серверы, содержащие службы SQL логики приложений и серверы промежуточного программного обеспечения, от других типов серверов данных.
В настоящее время, несмотря на то, что веб-браузеры стали повсеместными и обычно являются клиентом для конечных пользователей во многих стратегиях развертывания приложений, веб-приложения на основе браузера представляют собой лишь подмножество технологий сервера приложений.
Определение сервера приложений
Серверы приложений - это системное программное обеспечение, на котором работают веб-приложения или настольные приложения.
Серверы приложений состоят из
- коннекторы веб-сервера,
- языки компьютерного программирования ,
- библиотеки времени выполнения ,
- соединители базы данных и
- код администрирования, необходимый для развертывания, настройки, управления и подключения этих компонентов на веб-узле.
Сервер приложений работает за веб-сервером (например, Apache или Microsoft Internet Information Services (IIS)) и (почти всегда) перед базой данных SQL (например, PostgreSQL , MySQL или Oracle ). Веб-приложения - это компьютерный код, который выполняется поверх серверов приложений и написан на языке (ах), поддерживаемом сервером приложений, и вызывает библиотеки времени выполнения и компоненты, предлагаемые сервером приложений.
Существует множество серверов приложений. Выбор влияет на стоимость, производительность, надежность, масштабируемость и ремонтопригодность веб-приложения.
Проприетарные серверы приложений предоставляют системные услуги четко определенным, но частным образом. Разработчики приложений разрабатывают программы в соответствии со спецификацией сервера приложений. Недостатком такого подхода является зависимость от конкретного поставщика.
Противоположный, но аналогичный случай - платформа Java EE . Серверы приложений Java EE предоставляют системные услуги в соответствии с четко определенным открытым отраслевым стандартом. Разработчики приложений разрабатывают программы в соответствии со спецификацией Java EE, а не в соответствии с сервером приложений. Приложение Java EE, разработанное в соответствии со стандартом Java EE, может быть развернуто на любом сервере приложений Java EE, что делает его независимым от производителя.
Серверы приложений Java
Платформа Java, Enterprise Edition или Java EE (ранее J2EE) определяет базовый набор API и функций серверов приложений Java .
Инфраструктура Java EE разделена на логические контейнеры.
Некоторые серверы приложений Java не используют многие функции Java EE, такие как EJB и Java Message Service (JMS). Их внимание больше уделяется сервлетам Java и страницам JavaServer.
Существует множество серверов приложений Java с открытым исходным кодом, которые поддерживают Java EE.
На коммерческих серверах приложений Java доминируют WebLogic Application Server от Oracle , WebSphere Application Server от IBM и платформа JBoss Enterprise Application Platform с открытым исходным кодом (JBoss EAP) от Red Hat .
Вышеупомянутые серверы приложений в основном обслуживают веб-приложения и службы через RMI, EJB, JMS и SOAP. Некоторые серверы приложений нацелены на сети, отличные от веб- сетей : серверы протокола инициации сеанса , например, на целевые телефонные сети.
Microsoft
Третья сторона
Серверы приложений PHP
Серверы приложений PHP используются для запуска и управления приложениями PHP .
Zend Server , созданный Zend Technologies , обеспечивает функциональность сервера приложений для приложений на основе PHP.
appserver.io , созданный TechDivision GmbH, представляет собой многопоточный сервер приложений для PHP, написанный на PHP.
RoadRunner , созданный Spiral Scout, представляет собой высокопроизводительный сервер приложений PHP, балансировщик нагрузки и диспетчер процессов, написанный на Golang.
Серверы мобильных приложений
Мобильный сервер приложений подвижен промежуточный слой , что делает фоновая система , доступная для мобильного приложения для поддержки разработки мобильных приложений . Многое , как веб - сервер , который хранит, обрабатывает и доставляет веб - страницы для клиентов , мобильный сервер приложений ликвидирует отставание от существующей инфраструктуры мобильных устройств.
Хотя большая часть основанной на стандартах инфраструктуры (включая SOA ) предназначена для подключения к любому, независимо от поставщика, продукта или технологии, у большинства предприятий возникают проблемы с подключением серверных систем к мобильным приложениям, поскольку мобильные устройства создают следующие технологические проблемы:
- Ограниченные ресурсы - мобильные устройства имеют ограниченную мощность и пропускную способность
- Прерывистая связь - сотовая связь и покрытие Wi-Fi часто не непрерывно
- Трудно защитить - мобильность и BYOD затрудняют защиту мобильных устройств
Целью сервера мобильных приложений является создание существующей инфраструктуры для размещения мобильных устройств.
Общие черты
Основные возможности сервисов мобильных приложений включают:
- Маршрутизация данных - данные упаковываются в более мелкие ( REST ) объекты с некоторой бизнес-логикой, чтобы минимизировать требования к пропускной способности и батарее.
- Оркестровка - транзакции и интеграция данных из нескольких источников
- Служба аутентификации - безопасное подключение к серверным системам управляется мобильным промежуточным программным обеспечением.
- Автономная поддержка - позволяет пользователям получать доступ и использовать данные, даже если устройство не подключено
- Безопасность - шифрование данных, управление устройствами, SSL, ведение журнала вызовов
Серверы мобильных приложений против серверов приложений против веб-серверов
Серверы мобильных приложений, серверы приложений и веб-серверы служат схожим целям: они являются частями промежуточного программного обеспечения, которые соединяют серверные системы с пользователями, которым необходим доступ к ним, но технологии в каждом из трех различаются.
Серверы приложений
Веб-серверы
Серверы мобильных приложений
Серверы мобильных приложений идут по тому же пути. Появление мобильных устройств требует функциональности, которую разработчики традиционных серверов приложений не ожидали, и серверы мобильных приложений заполняют этот пробел. Они заботятся о безопасности, управлении данными и требованиях к автономному режиму, которые не удовлетворяются существующей инфраструктурой, и представляют контент исключительно в REST.
Со временем эти три категории могут полностью объединиться и стать доступными в одном продукте, но корневые функции различаются.
Читайте также: