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

Веб-сервисы · GitHub

Веб-сервисы

Веб-сервисы

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

Содержание:

• О веб-сервисах
• Архитектурные модели
• Стек протоколов
• Технологии

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

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

2. Пример веб сервиса: dailyinfo

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

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

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

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

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

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

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

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

   ^[source]

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

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

2. TCP/IP

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

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

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

   [[source]][ip]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

18. LDAP (Lightweight Directory Access Protocol)

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

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

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

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

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

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

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

25. MIME (Multi-purpose Internet Mail Extensions)

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

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

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

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

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

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

1. SOM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. ROM

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

3. SOAP

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

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

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

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

3. Клиент/сервер связь:

                  HTTP POST of SOAP request document
     SOAP: client ----------------------------------> service
           client <---------------------------------- service
                       SOAP (maybe JSON) document
   

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

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

4. WSDL

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

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

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

   • <types> — определяет типы данных, используемые веб сервисом.
   • <message> — определяет элементы данных для каждой операции.
   • <portType> — описывает операции и сообщение, которые могут встретиться в сервисе.
   • <binding> — определяет протокол и формат данных для каждого типа порта.
   • <service> — определяет адрес веб сервиса.
   • <definition> — корневой элемент каждого WSDL документа.
   • <operation> — абстрактное определение операции для сообщения.
   • <documentation> — предоставляет документацию
   • <import> — импортирует сторонние WSDL документы или XML Schemas.

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

   <definitions>
       <types>
         data type definitions........
       </types>
       <message>
         definition of the data being communicated....
       </message>
       <portType>
         set of operations......
       </portType>
       <binding>
         protocol and data format specification....
       </binding>
   </definitions> 

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

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

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

    <message name="getTermRequest">
      <part name="term" type="xs:string"/>
    </message>
    <message name="getTermResponse">
      <part name="value" type="xs:string"/>
    </message>
    <portType name="glossaryTerms">
      <operation name="getTerm">
        <input message="getTermRequest"/>
        <output message="getTermResponse"/>
      </operation>
    </portType> 

   • <portType> определяет «glossaryTerms» как имя порта, а getTerm — имя операции
   • <message> элементы определяют <part> сообщений «getTermRequest» и «getTermResponse».

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

    <message name="newTermValues">
      <part name="term" type="xs:string"/>
      <part name="value" type="xs:string"/>
    </message>
    <portType name="glossaryTerms">
      <operation name="setTerm">
        <input name="newTerm" message="newTermValues"/>
      </operation>
    </portType > 

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

7. Пример WSDL файла:

   <?xml version="1.0" encoding="UTF-8"?>
   <definitions name="HelloService"
                targetNamespace="http://www.ecerami.com/wsdl/HelloService.wsdl"
                xmlns="http://schemas.xmlsoap.org/wsdl/"
                xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                xmlns:tns="http://www.ecerami.com/wsdl/HelloService.wsdl"
                xmlns:xsd="http://www.w3.org/2001/XMLSchema">
       <types>
           <xsd:schema>
               <xsd:import
                       schemaLocation="http://localhost:9876/ts?xsd=1"
                       namespace="http://ts.ch02/">
               </xsd:import>
           </xsd:schema>
       </types>
       <message name="SayHelloRequest">
           <part name="firstName" type="xsd:string"/>
       </message>
       <message name="SayHelloResponse">
           <part name="greeting" type="xsd:string"/>
       </message>
       <portType name="Hello_PortType">
           <operation name="sayHello">
               <input message="tns:SayHelloRequest"/>
               <output message="tns:SayHelloResponse"/>
           </operation>
       </portType>
       <binding name="Hello_Binding" type="tns:Hello_PortType">
           <soap:binding
                         transport="http://schemas. xmlsoap.org/soap/http"/>
           <operation name="sayHello">
               <soap:operation soapAction="sayHello"/>
               <input>
               <soap:body
                       encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
                       namespace="urn:examples:helloservice"
                       use="encoded"/>
               </input>
               <output>
                   <soap:body
                           encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
                           namespace="urn:examples:helloservice"
                           use="encoded"/>
               </output>
           </operation>
       </binding>
       <service name="Hello_Service">
           <documentation>WSDL File for HelloService</documentation>
           <port binding="tns:Hello_Binding" name="Hello_Port">
               <soap:address
                       location="http://localhost:8080/soap/rpcrouter"/>
           </port>
       </service>
   </definitions>

   • <service>: HelloService.
   • <types>: Использование импортированной по локальному адресу XML Schema.
   • <message>: «sayHelloRequest»: «firstName» параметр, «sayHelloResponse»: «greeting» возвращаемое значение
   • <portType>: sayHello операция, которая состоит из request-response сервиса.
   • <binding>: Указание использовать SOAP HTTP протокол.
   • <service>: сервис доступен по ссылке http://www.examples.com/SayHello/.
   • <port>: Связывает <binding> с URI http://www.examples.com/SayHello/, по которой доступен данный сервис.

5. UDDI

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

6. REST

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

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

2. Клиент/сервер связь:

                     HTTP GET, POST, PUT, or DELETE
     REST: client ----------------------------------> service
           client <---------------------------------- service
                    XML, JSON, plaintext,... document
   

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

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

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

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

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

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

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

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

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

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

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

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

7. RSS (Really Simple Syndication)

8. RDF (Resource Description Framework)

Веб-сервисы | Сетевые технологии

Учебные программы » Сетевые технологии » Конспект лекций » Веб-сервисы

Что есть веб-сервис?

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

Веб-служба, веб-сервис (англ. web-service) — это сетевая технология, обеспечивающая межпрограммное взаимодействие на основе веб-стандартов. Консорциум W3C определяет веб-сервис, как «программную систему, разработанную для поддержки интероперабельного межкомпьютерного (machine-to-machine) взаимодействия через сеть»

Веб-службы: концепции и протоколы

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

Рис. 1. Концепция веб-сервиса

• SOAP (Simple Object Access Protocol) — протокол обмена сообщениями между потребителем и поставщиком веб-сервиса;
• WSDL (Web Services Description Language) — язык описания внешних интерфейсов веб-службы;
• UDDI (Universal Discovery, Description and Integration) — универсальный интерфейс распознавания, описания и интеграции, используемый для формирования каталога веб-сервисов и доступа к нему.

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

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

SOAP

SOAP (изначально Simple Object Access Protocol, а в версии 1.2 официальная расшифровка аббревиатуры отсутствует) — простой протокол доступа к объектам (компонентам распределенной вычислительной системы), основанный на обмене структурированными сообщениями. Как любой текстовый протокол, SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTPS и др., но чаще всего SOAP используется поверх HTTP.

Все сообщения SOAP оформляются в виде структуры, называемой конвертом (envelop), включающей следующие элементы:

• Идентификатор сообщения (локальное имя).
• Опциональный элемент Header (заголовок):
  • Ноль или более ссылок на используемые пространства имен;
  • Ноль или более свойств, доступных в этом пространстве имен.
• Обязательный элемент Body (тело сообщения)
  • Ноль или более ссылок на используемые пространства имен;
  • Дочерние элементы тела сообщения

Развернутый список элементов сообщения SOAP приведен в схеме данных (для SOAP версии 1.2).

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<n:alertcontrol xmlns:n="http://example.org/alertcontrol">
<n:priority>1</n:priority>
<n:expires>2001-06-22T14:00:00-05:00</n:expires>
</n:alertcontrol>
</env:Header>
<env:Body>
<m:alert xmlns:m="http://example. org/alert">
<m:msg>Get up at 6:30 AM</m:msg>
</m:alert>
</env:Body>
</env:Envelope>

XML-RPC: Не конкурент, а альтернатива SOAP

XML-RPC — очень простой и эффективный протокол взаимодействия веб-сервисов. Он не предназначен для решения глобальных задач, как SOAP, но широко используется во многих веб-разработках.

Концепция XML-RPC

XML-RPC — это «… спецификация и набор реализаций, которые позволяют программному обеспечению, работающему на разных операционных системах и в различных условиях, вызывать процедуры через Интернет. Это удаленный вызов процедуры с использованием HTTP как транспорта и XML как способа кодирования. XML-RPC разработан настолько простым, насколько это возможно для сложных структур данных, подлежащих передаче, обработке и приему». — [хmlrpc.com]

«Мы хотели, чистый, расширяемый и очень простой формат. Он должен представлять HTML-кодеру возможность заглянуть в файл, содержащий описание XML-RPC вызова, понять, что тот делает и быть в состоянии изменить его, чтоб он заработал с первой или второй попытки. .. Мы также хотели, чтобы это был легко реализуемый протокол, который может быть быстро адаптирован для работы в другой среде или на других операционных системах.»- [xmlrpc.com]

WSDL

Язык описания веб-сервисов (Web services Description Language, WSDL) предназначен для унифицированного представления внешних интерфейсов веб-службы. Текущая версия протокола (на момент написания этой лекции) WSDL 2.0 и она имеет некоторые отличия от предыдущих версий (см. табл. 1 и рис. 3).

Элемент WSDL 1.1	Элемент WSDL 2.0	Краткое описание
PortType	Interface	Представляет описание интерфейса веб-сервиса (список операций и их параметров).
Service	Service	Список системных функций
Binding	Binding	Специфицирует интерфейсы и задает параметры связывания с протоколом SOAP: стиль связывания (RPC/Document) и транспорт (SOAP). Эта секция доступна и для каждой из операций
Operation	Operation	Определяет операцию, представляемую веб-сервером. WSDL-операция — это аналог традиционным функциям и процедурам.
Message	не использ.	Сообщение, связанное с определенной операцией. Содержит информацию, необходимую для выполнения данной операции. Каждое сообщение может состоять из нескольких логических частей, описывающих типы данных и имена атрибутов. В версии 2.0 было исключено, т.к. была внедрена поддержка XML Schema для всех элементов.
Types	Types	Описание данных в соответствии с XML Schema.

Рис. 3. Структура протокола WSDL

В спецификации WSDL 1.1 было определено 4 шаблона обмена сообщениями (типы операций):

• Однонаправленные операции (One-way): операция может принимать сообщение, но не будет возвращать ответ.
• Запрос-ответ (Request-response): операция может принять запрос и должна вернуть ответ.
• Вопрос-ответ (Solicit-response): операция может послать запрос и будет ждать ответ на него.
• Извещение (Notification): операция может послать сообщение, но не будет ожидать ответ.

В версии WSDL 2.0 эти шаблоны изменены и расширены в сторону поддержки сообщений об ошибках (например, шаблон Robust-in-only), но для обратной совместимости поддерживаются типы WSDL 1.1

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

UDDI

Universal Description, Discovery and Integration (UDDI, универсальный интерфейс распознавания, описания и интеграции) — открытый стандарт, утвержденный OASIS, определяющий методы публикации и обнаружения сетевых программных компонентов сервис-ориентированной архитектуры (SOA). В практической реализации UDDI представляет собой сетевой реестр (службу каталогов), представляющий данные и метаданные о веб-сервисах и доступный по адресу http://uddi. xml.org/services.

UDDI опирается на отраслевые стандарты HTTP, XML, XML Schema (XSD), SOAP и WSDL. Концептуальная связь между UDDI и другими протоколами стека веб-сервисов показана на рисунке 4.

Рис. 4. Место UDDI в стеке протоколов веб-служб

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

Ключевыми функциями UDDI являются публикация информации о службе в реестре и поиск этой информации сторонними приложениями. Наряду с этими, реализованы и типовые для службы каталогов функции: представление модели хранимых данных и структуры информационной базы, отношения между объектами реестра, репликация, обеспечение безопасности и т. д. —Все основные функции реестра представлены в виде веб-сервисов и доступны через API UDDI.

Веб-сервисы: Pro et Contra

Достоинства

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

Недостатки

• Меньшая производительность и больший объем сетевого трафика по сравнению с такими технологиями как CORBA или DCOM.

CC-BY-CA Анатольев А.Г., 21.01.2014

Веб-сервисы — Технологии — Webmascon

Web-services
автор: 2002 (c) Patrick Cooney и A List Apart
перевод: Александр Качанов

Идея веб-сервисов была разработана такими гигантами компьютерной индустрии как Sun, Oracle, HP, Microsoft и IBM. В этой идее нет ничего нового, но это большой шаг вперед к упрощенному доступу к программам через сеть. Основываясь на стандартных форматах связи, веб-сервисы могут вообще поменять наше представление о том, как мы должны делать веб-сайты.

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

Благодаря веб-сервисам функции любой программы могут стать доступными через Интернет. Таким образом такие программы как PHP, ASP, JSP скрипты, JavaBeans, COM-объекты и все остальные наши любимые средства программирования могут теперь обращаться к какой-нибудь программе, работающей на другом сервере (т.е. к веб-свервису), и использовать ответ, полученный от нее на своем веб-сайте, или приложении.

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

Любой, кто хоть раз работал в последнее время с Hotmail, уже отчасти столкнулся с веб-сервисами: система аутентификации пользователей Passport — это один из сервисов, входящих в инициативу Microsoft . NET. пока он доступен бесплатно, так что создатели веб-сайтов могут запросто внедрить аутентификацию пользователей на своём сайте.

Основы

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

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

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

Стандарты в основе

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

До этого многие компании разрабатывали свои собственные закрытые стандарты и форматы. А сейчас нам для работы нужно знать всего лишь простой XML (eXtensible Markup Language), который передается по старому знакомому протоколу HTTP. Это значит, что информация о работе веб-сервисов доступна для всех, и веб-разработчики, которые по роду профессии знакомы с этими технологиями, могут начать играться с веб-сервисами уже сегодня.

Разница между веб-сервисами и другими технологиями, с которыми разработчикам приходилось сталкиваться (например, DCOM, именованные каналы — named pipes, RMI) в том, что веб-сервисы основаны на открытых стандартах, ими легко овладеть, и эти стандарты широко поддерживаются на всех платформах Unix и Windows.

Протокол Simple Object Access Protocol (SOAP) является стандартным протоколом, разработанным W3C. Он определяет формат запросов к веб-сервисам.

Сообщения между веб-сервисом и его пользователем пакуются в SOAP-конверты (SOAP envelopes). Сообщения содержат либо запрос на осуществление какого-либо действия, либо ответ — результат выполнения этого действия. Конверт и его содержимое закодировано языком XML, и его достаточно просто понять. Вот как выглядит простой SOAP-запрос, который отправляется через HTPP к веб-сервису:

<env:Envelope
xmlns:env="http://www.w3.org/2001/06/soap-envelope">
<env:Body>
<m:ValidatePostcode
env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://www.somesite.com/Postcode">
<Postcode>WC1A8GH</Postcode>
<Country>UK</Country>
</m:ValidatePostcode>
</env:Body>
</env:Envelope>

Ключевые элементы SOAP-конверта узнать достаточно просто: это два параметра (<postcode> («почтовый индекс») и <country> («страна»)), которые содержатся внутри элемента под названием <ValidatePostcode>. Этот элемент является названием веб-сервиса, к которому мы обращаемся с запросом. Прочие данные в конверте, такие как кодировка текста и версия SOAP помогают веб-сервису правильно обработать запрос.

А ответ будет выглядеть вот так:

<env:Envelope
xmlns:env="http://www.w3.org/2001/06/soap-envelope" >
<env:Body>
<m:ValidatePostcodeResponse
env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://www.somesite.com/Postcode">
<Valid>Yes</Valid>
</m:ValidatePostcodeResponse>
</env:Body>
</env:Envelope>

Это сообщение еще проще расшифровать. Элемент <ValidatePostcode> в нашем запросе поменялся на элемент <ValidatePostcodeResponse> в ответе на запрос. В этом элементе содержится только один элемент <Valid>, значение которого обозначает, верен наш почтовый индекс или нет. Таким образом с помощью волшебства SOAP мы создали запрос, который делает для нас полезную работу. В ответ через сеть мы получаем определенного вида ответ на языке XML.

Теперь об UDDI

Даже при всей простоте протокола SOAP пользы в веб-сервисах было бы немного, если бы у нас не было никакой возможности их найти. К счастью IBM, Microsoft и компания Ariba выступили с инициативой и создали проект Universal Description, Discovery and Integration (UDDI), который, как они надеются, станет общим каталогом всех веб-сервисов в Web-е.

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

Как это все работает

Так как же мне найти нужный веб-сервис?

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

Для осуществления этой проверки мне понадобилось бы создавать базу данных всех почтовых индексов всех 30 стран, где наша компания ведет бизнес, а потом проверять при регистрации соответствие почтового индекса указанному в регистрации городу. Но у меня этих данных нет, и я думаю, что на сбор подобных данных придется потратить ощутимую сумму денег.

Вместо того, чтобы раскошеливаться на покупку базы данных, писать самому код, следить за целостностью и правильностью всех данных и отлаживать работу скриптов, я просто иду в каталог UDDI и ищу, нет ли там веб-сервиса, который мог бы сделать эту работу за меня. Придя на сайт www.uddi.org, я запускаю поиск и нахожу прекрасный сервис от компании XYZ Corp.

Я внимательно рассматриваю определение формата веб-сервиса (определение записано на языке WSDL (Web Services Description Language), убеждаюсь, что сервис делает именно то, что мне нужно. Затем справляюсь у своих коллег о репутации компании XYZ Corp., узнаю, что она солидная, и затем обращаюсь к компании XYZ с вопросом о цене. Если цена на доступ к сервису доступна для моего бюджета, я пишу простую JSP-страницу для своего сайта, который вызывает веб-сервис компании XYZ Corp, и опля, на сайте появляется моментальная проверка почтового индекса.

На это стоит потратить время

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

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

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

Разработка сервиса

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

Выбор инструментов для разработки веб-сервисов обширен. В него входят инструментарии таких компании как Sun (Open Net), Microsoft (.NET), HP (e-services), и IBM (Web Services). Существуют также инструментарии с открытыми исходными кодами (open source frameworks). Например, проект Mono Project стремится заменить собой инструментарий Microsoft .NET, предоставив систему компиляции (compilers), исполнения кода (runtime) и библиотек (libraries) для работы одних и тех же веб-сервисов на всех платформах, включая Unix.

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

Минусы

Прежде чем я полностью откажусь от карьеры программиста и посвящу себя использованию веб-сервисов, я должен задать себе вопрос: «Уж слишком розовая картинка. Что в ней не так?». К сожалению, за великий потенциал веб-сервисов приходится платить определенную цену:

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

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

Patrick Cooney

Patrick — веб-разработчик, живущий в Лондоне (Англия).

« назад к списку статей

Что такое веб-службы? — GeeksforGeeks

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

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

Любое программное обеспечение, приложение или облачная технология, использующие стандартизированные веб-протоколы (HTTP или HTTPS) для подключения, взаимодействия и обмена сообщениями данных — обычно XML (расширяемый язык разметки) — через Интернет, считается веб-службой.
Преимущество веб-служб заключается в том, что они позволяют программам, разработанным на разных языках, соединяться друг с другом путем обмена данными через веб-службу между клиентами и серверами. Клиент вызывает веб-службу, отправляя XML-запрос, на который служба отвечает XML-ответом .

Функции веб-служб

• Возможен доступ через Интернет или интранет-сети.
• Стандартизированный протокол обмена сообщениями XML.
• Независимо от операционной системы или языка программирования.
• При использовании стандарта XML самоописание.
• Для его обнаружения можно использовать простой метод определения местоположения.

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

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

SOAP означает «простой протокол доступа к объектам». Это транспортно-независимый протокол обмена сообщениями. SOAP основан на отправке данных XML в виде сообщений SOAP. К каждому сообщению прилагается документ, известный как XML-документ. Только структура XML-документа, а не его содержимое, следует шаблону. Лучшее в Web-сервисах и SOAP то, что все отправляется через HTTP, стандартный веб-протокол.

Корневой элемент, известный как элемент, требуется в каждом документе SOAP. В документе XML корневой элемент является первым элементом. «Конверт» разделен на две половины. Сначала идет заголовок, затем тело. Данные маршрутизации или информация, которая указывает XML-документ, какому клиенту его следует отправить, содержатся в заголовке. Настоящее сообщение будет в теле.

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

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

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

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

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

Для выполнения этих запросов используются удаленные вызовы процедур. Вызовы методов, размещенных соответствующей веб-службой, известны как удаленные вызовы процедур (RPC). Пример: Flipkart предлагает веб-сервис, отображающий цены на товары, предлагаемые на Flipkart.com. Внешний интерфейс или уровень представления могут быть написаны на .Net или Java, но веб-служба может передаваться с использованием любого языка программирования.
Данные в формате XML, которыми обмениваются клиент и сервер, являются наиболее важной частью дизайна веб-службы. XML (расширяемый язык разметки) — это простой промежуточный язык, понятный различным языкам программирования. Это аналог HTML. В результате, когда программы взаимодействуют друг с другом, они используют XML. Это создает общую платформу для приложений, написанных на разных языках программирования, для взаимодействия друг с другом.
Для передачи XML-данных между приложениями веб-службы используют SOAP (простой протокол доступа к объектам). Данные отправляются с использованием стандартного HTTP. Сообщение SOAP — это данные, которые отправляются из веб-службы в приложение. Документ XML — это все, что содержится в сообщении SOAP. Клиентское приложение, которое вызывает веб-службу, может быть создано на любом языке программирования, поскольку содержимое записывается в формате XML.

Веб-службы имеют следующие характеристики:

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

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

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

(d) Крупномасштабный: Объектно-ориентированные системы, такие как Java, делают свои службы доступными с помощью отдельных методов. На корпоративном уровне техника персонажа — слишком тонкая операция, чтобы быть полезной. Создание Java-приложения с нуля требует разработки нескольких детальных стратегий, которые затем объединяются в приблизительный поставщик, потребляемый либо покупателем, либо службой.
Корпорации должны быть детализированы, как и интерфейсы, которые они предоставляют. Генерация веб-сервисов — это простой подход к определению сервисов общего назначения, которые имеют доступ к достаточному количеству коммерческой корпоративной логики.

(e) Поддерживает удаленный процедурный вызов: Потребители могут использовать протокол на основе XML для вызова процедур, функций и методов на удаленных объектах с использованием веб-служб. Веб-служба должна поддерживать структуру ввода и вывода, предоставляемую удаленными системами.
Разработка компонентов для всего предприятия За последние несколько лет JavaBeans (EJB) и компоненты .NET стали более распространенными в архитектурных и корпоративных развертываниях. Для выделения обеих технологий и доступа к ним используется ряд методов RPC.
Веб-функция может поддерживать RPC, предлагая собственные службы, аналогичные службам традиционной роли, или преобразовывая входящие вызовы в вызовы компонентов EJB или . NET.

(f) Поддерживает обмен документами: Одной из самых привлекательных особенностей XML является его простой подход к обмену данными и сложными объектами. Эти записи могут быть такими же простыми, как разговор с текущим адресом, или такими сложными, как разговор со всей книгой или запросом котировок. Веб-администрации упрощают простой обмен архивами, что способствует согласованию.
Дизайн веб-преимущества можно увидеть двумя способами: (i) Первый шаг — подробно изучить каждый экранный символ веб-преимущества. (ii) Во-вторых, необходимо взглянуть на быстрорастущий стек соглашений о преимуществах в Интернете.
 

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

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

(b) Интероперабельность : веб-администрирование позволяет различным приложениям взаимодействовать друг с другом и обмениваться информацией и услугами. Различные приложения также могут использовать веб-службы. Приложение .NET, например, может взаимодействовать с веб-администрированием Java и наоборот. Чтобы сделать стадию приложения и инновации автономными, используются веб-администрирования.

(c) Низкая стоимость связи : Поскольку веб-службы используют протокол SOAP через HTTP, для их реализации можно использовать существующее недорогое интернет-соединение. Веб-службы могут быть разработаны с использованием дополнительных надежных транспортных протоколов, таких как FTP, в дополнение к SOAP через HTTP.

(d) Стандартный протокол, понятный всем : веб-службы взаимодействуют через определенный отраслевой протокол. В стеке протоколов веб-служб все четыре уровня (транспорт службы, обмен сообщениями XML, описание службы и обнаружение службы) используют четко определенные протоколы.

(e) Повторное использование : Одна веб-служба может использоваться одновременно несколькими клиентскими приложениями.

Примеры вопросов

Вопрос 1. Что именно вы имеете в виду, когда говорите, что собираетесь загрузить файл в Интернет? Имя протокола, который использовался для этого.

Ответ: 

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

Вопрос 2. Зачем нужен веб-сервис ?

Ответ: 

В современном корпоративном мире веб-приложения разрабатываются с использованием ряда программных платформ. Некоторые приложения написаны на Java, другие — на .Net, третьи — на Angular JS, Node.js и других фреймворках. Большую часть времени эти разнообразные программы требуют некоторой формы общения для совместной работы. Поскольку они написаны на разных языках программирования, обеспечить точную связь между ними становится чрезвычайно сложно. Веб-сервисы играют в этом определенную роль. Веб-службы предоставляют общую платформу для нескольких приложений, написанных на разных языках программирования, для связи друг с другом

Вопрос 3. Какая безопасность требуется для веб-сервисов?

Ответ:

Веб-службы должны иметь более высокий уровень безопасности, чем уровень защищенных сокетов (SSL) (SSL). Entrust Secure Transaction Platform — единственный способ достичь такого уровня безопасности. Этот уровень безопасности необходим веб-службам для обеспечения надежных транзакций и защиты конфиденциальной информации.