веб сервер и веб сервис в чем разница
Веб-сервисы в теории и на практике для начинающих
Что такое веб-сервисы?
Прежде всего, веб-сервисы (или веб-службы) — это технология. И как и любая другая технология, они имеют довольно четко очерченную среду применения.
Если посмотреть на веб-сервисы в разрезе стека сетевых протококолов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP.
С другой стороны, если гипотетически разделить Интернет на несколько слоев, мы сможем выделить, как минимум, два концептуальных типа приложений — вычислительные узлы, которые реализуют нетривиальные функции и прикладные веб-ресурсы. При этом вторые, зачастую заинтересованы в услугах первых.
Но и сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки.
Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, и были придуманы веб-сервисы.
По сути, веб-сервисы — это реализация абсолютно четких интерфейсов обмена данными между различными приложениями, которые написаны не только на разных языках, но и распределены на разных узлах сети.
Именно с появлением веб-сервисов развилась идея SOA — сервис-ориентированной архитектуры веб-приложений (Service Oriented Architecture).
Протоколы веб-сервисов
На сегодняшний день наибольшее распространение получили следующие протоколы реализации веб-сервисов:
На самом деле, SOAP произошел от XML-RPC и является следующей ступенью его развития. В то время как REST — это концепция, в основе которой лежит скорее архитектурный стиль, нежели новая технология, основанный на теории манипуляции объектами CRUD (Create Read Update Delete) в контексте концепций WWW.
Безусловно, существуют и иные протоколы, но, поскольку они не получили широкого распространения, мы остановимся в этом кратком обзоре на двух основных — SOAP и REST. XML-RPC ввиду того, что является несколько «устаревшим», мы рассматривать подробно не будем.
Нас в первую очередь интересуют вопросы создания новых веб-служб, а не реализация клиентов к существующим (как правило поставщики веб-сервисов поставляют пакеты с функциями API и документацией, посему вопрос построения клиентов к существующим веб-службам менее интересен с точки зрения автора).
SOAP против REST
Проблемы данного противостояния хорошо описаны в статье Леонида Черняка, найденой на портале www.citforum.ru.
По мнению же автора, кратко можно выделить следующее:
SOAP более применим в сложных архитектурах, где взаимодействие с объектами выходит за рамки теории CRUD, а вот в тех приложениях, которые не покидают рамки данной теории, вполне применимым может оказаться именно REST ввиду своей простоты и прозрачности. Действительно, если любым объектам вашего сервиса не нужны более сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как правило — в 99% случаев этого достаточно), возможно, именно REST станет правильным выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы — PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен.
В любом случае вам решать, что больше подойдет вашему приложению. Вполне вероятно, вы даже захотите реализовать оба протокола, чтобы оставить выбор за пользователями службы и — это ваше право.
Практическое применение веб-сервисов
Поскольку речь идет о практическом применении, нам нужно выбрать платформу для построения веб-службы и поставить задачу. Так как автору ближе всего PHP 5, мы и выберем его в качестве технологии для построения службы, а в качестве задачи примем следующие требования.
Допустим, нам необходимо создать службу, предоставляющую доступ к информации о курсах валют, которая собирается нашим приложением, и накапливается в базе данных. Далее посредством веб-сервиса, данная информация передается сторонним приложениям для отображения в удобном для них виде.
Как видим задача довольно проста и, с точки зрения самой службы, ограничивается лишь чтением информации, но в практических целях нам этого будет достаточно.
Этап первый — реализация приложения сбора информации о курсах валют.
Информацию о курсах валют мы будем собирать со страниц сайта НБУ (Национального Банка Украины) ежедневно и складывать в базу данных под управлением СУБД MySQL.
Создадим структуру данных.
Таблица валют (currency):
Таблица номиналов обмена (exchange):
Для работы с базой данных воспользуемся ORM слоем на базе пакета PHP Doctrine. Реализуем граббер:
класс Grubber (models/Grabber.php):
и сам граббер (grabber.php):
Теперь заставим наш граббер отрабатывать раз в сутки в 10:00 утра, путем добавления команды запуска граббера в таблицы cron:
Все — у нас есть достаточно полезный сервис.
Теперь реализуем веб-сервис, который позволит другим приложениям извлекать данные из нашей базы.
Реализация SOAP сервиса
Для реализации веб-сервиса на базе SOAP протокола, мы воспользуемся встроенным пакетом в PHP для работы с SOAP.
Поскольку наш веб-сервис будет публичным, хорошим вариантом будет создание WSDL файла, который описывает структуру нашего веб-сервиса.
WSDL (Web Service Definition Language) — представляет из себя XML файл определенного формата. Подробное описание синтаксиса можно найти здесь.
На практике будет удобно воспользоваться функцией автоматической генерации файла, которую предоставляет IDE Zend Studio for Eclipse. Данная функция позволяет генерировать WSDL файл из классов PHP. Поэтому, прежде всего, мы должны написать класс, реализующий функциональность нашего сервиса.
класс CurrencyExchange (models/CurrencyExchange.php):
Отметим, что для автоматической генерации WSDL, нам необходимо написать комментарии в стиле javadoc, потому что именно в них мы прописываем информацию о типах принимаемых аргументов и возвращаемых значений. Неплохо также описывать в нескольких словах работу методов — ведь WSDL послужит описанием API для сторонних разработчиков, которые будут использовать ваш веб-сервис.
Не пишите в докблоках param void или return void — для WSDL это не критично, но вот при реализации REST доступа к тому-же классу у вас возникнут проблемы.
Теперь в Zend Studio входим в меню File->Export. выбираем PHP->WSDL, добавляем наш класс, прописываем URI-адрес нашего сервиса и создаем WSDL-файл. Результат должен быть примерно таким: http://mikhailstadnik.com/ctws/currency.wsdl
Если вы будете добавлять новую функциональность в ваш веб-сервис, вам нужно будет пересоздавать WSDL-файл. Но здесь не так все гладко. Следует учитывать, что SOAP-клиент, который уже запрашивал ваш WSDL файл, кеширует его на своей стороне. Поэтому, если вы замените старое содержимое новым в WSDL файле, некторые клиенты его не прочтут. А значит, при добавлении новой функциональности, дописывайте версию в имя вашего файла. И не забудбте обеспечить обратную совместимость для старых клиентов, особенно если вы не являетесь их поставщиком.
С другой стороны, WSDL довольно жестко задает структуру веб-сервиса, а это значит, что, если существует необходимость ограничить функциональность клиента по сравнению с сервером, вы можете не включать определенные методы ваших классов в WSDL. Таким образом они не смогут быть вызваны, несмотря на то, что существуют.
Реализация же самого сервера не предстваляет теперь никакой сложности:
Вы можете попробовать веб-сервис в работе по адресу: http://mikhailstadnik.com/ctws/
Там же доступен тестовый клиент: http://mikhailstadnik.com/ctws/client.php
Код простейшего клиента может быть таким:
Реализация REST сервиса
REST — это не стандарт и не спецификация, а архитектурный стиль, выстроенный на существующих, хорошо известных и контролируемых консорциумом W3C стандартах, таких, как HTTP, URI (Uniform Resource Identifier), XML и RDF (Resource Description Format). В REST-сервисах акцент сделан на доступ к ресурсам, а не на исполнение удаленных сервисов; в этом их кардинальное отличие от SOAP-сервисов.
И все же удаленный вызов процедур применим и в REST. Он использует методы PUT, GET, POST, DELETE HTTP протокола для манипуляции объектами. Кардинальное отличие его от SOAP в том, что REST остается HTTP-запросом.
Поскольку в PHP пока еще нет реалзации REST, мы воспользуемся Zend Framwork, в который включена реализация как REST клиента, так и REST севера.
Воспользуемся уже готовым классом CurrencyExchange. Напишем сам сервер:
Как видите все очень сходно и просто.
Однако, следует оговорить, что наш REST-сервис менее защищен, чем SOAP-сервис, так как любой добавленый метод в класс CurrencyExchange при его вызове отработает (сам класс определяет сруктуру сервиса).
Проверим работу нашего сервиса. Для этого достаточно передать параметры вызова метода в сроке GET-запроса:
При желании или необходимости вы можете самомтоятельно задавать структуру ваших XML ответов для сервиса REST. В этом случае, также будет необходимо позаботиться и о создании определения типа вашего XML документа (DTD — Document Type Definition). Это будет минимальным описанием API вашего сервиса.
Простейший тестовый клиент к REST сервису может быть в нашем случае таким:
В принципе, Zend_Rest на сегодняшний день нельзя назвать наиболее точной реализацией принципов REST. Утрируя, можно говорить о том, что эта реализация свелась к удаленному вызову процедур (RPC), хотя философия REST гораздо шире.
Вы можете скачать пример в исходных кодах c PHP Doctrine и Zend Framework (4,42 Мб).
Заключение
Мы выполнили задачу минимум и показали, что такое веб-сервисы, для чего они нужны и как их реализовывать. Естественно, приведенный пример, возможно, несколько оторван от жизни, но он был выбран лишь в качестве инструмента для объяснения предмета и сущности веб-сервисов.
Кроме того мы увидели, что реализация веб-сервиса — задача довольно простая при использовании современного инструментария, который позволяет сконцентрироваться, в первую очередь, на разработке функциональности самого сервиса, не заботясь о низкоуровневой реализации протоколов.
Автор надеется, что данный материал будет действительно полезен тем, кто становится на тропу разработки веб-служб.
Разница между веб-сервером и сервером приложений
Сервер — это центральное хранилище, где информация и компьютерные программы хранятся и доступны программисту в сети. Веб-сервер и сервер приложений — это разновидности серверов, которые используются для доставки сайтов, и, следовательно, последний имеет дело с операциями приложений, выполняемыми между пользователями и внутренними бизнес-приложениями организации.
Веб-сервер: это компьютерная программа, которая принимает запрос данных и отправляет указанные документы. Веб-сервером может быть компьютер, на котором хранится онлайн-контент. По сути, для размещения сайтов используется интернет-сервер, однако существуют разные веб-серверы, такие как отдых, хранение, FTP, электронная почта и т.д.
Сервер приложений: он включает в себя веб-контейнер, а также контейнер EJB. Серверы приложений организуют среду выполнения корпоративных приложений. Сервер приложений может быть разумным сервером, который означает, как поставить операционную систему, разместить приложения и сервисы для пользователей, ИТ-сервисов и организаций. При этом используется пользовательский интерфейс, аналогичный протоколу и протоколам RPC / RMI.
Примеры сервера приложений:
Разница между веб-сервером и сервером приложений:
Что такое веб-сервер и для чего он нужен?
Вы наверняка слышали словосочетание «веб-сервер». Что это такое? Чем он отличается от обычного сервера и в чем заключены его функции и задачи. Разберемся.
Веб-сервер – это программа выполняющая роль посредника между запросами пользователя компьютера и данными выложенными в интернете и, в конечном счете, на соответствующих серверах. Точно также называется и сервер, на котором располагается данное программное обеспечение. Если сказать сложнее и технически, веб-сервер – это программа позволяющая обрабатывать НТТР-запросы и выдавать корректные НТТР-ответы.
В общем, веб-сервер – это то, что позволяет работать всемирной паутине Интернет, а пользователям находить и воспринимать нужную информацию в виде различных ресурсов – сайтов, медиа-площадок, страничек, библиотек, видео и т.п.
Как это происходит?
Интернет содержит в себе огромные объемы данных, которые отображаются в том или ином виде, когда мы делаем запрос со своего браузера. Когда в строке вводится URL-адрес сайта или страницы, через соответствующий протокол (http и https) идет запрос в сервер, где расположены данные которые запрашиваются. Веб-сервер обрабатывает этот запрос и выдает корректный продукт в виде сайта, страницы, сервиса и т.п. всего, что вы можете найти на просторах глобальной сети.
Проще говоря, клиент (пользователь браузера) – задает вопрос, веб-сервер делает возможным обращение к информации которая требуется и выдает ответ. Цепочка такова: запрос браузера – веб-сервер – запрос всех необходимых данных – выведение запроса в адекватном для браузера формате. Например, сайт «со всеми потрохами» лежит на сервере, и достается оттуда в «удобоваримом виде» веб-сервером, чтобы показать его клиенту, который ввел адрес сайта.
Веб-сервер обладает дополнительными функциями, которые позволяют оптимизировать работу браузера и навигацию в интернете. Среди них: создание защищенных соединений, запись в журнале обращения к сайтам, авторизация пользователя, поддержка приложений вроде антивируса и т.п. То есть все то, что позволяет пользоваться достоинствами и недостатками сети интернет с помощью любого браузера.
То же самое происходит, когда осуществляются обновления на компьютере, смартфоне, планшете и т.д. Такие обращения за новыми данными (программными обновлениями) происходят автоматически с помощью функций веб-сервера.
В чем отличие веб-сервера от обычного сервера?
Суть процесса – подобна работе обычного сервера, где происходит обращение к определенным данным расположенным на сервере с помощью соответствующей специальной программы (как например, в случае 1С бухгалтерии). Отличие веб-сервера в том, что специализация программы, так сказать, распространяется на весь интернет, где она работает посредником и обработчиком запросов и выдач. Поэтому веб-серверы отличаются своей относительной универсальностью. Среди наиболее популярных компаний занимающихся разработкой веб-серверов являются Apache и Microsoft. Они без проблем взаимодействуют со всеми операционными системами, такими как Microsoft Windows, Linux, Mac OS и т.д.
Резюмируя: веб-сервер – это программа-посредник обрабатывающая запросы пользователей в интернете с помощью браузеров и выдающая корректный ответ в виде готового продукта.
Чем отличаются веб-сервис, веб-приложение и сайт
Серьёзный программист скажет, что это части одной системы, а не виды продуктов. А потом выдаст: «Делаем не сайт, а веб-приложение, — или, — Сайт готов, но нужно ещё подключить веб-сервисы». Как это понимать?
Только показываем или взаимодействуем?
Сравним блинную в торговом центре и федеральную сеть доставки пиццы.
Блинной хватает онлайн-визитки с указанием, какие блины она жарит, где находится. Можете анонсировать там скидки и мастер-классы, размещать срочные объявления: «Сегодня закрыты. Нет воды».
Пиццерия принимает заказы через сайт и мобильное приложение. С клиентами общается робот (чат-бот). У поваров и курьеров — свои приложения, чтобы получать задачи и фиксировать ход работ. Простеньким сайтом тут не обойтись: нужен целый комплекс программ.
Как работает веб-приложение
Повар раскатал тесто, выложил начинку, отправил пиццу в печь, упаковал в коробку для доставки. Так вот, коробка — это сайт, печь — веб-сервис, а повар — веб-приложение. Пицца, коробка, печь, повар — это не отдельные услуги, а часть единого процесса.
Перейдём от метафоры к реальности.
«Реализуем архитектуру “клиент-сервер”», — объявили разработчики. Что это значит: клиент только «просит» сервер поработать и выдать результат. Бизнес-процесс выполняется на сервере, а не на устройстве клиента. Веб-приложение — та часть кода на сервере, которая выполняет бизнес-процессы.
Веб-сервис — ещё более техническое понятие. Если веб-приложение хоть как-то касается клиента, то веб-сервис работает не с клиентом, а с другими приложениями и сервисами. Это код для другого кода.
Поясним на примере.
Заказчик пиццы при оформлении вводит адрес, контакты, номер карты. На сервер отправляется команда «Оформляй!» Сервер, а точнее, приложение на сервере, вычисляет стоимость доставки, применяет скидки, начисляет бонусы, записывает заказ в базу, уведомляет кухню и курьера, связывается с банком для оплаты, создаёт проводку для бухгалтерии. Проделав всё это, сервер отчитывается: «Заказ оформлен!» Заказчик видит уведомление.
Где тут веб-сервис? Там, где пиццерия связывается с банком, чтобы снять деньги со счёта плательщика. Он не видит, как сервер опрашивает банк: хватает ли денег на карте, правильно ли введены данные, не состоит ли карта в чёрном списке. С банком общается вспомогательный код — «веб-сервис». Ещё есть второй веб-сервис, для сбора метрик, и третий, для имейл-рассылок.
По сравнению с этим, на сайте блинной обрабатывать нечего: надо просто показать статичный текст и изображения. Пара незамысловатых страничек безо всяких приложений и сервисов.
К чему готовиться
Веб-приложение помогает компании расти благодаря тому, что:
Но вместе с тем оно приносит новые трудности:
Коротко о главном
В обиходе под сайтом понимают справочную: лендинг, портфолио, визитку. Пользователь ничего не делает, а только читает, что написано.
Под веб-приложением имеют в виду нечто более сложное: интернет-магазин, онлайн-банк, электронные госуслуги. Там есть взаимодействие с клиентом.
Говоря «мы разрабатываем веб-сервис», подразумевают, что пишут вспомогательный код. Для сбора метрик, например.
Технически приложение и сервис — не виды продуктов, а детали пазла. Малый оффлайн-бизнес обойдётся без них, средний и крупный онлайн-бизнес — нет. Пиццерия с онлайн-заказами никак не может быть простым сайтом.
В чем разница между сервером приложений и веб-сервером?
В чем разница между сервером приложений и веб-сервером?
В большинстве случаев эти термины веб-сервер и сервер приложений используются взаимозаменяемо.
Ниже приведены некоторые ключевые различия в возможностях веб-сервера и сервера приложений:
Это подробный ответ с некоторыми сценариями, чтобы четко понять разницу, сходство и то, как оба могут работать вместе и все
Информация, передаваемая назад и вперед между сервером и его клиентом, не ограничивается простой разметкой дисплея, а взаимодействует между ними.
Пример:
Сценарий 1. Веб-сервер без сервера приложений.
у вас есть интернет-магазин только с веб-сервером и без сервера приложений. На сайте будет отображаться, где вы можете выбрать продукт. Когда вы отправляете запрос, сайт выполняет поиск и возвращает результат HTML своему клиенту. Веб-сервер отправляет ваш запрос непосредственно на сервер базы данных (наберитесь терпения, я объясню этот в нашем следующем слепке) и ждем ответа. После получения веб-сервер формулирует ответ в HTML-файл и отправляет его в веб-браузер. Эта двусторонняя связь между сервером и сервером базы данных происходит каждый раз, когда выполняется запрос.
Сценарий 2: веб-сервер с сервером приложений
если запрос, который вы хотите выполнить, уже был выполнен ранее, и с тех пор данные не изменились, сервер сгенерирует результаты, не отправляя запрос на сервер базы данных. Это позволяет выполнять запрос в режиме реального времени, когда второй клиент может получить доступ к той же информации и получать надежную информацию в режиме реального времени, не отправляя еще один повторяющийся запрос на сервер базы данных. Сервер в основном действует как промежуточное звено между сервером базы данных и веб-сервером. Это позволяет извлекать информацию для повторного использования в первом сценарии, поскольку эта информация встроена в определенную и «настроенную» HTML-страницу, это не процесс повторного использования. Второй клиент должен будет снова запросить информацию и получить другую HTML-страницу с запрошенной информацией, что крайне неэффективно.
Для поддержки такого множества сложных задач этот сервер должен иметь встроенную избыточность, большую вычислительную мощность и большой объем оперативной памяти для обработки всех данных, которые он извлекает в режиме реального времени.
Надеюсь это поможет.
Оба термина очень общие, один содержит другой, и в некоторых случаях наоборот.
Веб-сервер : передает контент в Интернет по протоколу http.
Сервер приложений : размещает и предоставляет бизнес-логику и процессы.
Я думаю, что главное в том, что веб-сервер предоставляет все через протокол http, в то время как сервер приложений не ограничен этим.
Тем не менее, во многих сценариях вы обнаружите, что веб-сервер используется для создания внешнего интерфейса сервера приложений, то есть он предоставляет набор веб-страниц, которые позволяют пользователю взаимодействовать с бизнес-правилами, найденными в сервер приложений.
веб сервер
Сервер приложений
Скажем, у нас есть крошечное приложение, как показано ниже (фрагмент из Flask ).
О какой бизнес-логике говорят все остальные? Итак, поскольку URL-адрес отображается где-то конкретно в нашей кодовой базе, мы гипотетически показываем некоторую логику о том, как работает наша программа.
резюмируя
Обратите внимание, что вы можете создать веб-сервер с кодом сервера приложений. Это делается в некоторых случаях во время разработки, когда вы не хотите, чтобы на вашем компьютере работало несколько миллиардов различных серверов.
Как указали Рутеш и Дж.М.Сервера, различие нечеткое. Исторически они были разными, но на протяжении 90-х годов эти две ранее разные категории смешивали и эффективно объединяли. На данный момент, вероятно, лучше всего представить, что категория продукта «Сервер приложений» является строгим расширенным набором категории «веб-сервер».
В параллельной категории сервер приложений развивался и существовал долгое время. Компании поставляли продукты для Unix, такие как Tuxedo, TopEnd, Encina, которые были философски получены из сред управления и мониторинга приложений мэйнфреймов, таких как IMS и CICS. Microsoft предложила Microsoft Transaction Server (MTS), который впоследствии превратился в COM +. В большинстве этих продуктов указаны «закрытые» протоколы связи для конкретных продуктов, позволяющие подключать «жирных» клиентов к серверам. (Для Encina протокол связи был DCE RPC; для MTS это был DCOM и т. Д.) В 1995/96 году эти традиционные продукты для серверов приложений начали внедрять базовые возможности HTTP-связи, сначала через шлюзы. И линии начали стираться.
Веб-серверы становились все более и более зрелыми в отношении обработки более высоких нагрузок, большего количества параллелизма и улучшения функций. Серверы приложений предоставляют все больше возможностей связи на основе HTTP.
На данный момент грань между «сервером приложений» и «веб-сервером» нечеткая. Но люди продолжают использовать термины по-разному, в качестве акцента. Когда кто-то говорит «веб-сервер», вы часто думаете о HTTP-ориентированных веб-интерфейсах и приложениях. Когда кто-то говорит «Сервер приложений», вы можете подумать, что «большие нагрузки, корпоративные функции, транзакции и очереди, многоканальная связь (HTTP + больше)». Но зачастую это один и тот же продукт, который удовлетворяет обоим наборам требований к рабочей нагрузке.