Web сервисы


Содержание

Веб-сервис

(от английского web service — веб-служба; синоним – онлайновая служба)

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

Среди наиболее распространённых веб-служб выделяют:

— веб-архивы (хранилища различной информации: файлы, закладки) календари и проч.

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

• XML (расширяемый язык разметки, который предназначен для хранения и передачи структурированных данных);

• SOAP (протокол обмена сообщениями на базе XML);

• WSDL (язык описания внешних интерфейсов веб-службы на базе XML);

• UDDI (универсальный интерфейс распознавания, описания и интеграции (Universal Discovery, Description, and Integration).

Синонимы: нет
Все термины на букву «В»
Все термины в глоссарии

Web нового поколения — Web-сервисы

В данном обзоре мы рассмотрим Web-сервисы — технологию интеграции Web-приложений, которая приходит на смену традиционным Web-приложениям. Мы начнем с краткого рассказа о развитии Web, а затем более подробно поговорим о сервис-ориентированных Web. Затем рассмотрим концепцию Web-сервисов как таковых, стандарты, описывающие такие сервисы, — SOAP, WSDL и UDDI, средства разработки Web-сервисов, а также выясним, как эта концепция поддерживается в Microsoft Visual Studio.NET.

Генезис Web

Изначально World Wide Web была сетью документов. Web-серверы общались с клиентами по протоколу HTTP (Hypertext Transfer Protocol) и пересылали информацию в форме гипертекстовых документов, созданных средствами языка HTML (Hypertext Markup Language). Такие документы отображались в браузерах и содержали ссылки на другие документы. Этого было вполне достаточно для удовлетворения запросов создателей Web — ученых, которым было необходимо средство для обмена различными документами: результатами исследований, лабораторными протоколами, отчетами и т.п. Таким образом, Web появился как документо-ориентированная сеть.

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

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

Появление разнообразных мобильных устройств привело к тому, что вместо традиционных браузеров многие коммерческие Web-приложения теперь помимо протокола HTTP поддерживают и протокол WAP (Wireless Access Protocol) и способны возвращать информацию не только в стандарте HTML, но и в стандарте, удовлетворяющем пользователей, обращающихся к сервисам через мобильные устройства, — WML (Wireless Markup Language).

Естественно, электронная коммерция не может ограничиваться простой обработкой транзакций — следующим логических шагом в развитии Web стала интеграция бизнес-процессов различных компаний. Таким образом на свет появляется сервис-ориентированный Web. В его основе лежат две относительно новые технологии — SOAP (Simple Object Access Protocol) и XML (Extensible Markup Language). Согласно этому сценарию Web состоит из набора серверов приложений, обменивающихся информацией в формате XML по протоколу SOAP.

Основой сервис-ориентированного Web является Web-сервис — набор логически связанных функций, которые могут быть программно вызваны через Internet. Информация о том, какие функции предоставляет данный Web-сервис, содержится в документе WSDL (Web Service Description Language), а для поиска существующих Web-сервисов предполагается использование специальных реестров, совместимых со спецификацией UDDI (Universal Description, Discovery and Integration).

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

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

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

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

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

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

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

Рассмотрев практическое применение Web-сервисов, обратимся к стандартам, лежащим в основе этих сервисов.

Стандарты для Web-сервисов

Как мы уже знаем, в основе Web-сервисов лежат Internet-стандарты. Эти стандарты определяют протоколы, а не способы их реализации. Такое утверждение является залогом успеха Internet — ни одна компания не может влиять на Internet-стандарты и задавать собственные правила игры. Например, стандарты Web-сервисов разрабатываются совместно такими компаниями, как IBM, Microsoft, Ariba и некоторыми другими, и обсуждаются комитетом World Wide Web Consortium (W3C).

Web-сервисы базируются на трех основных Web-стандартах:

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

На рис. 1 показано, как эти три стандарта взаимодействуют друг с другим.

Серверы приложений являются хранилищами Web-сервисов и делают их доступными через протоколы HTTP GET, HTTP POST и HTTP SOAP.

Существующие Web-сервисы описываются в WSDL-документах, которые располагаются либо на сервере приложений, либо в специальных XML-хранилищах. WSDL-документ может ссылаться на другие WSDL-документы и документы XSD (XML Schema), в которых описаны типы данных, используемые Web-сервисами. XML-хранилища используются для управления WSDL-документами. Внутри WSDL-документа находится адрес (URL) Web-сервиса. Web-сервисы описаны и проиндексированы в бизнес-реестре, содержащем адреса (URL) WSDL-документов.

В следующих разделах мы рассмотрим три основных Web-стандарта, на которых базируются Web-сервисы SOAP, WSDL и UDDI, более подробно.

SOAP — Simple Object Access Protocol

SOAP — это стандарт для отсылки и получения сообщений по Internet. Изначально этот протокол был предложен фирмой Microsoft в качестве средства для удаленного вызова процедур (RPC, Remote Procedure Call) по протоколу HTTP, а спецификация SOAP 1.0 (Userland, Microsoft, Developmentor) была тесно связана с Component Object Model. Фирма IBM и ряд других компаний, в том числе Lotus, внесли определенный вклад в развитие этого протокола, и его стандарт был направлен на рассмотрение комитетом W3C.

Спецификация SOAP определяет XML-«конверт» для передачи сообщений, метод для кодирования программных структур данных в формате XML, а также средства связи по протоколу HTTP.

SOAP-сообщения бывают двух типов: запрос (Request) и ответ (Response). Запрос вызывает метод удаленного объекта, ответ возвращает результат выполнения данного метода. На рис. 2 и 3 приведены примеры запроса и ответа в формате SOAP.

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

Одной из первых реализаций протокола SOAP была Java-версия, созданная фирмой Developmentor. Компания IBM выпустила собственную Java-версию, известную под названием IBM SOAP4J, доступную на Web-узле alphaWorks (http://www.ibm.com/alphaworks/). Впоследствии эта версия была интегрирована в проект Apache XML (http://www.xml.apache.org/). В настоящее время она носит название Apache SOAP 2.0 и работает под управлением Apache Tomcat, IBM WebSphere Application Server и других серверов, поддерживающих сервлеты. Версия Microsoft, известная под названием SOAP Toolkit, позволяет использовать Visual Basic. Более полный список известных реализаций протокола SOAP можно найти на Web-узле SOAP WebServices Resource Center (http://www.soap-wrc.com/webservices/), а список доступных SOAP Web-сервисов — на Web-узле SOAP Web Services (http://www.xmethods.net/).

WSDL — Web Services Description Language

Для того чтобы приложения могли использовать Web-сервисы, программные интерфейсы последних должны быть детально описаны — с этой точки зрения язык WSDL играет ту же роль, что и язык Interface Definition Language (IDL) в распределенных вычислениях. Описание может включать такую информацию, как протокол, адрес сервера, номер используемого порта, список доступных операций, формат запроса и ответа и т.п.

Для описания этой информации было предложено несколько языков. Одним из них был язык Service Description Language (SDL), разработанный Microsoft и входивший в первую версию Microsoft SOAP Toolkit. Компания IBM переработала спецификацию и, использовав спецификацию Network Accessible Service Specification Language (NASSL), выпустила NASSL Toolkit как часть SOAP4J. Идеи, реализованные в NASSL, повлияли на спецификацию языка SOAP Contract Language (SCL), предложенную Microsoft. В настоящее время обе спецификации (NASSL и SDL/SCL), а также предложения других фирм учтены в спецификации языка WSDL. Для описания бизнес-логики IBM и Microsoft работают над спецификацией языка Web Services Flow Language (WSFL).

На рис. 4 показан скелет описания сервисов на языке WSDL.

Как мы видим, описание сервисов представляет собой XML-документ, состоящий из нескольких элементов, в том числе из описания пространства имен (namespace), описания типов и элементов, сообщений, порта, а также возможных операций — запросов и ответов.

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

Описание языка WSDL можно найти на Web-сайте компании Microsoft по адресу http://www.msdn.microsoft.com/xml/general/wsdl.asp/.

UDDI — Universal Description, Discovery and Integration

Задача UDDI — предоставить механизм для обнаружения Web-сервисов. UDDI задает бизнес-реестр, в котором провайдеры Web-сервисов могут регистрировать сервисы, а разработчики — искать необходимые им сервисы. Компании IBM, Microsoft и Ariba создали собственные UDDI-реестры (в скором времени эти реестры будут объединены в Web-реестр), в одном из которых разработчики могут зарегистрировать свои Web-сервисы, после чего данные будут автоматически реплицированы в другие реестры (рис. 5).

UDDI базируется на элементах четырех типов: Business Entity, Business Service, Binding Template и Technology Model. Элемент Business Entity описывает индустрию, предоставляющую данный Web-сервис. Этот элемент может включать описания категорий для данной индустрии, облегчающие более детальный поиск сервисов.

Business Service — это класс сервисов в рамках определенной отрасли промышленности или услуг. Каждая отрасль принадлежит определенному элементу Business Entity.

Вместе Binding Template и Technology Model определяют Web-сервис. Technology Model содержит абстрактное описание, а Binding Template — конкретную спецификацию сервиса. Каждый элемент Binding Template принадлежит определенному элементу Business Service, но несколько элементов Binding Template могут ссылаться на один элемент Technology Model.

Бизнес-реестр UDDI сам является SOAP Web-сервисом. Он поддерживает операции создания, модификации, удаления и поиска элементов всех четырех рассмотренных выше типов.

Полное описание UDDI можно найти на Web-сайте по адресу http://www.uddi.org/.

Средства разработки

Рассмотрев три основных Web-стандарта, на которых базируются Web-сервисы, — SOAP, WSDL и UDDI, мы теперь знаем, что они являются достаточно комплексными при создании всех необходимых для описания Web-сервиса XML-документов. Эту работу выполняют специальные средства разработки, предоставляя разработчикам возможность сосредоточиться на бизнес-логике создаваемого сервиса, а не на низкоуровневых деталях его реализации. Среди наиболее популярных в настоящее время средств разработки Web-сервисов следует упомянуть Microsoft SOAP Toolkit и IBM XML and Web Services Development Envirоnment (WSDE).

Ниже мы рассмотрим еще одно средство для создания Web-сервисов — Microsoft Visual Studio.NET, которое в скором времени станет основным инструментом для разработчиков, создающих решения для платформы Microsoft .Net.

Web-сервисы в Microsoft Visual Studio.NET

Для создания Web-сервиса средствами Microsoft Visual Studio.NET необходимо выполнить следующие действия:

  1. Запустить Visual Studio.NET 7.0.
  2. Выполнить команду File | New | Project (или выбрать команду Create New Project на стартовой странице VS Home Page).
  3. В панели New Projects выбрать Visual Basic Projects, в панели Templates выбрать Web Service (рис. 6).
  4. Задать название сервиса и нажать Ok.

В результате мы получим такой скелет сервиса (чтобы увидеть код, следует нажать правую кнопку мыши):


Microsoft Visual Studio.NET также создаст SDL-файл, который будет содержать описание нашего Web-сервиса, и DISCO-файл, используемый для регистрации и обнаружения сервиса.

В качестве примера создадим Web-сервис, выполняющий конвертацию валюты. Реализация метода Usd2Rub — преобразование суммы в долларах в сумму в рублях — показана ниже:

После создания Web-сервиса вызовем команду Build (выбрав опцию Release) для генерации необходимого кода и внедрения сервиса на Web-сервер. Теперь можно испытать наш сервис в действии. Для этого необходимо запустить Web-браузер и указать адрес, который был указан в панели New Project — Project will be created…

В нашем примере это будет http://terra/mywebservice/ (см. рис. 6). После этого указываем имя класса (в нашем примере — это ExchangeRateService) и расширение ASMX (Assembly). Полный адрес для запуска нашего сервиса будет выглядеть так:

В результате мы получаем тестовую страницу, созданную Visual Studio.NET (рис. 7).

Данная страница содержит описание Web-сервиса, а также список реализованных в нем методов. Например, описание метода Usd2Rub показано на рис. 8.

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

Завершая краткое описание создания Web-сервисов, отметим, что тестовая страница создается на основе информации, хранимой в SDL-файле, который можно просмотреть, указав параметр ?SDL в адресной строке браузера:

Для запуска Web-сервиса из приложения следует использовать следующий URL:

Обратите внимание также на то, что имя метода указывается после символа «/», а параметр — как обычный параметр URL-строки.

Собеседование по Java EE — Web services (вопросы и ответы)

Список вопросов и ответов по теме «Веб-сервисы» в Java (Java web services).

к списку вопросов раздела JEE

Вопросы

1. Что такое веб сервисы?
2. В чем разница между SOA и web service?
3. Что такое SOAP?
4. Что такое REST?
5. В чем разница между REST и SOAP веб сервисами?
6. Как бы вы решили какой из REST или SOAP веб сервисов использовать?
7. Объясните понятие WSDL.
8. Что такое JAX-WS?
9. Расскажите о JAXB.
10. Можем ли мы посылать soap сообщения с вложением?
11. Что такое MTOM?
12. Что такое XOP?
13. Объясните элемент SOAP envelope.
14. Как определяется пространство имен SOAP?
15. Что вы знаете о кодировании в SOAP (encoding)?
16. Что определяет атрибут encodingStyle в SOAP?
17. Какие два конечных типа веб сервисов используют JAX-WS?
18. Какие существуют правила для кодирования записи header?
19. Что вы знаете об инструменте wsimport?
20. Что вы знаете об инструменте wsgen?
21. Какие вы можете выделить различия между SOAP и другими техниками удаленного доступа?
22. Что такое resource в REST?
23. Какие HTTP методы поддерживаются в REST?
24. Когда можно использовать GET запрос вместо POST для создания ресурса?
25. Какая разница между GET и POST запросами?
26. Что означает WADL?
27. Какие вы знаете фреймворки, которые реализуют REST веб сервисы?
28. Какая разница между AJAX и REST?
29. Что делает аннотация @Path?
30. Что делает аннотация @PathParam?
31. Что делает аннотация @QueryParam?
32. Что делает аннотация @MatrixParam?
33. Что делает аннотация @FormParam?
34. Какие два способа получения заголовка HTTP запроса в JAX-RS вы знаете?
35. Как скачать файл с помощью JAX-RS?

Ответы

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

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

  • Функциональная совместимость
  • Расширяемость
  • Возможность машинной обработки описания

2. В чем разница между SOA и web service?

Сервис-ориентированная архитектура (SOA, service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам. Программные комплексы, разработанные в соответствии с сервис-ориентированной архитектурой, обычно реализуются как набор веб-служб, взаимодействующих по протоколу SOAP, но существуют и другие реализации (например, на базе jini, CORBA, на основе REST). Веб сервисы реализующие эту концепцию используют XML, JSON и др., а так же интернет протоколы вроде HTTP(S), SMTP и др..

Илон Маск рекомендует:  font-family в CSS

3. Что такое SOAP?

SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам; вплоть до спецификации 1.2) — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. Официальная спецификация последней версии 1.2 протокола никак не расшифровывает название SOAP. SOAP является расширением протокола XML-RPC.

SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.

4. Что такое REST?

REST (сокр. от англ. Representational State Transfer — «передача состояния представления») — архитектурный стиль взаимодействия компонентов распределённого приложения в сети. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой гипермедиа-системы. В определённых случаях (интернет-магазины, поисковые системы, прочие системы, основанные на данных) это приводит к повышению производительности и упрощению архитектуры. В широком смысле компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во Всемирной паутине. REST является альтернативой RPC.

В сети Интернет вызов удалённой процедуры может представлять собой обычный HTTP-запрос (обычно GET или POST; такой запрос называют REST-запрос), а необходимые данные передаются в качестве параметров запроса. Для веб-сервисов, построенных с учётом REST, то есть не нарушающих накладываемых им ограничений, применяют термин «RESTful».

5. В чем разница между REST и SOAP веб сервисами?

  • REST поддерживает различные форматы: text, JSON, XML; SOAP — только XML,
  • REST работает только по HTTP(S), а SOAP может работать с различными протоколами,
  • REST может работать с ресурсами. Каждый URL это представление какого-либо ресурса. SOAP работает с операциями, которые реализуют какую-либо бизнес логику с помощью нескольких интерфейсов,
  • SOAP на основе чтения не может быть помещена в кэш, а REST в этом случае может быть закэширован,
  • SOAP поддерживает SSL и WS-security, в то время как REST — только SSL,
  • SOAP поддерживает ACID (Atomicity, Consistency, Isolation, Durability). REST поддерживает транзакции, но ни один из ACID не совместим с двух фазовым коммитом.
REST vs SOAP. Часть 1. Почувствуйте разницу: https://habrahabr.ru/post/131343/

6. Как бы вы решили какой из REST или SOAP веб сервисов использовать?

REST против SOAP можно перефразировать как «Простота против Стандарта». В случае REST (простота) у вас будет скорость, расширяемость и поддержка многих форматов. В случае с SOAP у вас будет больше возможностей по безопасности (WS-security) и транзакционная безопасность (ACID).

7. Объясните понятие WSDL.

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

Каждый документ WSDL 1.1 можно разбить на следующие логические части:

  • определение типов данных (types) — определение вида отправляемых и получаемых сервисом XML-сообщений
  • элементы данных (message) — сообщения, используемые web-сервисом
  • абстрактные операции (portType) — список операций, которые могут быть выполнены с сообщениями
  • связывание сервисов (binding) — способ, которым сообщение будет доставлено

WEB сервисы 1С, создание и настройка

Михаил Сайко

Сегодня WEB сервисы используются практически повсеместно – именно они предоставляют нам информацию о рейсах самолетов и поездов, курсах валют и погоде. Неудивительно, что и 1С обладает возможностью создания собственных WEB сервисов, позволяющих выступать как в роли поставщика, так и потребителя. Данный механизм встроен в платформу «1С:Предприятие 8.3» и разработчики могут добавлять даже в типовую конфигурацию собственные объекты типа «WEB-сервисы». Их архитектура построена на наборе сервисов, позволяющих обмениваться информацией с другим программным обеспечением.

Создание веб-сервиса 1С

Одним из главных преимуществ WEB-сервисов 1С является отсутствие необходимости давать прямой доступ к данным ИБ. Правильно настроенный веб-сервис 1С позволяет другим приложениям пользоваться функциями извне. В таких случаях определять право пользования данными по заданным параметрам должна сама функция по прописанным разработчиком правилам.

Как создавать веб-сервис в 1С?

Чтобы определенная функция системы 1С стала доступна внешнему ПО, необходимо выполнить следующий алгоритм действий:

  1. Зайти в конфигурацию и в определенной ветке дерева добавить объект WEB-сервис;
  2. Описать все операции, которые сможет выполнять наш функционал. Описание функций производиться в модуле на встроенном в 1С языке;
  3. Добавить описание параметров функций веб-сервиса. Учтите, что типы данных описываются с учетом существующих типов механизма XDTO, появившегося в платформе версии 8.1;
  4. Опубликовать созданный WEB-сервис на сервере. Механизм, встроенный в платформу 1С, поддерживает следующие стандарты:
  • SOAP
  • WSDL
  • HTTP
  • SSL/TLS
  • WS-I BP

Пример создания простого WEB-сервиса

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

Открываем конфигуратор, находим в дереве ветку «WEB-сервисы» и добавляем новый сервис «wa_LengthString». Также необходимо на вкладке «Операции» добавить новую операцию. Назовем ее «CalcLengthString», в свойствах укажем тип возвращаемого значения – int или integer и создадим внутри нее параметр «InputString». Тип значения оставляем string.

Теперь необходимо прописать действие функции CalcLengthString в модуле WEB-сервиса. Для этого открываем свойства созданной функции и нажимаем кнопку в виде лупы справа, у поля ввода «Имя процедуры». 1С автоматически создаст функцию в модуле нашего WEB-сервиса и откроет его для того, чтобы мы описали действие CalcLengthString. Воспользуемся этим и напишем действие функции – определение длины вводимой строки.


Фактически на этом создание простейшего WEB-сервиса закончено. Теперь необходимо «выложить» этот сервис в общий доступ, чтобы стороннее ПО или другие системы 1С могли пользоваться данным функционалом.

Публикация веб-сервиса 1С

Для того чтобы мы смогли опубликовать созданный веб-сервис с его функциональностью, нам необходимо иметь доступ на сайт. Перед тем как мы начнем публикацию сервиса, необходимо проверить имя файла в свойствах созданного модуля wa_LengthString. Оно должно быть понятное, простое и иметь расширение «1cws».

Теперь настало время публиковать созданный нами WEB-сервис на сервере. Эта возможность появилась в версии платформы 8.3 и многие компании уже поняли всю пользу этого функционала. Для того чтобы приступить к публикации, необходимо в конфигураторе открыть форму «Администрирование/Публикация на веб-сервере…».

В открывшемся окне нам необходима настройка Web сервисов 1С и заполнение определенных полей:

  • Имя. Обозначает папку на веб-сервере, в которой будет храниться описание нашего веб-сервиса. Будьте внимательны к регистрам, так как иногда серверы различают символы большого и малого регистра;
  • Веб-сервер. Необходимо выбрать сервер из установленных на компьютере;
  • Каталог. Вы должны выбрать путь к папке, где хранятся данные веб-сервера по настройке подключения. Используются исключительно латинские буквы;
  • Два признака типа «Булево». Первый нам пригодиться, если необходимо настроить доступ через веб-клиент к конфигурации. Для того чтобы опубликовать сервис 1С, необходимо поставить вторую отметку.

Остается лишь проверить, что у нужного WEB-сервиса установлена галка в первом столбце, и нажать на «Опубликовать».

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

Проверить, опубликован ли ваш WEB-сервис на сервере, достаточно просто. Необходимо открыть любой браузер и в адресную строку вбить строчку типа:

В ответ на такой запрос адреса браузер должен отобразить структуру файла XML. Если же вы видите пустую страницу, ошибку или непонятные символы (проблемы с кодировкой), то нужно еще раз проверить все действия. Также не лишним будет убедиться, что сервер настроен верно, и у вас есть к нему доступ. После успешной публикации WEB-сервис 1С смогут использовать сторонние приложения.

Веб-сервисы и веб-приложения для бизнеса: кому, зачем и почему нужна такая разработка

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

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

Это всегда уникальная разработка, которая создается для решения конкретных задач в отдельно взятой компании. Или в группе компаний. Сразу возникает вопрос: если есть такой «волшебный» метод упорядочить взаимодействие и ускорить бизнес, почему не все его используют? Во-первых, не всем он нужен. Многие компании пользуются стандартными, распространенными CRM и иными системами, и их все устраивает. Во-вторых, для малого или начинающегося бизнеса разработка иногда кажется непосильной в финансовом плане. В-третьих, есть компании, и таких много, которые почему-то не считают, что веб-сервис может им серьезно помочь. Рассмотрим в статье эти три аспекта.

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

Преимущества веб-сервисов

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

  1. Сокращение затрат. За счет автоматизации процессов и моментального обмена данными происходит экономия рабочего времени сотрудников. Снижаются материальные издержки (те же расходы на канцтовары и электроэнергию). В итоге в компании высвобождаются свободные ресурсы.
  2. Автоматизация. Она, помимо снижения затрат, влечет и повышение эффективности. Представьте, что отчет начинает составлять не бухгалтер, который может уставать, плохо себя чувствовать и потому допускать ошибки, а программа, которая таким факторам не подвержена. Ускоряется рабочий цикл.
  3. Функциональность. Как правило, веб-сервис создают для решения нескольких задач. Поэтому эффективность организации повышается комплексно. Заложенные в продукт функции предусматривают успех по нескольким фронтам.

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

Веб-приложения для бизнеса

Все программные продукты, применяемые в коммерческой или производственной деятельности, условно можно выделить в 2 категории:

  • Софты, решающие внутренние, локальные задачи: рост продаж, повышение эффективности, упрощение сбора, обработки и использования информации.
  • Продукты, нацеленные вовне, ориентированные на работу с внешней аудиторией, направленные на продвижение и развитие бренда, увеличение лояльности ЦА и т. д.

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

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

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

В каком виде можно реализовать веб-сервис или приложение

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

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

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

Поэтому в ходе даже не самой разработки, а на этапе подготовке к ней, важно:

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

Упрощенная схема разработки выглядит так:

  1. Исследования.
  2. Проектирование.
  3. Прототипирование.
  4. Создание дизайна.
  5. Разработка.
  6. Тестирование.
  7. Ввод в эксплуатацию.

В каком примерно виде можно реализовать веб-сервис или приложения:

  • Личные кабинеты.
  • Сервисы для обмена информацией.
  • Софты для формирования финансовых и иных отчетов.
  • Калькуляторы.
  • Сервисы для составления и обработки заявок.
  • Ресурсы для хранения информации.
  • Коммуникационные площадки.
  • Базы данных.

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

Кому нужна такая разработка?

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

В пример можно привести:

  • Производство. Автоматизация здесь помогает существенно снизить издержки.
  • Медицинская деятельность. И в плане внутреннего обмена данными, и в плане удобства клиентов веб-приложения могут быть весьма полезны.
  • Ресторанный бизнес, особенно когда открыта сеть удаленных друг от друга заведений.
  • Туризм.
  • Сфера обслуживания автомобилей. Упорядочить можно процессы на СТО, автомойках — запись клиентов, учет оказанных услуг, ведение программ лояльности.
  • Салоны красоты. Процветающая в настоящее время отрасль может быть успешно автоматизирована, от онлайн-записи на процедуры до учета расходных материалов мастеров.
  • Фитнес-центры, спортивные клубы — и клиентам, и компаниям можно предложить выгодные решения для упорядочения прайсов, расписаний, записи на тренировки, учета достижений.

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

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

Как создать веб-сервисы при помощи расширений 1С

В этой статье рассмотрим, как можно реализовать веб-сервис в расширении платформы 1С.

В качестве примера возьмем веб-сервис, позволяющий передавать информацию о клиентах из внешней CRM-системы во внутреннюю систему управленческого учета на «1С:Управление нашей фирмой».

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

О чем эта статья

Материал статьи раскроет ответы на следующие вопросы:

  • Как работать с XDTO-пакетами?
  • Как создать веб-сервис и настроить его свойства?
  • Как опубликовать веб-сервис на сервере?

Постановка задачи

Компания ведет учет в типовом решении фирмы «1С:Управление нашей фирмой» (УНФ). Для управления взаимоотношениями с клиентами используется облачная CRM-система. В CRM-систему вводят информацию о новых клиентах. Необходимо реализовать перенос сведений о новых клиентах в УНФ сразу же при регистрации данных в CRM-системе.

Рисунок 1. Схема работы

Данные должны передаваться одним параметром (структурой). Спецификация данных, передаваемые из CRM в УНФ приведены в таблице 1.

Таблица 1. Требования к данным для обмена

Данные Имя cвойства Тип Ограничения
Полное наименование FullName Строка Обязательно для заполнения
ИНН INN Строка(12) Для ЮрЛица – длина 10
Для ИП – длина 12
Для ФизЛица – не заполняется
Допускаются только цифры
КПП KPP Строка(9) Для ЮрЛица – длина 9
Для ФизЛица – не заполняется
Допускаются только цифры
Телефон Phone Строка(12) Обязателен для заполнения
формат +7 (NNN) NNN-NN-NN

После создания контрагента в CRM-систему должен быть передан уникальный идентификатор. Идентификатор будет использоваться в дальнейшем для сопоставлении клиента в CRM и УНФ при обмене заказами. Необходимо реализовать описанный функционал без снятия УНФ с поддержки.


Обоснование выбора варианта решения

  1. Проанализируем требования. Добавлять клиентов надо «на лету», сразу же при вводе в CRM. Значит периодические обмены по расписанию нам не подходят.
  2. Выбранная CRM расположена в облаке, поэтому использовать COM-соединение не получится.
  3. В требованиях к передаваемым данным есть ограничения — на длину строк и на виды контрагентов. Выбирая между технологией обмена через http-сервисы и веб-сервисы, остановимся на веб-сервисах, так как типизация данных и настройка ограничений в них есть «из коробки». Дополнительным плюсом будет то, что веб-сервисы умеют «самодокументироваться», а значит мы экономим время на описании API для разработчиков CRM.
  4. Последнее требование — не снимать конфигурацию с поддержки.

Таким образом, для решения описанной задачи мы создадим расширение конфигурации. А в этом расширении реализуем веб-сервис для добавления информации о контрагентах.

Добавляем расширение

Начнем реализацию поставленной задачи и создадим новое расширение. Для этого откроем меню Конфигурация -> Расширения конфигурации.

Рисунок 2. Добавляем расширение

В открывшемся окне жмем кнопку Добавить, а затем заполняем окно создания расширения.

Рисунок 3. Заполняем свойства нового расширения

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

Импортируем объекты метаданных

Теперь импортируем в расширение объекты для дальнейшей работы. Нам нужны:

  • Справочник Контрагенты
  • Справочник Виды контактной информации
  • Перечисление Типы контактной информации

Начнем со справочника Контрагенты. Выделим его в основной конфигурации и вызовем контекстное меню Добавить в расширение.

Рисунок 4. Импортируем справочник

Затем добавим в расширение реквизиты справочника Контрагенты и табличную часть КонтактнаяИнформация.

В результате ветка Контрагенты в расширении должна выглядеть так:

Рисунок 5. Справочник «Контрагенты» в расширении

После чего добавим в расширение перечисления ВидыКонтрагентов и ТипыКонтактнойИнформации.

Идем дальше. Из справочника ВидыКонтактнойИнформации нам нужно предопределенное значение ТелефонКонтрагента. Выдяем в дереве метаданных справочник ВидыКонтактнойИнформации и переходим по гиперссылке Предопределенные:

Рисунок 6. Предопределенные элементы справочника

В ветке Контрагенты находим предопределенный элемент ТелефонКонтрагента.

Рисунок 7. Выбираем предопределенный элемент ТелефонКонтрагента

Выполняем команду контекстного меню Добавить в расширение. В расширение добавляется справочник ВидыКонтактнойИнформации и его предопределенный элемент ТелефонКонтрагента.

Рисунок 8. Справочник «Виды контактной информации» в расширении

С импортом объектов в расширение мы закончили. Теперь переходим к разработке веб-сервиса.

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

Веб-сервисы в 1C представляют собой реализацию протокола SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам). Архитектуру приложения на основе протокола SOAP можно представить в виде следующей схемы:

Рисунок 9. Архитектура приложений на основе протокола SOAP

Общий принцип работы веб-сервиса можно описать так: мы создаем некий функционал, чтобы предоставить его сторонним разработчикам. Для того, чтобы этот функционал был им доступен, мы размещаем его на веб-сервере (публикуем). При публикации веб-сервиса происходит размещение его описания в формате WSDL (WSDL – Web Service Definition Language). Это описание стандартизовано и содержит описание методов веб-сервиса и типов данных, которые могут передаваться между сервисом и его клиентом. Клиент сервиса получает описание сервиса в виде WSDL-файла и может начать обмениваться данными в соответствии с этим описанием. Обмен происходит по протоколу HTTP, а сообщения передаются в теле HTTP пакетов в формате XML.

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

Создаем XDTO-пакет

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

Приступаем к созданию XDTO-пакета для нашего веб-сервиса. В дереве метаданных расширения в ветке Общие -> XDTO-пакеты добавим XDTO-пакет ak_Customers. В URI пространства имен указываем http://kursy-po-1c.ru/ws/wsextension.

Это не ссылка на реальный адрес в интернете, а просто строка-идентификатор пространства имен, который помогает однозначно идентифицировать типы данных с одинаковыми именами. Например, программист Иванов определил тип данных Customer c двумя свойствами Name и FullName, а программист Петров определил свой тип Customer со свойствами Name, INN, KPP.

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

Илон Маск рекомендует:  Что такое код pdf_set_parameter

Рисунок 10. Свойства XDTO-пакета

Теперь жмем ссылку Открыть пакет и начинаем описывать типы данных.

Сначала опишем простые типы данных по которым нам нужно наложить ограничения. Это ИНН, КПП, Телефон.

ИНН по условиям задачи различается для ИП и для ЮрЛица.

Определим 2 простых типа: INN_IP и INN_UL. Для этого в форме редактирования пакета открываем меню Добавить -> ТипЗначения.

Рисунок 11. Добавляем тип значения в XDTO-пакет

Заполняем свойства как на рисунке ниже:

Рисунок 12. Свойства типа значения INN_IP

Здесь мы указали имя типа INN_IP (ИНН для ИП) и определили для него ограничение — это должна быть строка длиной 12 знаков.

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

Рисунок 13. Добавляем шаблона заполнения INN_IP

Заполняем свойство образца шаблоном в виде регулярного выражения [0-9]<12>. То есть мы допускаем в значении 12 цифр от 0 до 9.

Рисунок 14. Шаблон заполнения INN_IP

Подобные действия нужно произвести с INN_UL (ИНН юрлица) и KPP (КПП):

Рисунок 15. Добавляем типы значений и устанавливаем шаблоны

Рисунок 16. Типа значения Phone и шаблон его заполнения

Теперь перейдем к определению типов для данных о клиентах.

У нас есть три типа клиентов: Юрлицо, ФизЛицо и ИП. Для всех типов клиентов правила заполнения ИНН и КПП отличаются. Можно сделать только один класс Customer и контроль заполнения ИНН и КПП производить программно, но удобнее это делать декларативно — чтобы уменьшить возможность ошибок. Мы создадим три комплексных типа: CustomerIP, CustomerUL и CustomerFL. Значения ИНН и КПП будем выбирать из ранее созданных типов значений.

Для создания клиента ФизЛицо выделим корень пакета и вызовем меню Добавить -> ТипОбъекта. В свойствах укажем следующие значения:

Рисунок 17. Свойства типа объекта CustomerFL

  • CustomerFL — это имя типа. Должно быть на английском.
  • ComplexType — базовый тип, аналогичный структуре.

Выделим тип объекта CustomerFL и вызовем меню Добавить->Свойство. Заполним в редакторе свойств значения:

Рисунок 18. Добавляем свойство FullName в тип объекта CustomerFL


  • FullName — имя свойства. Должно быть на английском.
  • Тип string — строковый тип.
  • Поле FullName должно быть обязательно заполнено указываем Возможно пустое — Ложь.

Таким же образом добавим свойства Phone и GUID.

Рисунок 19. Добавляем свойство Phone в тип объекта CustomerFL

Рисунок 20 Добавляем свойство GUID в тип объекта CustomerFL

Затем добавим тип объекта CustomerIP с такими же свойствами, как у CustomerFL, добавив новое свойство INN.

Рисунок 21. Добавляем свойство INN в тип объекта CustomerIP

Дальше создадим тип объекта CustomerUL с такими же свойствами, как у CustomerIP. Добавим новое свойство KPP.

Рисунок 22. Добавляем свойство KPP в тип объекта CustomerUL

У свойства INN нужно изменить тип на INN_UL (http://kursy-po-1c.ru/ws/wsextension).

Рисунок 23. Добавляем свойство INN в тип объекта CustomerUL

Мы завершили создание XDTO-пакета.

Рисунок 24. Новый XDTO-пакет

Переходим к разработке веб-сервиса.

Создаем веб-сервис

В ветке метаданных Общие выделяем ветку Web-Сервисы. Вызываем контекстное меню Добавить и заполняем свойства нового веб-сервиса:

Рисунок 25. Заполняем свойства веб-сервиса

  • Имя — ak_Customers
  • ПакетыXDTO — http://kursy-po-1c.ru/ws/wsextension. Теперь сможем использовать типы данных, которые определены этом пакете.
  • URI пространства — http://kursy-po-1c.ru/ws/wsextension. Пространство имен будет использоваться клиентами веб-сервиса.
  • Имя файла публикацииCustomers.1cws. Имя будет использоваться в URL для получения WSDL.

Теперь добавим метод веб-сервиса, который будет записывать в УНФ нового контрагента-физлицо. Вызываем меню Добавить->Операция и заполняем свойства:

Рисунок 26. Свойства метода AddCustomerFL

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

Далее мы добавим параметры, которые будут передаваться в веб-сервис.

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

Рисунок 27. Свойства параметра Customer

  • Имя — имя параметра метода сервиса. Будет виден на клиенте веб-сервиса.
  • Тип значения — тип значения, определенный в нашем пакете.

Добавим еще две операции:

  • AddCustomerIP
  • AddCustomerUL.

Можно сделать это копированием. Затем нужно поменять имена операций, имена процедур-обработчиков (AddCustomerIP и AddCustomerUL) и типы параметров. Для AddCustomerIP тип параметра установим CustomerIP, а для AddCustomerUL — CustomerUP.

Теперь нужно создать процедуры-обработчики методов сервиса.

Код простой и каких-то особых комментариев не требует.

Публикуем веб-сервис на сервере

Для публикации веб-сервиса должны быть установлены:

  • Веб-сервер (Apache или IIS)
  • Платформа 8.3.7 и выше с установленным расширением веб-сервера

О подготовке рабочего окружения можно прочитать в статье Как настроить обмен 1С с интернет-сервисами.

Для публикации веб-сервиса нужно запустить конфигуратор с правами администратора. Для этого вызываем контекстное меню и выбираем «Запуск от имени администратора»:

Рисунок 28. Запускаем конфигуратор от имени администратора

После открываем меню Администрирование->Публикация на веб-сервере. В открывшемся окне заполняем настройки:

Рисунок 29. Публикация веб-сервиса

  • Имя — имя базы для публикации на сервере. Будет являться частью URL.
  • Веб-сервер — на нем будет опубликована база. В нашем случае используется Apache 2.4.
  • Каталог — место на диске, куда будет помещен default.vrd.
  • Публиковать веб-сервисы — отмечаем.
  • Публиковать веб-сервисы расширений по умолчанию — отмечаем, чтобы веб-сервисы были доступны из расширений.

Жмем Опубликовать.

Проверим, что веб-сервис опубликовался. Для этого запустим браузер и в адресной строке введем http://localhost/UNF/ws/Customers.1cws?wsdl. В результате в браузере должен отобразиться XML.

Рисунок 30. Проверяем работу веб-сервиса

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

Чтобы в дальнейшем не отвлекаться на пароли при изучении статьи (тему безопасности мы сознательно опускаем), откроем в текстовом редакторе файл default.vrd, (он лежит в каталоге, указанном при публикации). В него запишем логин и пароль в строке подключения: ib=”File=»D:\1CBase\UNF»;usr=admin;pwd=12345;”. Логин, пароль и путь должны быть от вашей базы 1С.

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

Для проверки работоспособности сервера можно создать отдельную базу 1С и добавить в ней обработку ТестВебСервера со следующими реквизитами:

  • FullName, строка(100)
  • INN, строка(12)
  • KPP, строка(9)
  • Phone, строка(20)

Реквизиты выводим на форму и добавляем три кнопки:

  • Создать ФизЛицо
  • Создать ЮрЛицо
  • Создать ИП.

Рисунок 31. Обработка для проверки веб-сервиса

В модуле формы напишем такой код:

  1. В обработчиках кнопок вызываем процедуру СоздатьКлиентаНаСервере() и передаем название типа клиента в виде строки.
  2. Получаем WSDL-описание веб сервиса, опубликованного по указанному в параметрах URL. На основании него создается объект WSОпределение.
  3. Создаем объект Прокси для работы с сервисом. Он позволяет обращаться к веб-сервису, вызывая его методы в привычном объектном стиле. В качестве параметров передаем WSОпределение сервиса, созданное на предыдущем шаге, пространство имен веб-сервиса, имя веб-сервиса и точку подключения. Имя точки подключения формируется путем добавления к имени сервиса суффикса Soap (так формирует WSDL 1C).
  4. Получаем тип клиента по URI пространства имен.
  5. На основании типа клиента, полученного на предыдущем шаге, создаем XDTOОбъект Клиент. По структуре этот объект будет соответствовать структуре типа, который мы определяли в нашем XDTO-пакете.
  6. Заполняем значения реквизитов клиента данными, введенными в форме;
  7. В зависимости от переданного в процедуру типа клиента, мы вызываем разные методы веб-сервиса. «Под капотом» этого вызова произойдет сериализация данных в XML, валидация XML, формирование HTTP пакета и отправка его на сервер.

С этой обработкой можно поэксперементировать. Попробуйте создавать клиентов разных типов, введя корректные данные и некорректные. Если вы попытаетесь ввести в ИНН буквы или заполнить телефон, не соблюдая формат, то появится окно ошибки.

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

На этом пока закончим, но не остановимся :-)

Об авторе


Автор статьи – Алексей Дубровин , г. Челябинск

Нужно быстро разобраться в работе расширений?

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

Использование Web-сервиса «Клеверенс» для работы в онлайн режиме работы с учетными системами на платформе «1С: Предприятие»

Глоссарий

Web-сервер — сервер, принимающий HTTP-запросы от клиентов, обычно Web-браузеров, требуется для публикации базы 1С.

Web-сервис — Web-службы могут взаимодействовать друг с другом и со сторонними приложениями посредством сообщений, основанных на определённых протоколах (SOAP, XML-RPC и т. д.) и соглашениях (REST). Web-служба является единицей модульности при использовании сервис-ориентированной архитектуры приложения.

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

Публикация расширения — это помещение объектов Web-сервиса для обмена из расширения в службу Web-сервера.

Для чего и кому это нужно

По-умолчанию продукты «Клеверенс» для доступа в базу 1С (для получения данных о товаре по штрихкоду, списка документов, или самого документа и т.п.) используют COM-соединение.

Когда мобильному устройству нужен онлайн-доступ в 1С, оно обращается к серверу Mobile SMARTS, который поднимает у себя COM-соединение к нужной базе 1С, открывает в этой базе специальную обработку «Клеверенс» и делает делает выборки по базе 1С, используя сервисные экспортные методы, написанные в этой обработке.

Для чего нужен Web-сервис

Web-сервис — предлагает более современную среду для обмена данными в онлайне с учетной системой на платформе «1С: Предприятие», нежели устаревшее COM-соединение.

Какие плюсы по сравнению с COM-соединением

Стабильнее при использовании с множеством клиентов.

Быстрый запуск как Web-сервиса, так и Web-сервера.

Есть настройки работы как с Web-сервером, так и с конкретным Web-сервисом.

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

Лучше работает с множеством запросов.

Какие минусы по сравнению с COM-соединением

Более высокие требования к платформе «1С: Предприятие», требуется платформа не ниже версии 8.3.12.

Требуется ручная настройка, и публикация Web-сервиса на Web-сервере.

Кому нужен Web-сервис

Web-сервис в первую очередь нужен тем, у кого есть проблемы с использованием COM-соединение к 1С при работе продуктов «Клеверенс», по любым причинам. Долгий первый запуск, медленное получение данных, обрывы соединений и т.д. Если есть проблемы, надо переходить на Web-сервис.

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

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

Установка компонентов на ПК


Минимальный набор, который должен быть установлен на ПК для работы с Web-сервисом «ТСД Клеверенс»

Операционная система: Windows 7 и выше.

Microsoft .Net Framework 4.6.1 и выше.

Платформа «1С: Предприятие» не ниже 8.3.12.

Компонент «1С: Предприятие»: “Модули расширения Web-сервера”.

Конфигурация базы данных 1С с версией совместимости не ниже 8.3.10.

Платформа Mobile SMARTS, версии 3.0.46.46670 и выше.

1. Установка Web-сервера Apache или IIS

Что лучше выбрать?

Смотрите на свои предпочтения и удобство использования, сервер Mobile SMARTS от «Клеверенс» будет работать одинаково с любым из них!

В ОС Windows проще всего установить IIS. Включить и установить его можно через программы и компоненты в панели управления, подробная инструкция по установке сервера на IIS и публикации базы, можно найти на просторах интернета, вот прекрасная инструкция с сайта tavalik.ru.

Обратите внимание что должны быть включены компоненты:

Общие функции HTTP (Common HTTP Features)

Статическое содержимое (Static Content)

Документ по умолчанию (Default Document)

Обзор каталогов (Directory Browsing)

Ошибки HTTP (HTTP Errors)

Разработка приложений (Application Development)

Расширяемость .NET 3.5 (.NET Extensibility 3.5)

Расширения ISAPI (ISAPI Extensions)

Фильтры ISAPI (ISAPI Filters)

Исправление и диагностика (Health and Diagnostics)

Ведение журнала HTTP (HTTP Logging)

Монитор запросов (Request Monitor)

Средства управления (Management Tools)

Консоль управления IIS (IIS Management Console)

Если же вы хотите использовать именно Web-сервер Apache, то используйте его, инструкция по установке есть на сайте programmist1s.ru.

2. Установка расширения

Запуск конфигуратора платформы 1С предприятия под администратором.

Для публикации или изменения публикации базы данных необходимо запускать конфигуратор «1С: Предприятие» от имени администратора.

Открываем окно с расширениями конфигурации.

Добавляем в список новую пустую, ничего не меняем и нажимаем “ОК”.

Открываем конфигурацию созданного расширения.

Загружаем конфигурацию расширения «Клеверенс».

Загружаем в созданное расширение данные из файла CleverenceWebExtension.cfe из папки базы, подпапки “ \Обработки 1С\Расширение для Web-сервиса\ ” и далее

для обычных форм из вложенной папки “Обычные формы”.


для управляемых форм из вложенной папки “Управляемые формы”.

Отключаем в расширении безопасный режим и защиту:

Снимаем флаг с “Безопасный режим”.

Снимаем флаг с “Защита от опасных действий”.

Устанавливаем режим совместимости для расширения.

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

Режим совместимости расширения «Клеверенс» должен быть равен значению режима совместимости основной конфигурации базы данных 1С.

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

3. Публикация Web-сервиса

Для публикации или изменения публикации базы данных необходимо запускать конфигуратор «1С:Предприятие» от имени администратора.

Если файл web.config не создался в каталоге (по умолчанию « C:\inetpub\wwwroot\ » ) и база 1С в браузере не открывается — необходимо выполнить публикацию открыв конфигуратор «1С:Предприятие» от имени администратора или для каталога хранения файлов дать полные права.

Минимальные настройки (отмечены на скриншоте ниже) для публикации Web-сервиса для расширения «Клеверенс». В этом случае сама база 1С не будет опубликована на Web-сервере, будет опубликован только наш Web-сервис.

4. Проверка работы опубликованного Web-сервиса

Для проверки открываем в браузере страницу:

127.0.0.1 — ip-адрес сервера, где установлен Web-сервер.

ut114demo — имя базы 1С в которую установлено расширение «Клеверенс».

Вводим логин пароль пользователя от базы данных 1С и если видим данную xml страницу, значит Web-сервис «ТСД Клеверенс» запущен и работает.

Обратите внимание, что в некоторых браузерах возможна проблема с вводом Логина-Пароля содержащих кириллицу, поэтому для подключения Web-сервиса создайте отдельного пользователя с логином и паролем не содержащего кириллицу. https://www.forum.mista.ru/topic.php? >

5. Настройка подключения к Web-сервису из панели управления Mobile SMARTS

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

Если онлайн режим работы с базой Mobile SMARTS включен, то всё хорошо.

Если не включен, то сначала добавляем вручную коннектор в 1С по инструкции. Затем прописываем события сервера с указанием идентификатора коннектора (пример: OneC_Connector) для событий сервера Mobile SMARTS, по которым он бужет вызывать коннектор к 1С.

Открываем панель управления — Внешние соединения — 1С Предприятие версия 8: OneC_Connector (коннектор был создан мастером настройки при включении онлайн режима работы).

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

Меняем тип подключения с “Менеджер COM-соединений” на “WebConnector”.

В строке сервер, меням значение на строку которую использовали для проверки в браузере http://127.0.0.1/ut114demo/ws/CleverenceWebExtension.1cws

Сохраняем и запускаем коннектор.

Для проверки работы, открываем Клиент Mobile SMARTS для ПК — Просмотр справочников — открываем просмотр Номенклатуры, Склады или Контрагенты.

6. Настройки бизнес-процессов и отборов документов

Настройки по обмену документами производятся в обработке 1С тем же способом как и при обычном онлайн режиме работы через COM соединение, подробнее см. статью — Как работать с обработкой «Клеверенса» в «1С:Предприятие».

Дополнительная информация и решение возможных проблем


Возможные варианты развертывания

Возможные и невозможные варианты развертывания Базы Mobile SMARTS с подключением к Web-сервису «ТСД Клеверенс» относительно Web-сервера и базы 1С.

Web-сервисы (SOAP), HTTP-сервисы, oData (автоматический REST-сервис) Новый курс

Внимание! Теперь курс проводится и в вечернее время с 18:30 до 21:30 в формате погружения.

На курсе Вы получите практические навыки по использованию следующих механизмов платформы «1С:Предприятие 8»:

  • WEB-сервисы (протокол SOAP)
  • Формат JSON
  • Интерфейс oData (автоматически REST-сервис)
  • HTTP-сервисы

ВАЖНО. Курс рассчитан на программистов, которые владеют навыками по работе с механизмом XDTO, или ранее прошли курс Интеграция и обмен данными.

Описание и программа курса:

В стоимость WEB-курса включено:

  • 2 недели курса, 2 вебинара с преподавателем
  • доступ на 2 года к обновляемым видеоматериалам после окончания курса
  • свидетельство 1С-Учебного центра №3 (при условии выполнения практики)

В стоимость очного курса-погружения включено:

  • 2 дня с 10:00 до 17:00 или 4 вечера с 18:30 по 21:30
  • конспект, наушники
  • обеды, кофе-брейки
  • доступ на 2 года к обновляемым видеоматериалам после окончания курса
  • свидетельство 1С-Учебного центра №3

Программа курса

Занятие №1 ( около 1,5 часов видео)

  • Демонстрационная база
    • Обращение по динамической ссылке
    • Реализация сервиса по данным отгрузки
    • Обращение по статической ссылке
    • Реализация сервиса по номенклатуре
  • Установка Apache
  • Простейшая операция (Ready)
  • Публикация базы
  • Обращение к простейшей операции
  • Параметры операций, направление передачи
  • Самостоятельная работа
  • Разбор первой части
  • ERP Монитор
    • Введение
    • Операция «Начать обмен»
    • Операция «Получить результат партнер»
  • JSON
    • Введение
    • Выгрузка/загрузка структур, массивов
    • Работа с датой
    • Выгрузка/загрузка не поддерживаемых типов
    • Сериализация XDTO
    • Потоковая техника
    • Совмещение техник

  • Заключение

Занятие №2 ( около 1,5 часов видео)

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

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

  • Веб-сервис — это любое программное обеспечение, которое делает его доступным через Интернет и использует стандартизованную систему обмена сообщениями XML. XML используется для кодирования всех сообщений в веб-службе. Например, клиент вызывает веб-службу, отправив XML-сообщение, а затем ожидает соответствующего ответа XML. Поскольку все коммуникации находятся в XML, веб-службы не привязаны ни к одной операционной системе, ни к языку программирования — Java может разговаривать с Perl; Приложения Windows могут разговаривать с приложениями Unix.
  • Веб-сервисы являются автономными, модульными, распределенными, динамическими приложениями, которые могут быть описаны, опубликованы, расположены или вызваны по сети для создания продуктов, процессов и цепочек поставок. Эти приложения могут быть локальными, распределенными или основанными на сети. Веб-службы создаются поверх открытых стандартов, таких как TCP / IP, HTTP, Java, HTML и XML.
  • Веб-службы представляют собой системы обмена информацией на основе XML, которые используют Интернет для прямого взаимодействия приложений с приложениями. Эти системы могут включать в себя программы, объекты, сообщения или документы. Веб-сервис представляет собой набор открытых протоколов и стандартов, используемых для обмена данными между приложениями или системами. Программные приложения, написанные на разных языках программирования и работающие на разных платформах, могут использовать веб-службы для обмена данными по компьютерным сетям, таким как Интернет, способом, аналогичным межпроцессорной коммуникации на одном компьютере. Эта совместимость (например, между Java и Python, или приложениями Windows и Linux) связана с использованием открытых стандартов.

Таким образом, полный веб-сервис является, таким образом, любой службой, которая:

  • Доступно через Интернет или частные (интранет) сети
  • Использует стандартизованную систему обмена сообщениями XML
  • Не привязан к какой-либо одной операционной системе или языку программирования
  • Является самоописанием через общую грамматику XML
  • Открывается через простой механизм поиска

Компоненты веб-служб

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

  • SOAP (протокол простого доступа к объектам)
  • UDDI (универсальное описание, обнаружение и интеграция)
  • WSDL (язык описания веб-служб)

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

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

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

  • XML для привязки данных
  • SOAP для передачи сообщения
  • WSDL для описания доступности сервиса.

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

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

Илон Маск рекомендует:  Asp события приложения

Пример

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

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

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

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

Как работают Web сервисы ASP.NET

Введение

Сегодня существует два фундаментально различных способа реализации Web сервисов, основанных на HTTP, в Microsoft® .NET. Первой и наиболее низкоуровневой техникой является написание специального класса IHttpHandler, который вставляется в цепочку .NET HTTP pipeline. Этот подход требует использования System.Web API для обработки входящих HTTP сообщений и System.Xml API для обработки конверта SOAP, находящегося в теле HTTP. При написании специального обработчика также требуется создать вручную документ WSDL, который точно описывает вашу реализацию. Чтобы сделать все это правильно, необходимо глубокое понимание спецификаций XML, XSD, SOAP и WSDL, что является для большинства устрашающим условием.

Более продуктивным способом реализовать Web сервисы является использование WebMethods оболочки Microsoft ASP.NET. С ASP.NET поставляется специальный класс IHttpHandler для .asmx (называемых WebServiceHandler), который обеспечивает набор необходимых вам функциональных возможностей XML, XSD, SOAP и WSDL. И, поскольку WebMethods оболочка защищает вас от сложностей, лежащих в основе XML технологий, вы можете быстро сосредоточиться на существующих проблемах бизнес логики.

Рисунок 1. Соотношение выгод и потерь между гибкостью и продуктивностью

Выбор между техниками реализации приводит к общему сравнению выгод и потерь между гибкостью и продуктивностью, как показано на Рисунке 1. Создание специального IHttpHandler дает вам неограниченную гибкость, но также требует большего времени на написание, тестирование и отладку кода. Оболочка WebMethods облегчает организацию вашего Web сервиса и быстроту разработки, но вы явно ограничены рамками оболочки. Однако в случаях, когда оболочка WebMethods не обеспечивает именно того, что вам надо, есть возможность расширить ее, добавляя собственные дополнительные функциональные возможности.

В общем, пока вы не освоили XML, XSD, SOAP и WSDL и не хотите утруждаться, работая с ними напрямую, лучше продолжайте работать с оболочкой WebMethods. Она поставляет основные сервисы, которые необходимы большинству конечных Web сервисов, а также некоторые интересные возможности расширения, которые позволяют привести оболочку в соответствие вашим конкретным надобностям. Исходя из этого, далее в статье обсуждаются внутренние механизмы работы WebMethods. Если вы новичок в XML Schema и SOAP, перед тем как продолжить прочитайте Understanding XML Schema ( http://msdn.microsoft.com/webservices/building/frameworkandstudio/default.aspx?pull=/library/en-us/dnxml/html/understandxsd.asp ) и Understanding SOAP ( http://msdn.microsoft.com/webservices/building/frameworkandstudio/default.aspx?pull=/library/en-us/dnsoap/html/understandsoap.asp ).
Оболочка WebMethods

Оболочка WebMethods занимается преобразованиями SOAP сообщений в методы класса .NET. Это делается, прежде всего, путем аннотирования ваших методов атрибутом [WebMethod], находящемся в пространстве имен System.Web.Services. Например, следующий класс .NET содержит четыре метода, два из которых аннотированы атрибутом [WebMethod]:

Чтобы использовать этот класс с оболочкой WebMethods, вам надо компилировать его в сборку и скопировать в виртуальную директорию директории bin. В этом примере методы Add и Subtract затем могут быть раскрыты как операции Web сервиса, в то время как с методами Multiply и Divide этого сделать нельзя (т.к. они не были отмечены атрибутом [WebMethod]).

Вы раскрываете Add и Subtract как операции Web сервиса через .asmx файл. Чтобы сделать это, создайте новый текстовый файл Math.asmx, содержащий следующее простое описание, и поместите его в ту же виртуальную директорию, которая содержит и сборку (обратите внимание: файл помещается в саму виртуальную директорию, а не в ее дочернюю директорию bin):

Это описание указывает обработчику .asmx, какой класс использовать для WebMethods, а обработчик чудесным образом заботится обо всем остальном. Например, предположим, виртуальная директория называется ‘math’ и содержит Math.asmx наряду с тем, что дочерняя директория bin содержит сборку, вызов http://localhost/math/math.asmx приводит к тому, что обработчик .asmx генерирует страницу документации, показанную на Рисунке 2 (см. далее).

Это один из основных вариантов работы обработчика .asmx. Файл .asmx обычно содержит только описание WebService, которое ссылается на класс Web сервиса по имени (как в примере, показанном ниже). Следовательно, в этом случае, сборка должна уже быть скомпилирована и размещена в директории bin виртуальной директории. Обработчик .asmx также обеспечивает JIT компиляцию исходного кода, находящегося в файле .asmx. Например, следующий файл (названный Mathjit.asmx) содержит описание WebService вместе с исходным кодом класса, на который ссылается.

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

Рисунок 2. Документация MathService

При создании нового проекта Web сервиса в Visual Studio® .NET вы всегда используете технику “двух файлов”, когда исходный файл класса отделен от файла .asmx, который на него ссылается. Интегрированная среда разработки (IDE) хорошо скрывает это от вас, но если вы нажмете Show All Files на панели инструментов Solution Explorer, вы увидите в проекте по два файла для каждого класса Web сервиса. Кстати, Visual Studio .NET не поддерживает для файлов .asmx синтаксическое выделение или IntelliSense®, поэтому вы сами решаете, следовать ли в этом направлении. В Web проектах Visual Studio .NET также заботится о создании виртуальной директории и автоматическом компилировании сборки в директорию bin виртуальной директории.

Перед погружением в детали работы обработчика .asmx давайте коротко обсудим, как обрабатываются сообщения от Internet Information Server (IIS), прежде всего, в обработчике .asmx. Когда входящее HTTP сообщение достигает порта 80, для того, чтобы определить, какая ISAPI DLL должна использоваться для его обработки, IIS использует информацию метабазы IIS. Инсталляция .NET связывает расширения .asmx с Aspnet_isapi.dll, как показано на Рисунке 3.

Рисунок 3. Связываение IIS и .asmx

Aspnet_isapi.dll – это стандартное расширение ISAPI, поставляемое .NET Framework, которое просто направляет HTTP запросы в отдельный рабочий процесс, называемый Aspnet_wp.exe. Aspnet_wp.exe выполняет роль хоста для общеязыковой среды выполнения и .NET HTTP pipeline. Как только сообщение входит в .NET HTTP pipeline, pipeline просматривает в файле конфигурации, какой класс IHttpHandler надо использовать для данного расширения. Если вы посмотрите свой файл Machine.config, то увидите, что он содержит httpHandler, связанный с расширением .asmx, как показано здесь:

Итак, когда сообщение поступает в .NET HTTP pipeline, нацеливаясь на файл .asmx, pipeline заходит в класс WebServiceHandlerFactory, чтобы создать новый объект WebServiceHandler, который может использоваться для обработки запроса (с помощью метода IHttpHandlerProcessRequest). Затем объект WebServiceHandler открывает физический файл .asmx, чтобы определить имя класса, содержащего ваш WebMethods. Более подробная информация о работе .NET HTTP pipeline представлена в HTTP Pipelines: Securely Implement Request Processing, Filtering, and Content Redirection with HTTP Pipelines in ASP.NET (http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/02/09/HTTPPipelines/default.aspx).

Сразу после того, как .NET HTTP pipeline вызывает обработчик .asmx, чудесным образом начинается обработка XML, XSD, SOAP и WSDL. Остальные функциональные возможности, предоставляемые обработчиком .asmx, могут быть разделены на три основные группы: 1) координирование сообщений, 2) преобразование XML в объекты и 3) автоматическое генерирование WSDL и документации. Давайте каждую из этих групп рассмотрим более детально.
Диспечеризация сообщений

Когда HTTP pipeline вызывает обработчик .asmx, просматривая описание WebService в файле .asmx, он определяет, какой класс .NET использовать. Затем он просматривает поступившее HTTP сообщение, чтобы определить, какой именно метод вызывать в данном классе. Чтобы вызвать операцию Add, показанную в предыдущих примерах, входящее HTTP сообщение должно выглядеть примерно так:

На самом деле во входящем HTTP сообщении есть два участка, которые могут использоваться для определения метода, который должен быть вызван в классе: заголовок SOAPAction или имя запрашиваемого элемента (т.е. имя элемента в пределах элемента soap:Body). В этом случае хотя бы один из них определяет имя метода, который хочет вызвать отправитель.

Для диспечеризации сообщения обработчик .asmx по умолчанию использует заголовок SOAPAction. Значит, обработчик .asmx смотрит на заголовок SOAPAction в сообщении, а затем, используя .NET рефлексию, проверяет методы класса. Он рассматривает только методы, помеченные атрибутом [WebMethod], но, просматривая значение SOAPAction каждого метода, он точно определяет, какой метод вызывать. Поскольку мы явно не определили значение SOAPAction в методах нашего класса, обработчик .asmx принимает, что значением SOAPAction будет сочетание пространства имен Web сервиса и имени метода. Поскольку мы также не определили и пространство имен, обработчик по умолчанию присваивает http://tempuri.org. Таким образом, значение по умолчанию SOAPAction для метода Add будет http://tempuri.org/Add.

Вы можете изменить пространство имен Web сервиса, помечая класс атрибутом [WebService], так же как и точное значение SOAPAction, помечая WebMethods атрибутом [SoapDocumentMethod], как показано далее:

Теперь обработчик .asmx ожидает, что значение SOAPAction для метода Add будет http://example.org/math/Add и urn:math:subtract для метода Subtract (поскольку мы явно задали это значение). Например, следующее сообщение HTTP запроса вызывает операцию Subtract:

Если обработчик .asmx не находит SOAPAction, подходящего для входящего HTTP сообщения, он просто формирует исключительную ситуацию (позже рассмотрим, как обрабатываются исключительные ситуации). Если для диспечерезации метода вы не используете заголовок SOAPAction, помечая класс свойством RoutingStyle атрибута [SoapDocumentService], вы можете указать обработчику .asmx использовать имя элемента запроса. Если вы делаете это, то также надо указать, что WebMethods не нуждаются в значении SOAPAction, путем установления их значений в пустую строку, как показано ниже:

В этом случае обработчик даже не рассматривает значение SOAPAction – он использует вместо него имя элемента запроса. Например, ожидается ,что имя элемента запроса для метода Add будет Add (из пространства имен http://example.org/math), как показано в этом сообщении HTTP запроса:

Значит, первое, что делает обработчик .asmx при получении входящего HTTP сообщения, – он определяет, как перенаправить сообщение в соответствующий WebMethod. Однако до того как он действительно сможет вызвать метод, он должен преобразовать входящий XML в .NET объекты.
Преобразование XML в объекты

Как только обработчик WebMehod определил, какой метод надо вызвать, он должен десериализовать XML сообщение в .NET объекты, которые могут быть предоставлены во время вызова метода. Так же как и при диспечеризации сообщения, обработчик проверяет класс с помощью рефлексии, чтобы выяснить, как обрабатывать входящее XML сообщение. Класс XmlSerializer осуществляет автоматическое преобразование между XML и объектами в пространстве имен System.Xml.Serialization.

XmlSerializer делает возможным преобразование любого public типа .NET в тип XML Schema и, вместе с тем, может проводить автоматические преобразования между .NET объектами и документами XML (см. Рисунок 4). XmlSerializer ограничен теми возможностями, которые сегодня поддерживает XML Schema, поэтому он не может работать со всеми сложностями сегодняшних объектных моделей, такими как комплексные не древовидные диаграммы объектов, дублирующие указатели и т.д. Несмотря на это, XmlSerializer может работать с большинством комплексных типов, используемых разработчиками.

Для приведенного выше примера Add XmlSerializer преобразует элементы x и y в .NET double значение, которые затем смогут предоставляться при вызове Add. Метод Add возвращает вызывающему значение типа double, которое затем должно быть опять сериализовано в XML элемент в рамках SOAP ответа.

Рисунок 4. Преобразование XML в объекты

Также XmlSerializer может автоматически работать с комплексными типами (за исключением описанных выше ограничений). Например, следующий WebMethod вычисляет расстояние между двумя структурами Point:

SOAP сообщение запроса для этой операции будет содержать элемент Distance, который включает два дочерних элемента, orig и dest, и каждый из этих элементов должен содержать дочерние x и y элементы:

В этом случае SOAP сообщение ответа будет содержать элемент DistanceResponse, включающий элемент DistanceResult типа double:

Применяемое по умолчанию XML преобразование использует имя метода в качестве имени элемента запроса и имена параметров в качестве имен дочерних элементов. Структура каждого параметра зависит от структуры типа. Имена public полей и свойств просто преобразовываются в дочерние элементы, как в случае x и y (в Point). Именем элемента ответа по умолчанию становится имя элемента запроса, оканчивающееся словом «Response». Элемент ответа также содержит дочерние элементы, названные так же как и элементы запроса, только оканчивающиеся словом «Result».

Есть возможность освободиться от стандартного XML преобразования путем использования большого количества встроенных атрибутов преобразования. Например, для преобразования имени типа и пространства имен можно использовать атрибут [XmlType]. Чтобы контролировать то, как параметры или члены класса преобразовывают элементы или атрибуты, вы можете пользоваться атрибутами [XmlElement] и [XmlAttribute], соответственно. А для контроля за тем, как сам метод преобразовывается в имена элементов в сообщениях запроса/ответа, можно воспользоваться атрибутом [SoapDocumentMethod]. Например, ознакомьтесь со следующей версией Distance, в которой используются различные атрибуты:

В этой версии Distance ожидается, что входящее SOAP сообщение будет выглядеть следующим образом:

И будет сгенерировано такое SOAP сообщение ответа:

Для реализации и определения приведенного выше преобразования, применяемого по умолчанию, обработчик .asmx использует документ/литерал стиль SOAP. Это означает, что описание WSDL будет содержать буквенные определения XML schema, описывающие и элементы запроса, и элементы ответа, используемые в SOAP сообщениях (т.е. правила SOAP кодирования не используются).

Обработчик .asmx также делает возможным использование rpc/литерал стиля SOAP. Это означает, что SOAP Body содержит XML представление вызова RPC и параметры сериализовываются с использованием правил SOAP кодирования (т.е. XML Schema не нужна). Соответственно, вместо атрибутов [SoapDocumentService] и [SoapDocumentMethod] вы используете [SoapRpcService] и [SoapRpcMethod]. Более подробно о различиях в этих стилях см. в разделе MSDN Understanding SOAP (http://msdn.microsoft.com/webservices/building/frameworkandstudio/default.aspx?pull=/library/en-us/dnsoap/html/understandsoap.asp).

Как видите, есть возможность полностью изменить процесс преобразования данного метода в SOAP сообщение. XmlSerializer обеспечивает мощный механизм сериализации со многими возможностями, о которых у нас нет времени здесь говорить. Более подробно о том, как работает XmlSerializer, см. в разделе MSDN Moving to .NET and Web Services (http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/01/11/webserv/). Я также рассмотрел многие нюансы XmlSerializer, не раскрытые в моей ежемесячной колонке MSDN Magazine, XML Files (http://msdn.microsoft.com/msdnmag/find/default.aspx?type=Ti&phrase=XML%20Files) (смотрите список колонок в online архивах).

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

Если, все-таки, вы хотите использовать информацию заголовка из WebMethod, вы должны предоставить класс .NET, наследуемый от SoapHeader, который представляет XML Schema заголовков (следуя рекомендациям преобразования, приведенным выше). Затем вы определяете переменную члена этого типа, выполняющую роль «заполнителя» для экземпляров заголовка. И наконец, вы помечаете каждый WebMethod, нуждающийся в доступе к заголовку, определяя имя того поля, куда вы хотите его направить.

Например, SOAP запрос, содержащий заголовок UsernameToken с целью аутентификации:

Чтобы сделать возможной для обработчика .asmx десериализацию заголовка, сначала надо определить класс .NET, представляющий предполагаемый тип XML Schema (обратите внимание: если у вас на самом деле есть XML Schema для заголовка, вы можете генерировать класс, используя xsd.exe /c). В этом случае соответствующий класс выглядит следующим образом:

Затем просто надо определить переменную члена в вашем классе WebMethod, чтобы хранить экземпляр класса заголовка , и аннотировать WebMethods атрибутом [SoapHeader], как показано ниже:

Затем в WebMethod вы можете обратиться к полю Token и извлечь информацию, которая была предоставлена заголовком. Вы также можете отправить заголовки обратно клиенту, используя ту же технику – вам просто надо определить направление заголовка в описании атрибута [SoapHeader]. Более подробную информацию об обработке SOAP заголовков в оболочке WebMethods см. в разделе MSDN Digging into SOAP Headers with the .NET Framework. (http://msdn.microsoft.com/webservices/building/frameworkandstudio/default.aspx?pull=/library/en-us/dnservice/html/service06182002.asp)

Обработчик .asmx также обеспечивает автоматическую сериализацию исключительных ситуаций .NET. Любая необработанная исключительная ситуация,перехваченная обработчиком .asmx, автоматически сериализуется в элемент SOAP Fault в ответе. Например, в предыдущем примере, если имя пользователя не совпадает с паролем, наш код формирует исключительную ситуацию .NET. Тогда обработчик .asmx обработает ее и сериализует в SOAP ответ, как показано ниже:

Если вы хотите еще больше контролировать элемент SOAP Fault, вы можете также явно сформировать объект SoapException, определяя все детали элемента SOAP Fault, такие как элементы faultcode, faulstring, faultactor и detail. Более подробная информации представлена в разделе MSDN Using SOAP Faults (http://msdn.microsoft.com/webservices/building/frameworkandstudio/default.aspx?pull=/library/en-us/dnservice/html/service09172002.asp).

Как видите, чтобы понять, как работает WebMethods, необходимо еще разобраться с механизмом, лежащим в основе сериализации, и всем многообразием его возможностей. Преимуществом механизма сериализации является то, что он скрывает весь лежащий в основе XML API код, который обычно вам приходится писать в специальном обработчике. Однако, в то время как большинство разработчиков считают это положительным моментом, некоторые называют это недостатком, потому что все еще хотят самостоятельно работать с SOAP сообщением в пределах реализации WebMethod. Более детально о том, как использовать такой смешанный подход, см. в разделе MSDN Accessing Raw SOAP Messages in ASP.NET Web Services (http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/03/03/WebServices/default.aspx).
Автоматическое генерирование WSDL

Клиентам надо точно знать, как должно выглядеть SOAP сообщение, чтобы успешно работать с ним. Общепринятым является предоставлять описания Web сервиса через WSDL (и встроенные XSD определения). Для этого обработчик .asmx автоматически генерирует и страницу документации, и описание WSDL, которое точно отражает интерфейс WebMethod. Если вы применили группу атрибутов преобразования к вашим WebMethods, все они будут отражены в сгенерированной документации.

Если вы посмотрите файл .asmx, то найдете страницу документации, такую как показано на Рисунке 2. Эта страница документации генерируется страницей .aspx, называемой DefaultWsdlHelpGenerator.aspx (находящейся в C:windowsMicrosoft.NETFramework v1.0.3705config). Если откроете файл, вы увидите, что это всего лишь стандартная страница ASP.NET, которая использует .NET рефлексию для генерирования документации. Эта возможность позволяет документации всегда соответствовать коду. Просто модифицируя этот файл, вы можете изменять генерируемую документацию.

Также можно блокировать генерирование документации на основе виртуальной директории, определяя другой файл документации в файле Web.config:

Если клиент завершает запрос GET для .asmx символами «?wsdl» в строке запроса, обработчик .asmx вместо документации генерирует описание WSDL. Клиенты могут использовать описание WSDL для генерирования proxy классов, которые автоматически знают, как общаться с Web сервисом (т.е. используя Wsdl.exe в .NET).

Чтобы изменить процесс генерирования WSDL, вы можете написать класс SoapExtensionReflector и зарегистрировать его с оболочкой WebMethods в файле Web.config. Затем, когда обработчик .asmx будет генерировать описание WSDL, он вызовет ваш класс и даст вам возможность изменить окончательное описание, поставляемое клиенту. Более подробно о том, как писать классы SoapExtensionReflector, см. в разделе MSDN SoapExtensionReflectors in ASP.NET Web Services (http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20030320WebServicesMP/manifest.xml).

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

Немного более автоматизированной техникой является использование атрибута [WebServicesBinding] для определения местоположения статического документа WSDL в виртуальной директории, которую реализовывает класс WebMethod. Вы также должны определить имя WSDL binding, которое реализовывает каждый WebMethod, используя атрибут [SoapDocumentMethod]. Процесс автоматического генерирования WSDL импортирует ваш статический WSDL файл и «завернет» его в новое описание сервиса. Более подробная информация по этой технике представлена в статье MSDN Place XML Message Design Ahead of Schema Planning to Improve Web Service Interoperability (http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/02/12/WebServicesDesign/).

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

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL