Web-сервисы

Размещено на http://www.allbest.ru/

Web services

Введение

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

Концепция веб-сервисов родилась после нескольких не вполне удачных попыток многих групп аналитиков, архитекторов и разработчиков по всему миру создать среду и механизм взаимодействия того многообразия информационных систем, которые они же, эти группы аналитиков, архитекторов и разработчиков, и создали. Столь большое количество неглупых в общем-то людей редко тратят столько энергии, интеллекта и времени просто так - обычно, это означает, что предполагаемый результат их усилий очень востребован. Например, как ни странно, бизнесом. Современное коммерческое предприятие трудно представить без информационных систем различного назначения: бухгалтерских, финансово-аналитических, производственных, складских и т. д. Большое предприятие использует большие многофункциональные информационные системы (можно вспомнить аббревиатуры ERP, CRM, SCM и т. п.), часто несколько одновременно. А есть еще поставщики, клиенты, партнеры, у которых свои, не менее сложные и специфичные, информационные системы, и с ними информационным системам предприятия необходимо взаимодействовать. Как организовать это взаимодействие? Как ЭФФЕКТИВНО организовать это взаимодействие, чтобы создать производительные, надежные и безопасные автоматизированные (экстра)корпоративные (т. е. простирающиеся за пределы предприятия) цепочки именно тех бизнес-процессов, интеграция которых необходима предприятию для осуществления своих бизнес-функций? Именно в области интеграции (экстра)корпоративных приложений (англ. Enterprise Application Integration, EAI) лежит основная масса IT-проблем современных предприятий, именно на решение вопросов взаимодействия разнородных информационных систем готовы бросить свои основные ресурсы CEO и CIO, и именно здесь наиболее эффективным инструментом решения будут веб-сервисы.

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

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

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

1. Определение сервиса

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

Назовем сервисом (service) ресурс, реализующий бизнес-функцию, обладающий следующими свойствами:

· является повторно используемым;

· определяется одним или несколькими явными технологически-независимыми интерфейсами;

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

2. Определение сервисно-ориентированной архитектуры

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

Компонентная модель, состоящая из отдельных функциональных модулей приложений, называемых сервисами, имеющих определенные согласно некоторым общим правилам интерфейсы и механизм взаимодействия между собой, называется сервисно-ориентированной архитектурой (Service-Oriented Architecture, SOA).

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

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

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

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

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

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

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

3. Требования к SOA

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

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

· обеспечивать реализацию различных типов интеграции: - пользовательская интеграция (user integration) - обеспечение взаимодействия информационной системы с конкретным персонифицированным пользователем; - интеграция приложений (application connectivity) - обеспечение взаимодействия приложений; - интеграция процессов (process integration) - интеграция бизнес-процессов; - информационная интеграция (information integration) - интеграция с целью обеспечения доступности информации и данных; - интеграция новых приложений (build to integrate) - интеграция новых приложений и сервисов в существующие информационные системы.

· обеспечивать поэтапность внедрения вновь созданных и миграции существующих информационных систем;

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

· позволять реализацию различных моделей построения информационных систем, в особенности таких как портальные решения, grid-системы и on-demand-системы.

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

4. Какова роль Web-сервисов

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

· описать их в виде сервиса и обеспечить к ним доступ пользователей извне;

· найти такой сервис сторонам, заинтересованным в его использовании;

· воспользоваться данным сервисом после его обнаружения;

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

Таким образом Web services обеспечивают построенную на открытых стандартах информационную инфраструктуру, посредством которой организации могут:

· интегрировать внутренние бизнес-процессы друг с другом;

· динамически связывать и синхронизировать собственные бизнес-процессы с бизнес-процессами своих деловых партнеров;

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

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

5. На чём базируются Web-сервисы

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

· Создатель конкретного веб-сервиса определяет формат запросов к нему и формат ответов на данные запросы;

· С любого комьютера в Интернет можно сделать запрос к данному веб-сервису;

· Веб-сервис выполняет заданную последовательность действий и отправляет обратно результат.

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

· SOAP (Simple Object Access Protocol) - протокол доступа к простым объектам, т.е. механизм для передачи информации между уделенными объектами на базе протокола HTTP и некоторых других Интернет-протоколов. Более подробную информацию о данном стандарте можно найти на странице "Ссылки";

· WSDL (Web Services Description Language) - язык описания Web-сервисов. Подробная спецификация находится в разделе "Документы" ;

· UDDI (Universal Description, Discovery and Integration) - универсальное описание, обнаружение и интеграция - упрощенно говоря, протокол поиска ресурсов в Интернете.

Серверы приложений являются хранилищами 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). Запрос вызывает метод удаленного объекта, ответ возвращает результат выполнения данного метода. Ниже приведены примеры запроса и ответа в формате 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).

Как мы видим, описание сервисов представляет собой 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-сервисы, после чего данные будут автоматически реплицированы в другие реестр.

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-сервисом. Он поддерживает операции создания, модификации, удаления и поиска элементов всех четырех рассмотренных выше типов.

6. Web Services -- это так легко. Только поменяй компьютер

Надо признать, что эти стати реально показывают простоту реализации двух вариантов приложений типа Web Services. С помощью механизмов WebClass и DHTML в том же Visual Basic 6.0 подобные задачи решались дольше и сложнее. Но нужно подчеркнуть, что это не связано с применением новых протоколов -- просто новые версии мастеров и конструкторов VS.NET лучше и качественнее автоматизируют работы программиста.

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

В среде Visual Studio.NET выберите вариант создания нового приложения типа Web Services с именем RateService. В автоматически созданном классе Service1 введите код функции.

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

Все вроде бы просто и быстро. Но для использования новых технологий средств VS.NET при решении подобной тривиально задачи мне пришлось обновить системный блок, установив в нем Pentium 800/133 и RAM 256 Мбайт.

Заключение

Если вы все-таки решились на резкий "прыжок" в мир Web-сервисов, то делайте это с большой осторожностью, уделяя пристальное внимание безопасности и стандартам. Выгоды от внедрения Web-сервисов, как краткосрочные, так и долгосрочные, являются вполне осязаемыми, так что в конце концов вы будете вынуждены мигрировать на них, хотите вы этого или нет. Большинство производителей ПО, особенно специализирующихся на рынке корпоративных приложений, взяли курс на внедрение Web-сервисов и рано или поздно перестанут предоставлять вашим разработчикам интерфейсы взаимодействия с бизнес-приложениями, отличные от Web-сервисов. Действительно, многие производители ПО быстро движутся в направлении Web-сервисов, ухватившись за преимущества сервисно-ориентированной архитектуры, которая снижает стоимость технической поддержки их продуктов как с точки зрения интерфейсов API, так и с точки зрения клиентов. Однако не стоит недооценивать возможные опасности, встречающиеся на этом пути: убедитесь в том, что ваша инфраструктура способна поддерживать необходимые Web-сервисам полосу пропускания и уровень безопасности. Начните с какого-нибудь не являющегося критически важным для бизнеса приложения и разработайте для него Web-сервис, предельно "вычистив" все ошибки, и только после этого двигайтесь дальше. Удачи!

Список использованной литературы

1. Цикл статей сайта "Технологии веб-сервисов" Статья вторая, Сентябрь 2004, © 2004 UBS Игорь Долотин, (igor.dolotin@ubs.ru)

2. Андрей Колесов. BYTE/Россия, № 2 (февраль) 2002 г.

3. LAN/журнал сетевых решений, сентябрь 2003 г.

4. Журнал "Компьютер Пресс ", № 6, июнь 2001 г.

Размещено на Allbest.ru