Что такое сервер приложения?
Из всего прочитанного в интернете мне удалось понять, что существуют 2 вида серверов: статические и динамические. Статические сервера включают в себя "сервер-железо" и "сервер-ПО", которое работает с HTTP и URL. Динамические сервера содержат все то, что содержат статические + сервер приложения и базу данных. Вся инфа отсюда.
То есть по сути динамический сервер называется таким из-за работы сервер приложения, который может изменять файлы, передаваемые по HTTP, налету.
У меня возник вопрос. Получается, что сервер приложения — это какой-то код, который позволяет обрабатывать файлы. Но судя по этой цитате, это не совсем так (вряд ли код может содержать веб-сервер):
Сервер приложений может содержать веб-серверы, поэтому он считается более мощным, чем веб-сервер.
Здесь мне скорее всего не понятно само строение или структура этого сервера приложения. Для чего и каким образом он содержит этот веб-сервер?
Также не понятна эта фраза:
Сервер приложений действует как набор компонентов, доступных разработчику программного обеспечения через API (интерфейс прикладного программирования), определённый самой платформой.
Получается, что если API поддерживает взаимодействие 2-ух программ, то в этом случае API может поддерживать взаимодействие между сервером приложения и какой-то любой другой программой. А всегда ли API поддерживает работу с сервером приложений, API работает только с сервером приложений?
я рискну ответить на вопрос, хотя, скорее всего, это не будет полным и законеченым ответом.
Мне кажется, что то непонимание, которое у Вас есть, происходит от обилия терминов и их "исторического напластования"
То, что Вы называете "статическиие и динамические сервера" — обычно, мне кажется, называется "статическим контентом" и "динамическим контентом".
то, что в тексте назывется серверами приложений — нужно понимать просто как "веб сервер без морды", как бы грубо это ни звучало. Это — программа, которая по HTTP принимает запросы и по HTTP же отвечает. Обычно это называют REST — протоколом (Representational state transfer)
Еще один распространённый термин для "серверов приложений" — это "веб-служба".
А всегда ли API поддерживает работу с сервером приложений?
Сам термин "сервер приложений" — это некая историческая шелуха.
Поясню свою мысль. На этапе зарождения WEB’а возможности написать файл с гиперссылками и отдавать его в примитивный браузер типа мозаики в общем всем хватало.
Но хотелось "динамики" например, счетчика числа посетителей на странице. Для этого использовался CGI (Common Gateway Interface).
Фактически, это означало, что в ответ на запрос из браузера на сервере выполнится программа, и результат её выполнения будет показан в браузере.
Чтобы "хорошо продавать" эту возможность ( а веб-сервера были не только бесплатными open source, но иногда и очень даже платными, типа Microsoft IIS и IBM WebSphere ) — был придуман маркетинговый термин "сервер приложений".
Который означал не более и не менее, чем возможность в ответ на запрос пользователя выполнить некий код, который на этот запрос ответит. В этом была разница с сервером, который умеет только "тупо хостить файлы"
Далее — под API, наверное, следует понимать "взаимодействие по заранее согласованному протоколу", но применительно к HTTP — серверам это в 99% случаев следует читать как REST API.
Объясню на примере. Пускай у меня есть база данных с ценной информацией.
Я могу сделать веб — сервер, который на своих страницах будет показывать эту информацию по запросам пользователя.
А могу предоставить интерфейс к своей базе данных, и многие — многие сервера в интернете начнут показывать эту информацию на своих страницах, обращаясь за самой информацией ко мне. По API. При этом у меня может вообще не быть "веб сервера, на котором есть страницы для просмотра посетителями".
Я надеюсь, что я смог — в этом коротком ответе — помочь Вам разобраться в терминах. Но если есть уточняющие вопросы — пишите!
Дополнение
я перечитал Ваш вопрос, и решил немного дополнить ответ вот в какой части:
Сервер приложений может содержать веб-серверы, поэтому он считается более мощным, чем веб-сервер.
Здесь мне скорее всего не понятно само строение или структура этого сервера приложения. Для чего и каким образом он содержит этот веб-сервер?
Я попытаюсь "на пальцах" рассказать, что имется в виду. Для этого посмотрим на стуктуру того, что вообще есть во всех этих серверах.
Есть программа, которая реализует HTTP — протокол. Она просто умеет получать HTTP-запрос и в ней есть модуль, который пытается на это запрос ответить.
Обычно эту программу просто "привязывают" к файловой системе WEB-сервера, и "модуль отвечания" работает по такому алгоритму: "К тебе пришел запрос? Посмотри, есть ли на диске файл, название которого соответствует запросу. Если есть — выдай этот файл в ответ на запрос, если нет — покажи страницу с 404-й ошибкой". Это — то что называется "статический контент", или "статический сервер" (как бы не передёргивало меня от этого термина)
Что такое "динамический сервер"? Это когда "модуль отвечания" в программе, которая обслуживает запросы, учат еще одному фокусу: ". а вот если к тееб придёт запрос определенного вида — то вместо отдачи файла пользователю выполни вот эту программу, и отдай пользоваетлю результаты её выполнения".
вот именно в этом смысле "Сервер приложений может содержать веб-серверы" — они имеют в виду, что, для того, чтобы принять запрос и отправить ответ — нужен модуль работы с HTTP протоколом, и называют его "веб-сервер". В этом смысле "динамический сервер" собержит "веб-сервер" в своём составе.
англ: serve — служить; +er —> server — тот, кто обслуживает.
Простыми словами "сервер" это то, что обслуживает (исполняет) запросы. Исполнитель.
Исполнитель (сервер) — это приложение. Однако этим же "словом" также называют железо на котором работает это приложение(-я). Да, на одном железе (сервере) могут быть запущены несколько приложений (серверов).
Деды от "айти" не перевели, в своё время, теперь вот такие вопросы.
Далее по наследию от дедов.
"Статичный, статический"
англ (прил): static — неподвижный.
"Динамичный, динамический и прочее динамо-"
англ (прил): dynamic — действующий, работающий, живой.
англ: web — паутина, сеть.
Соединяем всё до кучи.
Веб-сервер — исполнитель, который обрабатывает сетевые запросы, созданные по тем или иным правилам (договорённостям) (англ: protocol): TCP/IP, HTTP и т.д.
Сервер-приложений — исполнитель, на котором выполняется какое-либо прикладное приложение.
Статический-сервер — исполнитель, который также является ещё и веб-сервером, в задачи которого входит выдать те или иные данные, которые уже имеются у него. Т.е. ничего нового он при обращении к нему не создаёт. Например, у него есть набор изображений, вот, при обращении к нему, он и будет выдавать лишь эти изображения.
Динамический-сервер — исполнитель, который может быть веб-сервером, а может и не быть им, но в любом случае он является сервером-приложений. Если с ним можно общаться по сети, то значит это веб-сервер, если его задача, например, просто вычислять простые числа, то для этого никакой веб не нужен.
Ну и несколько слов про API исполнителя приложений.
К примеру, возьмём самовоз (англ: auto- (само-); mobile (подвижный)). У него есть рычаг переключения передач. Так вот допустимые положения для этого рычага являются API, т.е. способами для переключения передач, которые предоставлены разработчиками самовоза для этих нужд.
Наглядно положения передач можно описать так:
- 1-я: /влево/вверх
- 2-я: /влево/вниз
- ..
- 5-я: /вправо/вверх
- Задняя: /вправо/вниз
Для исполнителя приложений всё тоже самое. Есть набор мест (положений) при обращении к которым (с указанием дополнительных данных, если это необходимо) будет выполнено то или иное действие этим самым приложением. Например:
создать заметку: /createArticle, /create-article, /создатьЗаметку, /заметку-создать (выбор названия всецело зависит от разработчиков приложений).
Информатика. Тест 1
Поможем успешно пройти тест. Знакомы с особенностями сдачи тестов онлайн в Системах дистанционного обучения (СДО) более 50 ВУЗов. При необходимости проходим систему идентификации, прокторинга, а также можем подключиться к вашему компьютеру удаленно, если ваш вуз требует видеофиксацию во время тестирования.
Закажите решение теста для вашего вуза за 470 рублей прямо сейчас. Решим в течение дня.
1. Предшественницей сети Internetможно считать
Сеть RELCOM
Сеть ARPANET
Сеть MSN
Сеть AOL
2. Спам это
Поток рекламных писем, засоряющих почтовый ящик
Поток писем с предложением услуг
Поток приглашений от постоянных корреспондентов
Поток писем с предложением работы
3. В каком году создана сеть ARPANET?
1969
1973
1981
1982
4. В каком году появилась сеть CERN?
1969
1973
1981
1982
5. Как пример информационных технологий можно привести
Ремонт компьютерной техники.
Доставку компьютерной техники потребителю.
Прокладку кабеля при создании компьютерной сети.
Создание документов в редакторе MSWord
6. Информационное общество – это общество, в котором.
Изобретены компьютеры.
Созданы глобальные компьютерные сети.
Большая часть работоспособного населения занимается обработкой информации.
Большая часть населения владеет персональным компьютером.
7. Какая из приведенных записей содержит синтаксически правильную запись IP-адреса?
www.relcom.ru
km.mfua@mail.ru
c:\\windows\regedit.exe
192.16.09.04
8. Что такое октет?
Часть IP-адреса.
Часть URL-адреса
Часть mail– адреса
Часть доменного имени
9. Что такое программа-сервер ?
Программа, формирующая запросы и обрабатывающая результаты этих запросов.
Программа, принимающая и выполняющая запросы
Программа, управляющая трафиком сети
Программа, контролирующая целостность передачи данных.
10. Что такое информационный пакет ?
Блок данных, обрабатываемый сетевыми программами как единое целое.
Файл двоичного формата.
Файл, передаваемый по сети.
Набор команд процессора.
11. Что такое датаграмма?
Пакет прикладного уровня сети Internet.
Пакет сеансового уровня сети Internet.
Пакет системного (сетевого и транспортного) уровня сети Internet.
Пакет аппаратного уровня сети Internet/
12. Протокол HTTPотносится
К аппаратному уровню сети Internet.
К системному (сетевому или транспортному) уровню сети Internet.
К сеансовому уровню сети Internet.
К прикладному уровню сети Internet.
13. Протокол TCP/IPотносится
К аппаратному уровню сети Internet.
К системному (сетевому или транспортному) уровню сети Internet.
К сеансовому уровню сети Internet.
К прикладному уровню сети Internet.
14. В IP-заголовок записывается.
IP-адрес назначения иIP-адрес отправителя.
Контрольная сумма байт и информация для сборки прикладного пакета.
URL-адрес запрашиваемого ресурса.
Информация о формате передаваемого файла.
15. Какой из следующих идентификаторов может быть идентификатором домена верхнего уровня?
com
exe
doc
txt
Что такое программа-сервер?
В 6:33 поступил вопрос в раздел Современные средства ЭВМ и телекоммуникаций, который вызвал затруднения у обучающегося.
Вопрос вызвавший трудности
Ответ подготовленный экспертами Учись.Ru
Для того чтобы дать полноценный ответ, был привлечен специалист, который хорошо разбирается требуемой тематике «Современные средства ЭВМ и телекоммуникаций». Ваш вопрос звучал следующим образом: Что такое программа-сервер?
После проведенного совещания с другими специалистами нашего сервиса, мы склонны полагать, что правильный ответ на заданный вами вопрос будет звучать следующим образом:
-
Ответ: Программа, принимающая и выполняющая запросы
НЕСКОЛЬКО СЛОВ ОБ АВТОРЕ ЭТОГО ОТВЕТА:
Работы, которые я готовлю для студентов, преподаватели всегда оценивают на отлично. Я занимаюсь написанием студенческих работ уже более 4-х лет. За это время, мне еще ни разу не возвращали выполненную работу на доработку! Если вы желаете заказать у меня помощь оставьте заявку на этом сайте. Ознакомиться с отзывами моих клиентов можно на этой странице.
Абрамова Милослава Николаевна — автор студенческих работ, заработанная сумма за прошлый месяц 58 559 рублей. Её работа началась с того, что она просто откликнулась на эту вакансию
ПОМОГАЕМ УЧИТЬСЯ НА ОТЛИЧНО!
Выполняем ученические работы любой сложности на заказ. Гарантируем низкие цены и высокое качество.
Деятельность компании в цифрах:
Зачтено оказывает услуги помощи студентам с 1999 года. За все время деятельности мы выполнили более 400 тысяч работ. Написанные нами работы все были успешно защищены и сданы. К настоящему моменту наши офисы работают в 40 городах.
Ответы на вопросы — в этот раздел попадают вопросы, которые задают нам посетители нашего сайта. Рубрику ведут эксперты различных научных отраслей.
Полезные статьи — раздел наполняется студенческой информацией, которая может помочь в сдаче экзаменов и сессий, а так же при написании различных учебных работ.
Красивые высказывания — цитаты, афоризмы, статусы для социальных сетей. Мы собрали полный сборник высказываний всех народов мира и отсортировали его по соответствующим рубрикам. Вы можете свободно поделиться любой цитатой с нашего сайта в социальных сетях без предварительного уведомления администрации.
Площадка Учись.Ru разработана специально для студентов и школьников. Здесь можно найти ответы на вопросы по гуманитарным, техническим, естественным, общественным, прикладным и прочим наукам. Если же ответ не удается найти, то можно задать свой вопрос экспертам. С нами сотрудничают преподаватели школ, колледжей, университетов, которые с радостью помогут вам. Помощь студентам и школьникам оказывается круглосуточно. С Учись.Ru обучение станет в несколько раз проще, так как здесь можно не только получить ответ на свой вопрос, но расширить свои знания изучая ответы экспертов по различным направлениям науки.
Что такое сервер приложения
Когда вы открываете любой сайт — например, google или facebook, вы видите конечный продукт. Но чтобы этот продукт увидеть, и пощупать, нужно:
Написать код приложения
Поднять его на сервере приложения
Сегодня я расскажу про третий этап: что вообще такое сервер приложения и зачем он нужен.
Что это такое и зачем он нужен
Жила была Анечка. Она пекла вкусные кексики и тортики на заказ. Чтобы удобнее было делать заказ, решила Анечка сделать свой интернет-магазин. И обратилась за помощью к брату, разработчику Ване.
Ваня говорит:
— Да не вопрос!
Он как раз занимается фриланс-заказами с простыми системами типа интернет-магазинчиков. Поэтому он быстренько написал код на php. Но код — это просто набор файликов с расширением .php.
А как сделать так, чтобы у нас в интернете появилась страничка? Для этого нужен сервер приложения. Ваня для магазинчика выбирает apache (Apache HTTP Server), как наиболее популярный.
Мои тестовые системы:
— Users
— ShopТоже подняты на Apache. И написаны на php, то есть не требуют сборки))
Сервер обеспечивает возможность обращаться с приложением по HTTP-протоколу. Вы, конечно, можете и сами написать такой код, но зачем? Когда для этого уже есть готовая система. Причем бесплатная и open-source.
Положили код PHP в сервер. Запустили — вуаля, оно работает! Теперь у Анечки есть свой интернет-магазин, доступный извне, с любого устройства.
Если бы код был не на PHP, а на Java, у нас добавился бы шаг «собрать проект» — из набора текстовых файликов получить приложение. Обычно это архив, например, test.war. И уже его мы подкладываем в сервер. Ну а PHP — интерпретируемый язык. Ему не нужен сборщик.
Конечно, пока сайт доступен только по его IP. Чтобы это исправить, Анечке нужно выбрать доменное имя и купить домен. И тогда уже будет красивое название:
Вот теперь точно все готово!
Использование сервера приложений помогло Ване сконцентрироваться именно на бизнес-логике программы, не отвлекаясь на детали обеспечения транспортного пути. Ведь сервер приложения — это подобранный набор согласованных по версиям инфраструктурных библиотек. Например, http-сервер, который умеет принимать запросы.
Преимущества серверов приложений
Готовый HTTP-сервер
Пожалуй, самая важная и популярная функция сервера приложений — поддержка HTTP-сервисов и текущих HTTP-стандартов. Зайдите на любой сайт в интернете — фактически вы отправляете HTTP-запрос в приложение:
Открой мне страницу гугла
Покажи еще больше видео с котиками
Да, можно написать обработку запросов самостоятельно. И следить за стандартами, постоянно обновлять код. Но зачем, когда есть готовый сервер?
Для небольших проектов хватает HTTP-сервера, без дополнительных функций и плюшек. На текущий момент самый популярный сервер — Apache HTTP Server. Есть и более сложные сервера, например, Wildfly. Они имеют больше функций и используются в энтерпрайз системах.
Систему Users мне делал фриланс разработчик. Она написана на PHP и поднята на сервере Apache.
А на работе у меня на одном из проектов был enterprise продукт.. Написан на Java, поднимается на сервере Wildfly.
Поддержка горячего резерва
Если упал сервер, то есть испортилось 1 звено в клиент-серверной архитектуре — всё, все в ступоре, все отдыхают. Сотни, тысячи, да хоть миллионы клиентов если есть — никто не может работать. Открываешь сайт в интернете и грустно смотришь на окно «Простите, что-то пошло не так»
Именно поэтому в бизнес-критичном ПО архитектуру усложняют и даже дублируют. Банк с тысячами операционистов не может позволить себе простой. Поэтому они используют кластер серверов — один упал, остальные работают.
Сервера в кластере называются нодами. На каждой ноде (железке) стоит свой wildfly (или аналог). Когда приходит запрос на одну ноду, она оповещает об этом вторую, третью, четвертую, или сколько их там будет.
Каждая нода может обработать запрос независимо. Если приложение имеет какое-либо состояние, то оно может быть сохранено в общую БД. А также ноды могут оповещать другие ноды об изменении состояния через очереди/топики.
Такая схема называется горячим резервом — когда у нас есть несколько работающих в параллели серверов. Может быть и схема холодного резерва, когда второй сервер у нас «на всякий случай», а не для постоянного использования.
Но какой бы ни был резерв, фишка в том, что синхронизацией занимается сервер приложения, а не разработчик. У разработчика не болит голова о том, как бы данные на разных серверах не разъехались. Он может сосредоточиться на бизнес-логике системы.
Централизованная настройка и управление
В сервере приложений обычно есть админка. Заходишь по специальному URL — и у тебя есть доступ к настройкам приложения. Вот так выглядит приветственная страница админки wildfly:
Если у вас несколько серверов приложения, то изменение настроек может быть опасным занятием. Одну ноду (сервер) обновили, вторую забыли, а потом ловим баг.
Но так как сервер поддерживает работу в кластере, то все упрощается:
Мы меняем настройки в админке.
Они сами расползаются по всем нодам.
Безопасность
В больших бюрократических компаниях разделяют разных админов:
админ физического сервера (железка, на которой установлено ПО)
админ сервера приложений (например, wildfly)
Так вот, админу приложения дают доступ только в админку wildfly. Физически на сервер он зайти не может, или может, но на птичьих правах, логи почитать. А если нужно параметры системы изменить — извольте заводить заявку для админа железяки.
Так безопаснее, когда у тебя нет лишних прав. Иначе неопытный админ системы может наворотить дел, разгребай потом за ним. Поэтому чем больше контора, тем важнее иметь возможность разделить права. Сервер приложения позволяет это сделать: OS отдельно, приложение отдельно.
Поддержка транзакций
Сервер поддерживает поддержку XA транзакций — когда несколько транзакционных источников поддерживают распределенную спецификацию, и сервер ее координирует.
Например, что-то записали в БД и послали сообщение по JMS, всё в одной транзакции, вот сервер приложений предоставляет в том числе менеджера распределенных транзакций.
Фишка всё та же — пока сервер приложений выполняет массу инфраструктурного кода, разработчики могут сфокусироваться на бизнес-логике.
И наверняка есть что-то еще
Я честно пыталась выведать у знакомых разработчиков, зачем вообще сервер приложения нужен.
Оказалось, что он, в общем-то, и не особо нужен. Ну разве что как HTTP-сервер, хотя и для этого уже есть готовые библиотеки, можно в коде это все делать и запускать условный Main.java, без всякого дополнительного сервера.
На работе в одном из проектов мы использовали wildfly. Он дает кучу возможностей, но по факту мы использовали:
• HTTP-сервер — а куда же без него?
• Datasource — файл, где прописывается соединение с БД
• MQ-очереди — для горячего резерва, синхронизация нод между собой. Один сервер уведомляет другой об изменениях. Если другой сервер пока занят, то это сообщение встает в очередь.Вот и всё!
Иногда сервер приложений используется просто потому, что так принято. Например, все старые приложения поднимались на Jboss, ну и новые тоже требуют делать на нем же. Потому что админы умеют работать именно с ним.
Или безопасники требуют разграничить доступ. Или по другим причинам используется именно этот сервер приложения, а не какой-то другой.
При этом я уверена, что в каких-то компаниях используют сервер приложения на полную катушку. И что в разных серверах есть еще куча разного полезного функционала, который вы могли бы написать сами в коде, но. Зачем? Когда вот оно, готовое.
Можно обойтись и без сервера. Да. Но с ним удобнее =)
Другие определения сервера
Когда вы разговариваете с коллегами, очень важно, чтобы вы говорили на одном языке!
Поэтому учтите, что под сервером приложений могут понимать разные вещи:
Сервер приложения как ПО — Apache, Wildfly, и другие. Та программа, которая запускает ваше приложение.
Физический сервер — компьютер, на котором установлен wildfly
Сервер приложений — это сервисная программа, которая обеспечивает доступ клиентов к прикладным программам, выполняющимся на сервере. Сервер приложений обычно выделяется как среднее звено в трехуровневой клиент-серверной архитектуре (3-tier)
Тут сервером называется именно программа. А вот другое определение:
Сервер приложений это набор физического и программного обеспечения, которое способно обеспечить доступ клиентов к программам, выполняющихся непосредственно на серверном оборудовании.
Тут уже сервером называют не только программное обеспечение, но и физический сервер.
Так что если сомневаетесь, что вы с собеседником говорите об одном и том же, лучше уточнить, что он имеет в виду!
Дополнительные материалы
Итого
Сервер приложения — это ПО, которое запускает ваше приложение. Сначала разработчик пишет код, потом собирает билд сборщиком. Но это просто некий архив с кодом. А вот чтобы это стало доступной в интернете ссылочкой, и нужен сервер приложения.
Сервер берет на себя скучную инфраструктурную работу. Например, организацию HTTP-уровня OSI. Он принимает запросы и обрабатывает их по всем стандартам. А разработчик может сконцентрироваться на бизнес-логике, не отвлекаясь на детали обеспечения транспортного пути.