Web сервис как пишется

Поиск ответа

Вопрос № 296685

Здравствуйте! Уточните, пожалуйста, нужнали запятая в этом объявлении? : Приглашаем к сотрудничеству владельцев Web- камер ? для трансляции в эфире нашего чата. Спасибо.

Ответ справочной службы русского языка

Добрый день, подскажите, пожалуйста, допустимо ли написание web- проект? Или все же правильно веб-проект? Спасибо.

Ответ справочной службы русского языка

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

Как правильно написать, web- страница или веб-страница? Спасибо

Ответ справочной службы русского языка

Пожалуйста, ответьте на вопрос:
Демо- Web- интерфейс — как правильно? Верно ли расставлены дефисы?
спасибо

Ответ справочной службы русского языка

Орфографически верно: демо-веб-интерфейс .

Здравствуйте! Подскажите, пожалуйста, можно ли писать web- сайт или обе части это слова должны быть написаны по-русски: веб-сайт? Спасибо!

Ответ справочной службы русского языка

Предпочтительно писать слово веб-сайт.

Здравствуйте! Я всегда задумывался над тем, как правильно писать: веб-сайт, вебсайт или web- сайт? Также возникают вопросы с такими словами как «вебмастер» и «веб-дизайнер», «веб-программист» (мне действительно кажется что первое пишется слитно, а второе и третье — через дефис). Допустимо ли употребление слова «веб» в значении «сеть, интернет»?

Ответ справочной службы русского языка

Правильное написание: веб-сайт (именно такое написание рекомендует «Русский орфографический словарь» РАН). В значении «Интернет» существительное Веб пишется с большой буквы. Слова с первой частью веб. ( веб-программист, веб-дизайнер, веб-мастер ) пишутся через дефис, со строчной буквы.

Здравствуйте! Скажите пожалуйста, правильно ли написание слова «интернет» в середине предложения с большой буквы, и склоняется ли это слово? «Размещение электронной версии каталога в Интернете на web- странице выставочной компании.»

Ответ справочной службы русского языка

Да, слово _Интернет_ пишется с большой буквы и склоняется. Вы написали верно.

Добрый день! У меня к Вам оргомная прсьба. Знакомые открывают новое направление и попросили написать для них коммерческое предложение, что я и сделала. Но я не уверена, что здесь нет орфографических ошибок. Пожалуйста, проверьте текст. С благодарностью приму все замечания и исправления. Уважаемые дамы и господа! Не для кого не секрет, что в последнее время все большей популярностью пользуется всемирная сеть Интернет. В связи с этим наша компания запускает новый проект — _______________ ___________________ – это информационно-справочный Интернет-сайт, посвященный развлечениям и досугу. Поскольку, наш город растет и развивается с неумолимой скоростью и почти каждый день открываются новые торговый центры, кафе, клубы и прочие заведения, мы считаем, что столица давно нуждается в таком проекте. На сайте будет размещаться информация рекламного характера, позволяющая жителям и гостям нашей столицы легко ориентироваться и выбирать для себя нужное из огромного количества предложений. Одним из неоспоримых преимуществ Интернет сайта является то, что Ваша информация работает на Вас 24 часа в сутки, 7 дней в неделю, при необходимости она обновляется. Наша цель – собрать информацию обо всех организациях, деятельность которых, так или иначе, соприкасается с досугом и развлечениями. Мы отлично понимаем, что у нас огромная целевая аудитория и для Вашего удобства мы сформировали 3 варианта размещения информации. Вы можете выбрать тот пакет, который оптимально подходит для Вас. У многих фирм существуют собственные web- сайты, но зачастую их посещаемость оставляет желать лучшего, ведь тратить огромные средства на продвижение в сети иногда бывает не целесообразно. _________________ – это идеальный вариант рекламы не только Вашей фирмы, но и Вашего персонального электронного представительства. Мы постоянно работаем над продвижением сайта и стремимся занять лидирующие позиции. Помимо прочего на сайте так же будут размещаться новостная лента, интересные фотографии о нашем городе, рубрика «Халява», в которой Вы можете размещать информацию о предстоящих мероприятиях, о скидках, распродажах, акциях и т.д. совершенно бесплатно, прогноз погоды, курсы валют и многое другое. P.S.: Поскольку наш проект пока только набирает обороты нам хочется знать Ваше мнение. Будем рады принять Ваши пожелания, предложения и замечания по e-mail.

Ответ справочной службы русского языка

«Справочное бюро» не занимается проверкой текстов.

Добрый день! Скажите, пожалуйста, нужна ли запятая после «однако» в следующем предложении: Однако когда запрашивается динамическая страница, действия web- сервера не столь однозначны. Спасибо.

Ответ справочной службы русского языка

Как правильно писать « Web- страницы»?

Ответ справочной службы русского языка

Здравствуйте, скажите пожалуйста, как следует писать Web- страница или web- страница? Спасибо, Ирина

Ответ справочной службы русского языка

В русском языке есть слово _веб-страница_.

Запятая ставится в обоих случаях или нигде? Спасибо. Каталоги самых известных поисковых машин содержат ссылки на более, чем миллионы web- ресурсов. Каталог содержит более, чем 150 наименований продукции.

Ответ справочной службы русского языка

Запятые не ставятся в обоих случаях.

Web- сайт[,] как эффективный инструмент pr-кампании.

Ответ справочной службы русского языка

Подскажите, пожалуйста, как правильно: «закончить дела по окончанИЮ рабочего дня» или «закончить дела по окончанИИ рабочего дня»? И еще одни вопрос: Во фразе «Если Вы разбираетесь в компьютерных технологих и знаете, чем отличается браузер от web- обозревателя Вы наш главный кандидат» правильно ли расставлены знаки препинания?

Ответ справочной службы русского языка

Правильно: _по окончании рабочего дня_.
Правильно: _Если Вы разбираетесь в компьютерных технологиях и знаете, чем отличается браузер от web- обозревателя, Вы наш главный кандидат_.

Источник статьи: http://new.gramota.ru/spravka/buro/search-answer?s=web-

Веб-сервисы в теории и на практике для начинающих

Что такое веб-сервисы?

Прежде всего, веб-сервисы (или веб-службы) — это технология. И как и любая другая технология, они имеют довольно четко очерченную среду применения.

Если посмотреть на веб-сервисы в разрезе стека сетевых протококолов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP.

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

Но и сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки.

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

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

Именно с появлением веб-сервисов развилась идея SOA — сервис-ориентированной архитектуры веб-приложений (Service Oriented Architecture).

Протоколы веб-сервисов

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

SOAP (Simple Object Access Protocol) — по сути это тройка стандартов SOAP/WSDL/UDDI
REST (Representational State Transfer)
XML-RPC (XML Remote Procedure Call)

На самом деле, 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.

Создадим структуру данных.

Таблица номиналов обмена (exchange):

Для работы с базой данных воспользуемся ORM слоем на базе пакета PHP Doctrine. Реализуем граббер:

класс Grubber (models/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 Мб).

Заключение

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

Кроме того мы увидели, что реализация веб-сервиса — задача довольно простая при использовании современного инструментария, который позволяет сконцентрироваться, в первую очередь, на разработке функциональности самого сервиса, не заботясь о низкоуровневой реализации протоколов.

Автор надеется, что данный материал будет действительно полезен тем, кто становится на тропу разработки веб-служб.

Источник статьи: http://habr.com/ru/post/46374/

Что такое веб-сервисы и как они используются

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

Веб-сервис или веб-сайт?

Начнем с понятий. Веб-сервис (web-service) — это программа в интернете, которая оказывает услугу или отвечает на определенное требование пользователя. Например, электронная почта отправляет письма, поисковик Google ищет информацию в интернете, а сайт с погодой показывает прогноз. Веб-сервис , который еще называют веб-службой — это веб-приложение.

Веб-сайт — это тоже веб-приложение, но с другой функциональностью. Это страница или страницы в интернете, которые содержат информацию о чем-то. Бизнес использует оба вида веб-приложений. Например, если у вас тур-агентство, то вам подойдет и веб-сайт, и веб-сервис . Вот как между ними выбрать:

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

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

Зри в корень: архитектура и протоколы

Архитектура — это набор компонентов веб-приложения и способ взаимодействия между ними. К компонентам веб-приложения относятся:

пользовательский интерфейс;
программный интерфейс (API);
базы данных;
внешние сервисы — помогают веб-сервису реализовывать бизнес-логику. Например, брокер сообщений или эквайринг;
кэш.

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

Архитектура и ее компоненты

Фактически архитектура делится на 2 части:

Клиентская (frontend) — то, что видит пользователь на экране;
Серверная (backend) — то, что находится за экраном, т.е. запрограммированная реакция на действия пользователя.

Чтобы представить себе архитектуру веб-сервиса, подумайте об архитектуре здания. Вот вы видите фасад дома: количество этажей, форму окон, крышу, ступеньки и дверь. Это все клиентская часть, фронтенд. А потом вы заходите внутрь и видите, какие там комнаты, как они расположены, из какой комнаты можно пройти в другую, а из какой нельзя. Где есть лестница и куда она ведет. Параллельно замечаете, что вот здесь зря не сделали дверь, ведь так можно быстрее добраться до другой части дома, а здесь можно добавить лестницу, чтобы попасть на мансарду, минуя два этажа. Это уже серверная часть, бэкенд. А если здание плохо спроектировано, то оно вообще может обрушиться.

Примерно так же построен и веб-сервис , с той лишь разницей, что бэкенд пользователям не виден.

Протоколы и технологии

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

HTTP, HTTPS, FTP, TCP/IP— сетевые протоколы или протоколы передачи данных;
SSL, TLS— протокол шифрования, нужен для безопасной передачи или хранения данных;
API — набор или описание способов как одна программа может обращаться к другой;
XML и JSON — структурируют информацию для обмена;
WSDL ( Web Services Description Language) — это язык описания веб-сервиса . С помощью него клиентский сервис понимает, как можно пользоваться веб-сервисом;
SOAP — это простой протокол доступа к объектам. Он работает через HTTP и позволяет взаимодействовать приложениям на его основе.

Как работает веб-сервис на примере банка

На самом деле, если вы не веб-разработчик и не собираетесь самостоятельно писать код для веб-приложения, то знать все протоколы и компоненты веб-приложения необязательно. Главное понимать, как работает веб-сервис. Тогда получится правильно сформулировать задачу разработчиками и проверить как она выполнена.

Разберем как работает веб-сервис на примере заявки клиента на выпуск кредитной карты в банке. Банку надо разгрузить операторов, которые формируют и обрабатывают заявки. Для этого сделали веб-приложение :

1. Пользователь заходит на сайт банка и переходит на страницу с формой заявки. Заполняет ее и нажимает «Отправить». Таким образом производится запрос на бэкенд .

2. Бэкенд обрабатывает заявку и определяет, правильно ли она заполнена. Если нет, то веб-сервис возвращает ответ клиенту, о том, что произошла ошибка. Если правильно, то он отправляет заявку в сервис управления заявками и ждет ответа.

3. Сервис управления заявками принимает или не принимает ее. Потом отправляет сообщение обратно в веб-сервис . Если заявка отклонена, то веб-сервис сообщает клиенту, что произошла ошибка. Если заявка принята, то веб-сервис передает данные брокеру сообщений.

4. В брокере сообщений заявка встает в очередь на распределение между менеджерами. После этого клиент получает сообщение, что заявка принята и с ним свяжется менеджер.

Клиент не видит пункты 2-4, так как они происходят на стороне бэкенда. Ему виден лишь результат — заявка принята или произошла ошибка.

Хотите еще пример веб-сервиса? По ссылке ниже мы рассказываем, как за 3 месяца разработали маркетплейс для видеоконтента. В кейсе подробно описана реализация веб-сервиса, какие нюансы обсуждали с заказчиком, с какими вопросами и сложностями столкнулись и как их решили.

Зачем нужны веб-сервисы?

Есть сферы бизнеса, где веб-приложения принесут пользу компаниям: фитнес-индустрия, ресторанная сфера и доставка еды, туризм, медицина. Ценность веб-сервисов для бизнеса можно разделить на две составляющие:

Внутренняя. Помогает автоматизировать и упростить процесс бизнеса. Например, сделать отчет, наладить обмен информацией между отделами или следить за наличием товара;
Внешняя. Это взаимодействие с пользователями. Например, онлайн-запись на услуги, заказ товаров или услуг.

Функциональность веб-приложения и его применение ограничивается только вашей фантазией. Но от того, как реализован веб-сервис и что он «умеет», во многом зависит успех стартапа.

У вас есть идеи для веб-сервиса? Напишите нам и мы поможем их реализовать. Команда Purrweb разрабатывает веб-приложения с нуля: помогаем анализировать рынок, прорабатываем бизнес-логику и UI/UX дизайн, создаем цифровой продукт и поддерживаем работу веб-сервиса.

Источник статьи: http://www.purrweb.com/ru/blog/chto-takoe-veb-servisy-i-kak-oni-ispolzuyutsya/

Веб-сервис

Веб-служба, веб-сервис (англ. web service ) — программная система, идентифицируемая строкой интерфейсы определены на языке XML, и передаваемых с помощью интернет-протоколов. Веб-служба является единицей модульности при использовании сервисно-ориентированной архитектуры приложения.

Содержание

Используемые стандарты

Достоинства веб-служб

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

Недостатки веб-служб

Меньшая производительность и больший размер сетевого трафика по сравнению с технологиями CORBA, DCOM за счет использования текстовых XML-сообщений

Платформы

Веб сервисы развёртываются на серверах приложений. Несколько серверов приложений:

Axis и Tomcat (оба являются проектами Apache).
Mono development platform от Microsoft .NET серверы от Sun Microsystems (основан на Jakarta Tomcat)
объектно ориентированным web application server написанным на WebSphere Application Server от Apache и платформе J2EE)
Macromedia
Cordys WS-AppServer
infoRouter Document Management software Web Services API
GNU Project
JOnAS (является частью ObjectWeb Open Source initiative)
BEA Systems
Web Application Server от SAP (Web AS является ключевой частью стека SAP NetWeaver)
Pramati Application Server от Pramati Technologies Limited
OpenEdge Platform от Progress Software
Oracle Application Server от Oracle Corporation
Zend Framework — open source от Zend Technologies
Google App Engine — платформа для высокомасштабируемых приложений, использующих инфраструктуру компании

Ссылки

Wikimedia Foundation . 2010 .

Полезное

Смотреть что такое «Веб-сервис» в других словарях:

Веб сервис — Веб служба. Веб служба, веб сервис (англ. web service) программная система, идентифицируемая строкой интерфейсы определены на языке XML, и передаваемых с помощью интернет протоколов. Веб служба является единицей модульности при использовании… … Википедия

веб-сервис — сущ., кол во синонимов: 1 • сервис (13) Словарь синонимов ASIS. В.Н. Тришин. 2013 … Словарь синонимов

веб-сервис — (МСЭ Т J.365). [http://www.iks media.ru/glossary/index.html?glossid=2400324] Тематики электросвязь, основные понятия EN web serviceWS … Справочник технического переводчика

веб-сервис — в еб с ервис, а … Русский орфографический словарь

Веб-сайт — Запрос «сайт» перенаправляется сюда; см. также другие значения. Веб сайт (от англ. website: web «паутина», «сеть» и site «место», букв. «место в сети») или просто сайт в компьютерной сети объединённая под одним адресом (доменным … Википедия

Система вопросов и ответов (веб-сервис) — У этого термина существуют и другие значения, см. Система вопросов и ответов. Система вопросов и ответов вид веб сайтов, позволяющий пользователям задать вопрос или ответить на уже заданные вопросы. Таким образом формируется социальная сеть … Википедия

Веб служба — Веб служба. Веб служба, веб сервис (англ. web service) программная система, идентифицируемая строкой интерфейсы определены на языке XML, и передаваемых с помощью интернет протоколов. Веб служба является единицей модульности при использовании… … Википедия

сервис — служба, услуги, обслуживание, стервис, услуга Словарь русских синонимов. сервис см. обслуживание Словарь синонимов русского языка. Практический справочник. М.: Русский язык. З. Е. Александрова … Словарь синонимов

Веб-служба — У этого термина существуют и другие значения, см. Служба. Веб служба Веб служба, веб сервис (англ. web service) идентифицируемая веб адресом программная система со стандартизированными интерфейсами. Веб службы могут взаимодействовать… … Википедия

Сервис форумов — Значимость предмета статьи поставлена под сомнение. Пожалуйста, покажите в статье значимость её предмета, добавив в неё доказательства значимости по частным критериям значимости или, в случае если частные критерии значимости для… … Википедия

Источник статьи: http://dic.academic.ru/dic.nsf/ruwiki/835646

Пишем свой первый RESTful веб-сервис на ASP.NET

Что такое RESTful веб-сервис?

REST используется для создания легковесных, поддерживаемых и масштабируемых веб-сервисов. Сервис, построенный на REST архитектуре, называется RESTful-сервисом. REST использует HTTP — базовый сетевой протокол.

Ключевые составляющие RESTful

Веб-сервисы прошли долгий путь с момента их появления. В 2002 году W3C выпустил определения WSDL и SOAP веб-сервисов. Это сформировало стандарт по созданию веб-сервисов.

В 2004 году W3C выпустил определение ещё одного стандарта под названием RESTful. В последние годы этот стандарт стал довольно популярным. На данный момент он используется многими известными сайтами по всему миру, в число которых входит и Twitter.

REST — это способ получить доступ к ресурсам, которые находятся в определённой среде. Например, у вас может быть сервер с важными документами или фотографиями. Всё это — ресурсы. Если клиенту, скажем, веб-браузеру, нужны какие-то из этих ресурсов, ему необходимо отправить запрос на сервер для получения доступа к ним. REST определяет, как может осуществляться доступ к этим ресурсам.

Ключевые составляющие реализации RESTful:

Ресурсы. Допустим, у нас есть сервер с записями о сотрудниках, а адрес веб-приложения — http://server.com. Чтобы получить доступ к записи сотрудника, мы можем выполнить команду http://server.com/employee/1, которая говорит серверу предоставить запись сотрудника под номером 1.
Методы запросов. Они говорят, что вы хотите сделать с ресурсом. Браузер использует метод GET, чтобы проинформировать удалённую сторону о том, что он хочет получить данные. Кроме GET есть много других методов вроде POST, PUT и DELETE. В примере с http://server.com/employee/1 выше браузер на самом деле использует метод GET, поскольку он хочет получить данные о сотруднике.
Заголовки запроса. Это дополнительные инструкции, посылаемые вместе с запросом. Они могут определять тип необходимого ресурса или подробности авторизации.
Тело запроса. Это данные, отправляемые вместе с запросом. Данные обычно отправляются, когда выполняется POST-запрос к REST веб-сервису. Зачастую в POST-запросе клиент говорит серверу, что он хочет добавить на него ресурс. Следовательно, тело запроса содержит подробную информацию о ресурсе, который необходимо добавить на сервер.
Тело ответа. Это основная часть ответа. В нашем примере на запрос http://server.com/employee/1 сервер мог бы прислать XML-документ с данными о сотруднике в теле ответа.
Коды ответа. Эти коды возвращаются сервером вместе с ответом. Например, код 200 обычно означает, что при отправке ответа не произошло никакой ошибки.

Методы RESTful

Представим, что у нас есть RESTful веб-сервис по адресу http://server.com/employee/. Когда клиент делает запрос к нему, он может указать любой из обычных HTTP-методов вроде GET, POST, DELETE и PUT. Ниже указано, что могло бы произойти при использовании соответствующего метода:

POST — с его помощью можно создать новую запись сотрудника;
GET — с его помощью можно запросить список сотрудников;
PUT — с его помощью можно обновить данные сотрудников;
DELETE — с его помощью можно удалять записи сотрудников.

Посмотрим на это с точки зрения одной записи. Допустим у нас есть запись сотрудника под номером 1. Вот какое значение могли бы иметь следующие действия:

POST — этот метод нельзя применить, так как сотрудник с номером 1 уже существует;
GET — этот метод можно использовать для получения данных о сотруднике под номером 1;
PUT — этот метод можно использовать для обновления данных сотрудника под номером 1;
DELETE — этот метод можно использовать для удаления записи сотрудника под номером 1.

Почему RESTful

В основном популярность RESTful обусловлена следующими причинами:

1. Разнородные языки и среды — это одна из основных причин:

У веб-приложений, написанных на разных языках, есть возможность взаимодействовать друг с другом;
Благодаря RESTful эти приложения могут находиться в разных средах, будь то Windows или Linux.

Представим, что для работы с такими сайтами как Twitter, Google и т. д. клиентскому приложению нужно знать, на каких языках и на какой платформе они написаны. Основываясь на этих знаниях, мы могли бы написать код для взаимодействия с ними, однако это превратилось бы в сущий ад.

Twitter и Google дают доступ к их функциональности посредством RESTful веб-сервисов. Это даёт возможность любому клиентскому приложению взаимодействовать с этими сервисами с помощью REST.

2. Технологический бум – сегодня всё должно работать на разнообразных устройствах, будь то смартфон, ноутбук или кофеварка. Представляете, каких бы усилий стоило наладить взаимодействие этих устройств с помощью обычных веб-приложений? RESTful API делают эту задачу гораздо проще, поскольку, как было упомянуто выше, вам не нужно знать, что у устройства «под капотом».

3. Появление облачных сервисов — всё переезжает в облако. Приложения медленно перемещаются в облачные системы вроде Azure или Amazon, которые предоставляют большое количество API на основе RESTful архитектуры. Следовательно, приложения должны разрабатываться таким образом, чтобы они были совместимы с облаком. Так как все облачные архитектуры работают на основе REST, логично разрабатывать веб-сервисы тоже на REST-архитектуре, чтобы извлечь максимум пользы из облачных сервисов.

RESTful архитектура

Приложение или архитектура считается RESTful, если ей присущи следующие характеристики:

Состояние и функциональность представлены в виде ресурсов — это значит, что каждый ресурс должен быть доступен через обычные HTTP-запросы GET, POST, PUT или DELETE. Так, если кто-то хочет получить файл на сервере, у них должна быть возможность отправить GET-запрос и получить файл. Если он хочет загрузить файл на сервер, то у него должна быть возможность использовать POST или PUT-запрос. Наконец, если он хочет удалить файл, должна быть возможность отправить запрос DELETE.
Архитектура клиент-сервер, отсутствие состояния (stateless) и поддержка кеширования:
- Клиент-сервер — обычная архитектура, где сервером может быть веб-сервер, на котором размещено приложение, а клиентом — обычный веб-браузер;
- Архитектура без сохранения состояния означает, что состояние приложения не сохраняется в REST. Например, если вы удалили ресурс с сервера командой DELETE, то даже при получении положительного кода ответа нет гарантий, что он действительно был удалён. Чтобы убедиться, что ресурс удалён, необходимо отправить GET-запрос. С его помощью можно запросить ресурсы, чтобы посмотреть, присутствует ли там удалённый.

Принципы и ограничения RESTful

Архитектура REST основывается на нескольких характеристиках, которые описаны ниже. Любой RESTful веб-сервис должен им соответствовать, чтобы называться таковым. Эти характеристики также известны как принципы проектирования, которым нужно следовать при работе с RESTful-сервисами.

RESTful клиент-сервер

Это самое важное требование REST-архитектуры. Оно означает, что на сервере располагается RESTful веб-сервис, который предоставляет необходимую функциональность клиенту. При отправке клиентом запроса к веб-сервису сервер должен либо отклонить его, либо принять и предоставить соответствующий ответ.

Отсутствие состояния

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

Концепция кеша помогает нивелировать проблему отсутствия состояния. Так как каждый запрос клиента независим по своей природе, порой клиент может повторно отправить какой-нибудь запрос. Запрос придёт на сервер, и сервер отправит ответ. Это увеличивает сетевой трафик. Кеш позволяет клиенту хранить прежде отправленные запросы и ответы. Поэтому при повторной отправке запроса он не будет отправлен серверу; вместо этого необходимые данные будут взяты из кеша.

Многослойная система

Суть этой концепции заключается в том, что любой дополнительный слой вроде промежуточного (слой, в котором создаётся бизнес-логика; это может быть дополнительный сервис, с которым клиент взаимодействует до сервера) можно поместить между клиентом и сервером, на котором располагается RESTful веб-сервис. Однако этот слой должен быть внедрён прозрачно, чтобы он не нарушил взаимодействия клиента и сервера.

Единообразие интерфейса

Это фундаментальное требование дизайна RESTful-сервисов. RESTful работает на уровне HTTP и использует нижеприведённые методы для работы с ресурсами на сервере:

POST — для создания ресурса;
GET — для его получения;
PUT — для его обновления;
DELETE — для его удаления.

Создаём свой первый RESTful веб-сервис с ASP.NET

Веб-сервисы можно создавать на множестве языков. Многие IDE можно использовать для создания REST-сервисов.

Мы напишем REST-приложение на .NET, используя Visual Studio.

Наш сервис будет работать со следующим набором данных «туториалов»:

TutorialId	TutorialName
0	Arrays
1	Queues
2	Stacks

Мы реализуем следующие RESTful методы:

GET Tutorial — при его вызове клиент получает все доступные TutorialName;
GET Tutorial/TutorialId — при его вызове клиент получает TutorialName, соответствующее переданному TutorialId;
POST Tutorial/TutorialName — при его вызове клиент отправляет запрос на добавление туториала с переданным TutorialName;
DELETE Tutorial/TutorialId — при его вызове клиент отправляет запрос на удаление туториала с TutorialName, соответствующему переданному TutorialId.

Теперь создадим шаг за шагом наш веб-сервис.

Нам нужно создать пустое ASP.NET веб-приложение. Для этого откройте Visual Studio и создайте новый проект:

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

В открывшемся окне перейдите по вкладкам C# → Веб. Выберите опцию «Веб-приложение ASP.NET (.NET Framework)» и введите необходимые данные проекта вроде названия и каталога:

Если далее у вас появилось следующее окно, выбирайте вариант «Пустой»:

После этого должно открыться окно, где в обозревателе решений можно увидеть наш проект:

Теперь нужно создать файл нашего RESTful веб-сервиса. Для этого сначала нажмите Ctrl+Shift+A, либо кликните правой кнопкой по файлу проекта Webservice.REST и выберите опции Добавить → Создать элемент…:

В открывшемся окне найдите опцию «Служба WCF (с поддержкой технологии AJAX)» и дайте ей имя TutorialSevice.svc:

Прим. перев. Если вы не можете найти эту опцию, то попробуйте открыть Visual Studio Installer и загрузить часть среды, ответственную за работу с ASP.NET:

После выбора опции «Служба WCF (с поддержкой технологии AJAX)» Visual Studio создаст код, который будет основой для реализации веб-сервиса. WCF (Windows Communication Foundation) — библиотека, необходимая для налаживания взаимодействия между приложениями с помощью разных протоколов вроде TCP, HTTP и HTTPS. AJAX позволяет асинхронно обновлять веб-страницы, обмениваясь небольшими объёмами информации с сервером.

Шаг четвёртый

Теперь нам нужно внести изменения в конфигурационный файл Web.config. Он содержит настройки, необходимые для правильной работы приложения. Наше изменение позволит приложению отправлять и принимать данные как RESTful веб-сервис.

Откройте конфигурационный файл:

В открывшемся файле найдите строку и замените её на .

Пора приниматься за код. Откройте файл TutorialService.svc. Сначала добавим код для отображения наших данных. Создадим список со строками «Arrays», «Queues» и «Stacks». Они будут отражать имена доступных туториалов:

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

Строка [WebGet(UriTemplate=»/Tutorial»)] — самая важная. Она нужна для определения того, как мы будем вызывать этот метод по URL. Если наш сервис расположен по адресу http://localhost:52645/TutorialService.svc и в его конец мы добавим «/Tutorial» и получим http://localhost:52645/TutorialService.svc/Tutorial, то будет вызван вышеприведённый код. Атрибут WebGet является параметром, который позволяет GetAllTutorials() быть RESTful-методом, который можно вызвать GET-запросом.

В самом методе GetAllTutorials() находится код, который собирает все названия туториалов и возвращает их в одной строке.

Шаг седьмой

Код, показанный ниже, нужен для того, чтобы вернуть соответствующий TutorialName при получении GET-запроса с TutorialId :

Как и в предыдущем примере, первая строка — самая важная, так как определяет то, как мы будем вызывать этот метод. Если мы сделаем запрос http://localhost:52645/TutorialService.svc/Tutorial/1, то веб-сервис должен вернуть TutorialName , соответствующий TutorialId с индексом 1.

Метод GetTutorialByID() реализует описанную логику. Обратите внимание на то, что мы приводим TutorialId к типу Integer . Это связано с тем, что всё передаваемое в адресную строку браузера является строкой. А поскольку индексом списка не может быть строка, мы добавляем код, необходимый для преобразования в число.

Шаг восьмой

Настала очередь кода для метода POST, который будет вызываться каждый раз, когда мы захотим добавить строку в наш список туториалов с помощью POST-запроса:

На первой строке находится атрибут WebInvoke , прикреплённый к нашему методу, что позволяет вызывать его с помощью POST-запроса. Для атрибутов RequestFormat и ResponseFormat мы указываем JSON, так как именно с этим форматом работает RESTful веб-сервис.

Шаг девятый

Осталось добавить метод для работы с DELETE-запросами. Он будет вызываться каждый раз, когда мы будем пытаться удалить существующее значение из списка с помощью DELETE-запроса:

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

В самом методе DeleteTutorial() мы приводим переданный TutorialId к типу Integer и удаляем из списка соответствующий элемент.

В итоге код должен выглядеть так (не учитывая элементов, которые были там изначально):

Запускаем наш веб-сервис

Мы создали наш веб-сервис, пора его запустить.

Сначала кликните правой кнопкой по файлу проекта Webservice.REST и выберите опцию «Назначить автозагружаемым проектом», чтобы Visual Studio запустила этот проект при запуске всего решения:

Теперь осталось запустить проект. Рядом с кнопкой запуска будет указано имя браузера, в котором будет запускаться проект. Автоматически будет предложен браузер по умолчанию, однако вам ничто не мешает выбрать другой:

После запуска должно открыться окно браузера. Перейдите по адресу http://localhost:51056/TutorialService.svc/Tutorial и в зависимости от выбранного браузера вы увидите что-то такое:

Прим. перев. В вашем случае сервис может запуститься на localhost с другим портом. Далее в статье мы будем использовать значение 51056, однако не забывайте заменять его на своё, когда будете пытаться запускать примеры.

В этом примере браузер делает GET-запрос и тем самым вызывает написанный нами метод GetAllTutorials() , который возвращает список со всеми туториалами.

Тестируем веб-сервис

Выше мы увидели, как браузер делает GET-запрос для вызова GetAllTutorials() . Давайте проверим другие сценарии.

1. GET Tutorial/TutorialId — при вызове этого RESTful API клиент должен получить TutorialName , соответствующий переданному TutorialId .

Для вызова просто добавьте строку «/1» в конце URL, чтобы получить http://localhost:51056/TutorialService.svc/Tutorial/1. После перехода по этой ссылке вы должны увидеть следующее:

В этот раз был вызван метод GetTutorialByID() , который вернул туториал с индексом 1 — «Queues».

2. POST Tutorial/TutorialName — при вызове этого API клиент отправляет запрос на добавление переданного TutorialName , который сервер должен добавить в список. В этот раз нам понадобится инструмент Fiddler, который можно бесплатно скачать с официального сайта.

Запустите Fiddler и выполните следующие действия:

Переключитесь на вкладку Composer. Она используется для создания запросов, которые можно отравить любому веб-приложению;
Установите тип запроса равным «POST», а в URL вставьте адрес сервиса, в нашем случае это http://localhost:51056/TutorialService.svc/Tutorial;
В окне, где уже есть строка «User-Agent: Fiddler» добавьте строку «Content-Type: application/json». Наш сервис работает только с данными в формате JSON, помните?
Осталось ввести данные в поле «Request Body». Наш метод для POST-запросов принимает параметр str . Передавая строку <"str": "Trees">, мы указываем, что хотим добавить в список значение «Trees».

Нажмите на кнопку «Execute». После этого нашему сервису будет отправлен запрос на добавление «Trees».

Чтобы убедиться, что всё прошло как надо, получим список всех туториалов, перейдя по ссылке http://localhost:51056/TutorialService.svc/Tutorial. Вы должны увидеть следующее:

3. DELETE Tutorial/TutorialId — при вызове этого API клиент отправит запрос на удаление из списка TutorialName , которое соответствует переданному TutorialId .

Запустите Fiddler и выполните следующие действия:

Переключитесь на вкладку Composer;
Установите тип запроса равным «DELETE», а в URL вставьте адрес сервиса вместе с id элемента, который хотите удалить. Если мы хотим удалить второй элемент, то адрес будет http://localhost:51056/TutorialService.svc/Tutorial/1.

Нажмите на кнопку «Execute», чтобы отправить DELETE-запрос на удаление элемента «Queues».

Если мы опять запросим список всех туториалов, мы увидим, что их стало меньше на один:

Источник статьи: http://tproger.ru/translations/restful-service-asp-net/

Веб-сервисы – Краткое руководство

Различные книги и разные организации предоставляют разные определения для веб-сервисов. Некоторые из них перечислены здесь.

Веб-сервис – это любое программное обеспечение, которое доступно через Интернет и использует стандартизированную систему обмена сообщениями XML. XML используется для кодирования всех сообщений в веб-сервис. Например, клиент вызывает веб-службу, отправляя сообщение XML, а затем ожидает соответствующего ответа XML. Поскольку вся связь осуществляется в XML, веб-сервисы не привязаны к какой-либо одной операционной системе или языку программирования – Java может общаться с Perl; Приложения Windows могут общаться с приложениями Unix.

Веб-службы – это автономные, модульные, распределенные, динамические приложения, которые можно описывать, публиковать, размещать или вызывать по сети для создания продуктов, процессов и цепочек поставок. Эти приложения могут быть локальными, распределенными или сетевыми. Веб-сервисы построены на основе открытых стандартов, таких как TCP / IP, HTTP, Java, HTML и XML.

Веб-сервисы – это системы обмена информацией на основе XML, которые используют Интернет для прямого взаимодействия между приложениями. Эти системы могут включать программы, объекты, сообщения или документы.

Веб-сервис – это набор открытых протоколов и стандартов, используемых для обмена данными между приложениями или системами. Программные приложения, написанные на разных языках программирования и работающие на разных платформах, могут использовать веб-сервисы для обмена данными по компьютерным сетям, таким как Интернет, аналогично межпроцессному взаимодействию на одном компьютере. Эта совместимость (например, между приложениями Java и Python или Windows и Linux) обусловлена использованием открытых стандартов.

Таким образом, полный веб-сервис – это любой сервис, который –

Доступен через Интернет или частные (интранет) сети

Использует стандартизированную систему обмена сообщениями XML

Не привязан ни к одной операционной системе или языку программирования

Это самоописание через общую грамматику XML

Обнаруживается с помощью простого механизма поиска

Доступен через Интернет или частные (интранет) сети

Использует стандартизированную систему обмена сообщениями XML

Не привязан ни к одной операционной системе или языку программирования

Это самоописание через общую грамматику XML

Обнаруживается с помощью простого механизма поиска

Компоненты веб-сервисов

Базовая платформа веб-сервисов – это XML + HTTP. Все стандартные веб-сервисы работают с использованием следующих компонентов:

SOAP (простой протокол доступа к объектам)

UDDI (универсальное описание, обнаружение и интеграция)

WSDL (язык описания веб-сервисов)

SOAP (простой протокол доступа к объектам)

UDDI (универсальное описание, обнаружение и интеграция)

WSDL (язык описания веб-сервисов)

Все эти компоненты обсуждались в главе « Архитектура веб-сервисов» .

Как работает веб-сервис?

Веб-сервис обеспечивает связь между различными приложениями с использованием открытых стандартов, таких как HTML, XML, WSDL и SOAP. Веб-сервис принимает помощь –

SOAP для передачи сообщения

WSDL для описания доступности сервиса.

SOAP для передачи сообщения

WSDL для описания доступности сервиса.

На Solaris можно создать веб-службу на основе Java, доступную из вашей программы Visual Basic, которая работает в Windows.

Вы также можете использовать C # для создания новых веб-служб в Windows, которые могут быть вызваны из вашего веб-приложения, основанного на JavaServer Pages (JSP) и работающего в Linux.

пример

Рассмотрим простую систему управления счетами и обработки заказов. Сотрудники бухгалтерии используют клиентское приложение, созданное с помощью Visual Basic или JSP, для создания новых учетных записей и ввода новых заказов клиентов.

Логика обработки для этой системы написана на Java и находится на компьютере Solaris, который также взаимодействует с базой данных для хранения информации.

Шаги для выполнения этой операции следующие:

Клиентская программа связывает информацию о регистрации учетной записи в сообщение SOAP.

Это SOAP-сообщение отправляется веб-службе как тело HTTP-запроса POST.

Веб-служба распаковывает запрос SOAP и преобразует его в команду, понятную приложению.

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

Затем веб-служба упаковывает ответ в другое сообщение SOAP, которое отправляет обратно клиентской программе в ответ на свой HTTP-запрос.

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

Клиентская программа связывает информацию о регистрации учетной записи в сообщение SOAP.

Это SOAP-сообщение отправляется веб-службе как тело HTTP-запроса POST.

Веб-служба распаковывает запрос SOAP и преобразует его в команду, понятную приложению.

Почему веб-сервисы?

Вот преимущества использования веб-сервисов –

Разоблачение существующей функции в сети

Веб-сервис – это блок управляемого кода, который можно вызывать удаленно с помощью HTTP. То есть его можно активировать с помощью HTTP-запросов. Веб-сервисы позволяют вам раскрыть функциональность существующего кода через сеть. После того, как он выставлен в сети, другие приложения могут использовать функциональные возможности вашей программы.

Interoperability

Веб-сервисы позволяют различным приложениям общаться друг с другом и обмениваться данными и услугами между собой. Другие приложения также могут использовать веб-сервисы. Например, приложение VB или .NET может взаимодействовать с веб-службами Java и наоборот. Веб-сервисы используются, чтобы сделать платформу и технологию приложений независимыми.

Стандартизированный протокол

Веб-сервисы используют стандартизированный протокол промышленного стандарта для связи. Все четыре уровня (уровни Service Transport, XML Messaging, Service Description и Service Discovery) используют четко определенные протоколы в стеке протоколов веб-служб. Эта стандартизация стека протоколов дает бизнесу множество преимуществ, таких как широкий выбор, снижение стоимости из-за конкуренции и повышение качества.

Низкая стоимость связи

Веб-сервисы используют протокол SOAP поверх HTTP, поэтому вы можете использовать существующий недорогой интернет для реализации веб-сервисов. Это решение намного дешевле по сравнению с запатентованными решениями, такими как EDI / B2B. Помимо SOAP через HTTP, веб-службы также могут быть реализованы на других надежных транспортных механизмах, таких как FTP.

Веб-сервисы – Характеристики

Веб-сервисы имеют следующие специальные поведенческие характеристики –

XML-Based

Веб-сервисы используют XML на уровнях представления данных и передачи данных. Использование XML устраняет любые сетевые, операционные системы или привязки платформы. Приложения на основе веб-служб обладают высокой функциональной совместимостью на уровне ядра.

Слабо связанный

Потребитель веб-сервиса не привязан к этому веб-сервису напрямую. Интерфейс веб-службы может меняться со временем, не ставя под угрозу способность клиента взаимодействовать со службой. Тесно связанная система подразумевает, что клиентская и серверная логика тесно связаны друг с другом, подразумевая, что если один интерфейс изменяется, другой должен быть обновлен. Использование слабосвязанной архитектуры делает программные системы более управляемыми и упрощает интеграцию между различными системами.

Крупнозернистый

Объектно-ориентированные технологии, такие как Java, предоставляют свои услуги с помощью отдельных методов. Отдельный метод – это слишком хорошая операция, чтобы предоставить какие-либо полезные возможности на корпоративном уровне. Создание Java-программы с нуля требует создания нескольких детализированных методов, которые затем объединяются в грубый сервис, который используется клиентом или другим сервисом.

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

Способность быть синхронной или асинхронной

Синхронность относится к привязке клиента к выполнению услуги. При синхронных вызовах клиент блокирует и ждет, пока служба завершит свою работу, прежде чем продолжить. Асинхронные операции позволяют клиенту вызывать службу и затем выполнять другие функции.

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

Поддерживает удаленные вызовы процедур (RPC)

Веб-службы позволяют клиентам вызывать процедуры, функции и методы на удаленных объектах с использованием протокола на основе XML. Удаленные процедуры предоставляют входные и выходные параметры, которые должен поддерживать веб-сервис.

За последние несколько лет разработка компонентов с помощью Enterprise JavaBeans (EJB) и .NET Components все чаще становится частью архитектур и развертываний на предприятиях. Обе технологии распространяются и доступны через различные механизмы RPC.

Веб-сервис поддерживает RPC, предоставляя собственные сервисы, эквивалентные сервисам традиционного компонента, или переводя входящие вызовы в вызов компонента EJB или .NET.

Поддерживает обмен документами

Одним из ключевых преимуществ XML является его общий способ представления не только данных, но и сложных документов. Эти документы могут быть такими же простыми, как представление текущего адреса, или такими же сложными, как и представление всей книги или запроса предложения (RFQ). Веб-сервисы поддерживают прозрачный обмен документами для облегчения интеграции бизнеса.

Веб-сервисы – Архитектура

Существует два способа просмотра архитектуры веб-службы:

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

Роли веб-сервисов

В архитектуре веб-службы есть три основные роли:

Поставщик услуг

Это поставщик веб-службы. Поставщик услуг реализует услугу и делает ее доступной в Интернете.

Запрос на обслуживание

Это любой потребитель веб-сервиса. Запрашивающая сторона использует существующую веб-службу, открывая сетевое соединение и отправляя запрос XML.

Сервисный реестр

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

Стек протоколов веб-служб

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

Сервисный транспорт

Этот уровень отвечает за передачу сообщений между приложениями. В настоящее время этот уровень включает гипертекстовый транспортный протокол (HTTP), простой протокол передачи почты (SMTP), протокол передачи файлов (FTP) и более новые протоколы, такие как Blocks Extensible Exchange Protocol (BEEP).

Обмен сообщениями XML

Этот уровень отвечает за кодирование сообщений в общем формате XML, чтобы сообщения могли быть поняты с любого конца. В настоящее время этот уровень включает в себя XML-RPC и SOAP.

Описание услуг

Этот уровень отвечает за описание общедоступного интерфейса к определенному веб-сервису. В настоящее время описание службы обрабатывается с помощью языка описания веб-служб (WSDL).

Сервис Discovery

Этот уровень отвечает за централизацию сервисов в общем реестре и обеспечивает простую функциональность публикации / поиска. В настоящее время обнаружение служб обрабатывается с помощью универсального описания, обнаружения и интеграции (UDDI).

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

Следующая глава объясняет компоненты веб-сервисов.

Несколько слов о сервисном транспорте

Нижняя часть стека протоколов веб-службы – это транспортная служба. Этот уровень отвечает за фактическую передачу сообщений XML между двумя компьютерами.

Протокол передачи гипертекста (HTTP)

В настоящее время HTTP является наиболее популярным вариантом для транспорта службы. HTTP прост, стабилен и широко используется. Кроме того, большинство брандмауэров разрешают HTTP-трафик. Это позволяет сообщениям XMLRPC или SOAP маскироваться под сообщения HTTP. Это хорошо, если вы хотите интегрировать удаленные приложения, но это вызывает ряд проблем с безопасностью.

Блокирует расширяемый протокол обмена (BEEP)

Это многообещающая альтернатива HTTP. BEEP – это новая структура IETF для разработки новых протоколов. BEEP является многоуровневым протоколом TCP и включает в себя ряд встроенных функций, включая протокол первоначального рукопожатия, аутентификацию, безопасность и обработку ошибок. Используя BEEP, можно создавать новые протоколы для различных приложений, включая обмен мгновенными сообщениями, передачу файлов, распространение контента и управление сетью.

SOAP не привязан к какому-либо конкретному транспортному протоколу. Фактически, вы можете использовать SOAP через HTTP, SMTP или FTP. Поэтому одной из многообещающих идей является использование SOAP поверх BEEP.

Веб-сервисы – Компоненты

За последние несколько лет три основные технологии стали мировыми стандартами, составляющими основу современных технологий веб-сервисов. Эти технологии обсуждаются ниже.

XML-RPC

Это самый простой протокол на основе XML для обмена информацией между компьютерами.

XML-RPC – это простой протокол, который использует XML-сообщения для выполнения RPC.

Запросы кодируются в XML и отправляются через HTTP POST.

Ответы XML встраиваются в тело ответа HTTP.

XML-RPC не зависит от платформы.

XML-RPC позволяет различным приложениям общаться.

Java-клиент может передавать XML-RPC на сервер Perl.

XML-RPC – это самый простой способ начать работу с веб-сервисами.

XML-RPC – это простой протокол, который использует XML-сообщения для выполнения RPC.

Запросы кодируются в XML и отправляются через HTTP POST.

Ответы XML встраиваются в тело ответа HTTP.

XML-RPC не зависит от платформы.

XML-RPC позволяет различным приложениям общаться.

Java-клиент может передавать XML-RPC на сервер Perl.

XML-RPC – это самый простой способ начать работу с веб-сервисами.

Чтобы узнать больше о XML-RPC, посетите наш учебник по XML-RPC .

SOAP – это основанный на XML протокол для обмена информацией между компьютерами.

SOAP для связи между приложениями.

SOAP – это формат для отправки сообщений.

SOAP предназначен для общения через Интернет.

SOAP не зависит от платформы.

SOAP позволяет обойти брандмауэры.

SOAP будет разработан как стандарт W3C.

SOAP для связи между приложениями.

SOAP – это формат для отправки сообщений.

SOAP предназначен для общения через Интернет.

SOAP не зависит от платформы.

SOAP позволяет обойти брандмауэры.

SOAP будет разработан как стандарт W3C.

Чтобы узнать больше о SOAP, посетите наш учебник по SOAP .

WSDL – это язык на основе XML для описания веб-сервисов и способов доступа к ним.

WSDL расшифровывается как язык описания веб-сервисов.

WSDL был разработан совместно Microsoft и IBM.

WSDL – это основанный на XML протокол для обмена информацией в децентрализованных и распределенных средах.

WSDL – это стандартный формат описания веб-службы.

Определение WSDL описывает, как получить доступ к веб-службе и какие операции она будет выполнять.

WSDL – это язык для описания взаимодействия с сервисами на основе XML.

WSDL является неотъемлемой частью UDDI, всемирного бизнес-реестра на основе XML.

WSDL – это язык, который использует UDDI.

WSDL произносится как «wiz-тупой» и произносится как «WSD-L».

WSDL расшифровывается как язык описания веб-сервисов.

WSDL был разработан совместно Microsoft и IBM.

WSDL – это основанный на XML протокол для обмена информацией в децентрализованных и распределенных средах.

WSDL – это стандартный формат описания веб-службы.

Определение WSDL описывает, как получить доступ к веб-службе и какие операции она будет выполнять.

WSDL – это язык для описания взаимодействия с сервисами на основе XML.

WSDL является неотъемлемой частью UDDI, всемирного бизнес-реестра на основе XML.

WSDL – это язык, который использует UDDI.

WSDL произносится как «wiz-тупой» и произносится как «WSD-L».

Чтобы узнать больше о WSDL, посетите наш учебник WSDL .

UDDI – это основанный на XML стандарт для описания, публикации и поиска веб-сервисов.

UDDI расшифровывается как универсальное описание, обнаружение и интеграция.

UDDI – это спецификация для распределенного реестра веб-сервисов.

UDDI является независимой от платформы, открытой структурой.

UDDI может взаимодействовать через SOAP, CORBA и протокол Java RMI.

UDDI использует WSDL для описания интерфейсов к веб-сервисам.

UDDI рассматривается в SOAP и WSDL как один из трех основных стандартов веб-сервисов.

UDDI – это открытая отраслевая инициатива, позволяющая компаниям узнавать друг друга и определять, как они взаимодействуют через Интернет.

UDDI расшифровывается как универсальное описание, обнаружение и интеграция.

UDDI – это спецификация для распределенного реестра веб-сервисов.

UDDI является независимой от платформы, открытой структурой.

UDDI может взаимодействовать через SOAP, CORBA и протокол Java RMI.

UDDI использует WSDL для описания интерфейсов к веб-сервисам.

UDDI рассматривается в SOAP и WSDL как один из трех основных стандартов веб-сервисов.

Чтобы узнать больше об UDDI, посетите наш учебник UDDI .

Веб-сервисы – Примеры

На основе архитектуры веб-сервисов мы создаем следующие два компонента в рамках реализации веб-сервисов:

Поставщик услуг или издатель

Это поставщик веб-службы. Поставщик услуг внедряет услугу и делает ее доступной в Интернете или интрасети.

Мы напишем и опубликуем простой веб-сервис с использованием .NET SDK.

Запрос на обслуживание или Потребитель

Мы также напишем два запросчика веб-службы: один веб-пользователь (приложение ASP.NET) и другой пользователь Windows-приложения.

Ниже приведен наш первый пример веб-службы, которая работает в качестве поставщика услуг и предоставляет два метода (add и SayHello) в качестве веб-служб, которые будут использоваться приложениями. Это стандартный шаблон для веб-службы. Веб-сервисы .NET используют расширение .asmx. Обратите внимание, что метод, предоставляемый в качестве веб-службы, имеет атрибут WebMethod. Сохраните этот файл как FirstService.asmx в виртуальном каталоге IIS (как описано при настройке IIS; например, c: \ MyWebSerces).

Чтобы протестировать веб-сервис, его необходимо опубликовать. Веб-сервис может быть опубликован либо в интрасети, либо в Интернете. Мы опубликуем этот веб-сервис на IIS, работающем на локальной машине. Давайте начнем с настройки IIS.

Откройте Пуск → Настройки → Панель управления → Администрирование → Диспетчер служб Интернета.

Разверните и щелкните правой кнопкой мыши веб-сайт по умолчанию; выберите Новый & # rarr; Виртуальный каталог. Откроется мастер создания виртуального каталога. Нажмите кнопку “Далее.

Откроется экран «Псевдоним виртуального каталога». Введите имя виртуального каталога. Например, MyWebServices. Нажмите кнопку “Далее.

Откроется экран «Каталог содержимого веб-сайта».

Введите путь к каталогу для виртуального каталога. Например, c: \ MyWebServices. Нажмите кнопку “Далее.

Откроется экран «Разрешение на доступ». Измените настройки в соответствии с вашими требованиями. Давайте оставим настройки по умолчанию для этого упражнения.

Нажмите кнопку Далее. Завершает настройку IIS.

Нажмите Готово, чтобы завершить настройку.

Откройте Пуск → Настройки → Панель управления → Администрирование → Диспетчер служб Интернета.

Откроется экран «Каталог содержимого веб-сайта».

Введите путь к каталогу для виртуального каталога. Например, c: \ MyWebServices. Нажмите кнопку “Далее.

Нажмите кнопку Далее. Завершает настройку IIS.

Нажмите Готово, чтобы завершить настройку.

Чтобы проверить, правильно ли настроен IIS, скопируйте файл HTML (например, x.html) в виртуальный каталог (C: \ MyWebServices), созданный выше. Теперь откройте Internet Explorer и введите http: //localhost/MyWebServices/x.html . Он должен открыть файл x.html.

Примечание. Если это не помогает, попробуйте заменить localhost IP-адресом вашего компьютера. Если это все еще не работает, проверьте, работает ли IIS; вам может понадобиться перенастроить IIS и виртуальный каталог.

Чтобы протестировать этот веб-сервис, скопируйте FirstService.asmx в виртуальный каталог IIS, созданный выше (C: \ MyWebServices). Откройте веб-службу в Internet Explorer (http: //localhost/MyWebServices/FirstService.asmx). Он должен открыть страницу вашего веб-сервиса. На странице должны быть ссылки на два метода, предоставляемых нашим приложением как веб-сервисы. Поздравляем! Вы написали свой первый веб-сервис!

Тестирование веб-службы

Как мы только что видели, написание веб-сервисов легко в .NET Framework. Написание потребителей веб-сервисов также легко в .NET Framework; однако, это немного более сложно. Как было сказано ранее, мы напишем два типа потребителей услуг: один для веб-пользователей и другой для Windows-приложений. Давайте напишем наш первый потребитель веб-услуг.

Потребитель услуг через Интернет

Напишите веб-потребителю, как указано ниже. Назовите это WebApp.aspx. Обратите внимание, что это приложение ASP.NET. Сохраните это в виртуальном каталоге веб-службы (c: \ MyWebServices \ WebApp.axpx).

Это приложение имеет два текстовых поля, которые используются для получения чисел от пользователя, который будет добавлен. Он имеет одну кнопку «Выполнить», которая при нажатии получает веб-сервисы Add и SayHello.

После того, как потребитель создан, нам нужно создать прокси для потребляемой веб-службы. Visual Studio .NET автоматически выполняет эту работу для нас при ссылке на добавленный веб-сервис. Вот шаги, которым нужно следовать –

Создайте прокси для использования веб-службы. Прокси создается с помощью утилиты WSDL, поставляемой с .NET SDK. Эта утилита извлекает информацию из веб-службы и создает прокси. Прокси-сервер действителен только для определенной веб-службы. Если вам нужно использовать другие веб-службы, вам также необходимо создать прокси-сервер для этой службы. Visual Studio .NET автоматически создает прокси-сервер при добавлении ссылки на веб-службу. Создайте прокси для веб-службы с помощью утилиты WSDL, поставляемой с .NET SDK. Это создаст файл FirstSevice.cs в текущем каталоге. Нам нужно скомпилировать его, чтобы создать FirstService.dll (прокси) для веб-службы.

Поместите скомпилированный прокси в каталог bin виртуального каталога веб-службы (c: \ MyWebServices \ bin). Информационные службы Интернета (IIS) ищет прокси в этом каталоге.

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

Введите URL-адрес потребителя в IE, чтобы проверить его (например, http: //localhost/MyWebServices/WebApp.aspx).

Потребитель веб-служб на основе приложений Windows

Написание потребителя веб-службы на основе приложения Windows аналогично написанию любого другого приложения Windows. Вам нужно только создать прокси-сервер (что мы уже сделали) и ссылаться на него при компиляции приложения. Ниже приводится наше приложение для Windows, которое использует веб-сервис. Это приложение создает объект веб-службы (конечно, прокси) и вызывает SayHello и методы Add для него.

Скомпилируйте его, используя c:\>csc /r:FirstService.dll WinApp.cs . Это создаст WinApp.exe. Запустите его, чтобы протестировать приложение и веб-сервис.

Теперь возникает вопрос: как вы можете быть уверены, что это приложение на самом деле вызывает веб-сервис?

Это просто проверить. Остановите ваш веб-сервер, чтобы с веб-службой нельзя было связаться. Теперь запустите приложение WinApp. Это вызовет исключение времени выполнения. Теперь запустите веб-сервер снова. Он должен работать.

Веб-сервисы – безопасность

Безопасность имеет решающее значение для веб-служб. Однако ни спецификации XML-RPC, ни SOAP не предъявляют никаких явных требований к безопасности или аутентификации.

Есть три конкретных проблемы безопасности с веб-сервисами –

конфиденциальность
Аутентификация
Сетевая безопасность

конфиденциальность

Если клиент отправляет запрос XML на сервер, можем ли мы гарантировать, что связь остается конфиденциальной?

XML-RPC и SOAP работают в основном поверх HTTP.
HTTP поддерживает Secure Sockets Layer (SSL).
Связь может быть зашифрована через SSL.
SSL является проверенной и широко распространенной технологией.

Один веб-сервис может состоять из цепочки приложений. Например, один большой сервис может связать воедино сервисы трех других приложений. В этом случае SSL не подходит; сообщения должны быть зашифрованы на каждом узле вдоль пути обслуживания, и каждый узел представляет собой потенциально слабое звено в цепочке. В настоящее время не существует согласованного решения этой проблемы, но одним из многообещающих решений является стандарт шифрования XML W3C. Этот стандарт обеспечивает основу для шифрования и дешифрования целых XML-документов или только частей XML-документа. Вы можете проверить это на www.w3.org/Encryption

Аутентификация

Если клиент подключается к веб-сервису, как мы идентифицируем пользователя? Пользователь имеет право использовать сервис?

Можно рассмотреть следующие варианты, но нет четкого консенсуса по поводу строгой схемы аутентификации.

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

Цифровая подпись SOAP (SOAP-DSIG) использует криптографию с открытым ключом для цифровой подписи сообщений SOAP. Это позволяет клиенту или серверу проверять личность другой стороны. Проверьте это на www.w3.org/TR/SOAP-dsig .

Организация по продвижению стандартов структурированной информации (OASIS) работает над языком разметки утверждений безопасности (SAML).

Сетевая безопасность

В настоящее время нет простого ответа на эту проблему, и он был предметом многочисленных споров. На данный момент, если вы действительно хотите отфильтровать сообщения SOAP или XML-RPC, одна из возможностей – отфильтровать все запросы HTTP POST, в которых для их типа содержимого установлено значение text / xml.

Другой альтернативой является фильтрация атрибута заголовка HTTP SOAPAction. В настоящее время производители брандмауэров также разрабатывают инструменты, специально предназначенные для фильтрации трафика веб-служб.

Веб-сервисы – Стандарты

Эта глава дает вам представление обо всех последних стандартах, связанных с веб-сервисами.

Транспорты

BEEP, Blocks Extensible Exchange Protocol (ранее назывался BXXP), является основой для построения прикладных протоколов. Он был стандартизирован IETF и делает для интернет-протоколов то, что XML сделал для данных.

обмен сообщениями

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

Источник статьи: http://coderlessons.com/tutorials/veb-razrabotka/izuchite-veb-servisy/veb-servisy-kratkoe-rukovodstvo

Веб-сервис — Web service

Термин веб-служба (WS) может быть либо:

услуга, предлагаемая одним электронным устройством другому электронному устройству, обменивающаяся данными друг с другом через World Wide Web или
сервер, работающий на компьютерном устройстве, прислушивающийся к запросам на определенном порту по сети, обслуживая веб-документы (HTML, JSON, XML, изображения), nd создание служб веб-приложений, которые служат для решения конкретных проблем домена через Интернет (WWW, Интернет, HTTP)

В веб-службе веб-технология, такая как HTTP, используется для передачи машиночитаемого файла такие форматы, как XML и JSON.

На практике веб-служба обычно предоставляет объектно-ориентированный веб-интерфейс для сервера базы данных, используемый, например, другим Веб-сервер или мобильное приложение , которое предоставляет конечному пользователю пользовательский интерфейс. Многие организации, которые предоставляют данные в форматированных HTML-страницах, также предоставляют эти данные на свой сервер в формате XML или JSON, часто через веб-службу, чтобы разрешить распространение, например, из Википедии. Другое приложение, предлагаемое конечному пользователю, может быть mashup, где веб-сервер использует несколько веб-служб на разных машинах и компилирует контент в один пользовательский интерфейс.

Содержание

1 Веб-сервисы (общие)
- 1.1 Асинхронный JavaScript и XML
- 1.2 REST
- 1.3 Веб-сервисы, использующие языки разметки
- 1.4 Веб-API
2 Веб-сервисы W3C
- 2.1 Объяснение
- 2.2 Методы автоматизированного проектирования
- 2.3 Критика
- 2.4 Регрессионное тестирование веб-служб
- 2.5 Управление изменениями веб-служб
3 См. Также
4 Примечания
5 Ссылки
6 Внешние ссылки

Веб-сервисы (общие)

Асинхронный JavaScript и XML

Асинхронный JavaScript и XML (AJAX) — доминирующая технология для веб-сервисов. Разработанный на основе комбинации HTTP-серверов, клиентов JavaScript и Plain Old XML (в отличие от веб-служб SOAP и W3C), теперь он часто используется с JSON, а также или вместо из, XML.

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

В документе 2004 года W3C устанавливает следующий REST в качестве ключевой отличительной черты веб-сервисов:

Мы можем выделить два основных класса веб-сервисов:

REST -совместимые веб-сервисы, в котором основной целью службы является манипулирование XML-представлениями веб-ресурсов с использованием унифицированного набора операций без сохранения состояния ; и
произвольные веб-службы, в которых служба может предоставлять произвольный набор операций. — W3C, Архитектура веб-служб

Веб-службы, использующие языки разметки

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

Web API

A Веб-API — это разработка веб-служб, в которой упор был перенесен на более простую связь на основе репрезентативной передачи состояния (REST). Restful API не требуют протоколов веб-служб на основе XML (SOAP и WSDL) для поддержки своих интерфейсов.

Веб-сервисы W3C

В отношении веб-сервисов W3C W3C определил веб-сервис как:

Веб-сервис — это программная система, предназначенная для поддержки взаимодействия межмашинное взаимодействие по сети. Он имеет интерфейс, описанный в машино-обрабатываемом формате (в частности, WSDL ). Другие системы взаимодействуют с веб-службой способом, предписанным ее описанием, с использованием SOAP -сообщений, обычно передаваемых с помощью HTTP с сериализацией XML в сочетании с другими веб-стандартами.

Веб-службы W3C могут использовать SOAP по протоколу HTTP, что позволяет менее затратное (более эффективное) взаимодействие через Интернет, чем через собственные решения, такие как EDI / B2B. Помимо SOAP через HTTP, веб-службы также могут быть реализованы на других надежных транспортных механизмах, таких как FTP. В документе 2002 года Рабочая группа по архитектуре веб-служб определила архитектуру веб-служб, требующую стандартизованной реализации «веб-службы».

Пояснение

Термин «веб-служба» описывает стандартизованный способ интеграции веб-приложений с использованием XML, SOAP, WSDL и UDDI. открытые стандарты на основе Интернет-протокола. XML — это формат данных, используемый для хранения данных и предоставления метаданных вокруг них, SOAP используется для передачи данных, WSDL используется для описания доступных сервисов, а UDDI перечисляет, какие сервисы доступны.

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

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

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

Необходимо определить правила взаимодействия между различными системами, например:

Как одна система может запрашивать данные у другой системы.
Какие конкретные параметры необходимы в запросе данных.
Какова будет структура полученных данных. (Обычно данные обмениваются в файлах XML, и структура файла XML проверяется по файлу.xsd.)
Какие сообщения об ошибках отображать, когда не соблюдается определенное правило обмена данными, чтобы сделать устранение неполадок проще.

Все эти правила связи определены в файле с именем WSDL (язык описания веб-служб), который имеет расширение .wsdl . (Предложения для автономных веб-сервисов (AWS ) направлены на разработку более гибких веб-сервисов, не основанных на строгих правилах.)

Каталог с именем UDDI (Универсальное описание, обнаружение и интеграция) определяет, к какой системе программного обеспечения следует обращаться для получения данных какого типа. Поэтому, когда одной программной системе требуется один конкретный отчет / данные, она переходит к UDDI и выясняет, с какими другими системами она может связаться для получения этих данных. Как только программная система обнаруживает, с какими другими системами ей следует связаться, она затем связывается с этой системой, используя специальный протокол, называемый SOAP (протокол простого доступа к объектам). Система поставщика услуг сначала проверит запрос данных, ссылаясь на файл WSDL, а затем обработает запрос и отправит данные по протоколу SOAP.

Автоматизированные методы проектирования

Автоматизированные инструменты могут помочь в создании Web-сервиса. Для служб, использующих WSDL, можно либо автоматически сгенерировать WSDL для существующих классов (восходящая модель), либо сгенерировать каркас класса с учетом существующего WSDL (нисходящая модель).

Разработчик, использующий восходящую модель, сначала пишет реализующие классы (на каком-то языке программирования), а затем использует инструмент генерации WSDL для предоставления методов из этих классов в виде веб-службы. Это проще разработать, но может быть сложнее поддерживать, если исходные классы часто меняются.
Разработчик, использующий нисходящую модель, сначала пишет документ WSDL, а затем использует инструмент генерации кода для создания скелет класса, доработанный по мере необходимости. Эта модель обычно считается более сложной, но может создавать более чистый дизайн и, как правило, более устойчива к изменениям. Пока форматы сообщений между отправителем и получателем не изменяются, изменения в самих отправителях и получателях не влияют на веб-службу. Этот метод также называется первым контрактом, поскольку WSDL (или контракт между отправителем и получателем) является отправной точкой.
Разработчик, использующий подмножество WSDL (SWSDL) (т. Е. WSDL с операцией подмножества в оригинальный WSDL) может выполнять тестирование веб-сервисов и разработку сверху вниз.

Критика

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

Также существуют опасения по поводу производительности из-за использования веб-службами XML в качестве формата сообщений и SOAP / HTTP при обертывании и транспортировке.

Регрессионное тестирование веб-служб

Функциональное и нефункциональное тестирование веб-служб выполняется с помощью синтаксического анализа WSDL. Регрессионное тестирование выполняется путем выявления изменений, внесенных в обновление программного обеспечения. Потребности в регрессионном тестировании веб-сервисов можно разделить на три категории, а именно: изменения в WSDL, изменения в коде и выборочное повторное тестирование операций. Мы можем уловить три вышеупомянутые потребности в трех промежуточных формах подмножества WSDL, а именно: Difference WSDL (DWSDL), Unit WSDL (UWSDL) и сокращенный WSDL (RWSDL) соответственно. Затем эти три подмножества WSDL объединяются в комбинированный WSDL (CWSDL), который в дальнейшем используется для регрессионного тестирования веб-службы. Это поможет в автоматизированном управлении изменениями веб-сервисов (AWSCM), выполняя выбор соответствующих тестовых случаев для создания сокращенного набора тестов из старого набора тестов.

Тестирование веб-сервисов также можно автоматизировать с помощью нескольких инструментов автоматизации тестирования, таких как SOAP UI, Oracle Application Testing Suite (OATS), Unified Functional Testing, Selenium и т. Д.

Управление изменениями веб-службы

Работа, связанная с фиксацией и визуализацией изменений, внесенных в веб-службу. Визуализация и вычисление изменений могут выполняться в виде промежуточных артефактов (подмножество WSDL). Понимание расчета влияния изменений полезно при тестировании, нисходящей разработке и сокращении регрессионного тестирования. AWSCM — это инструмент, который может идентифицировать операции подмножества в файле WSDL для создания подмножества WSDL.

Источник статьи: http://ru.wikibrief.org/wiki/Web_service

Возможности веб-сервисов в примерах

Андрей Батурин

Иногда для решения той или иной задачи бизнеса в интернете недостаточно создания сайта — даже “сложного” с разнообразным функционалом и большим количеством страниц. Но это не значит, что компании нужно отказаться от своей задачи — скорее всего, для ее решения просто нужен другой формат. Например, полноценный веб-сервис. В это статьей на понятных примерах мы расскажем, что такое веб-сервис и какие у него есть возможности.

Что такое веб-сервис и чем он отличается от веб-сайта

Начнем с небольшого определения. Веб-сервис — это онлайн система, которая обеспечивает взаимодействие разных частей платформы между собой и со сторонними сервисами и тем самым решает задачи клиента или предоставляет ему услуги. Звучит сложно? Давайте разберем на примере.

Допустим, у вас есть риэлторское агентство, и вы решили, что вам нужно интернет-представительство.

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

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

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

А теперь еще раз дадим определение веб-сервиса — это система, которая обеспечивает онлайн-взаимодействие разных элементов платформы между собой и с пользователем.

Возможности веб-сервисов

У веб-сервисов намного более разнообразные и гибкие возможности, чем у обычных сайтов. Вот, что они умеют.

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

Подробнее о преимуществах веб-сервисов для бизнеса читайте в статье нашего блога.

Примеры простых и сложных веб-сервисов

Официального разделения веб-сервисов на простые, средние и сложные нет, но мы из нашего опыта ориентируемся на следующие особенности (они касаются количества функций и объемов работы над сервисом).

Простой веб-сервис

Минимальный функционал для взаимодействия с пользователем и минимальная интеграция со сторонними приложениями. Пример — простой агрегатор, который по указанным пользователем параметрам собирает информацию в других сервисах и показывает ее. Это может быть список кафе в городе, прогноз погоды в разных городах, каталог местных производителей и т.д.

Средний веб-сервис

Здесь функционал может быть устроен сложнее — добавляется документооборот, интеграция с несколькими веб-приложениями, настраивается разветвленная структура действия в зависимости от разных условий. Пример — личный кабинет пользователя, через который он может искать товар, заказывать и получать услуги, оплачивать их, оформлять доставку. Чаще всего встречается в сфере e-commerce.

Сложный веб-сервис

Сюда можно отнести все соцсети и платформы со сложным документооборотом (например, портал “Госуслуги”). Здесь необходима интеграция с большим количеством сторонних сервисов, настройка сразу нескольких путей пользователя в зависимости от его потребностей.

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

Для агентства недвижимости “МЁД” мы разработали сервис-каталог, который интегрирован с огромной базой недвижимости. Пользователь на сайте агентства указывает интересующий его параметры, и сервис из этой базы подбирает наиболее привлекательные предложения. Это можно считать примером простого веб-сервиса. Подробнее о кейсе.

Для сети ресторанов CARL’S JR. мы сделали веб-сервис среднего уровня сложности. Это закрытый сайт для сотрудников компании, который автоматизирует взаимодействие между главным офисом и многочисленными сотрудниками из разных ресторанов. Здесь настроена многоуровневая система доступов и ролей у пользователей, богатый функционал, “заточенный” под конкретные задачи компании. Подробнее о кейсе.

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

Хотите заказать веб-сервис?

Закажите веб-сервис в RedKrab

Создадим продукт, который будет ориентирован на решение задач именно вашего бизнеса.

Консультация и разбор вашей ситуации — бесплатно .

Источник статьи: http://redkrab.ru/blog/sajti/veb-servisi-primeri-vozmozhnosti/

WEB–сервис

Князев А.А. Энциклопедический словарь СМИ. — Бишкек: Издательство КРСУ . А. А. Князев . 2002 .

Смотреть что такое «WEB–сервис» в других словарях:

Web-сервис — Веб служба. Веб служба, веб сервис (англ. web service) программная система, идентифицируемая строкой интерфейсы определены на языке XML, и передаваемых с помощью интернет протоколов. Веб служба является единицей модульности при использовании… … Википедия

Web сервис — Веб служба. Веб служба, веб сервис (англ. web service) программная система, идентифицируемая строкой интерфейсы определены на языке XML, и передаваемых с помощью интернет протоколов. Веб служба является единицей модульности при использовании… … Википедия

Web Cache Communication Protocol — (WCCP) разработанный компанией Cisco протокол перенаправления контента. Предоставляет механизм перенаправления потоков трафика в реальном времени. Имеет встроенные масштабирование, балансировку нагрузки, отказоустойчивость. Cisco IOS… … Википедия

Web Map Service — (WMS рус. сервис веб карт) стандартный протокол для обслуживания через Интернет географически привязанных изображений, генерируемых картографическим сервером на основе данных из БД ГИС.[1] Данный стандарт был разработан и впервые… … Википедия

Web Hotel Salvador — (Сальвадор,Бразилия) Категория отеля: 2 звездочный отель Адрес: Rua das Alfazemas … Каталог отелей

Web Hotel Aparecida — (Апаресида,Бразилия) Категория отеля: 3 звездочный отель Адрес: Av. Isaac Ferrei … Каталог отелей

сервис-ориентированная архитектура — Бизнес процессы организации реализуются на основе сервисов, предоставляемых существующими приложениями Заказчика. Если приложения не поддерживают возможность предоставления cервисов (Web Services), при внедрении продукта разрабатываются… … Справочник технического переводчика

Web 2 — Ключевые понятия, связываемые с Веб 2.0 Web 2.0 (определение Тима О’Рейли) методика проектирования систем, которые путем учета сетевых взаимодействий, становятся тем лучше, чем больше людей ими пользуются. Особенностью веб 2.0. является принцип… … Википедия

Web 2.0 — Ключевые понятия, связываемые с Веб 2.0 Web 2.0 (определение Тима О’Рейли) методика проектирования систем, которые путем учета сетевых взаимодействий, становятся тем лучше, чем больше людей ими пользуются. Особенностью веб 2.0. является принцип… … Википедия

Web-сайт — Запрос «сайт» перенаправляется сюда. Cм. также другие значения. Веб сайт (от англ. Website: web паутина и site «место») в компьютерной сети объединённая под одним доменным именем или IP адресом) совокупность документов частного лица или… … Википедия

Источник статьи: http://smi.academic.ru/7/WEB%E2%80%93%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81

vchernogorov / _readme.md

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

Web Service — программная система, предназначенная поддерживать взаимодействие между интераперабельными устройствами через сеть. Веб сервис обладает интерфейсом, описанным в WSDL формате. Другие системы, взаимодействуют с веб сервисом через SOAP-сообщения, которые обычно передаются с помощью HTTP с XML сериализацией в связке с другими веб-стандартами. [source]

Сервис доступен по сети, может располагаться и выполняться на разных компьютерах.
Передача сообщений между сервисом и клиентом происходит в независимом формате.
Web Service может быть создан из существующего Web приложения.
Сервис использует стандартизированную XML messaging систему.
Не привязан к операционной системе или языку программирования

SOA (Service Based Architecture) — модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам. [source]

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

ROA (REST-Oriented Architecture) — архитектурный стиль приложения и подход к разработке для создания ПО в виде ресурсов с RESTful интерфейсами. Эти ресурсы являются программными компонентами, которые могут быть переиспользованы для различных целей. [source]

MOM (Message-Oriented Model) сосредаточена на тех аспектах архитектуры, которые относятся к сообщениям и их обработке. [source]

SOM (Service-Oriented Model) сосредаточена на тех аспектах архитектуры, которые относятся к сервису и действиям. [source]

Главная цель SOM — устанавливать отношения между агентом, сервисом, который он реализует, и запросами.
SOM построен на основе MOM, но сосредочен больше на действия, чем на сообщения.

ROM (Resource-Oriented Model) сосредоточена на тех аспектах архитектуры, которые относятся к ресурсам, и сервис модель которых связана с манипулированием ресурсами. [source]

PM (Policy Model) сосредаточена на тех аспектах архитектуры, которые относятся к политике, расширениям, защите и качеству сервиса. [source]

MM (Management Model) сосредаточена на тех аспектах архитектуры, которые относятся к регулированию веб сервисов. [source]

Протокол — набор соглашений интерфейса логического уровня, которые определяют обмен данными между различными программами. [[source]][protocol]

TCP/IP — семейство протоколов, предназначенных для взаимодйествия между электронными устройствами. Определяет, как они должны быть связаны через интернет и как нужно передавать данные между ними. [source]

TCP (Transmission Control Protocol) — отвечает за разбиение данных на небольшие пакеты перед тем, как пересылать их по сети, и за сборку этих пакетов в исходное состояние после получения. [[source]][tcp]

IP (Internet Protocol) — отвечает за обмен данными между устройствами, т.е. за адресацию, отправку и получение пакетов данных через интернет. [[source]][ip]

DNS (Domain Name Server) — иерархическая система имен, построенная на распределенных базах данных. [source]

Когда пользователь посещает сайт, то имя сайта преобразуется в числовое представление с помощью DNS.
Когда регистрируется новый домен вместе с TCP/IP адресом, DNSs по всему миру фиксируют эту информацию.

HTTP (HyperText Transfer Protocol) — протокол уровня приложения, используемый в основном в World Wide Web. HTTP использует клиент-серверную модель, где браузер является клиентом и общается с веб-сервером, который хостит веб-сайт. [source]

Обычный HTTP запрос состоит из следующих шагов:
- Открывается соединение к HTTP серверу.
- Запрос отправляется на сервер.
- Выполняются вычисления на сервере.
- Сервер посылает назад ответ.
- Соединение закрывается.
Для HTTP, действие над данными задается с помощью методов (CRUD операций):
- GET — получить.
- PUT — добавить, заменить.
- POST — добавить, изменить, удалить.
- DELETE — удалить.

HTTPS (HyperText Transfer Protocol Secure) — разновидность HTTP протокола, который добавляет передаваемым данным уровень безопасности через SSL протокол или TLS протокол. [source]

FTP (File Transfer Protocol) — протокол, используемый для передачи или обмена файлами между компьютерами. FTP часто используется для загрузки сетевых страниц и других документов с частного устройства разработки на открытые сервера хостинга.

GIOP (General Inter-ORB Protocol) — абстрактный протокол в распределённых объектных системах, обеспечивающий возможность взаимодействия сервисов-брокеров.

IIOP (Inter-ORB Protocol) — является конкретной реализацией абстрактных определений GIOP.

SSL (Secure Socket Layer) — стандартный протокол, используемый для защищенной передачи документов через сеть.

TLS (Transport Layer Security) — улучшенная версия SSL протокола.

SNMP (Simple Network Management Protocol) — используется для управления сетями.

ARP (Address Resolution Protocol) — используется IP для поиска адреса параметров сетевой карты компьютера, опираясь на IP-адрес.

RARP (Reverse Address Resolution Protocol) — используется IP для поиска IP-адресов, опираясь на параметры сетевой карты компьютера.

PPTP (Point to Point Tunneling Protocol) — используется для установления соединения (тунеля) между приватными сетями.

NTP (Network Time Protocol) — используется для синхронизации времени между компьютерами.

LDAP (Lightweight Directory Access Protocol) — используется для сбора информации о пользователях и электронных почтовых адресов из интернета.

ICMP (Internet Control Message Protocol) — заботится об ошибках в сети.

DHCP (Dynamic Host Configuration Protocol) — используется для поиска динамических IP-адресов компьютеров в сети.

BOOTP (Boot Protocol) — используется для бута (запуска) компьютеров из сети.

POP (Post Office Protocol) — используется программами с почтовой функциональностью для отыскания нужной почти из почтового сервера.

IMAP (Internet Message Access Protocol) — действует также, как и POP, только не загружает сразу все запрашиваемые почты, а дает возможность посмотреть на сообщения, которые выдает почтовый сервер, или удалить их из базы.

SMTP (Simple Mail Transfer Protocol) — заботится об отправки сообщений в почту. Обычно сообщения посылаются на почтовый сервер, а затем в другие серверы и только потом в пункт назначения. Может передавать только текстовые данные.

MIME (Multi-purpose Internet Mail Extensions) — выполняет такие же функции, что и SMTP, только может еще передавать в сообщениях двоичные данные, т.е. аудио, видео, картинки, что угодно.

SOAP (Simple Object Access Protocol) — основанный на XML протокол обмена сообщениями.

WSDL (Web Services Description Language) — язык разметки, основанный на XML, преднзначенный для описания веб сервисов.

UDDI (Universal Description, Discovery, and Integration) — предоставляет всемирный реестр веб сервисов для рекламы, поиска и хранения.

Взаимодействие между SOAP, WSDL и UDDI:

Приложение играет роль веб сервисов, которые нужны клиенту для доступа к другому приложению или бизнес логике, расположенной где-то в сети.
Клиент делает запрос в UDDI реестр для нахождения сервиса по имени, категории, идентификатору или какой-то другой спецификации.
Как только сервис найден, клиент получает информацию о местонахождении WSDL документа из UDDI реестра.
WSDL документ содержит информацию о том, как обратиться к веб сервису, и формат запросов в XML схему.
Клиент создает SOAP сообщение в соответствии с XML схемой, взятой из WSDL, и посылает запрос хосту (где находится веб сервис).

SOM (Service-Oriented Model) сосредаточена на тех аспектах архитектуры, которые относятся к сервису и действиям. [source]

Главная цель SOM — устанавливать отношения между агентом, сервисом, который он реализует, и запросами.
SOM построен на основе MOM, но сосредочен больше на действия, чем на сообщения.

Message — единица информации, отсылаемая одним агентом другому в конексте веб сервисов. [source]

Action — любое действие, представленное агентом в качестве отклика на получение сообщения, или посылки сообщения, или другого изменения состояния. [source]

Service — набор действий, которые формируют целостную систему с точки зрения провайдеров и реквесторов. [source]

Agent — программа, выполняющая функции, указанные пользователем, сущностью или процессом. [source]

Агент представляет программу, выполняющую функции согласно действиям пользователя, сущности или процесса.
Агент обладает идентификатором, владельцем (сущностью) и может предоставлять 1 и более сервисов или запрашивать 0 и более сервисов.

Choreography — определяет очередность и условия, которые позволяют объеденению независимых веб сервисов обмениваться информацией с целью достичь некоторую полезную функцию. [source]

Choreography Description Language — нотация для описания хореографии. [source]

Service Description — набор документов, описывающих интерфейс и семантику сервиса. [source]

Описание выражается через XML и обуславливается одним или более стандартами.

Service Operation — абстрактная группировка сообщений, которую сервис посылает и получает, чтобы совершить определенную задачу. [source]

Service Platform — среда, используемая для хостинга одного или более веб сервисов. [[source]][service-platform]

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

Service Provider — агент, который способен и предназначен для совершения действий, связанных с сервисом. [source]

Провайдер предоставляет 1 или более сервисов.
Провайдер представляет или вызывает представление действий, связанных с сервисом.

Service Requester — сущность, которая отвечает за запросы к сервису через провайдер. [source]

Реквестор запрашивает 1 или более сервисов.

Service Registry (Broker) — логически-централизованная директория сервисов, куда девелоперы публикуют новые сервисы и где можно найти существующие. Поэтому этот элемент является координационным центром для компаний и их услуг. [[source]][service-registry]

Реестр предоставляет следующего вида информацию: бизнес данные, такие как имя, описание, контактная информация, или данные, необходимые для использования веб сервиса.

Service Semantics — контракт между провайдером и реквестором, который отображает вызов сервиса. [source]

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

Service Task — еденица активности, связанная с сервисом. [source]

ROM (Resource-Oriented Model) сосредоточена на тех аспектах архитектуры, которые относятся к ресурсам, и сервис модель которых связана с манипулированием ресурсами. [source]

SOAP — протокол обмена структурированными сообщениями в распределенной вычислительной среде. Также предоставляет стандарт структуры упаковки данных для транспортировки XML документов с помощью различных интернет-технологий, как: SMTP, HTTP, FTP. [source]

Так как SOAP обладает стандартным механизмом транспортировки, различные клиенты и серверы могут взаимодействовать, например, с EJB через .NET клиент и наоборот.

Пример взаимодействия клиента с Web приложением (регистрация аккаунта):

Программа на клиентской стороне конвертирует информацию о регистрации аккаунта в SOAP сообщение.
SOAP сообщение отсылается в веб сервис, как тело HTTP POST запроса.
Веб сервис распаковывает SOAP реквест и конвертирует в комманду, которую понимает приложение на сервере.
Приложение обрабатывает информацию своей логикой и отправляет ответ с новым уникальным номером аккаунта.
Следующим шагом, веб сервис конвертирует ответ сервера в SOAP сообщение, которое отправляет назад в клиентское приложение, как ответ на HTTP запрос.
Клиентское приложение распаковывает SOAP сообщение и предоставляет клиенту соотвествующую информацию.

SOAP Building Blocks. SOAP сообщение — это обычный XML документ, содержащий следующие элементы:

Оболочка — идентифицирует XML документ как SOAP сообщение.
Заголовок — содержит различного рода информацию о сообщении, которая помещается обычно в заголовки.
Тело — содержит информацию о вызове и ответе.
Ошибка — содержит все ошибки и текущий статус.

WSDL (Web Service Description Language) — XML технология, которая описывает интерфейс веб сервиса в стандартизированном виде. WSDL указывает стандарт, как веб сервис должен представлять входные и выходные параметры при вызове извне, как должна выглядеть структура функции, природа вызова и как осуществлять связывание протокола сервера. [source]

WSDL позволяет различным клиентам автоматически распознавать, как взаимодействовать с веб сервисом.

WSDL документ — описывает веб сервис. Он указывает местоположение сервиса и его методы, используя следующие элементы:

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

— описывает операции и сообщение, которые могут встретиться в сервисе.

— определяет протокол и формат данных для каждого типа порта.

— определяет адрес веб сервиса.

— корневой элемент каждого WSDL документа.

— абстрактное определение операции для сообщения.

— предоставляет документацию

— импортирует сторонние WSDL документы или XML Schemas.

Структура WSDL документа выглядит следующим образом:

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

request-response — самый распространенный тип операции. Она получает запрос и возвращает ответ.
one-way — операция может получать сообщения, но не будет возвращать ответ.
solicit-response — операция может отправлять запрос и будет ждать ответа.
notification — операция может посылать сообщений, но не будет ждать ответа.

Пример Request-Response операции (словарь терминов):

определяет «glossaryTerms» как имя порта, а getTerm — имя операции
элементы определяют

сообщений «getTermRequest» и «getTermResponse».

Пример One-Way операции (словарь терминов):

В этом примере «glossaryTerms» определяет one-way операцию «setTerm».
«setTerm» операция позволяет вводить новое сообщение используя «newTermValues».

: HelloService.
: Использование импортированной по локальному адресу XML Schema.
: «sayHelloRequest»: «firstName» параметр, «sayHelloResponse»: «greeting» возвращаемое значение

: sayHello операция, которая состоит из request-response сервиса.

: Указание использовать SOAP HTTP протокол.

: сервис доступен по ссылке http://www.examples.com/SayHello/.

: Связывает с URI http://www.examples.com/SayHello/, по которой доступен данный сервис.

UDDI (Universal Description, Discovery, and Integration) — предоставляет всемирный реестр веб сервисов для рекламы, поиска и хранения. [source]
- UDDI предоставляет структуру для представления деловых отношений, веб сервисов, технических метаданных и точек доступа к веб сервисам.

REST (REpresentational State Transfer) — это стиль архитектуры программного обеспечения для распределенных систем, использующий веб протоколы и веб технологии. REST архитектура включает в себя клиентское и серверное взаимодействие, построенное вокруг передачи ресурсов. [source]

Самая большая реализация REST — World Wide Web, которая, как правило, используется для построения веб-служб.
Системы, которые построены согласно REST принципам, называются RESTful.
REST может быть использован для сбора данных вебсайта через XML файлы веб страницы.
Пользователи могут обращаться к веб страницам через URL сайта, взаимодействовать с XML файлами через браузер и использовать данные как угодно.
Базовые REST принципы:
- Client и Server — клиент и сервер должны быть отделены от REST операций через специальный интерфейс, который улучшает переносимость кода.
- Stateless — каждый клиентский запрос должен содержать все требуемые данные для обработки запроса без хранения клиентского окружения на сервере.
- Cacheable — ответы могут быть закэшированны на клиентском компьютере, чтобы ускорить веб поиск.
- Layered System — позволяет клиентам подключаться к серверу через вспомогательный уровень для улучшения расширяемости.

Servlet API является основой для всех остальных технологий Java, касающихся Web и дает возможность динамически генерировать любой web-контент, используя любые библиотеки, доступные для java.

JSP (JavaServer Pages) — технология, используемая для разработки интерактивных веб страниц. JSP была разработана Sun Microsystems и является улучшенной версией Java сервлетов. [source]

Как и большинство серверных технологий, JSP отделяет бизнес логику от представления.
JSP являются обычные HTML страницы с встроенным Java кодом.
Чтобы обработать JSP файл, разработчику нужен JSP движок, который подключен к веб серверу.
JSP страница компилируется в сервлет, который управляет сервлет движком (этот этап называется «преобразованием»). Сервлет движок затем загружает класс сервлета и реализовывает его, чтобы создать динамический HTML, который затем посылается в браузер. Такой процесс запускается каждый раз, когда запрашивается очередная страница.
Если вместе с JSP исользовать JDBC, то можно сделать динамические, связанные с базой данных, вебсайты.

Apache Tomcat — опенсорсный веб сервер, разработанный Apache Software Foundation. Он позволяет реализовывать Java сервлеты и JSPs для поддержки эффективных Java-серверных сред. [source]

Пользователь также может получить доступ к конфигурациям и использовать XML для настройки проектов.
Tomcat может предоставить рантайм оболочку для Java сервлетов.
Ключевой элемент Java-based веб сервера — сервлет контейнер, поэтому JSP скрипты и им подобные автоматически преобразовываются в сервлет.
Catalina — контейнер сервлетов Tomcat’а, который реализует спецификацию сервлетов.

Apache Ant — Java-based опенсорсный build tool, разработанный Apache Software Foundation. Он схож с «make» утилитой, но в большинстве своем функционирует только на java платформе. [source]

В отличии от Make, Ant написан на XML, поэтому портируемость и простота — это два главных преимущества Ant.

RPC (Remote Procedure Call) — класс технологий, позволяющих компьютерным программам вызывать функции или процедуры в другом адресном пространстве (как правило, на удаленных компьютерах). [source]

RPC работает по принципу: отправитель или клиент создает запрос с помощью процедуры, функции или вызова метода в удаленный сервер, который RPC обрабатывает и посылает. Когда удаленный сервер получает запрос, он отсылает ответ назад клиенту, и приложение продолжает свою работу. Перед тем, как продолжать работу программы, клиент ждет, пока сервер завершит процесс обработки.
В общем, RPC приложения используют модули, называемые прокси и заглушки, которые заставляют их выглядеть как простые локальные вызовы процедур.
RPC-ориентированное приложение — приложение, в которых существует интерактивная связь между удалёнными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных.
Пример RPC можно найти в GWT.

RMI (Remote Method Invocation) — программный интерфейс вызова удаленных методов в языке Java. [source]

Он представляет объектно-ориентированный эквивалент RPC.
RMI функциональность находится в java.rmi пакете и предоставляет распределенную объектную модель, специфицирующую, каким образом производится вызов удаленных методов, работающих на другой виртуальной машине Java.
При доступе к объектам на другом компьютере возможно вызывать методы этого объекта. Необходимо только передать параметры метода на другой компьютер, сообщить объекту о необходимости выполнения метода, а затем получить обратно возвращаемое значение.

RSS (Really Simple Syndication)

RDF (Resource Description Framework)

Источник статьи: http://gist.github.com/vchernogorov/81da656048875132d6963304d449f770

Проверка ошибок в словах

Поиск ответа

Веб-сервисы в теории и на практике для начинающих

Что такое веб-сервисы?

Протоколы веб-сервисов

SOAP против REST

Практическое применение веб-сервисов

Этап первый — реализация приложения сбора информации о курсах валют.

Реализация SOAP сервиса

Реализация REST сервиса

Заключение

Что такое веб-сервисы и как они используются

Веб-сервис или веб-сайт?

Зри в корень: архитектура и протоколы

Архитектура и ее компоненты

Протоколы и технологии

Как работает веб-сервис на примере банка

Зачем нужны веб-сервисы?

Веб-сервис

Содержание

Используемые стандарты

Достоинства веб-служб

Недостатки веб-служб

Платформы

Ссылки

Полезное

Смотреть что такое «Веб-сервис» в других словарях:

Пишем свой первый RESTful веб-сервис на ASP.NET

Что такое RESTful веб-сервис?

Ключевые составляющие RESTful

Методы RESTful

Почему RESTful

RESTful архитектура

Принципы и ограничения RESTful

RESTful клиент-сервер

Отсутствие состояния

Многослойная система

Единообразие интерфейса

Создаём свой первый RESTful веб-сервис с ASP.NET

Запускаем наш веб-сервис

Тестируем веб-сервис

Веб-сервисы – Краткое руководство

Компоненты веб-сервисов

Как работает веб-сервис?

пример

Почему веб-сервисы?

Разоблачение существующей функции в сети

Interoperability

Стандартизированный протокол

Низкая стоимость связи

Веб-сервисы – Характеристики

XML-Based

Слабо связанный

Крупнозернистый

Способность быть синхронной или асинхронной

Поддерживает удаленные вызовы процедур (RPC)

Поддерживает обмен документами

Веб-сервисы – Архитектура

Роли веб-сервисов

Поставщик услуг

Запрос на обслуживание

Сервисный реестр

Стек протоколов веб-служб

Сервисный транспорт

Обмен сообщениями XML

Описание услуг

Сервис Discovery

Несколько слов о сервисном транспорте

Протокол передачи гипертекста (HTTP)

Блокирует расширяемый протокол обмена (BEEP)

Веб-сервисы – Компоненты

XML-RPC

Веб-сервисы – Примеры

Поставщик услуг или издатель

Запрос на обслуживание или Потребитель

Тестирование веб-службы

Потребитель услуг через Интернет

Потребитель веб-служб на основе приложений Windows

Веб-сервисы – безопасность

конфиденциальность