Web-службы - это технология предоставления совместно используемых функций, не зависящих от устройств, сетей, операционных систем и языков программирования.
Сегодня доступ к Интернету можно получить с помощью различных устройств, обеспечивающих большое разнообразие функциональных средств. В большинстве случаев обмен информацией в Интернете осуществляется посредством запросов и ответов с использованием открытых протоколов, в частности HTTP. Обычно большая часть такой информации представлена на языке HTML, специальные теги которого позволяют организовать пользовательский интерфейс в отображаемых браузером web-страницах.
С недавних пор настольные и web-приложения стали похожи друг на друга. Интерфейсы настольных приложений, например таких, как в системе Windows ХР, теперь напоминают интерфейсы интернет-браузеров. В обычных настольных приложениях применяются функции Интернета, а Windows-приложения способны взаимодействовать с web-серверами посредством протокола HTTP. В частности, программа Microsoft Money автоматически загружает банковскую информацию; операционная система Windows уведомляет вас о появляющихся обновлениях; Visual Studio .NET позволяет проводить поиск в библиотеке MSDN, не покидая среду разработки.
Web-приложения нельзя назвать совершенными, поскольку для интеграции функциональных возможностей различных web-узлов используются достаточно "неуклюжие" методы, такие как метод поиска связей, кадров и экранов. Недостаток приложений подобного типа состоит в их "монолитности" (связанности): они существуют как пакеты "все в одном", и очень непросто отделить пользовательский интерфейс от его функциональности, обеспечить, скажем, отслеживание курсов акций или их пакетов без того, чтобы принуждать пользователя "бегать" по всему web-узлу.
С появлением web-служб и технологии .NET ситуация изменилась. Протоколы web-служб определяют структуру для предоставления функций через Интернет. Они основаны на открытых стандартах, являются взаимосвязанными, расширяемыми и используются для нынешнего поколения web-ориентированных приложений. Система .NET Framework представляет собой высокооптимизированную платформу и имеет набор инструментов для развертывания web-служб.
Web-служба (Web Service) - это приложение или блок находящегося на web-сервере выполняемого кода, функционирование которого основано на применении стандартных форматов XML. Поиск этого кода, его извлечение и получение посредством него требуемого результата выполняется в среде .NET Framework. Вызывается web-служба .NET так же просто, как и
Web-служба .NET - это не объект (во всяком случае, не в его традиционном представлении). Web-метод является, по сути, независимым, "атомарным" и не имеющим постоянного местонахождения. Web-служба больше подобна библиотеке функций в DLL и ее сложно ограничить рамками объектно-ориентированной абстракции. Это упрощение в значительной мере и обеспечивает преимущества web-служб. Поскольку web-службы не ограничены конкретной технологией (безопасности, управления или транспортировки), они могут быть использованы почти в любом разрабатываемом сценарии, что существенным образом отличает их от предыдущих технологий, таких как СОМ и CORBA.
Web-службы предоставляют способ совместного использования программных функций. Их даже можно назвать "СОМ для Web", хотя в основе работы этих систем лежит совсем другая технология.
Web-служба не является продуктом для конечного пользователя. Она представляет собой основанное на компонентах приложение, позволяя многократно использовать свою функциональность в различных средах и на клиентах разных типов. Пользователем web-службы всегда является другое приложение.
Web-службы могут использоваться для решения следующих задач:
На сегодняшний день это наиболее широко распространенные задачи, решаемые с применением web-служб. Web-службы позволяют совместно использовать информацию либо могут интегрироваться с другими службами. Например, компания, занимающаяся электронной коммерцией, может обращаться к web-службе для осуществления автоматического взаимодействия с поставщиками. В подобных случаях в качестве пользователя web-службы, скорее всего, будет выступать программное обеспечение, установленное в такой компании.
Допустим, независимый разработчик спроектировал web-службу аутентификации, предназначенную для применения в среде ASP .NET. Если вы пожелаете воспользоваться этой службой, то за соответствующую плату можете приобрести месячную подписку на нее. Однако данный процесс будет совершенно прозрачным для конечного пользователя, который решит, что указанные средства аутентификации являются частью вашего приложения. Такие готовые компоненты можно использовать в web-приложениях, а также в настольных и мобильных программах.
Компания Microsoft выдвинула инициативу создания технологии встройки, которая позволила системным администраторам осуществлять дистанционное администрирование с применением web-служб. Банк, который имеет намерение открыть вам инвестиционный счет, заинтересован в наличии web-службы для загрузки информации о транзакциях, которую можно было бы использовать без необходимости тратиться на финансовую программу наподобие Quicken. Пока конечные пользователи не получат напрямую требуемую услугу, ее доступность в Quicken может вынудить их открыть счет в другом банке, который предоставляет данную программу.
DLL для многократного использования кодаСамый простой способ многократного использования определенных функциональных возможностей в приложениях ASP .NET заключается не в создании сборки .NET, а в проектировании web-службы, к которой могли бы обращаться различные клиенты, в том числе настольные приложения,
Web-службы можно использовать, в частности, для соединения специализированной программы по работе с
Концепция, лежащая в основе функционирования web-служб, не нова. Существует множество и других сред программирования, которые базируются на принципе разделения приложений и функций между компьютерами по сети, позволяющем сделать работу их пользователей более эффективной и гибкой. Однако до сих пор ни одна из таких сред не приобрела широкой популярности, поскольку с их применением связаны две проблемы:
История программирования в значительной степени представляет собой процесс перехода от небольших изолированных сред (таких как мэйнфреймы и автономные приложения) к более широкомасштабным и многокомпонентным системам, начиная от сетевого и клиент-серверного программного обеспечения и заканчивая Интернет -приложениями и распределенными приложениями.
В начале 90-х годов прошлого века интерес разработчиков привлекали две соперничающие
Однако по мере того как распределенные сети приобретали все более широкую популярность, возникла необходимость в обеспечении возможности взаимодействия отдельных компьютеров. Разработчики могли создавать собственные решения, воспользовавшись сокетами, хотя это требовало от клиентов и серверов выполнения достаточно тяжелой работы, а для кодирования и декодирования сообщений нужны были высокоуровневые протоколы. Но не только в этом состояло неудобство для разработчиков: их программы получались громоздкими и могли содержать множество ошибок.
В середине 90-х годов компания Microsoft выпустила расширенную компонентную модель - DCOM ( Distributed СОМ ). Эта модель не являлась альтернативой или дополнением модели СОМ - в действительности она была лишь сетевым протоколом, определяющим способ взаимодействия СОМ -объектов различных компьютеров. Компания
Эти стандарты позволили приложению, запущенному на одном компьютере, использовать код, расположенный на другом компьютере. Но поскольку оба указанных стандарта являлись потомками стандартов разработки настольных приложений, они имели несколько уровней сложности, затрудняющих их применение (в частности, модель DCOM за это часто критиковали). Опытные разработчики считают, что эти протоколы сыграли положительную роль, обеспечив возможность создавать приложения, которые могут выполняться распределено на нескольких рабочих станциях, тем самым позволив подняться от разработки клиент-серверного программного обеспечения до так называемых 3-уровневых и n-уровневых приложений.
К сожалению, ни COM/DCOM, ни CORBA/ не функционировали должным образом в рамках Интернета. В частности, потому, что оба этих стандарта являются взаимно исключающими. Серверы DCOM могут взаимодействовать только с клиентами DCOM, стандарты CORBA и DCOM ограничена компьютерами, оснащенными операционной системой Microsoft Windows. Модель CORBA, подобно СОМ, является сложным стандартом, не предназначенным для работы через брандмауэры. Таким образом, помимо необходимости адаптировать модели СОМ и CORBA для использования в сетевой среде, требовалось создать простые программные средства разработки распределенных приложений в сети Web.
DCOM - это сетевой протокол, основанный на стандарте распределенной среды обработки СОМ - объекты на удаленном компьютере точно так же, как и на локальном (рис. 12.1). DCOM просто переносит локальную межпроцессную связь с помощью сетевого протокола. Вызов становится несколько более медленным, но ни клиенту, ни компоненту нет необходимости знать, что связь между ними осуществляется по сети. На рис. 12.1 показан многоуровневый протокол, позволяющий модели СОМ работать через сеть.
(рис 12.1) Архитектура COM/DCOM
К сожалению, модель COM/DCOM не подходит для работы в распределенных сетях.
Применить DCОМ в сети приводит к большим издержкам из-за возникновения помех и большого количества отложенных сообщений. Очевидно, что применять DCОМ в сети Интернет тем более не имеет смысла, поскольку по мере роста числа клиентов в сети объем сетевого трафика увеличивается и необходимость обрабатывать большое количество запросов наносит серьезный вред всей системе. Таким образом, разработчики пришли к выводу, что протокол DCOM является принципиально не масштабируемым для обслуживания большого числа клиентов. Кроме того, указанные ограничения делают невозможным использование DCOM -компонента в случае ненадежной или периодически устанавливаемой связи.
Модель CORBA является общим стандартом для создания СОМ на платформе Microsoft, - они обеспечивают взаимодействие объектов. С появлением CORBA большинство разработчиков рассчитывали на то, что распределенная среда компьютерной обработки CORBA, показаны на рис. 12.2.
По многим параметрам CORBA кажется идеальным средством для работы с распределенными объектами. Об этом свидетельствует, в частности, тот факт, что данная технология поддерживается внушительной группой разработчиков, включающей более 500 компаний-партнеров. Но все они и несут ответственность за снижение интереса к модели CORBA. Имеется множество реализаций CORBA, и все они обладают своими особенностями. Не существует коммерческих брокеров
(рис 12.2) Архитектура CORBA/IIОР
Протокол CORBA быстро теряет репутацию, становясь все более сложным и неудобным для программирования. Частично в ответ на это компания Sun создала свой собственный механизм Java, поскольку прекрасно интегрируется с ним. Однако подобное интегрирование также является и недостатком. Работа Java, ни одна из которых не поддерживается популярными языками наподобие C++. Фактически CORBA.
Несмотря на имеющиеся различия, технологии COM/DCOM и CORBA/ обладают рядом общих ограничений:
Данная особенность затрудняет использование указанных стандартов при наличии в сети брандмауэров, которые ограничивают доступ нетекстовых данных через большинство портов. Даже если брандмауэр сконфигурирован так, что подобные данные могут поступать через порт, изменение каких-либо настроек (что обычно и случается) приведет к разрыву объектной коммуникации.
С помощью СОМ и CORBA можно спроектировать компоненты, способные взаимодействовать с сотнями клиентов так же легко, как и с десятками. Однако это требует от программистов огромного опыта и дисциплины. Типичный компонент того не стоит.
Протокол СОМ тесно связан с платформой Windows. Не существует простого способа создать и разместить СОМ -компонент в другой операционной системе, такой как UNIX. Модель CORBA подобным недостатком не обладает, но ее сложно использовать в языках, отличных от Java. В конечном счете, оба этих стандарта оказываются "закрытыми", что ограничивает сферу и способы их использования.
Стандарты СОМ и CORBA включают множество встроенных средств, таких как транзакции, инструменты безопасности и шифрования, что повышает вероятность возникновения проблем, связанных, в частности, с несовместимостью и дополнительными затратами. В настоящее время протоколы web-служб не предоставляют и не специфицируют инструменты API для указанных высокоуровневых служб. Этот факт значительно упрощает их реализацию, но означает, что в случае необходимости вам придется самостоятельно разрабатывать такие средства.
Рассматривая историю развития совместного использования программного кода в сетях, мы оставили без внимания такой важный вопрос разработки, как эволюция универсального стандарта для кодирования информации. Это объясняется тем, что в то время, когда создавались технологии СОМ и CORBA, стандарта для совместного использования структурированных данных не существовало. И лишь позднее появились такие стандарты, как SGML, XML и SOAP, предназначенные непосредственно для представления типов данных.
Несмотря на все выше сказанное технологии СОМ и CORBA по-прежнему широко используются. Конечно, у них есть свои недостатки, но они отнюдь не потеряли еще своей работоспособности. В некоторых отношениях они не способны конкурировать с web-службами, но могут стать идеальным инструментом для реализации распределенных компонентов в гетерогенной сетевой среде.
Web-службы были разработаны с целью преодоления ограничений описанных выше технологий. С помощью .NET компания Microsoft надеется построить более совершенную структуру программирования для создания и предоставления web-услуг.
Web-службы .NET отличаются от существующих технологий создания распределенных приложений следующими характеристиками.
В web-службах отсутствуют какие-либо скрытые или недоступные элементы. Каждый аспект технологии, от способа поиска web-службы до ее описания и организации связи с ней, определен общедоступными стандартами. Доступность информации способствует дальнейшему расширению и развитию данной технологии.
Язык программирования, который позволяет создавать XML-документы и отправлять информацию посредством HTTP, позволяет взаимодействовать с любой web-службой. Вы можете получить web-услугу из системы, отличной от .NET. Самое приятное то, что вам никогда не придется ориентироваться на определенный "уровень совместимости" - web-службы .NET изначально встроены в открытые стандарты.
Рассматривая различные стандарты, которые используются для реализации web-служб, нельзя не отметить простоту, элегантность и легкость их применения. Это сводит к минимуму количество ошибок при разработке, но также означает, что программисты должны создавать свои собственные функции обеспечения безопасности,
Переход от двоичных стандартов, применяемых в СОМ и CORBA, к XML-тексту позволил упростить исправление ошибок и обеспечил возможность осуществлять взаимодействие с web-службами по обычным каналам HTTP, без усилий отправляя сообщения через брандмауэры. Но такое изменение привело к нескольким потенциальным неудобствам. Один из недостатков состоит в том, что сообщения web-службы требуют большего количества байтов для передачи одного и того же объема информации.
Реализация web-служб .NET осуществляется так же просто, как и активизация удаленной web-службы или вызов метода локального класса. Это достигается за счет применения инструментов, предоставляемых системой .NET Framework, которые позволяют создать полноценную web-службу, не вникая в детали работы таких стандартов, как SOAP и WSDL. Порядок действий при этом подобен приведенному ниже (обратите внимание, что этапы 1, 3, 5 и 8 выполняются вручную).
.NET -класс с атрибутами, которые идентифицируют его как web-службу с некоторыми функциями..NET автоматически создается документ WSDL, где описывается, как клиент должен взаимодействовать с web-службой..NET осуществляется автоматическая SOAP -ответ, преобразует таковой в соответствующий тип данных и возвращает его как обычный тип данных .NET.Описанный процесс схематически показан на рис.12.3.
(рис 12.3) Взаимодействие с web-службой
При работе web-служб .NET используется технология ASP .NET, являющаяся частью системы .NET Framework. Она также требует поддержки со стороны сервера Microsoft IIS (Internet Information Server). Среда Visual Studio .NET обеспечивает большое количество инструментов, которые помогают облегчить решение задач, связанных с получением и выполнением web-службы.
Для создания и использования web-службы не требуется глубоких знаний о технологии, лежащей в ее основе. Однако если вы хотите создать web-службу, реализующую лучшие свойства платформы, и избежать при этом наиболее распространенных ошибок, без понимания работы базовых технологий вам не обойтись.
Работа web-служб построена на использовании различных открытых стандартов, которые описаны в таблице.
| Технология | Назначение |
|---|---|
| WSDL | Основанный на XML формат описания web-службы, ее методов, типов данных параметров и возвращаемого значения, а также поддерживаемых методов коммуникации |
| HTTP | Коммуникационный протокол, служащий для отправки запросов web-службе через Интернет. (Кроме того, это распространенный стандарт, применяемый для передачи web-страниц web-браузеру) |
| SOAP | Основанный на XML формат кодирования информации в запросе, посылаемом web-службе, и ответном сообщении для отправки таковых через Интернет. Например, SOAP определяет способы представления величин различных типов данных |
| DISCO | Необязательная спецификация Microsoft, позволяющая клиентам находить требуемые web-службы. DISCO-файл является, по сути, несистематизированным списком связей с web-службами. В настоящее время вытесняется стандартом WS-Inspection. |
| Каталог, который позволяет клиентам находить web-службы, предоставляемые конкретной компанией. |
WSDL представляет собой стандарт, разработанный только для web-служб .NET. С целью обеспечения совместимости с другими платформами. При создании web-служб рекомендуется использовать формат SOAP, но допускается также применять методы POST и GET протокола HTTP. Спецификации DISCO и HTTP -коммуникация, и нет смысла от нее отказываться.
К числу менее распространенных стандартов, используемых при создании web-служб, относится WS-Inspection - спецификация для поиска документов, в которых перечислены группы web-служб и их местонахождение. Эта спецификация была разработана совместными усилиями компаний Microsoft и IBM и предназначалась для замены протокола DISCO.
Кроме того, имеются конкурирующие спецификации, служащие для преодоления некоторых присущих web-службам ограничений, к которым можно отнести отсутствие транзакций, аутентификации, лицензирования и шифрования. Ни одна из подобных спецификаций не достигла уровня установленного стандарта и не была включена в .NET, но, возможно, в будущем это произойдет.
Каждая web-служба предоставляет документ WSDL (Web Service Description Language - язык описания web-службы), в котором описывается все, что клиенту необходимо знать об этой службе. WSDL -документ служит тем же целям, что и файл IDL (CORBA или СОМ: он определяет интерфейс web-службы. Указанный документ, по сути, представляет собой контракт между клиентом и web-службой, где декларируется, что "если вы вызовете такой-то метод с такими-то параметрами, то в качестве возвращаемой величины получите такие-то данные".
Во многих отношениях web-службы даже проще, чем создаваемые для CORBA или СОМ компоненты. Например, в web-службах отсутствует возможность поддержки нескольких интерфейсов - каждый класс web-службы обеспечивает только один набор открытых ( public ) методов. С другой стороны, документ WSDL немного сложнее своего IDL -эквивалента, поскольку он является платформонезависимым и поддерживает коммуникационные протоколы, отличные от SOAP и HTTP. Это означает, что каждый WSDL -файл для web-службы .NET содержит значительный объем стереотипного кода, служащего для обеспечения поддержки базового уровня коммуникации (в соответствии с протоколом SOAP или методами GET и POST протокола HTTP ).
ПРИМЕЧАНИЕ
В процессе .NET -программирования нет необходимости создавать свой собственный WSDL -документ. Каждая web-служба .NET генерирует такой документ автоматически. Его можно увидеть с помощью поддерживающего XML браузера.
Некоторые разработчики утверждают, что стандарт WSDL для web-служб не нужен, поскольку сообщения SOAP являются самодостаточными и точно специфицируют типы данных любых содержащихся в них величин. Однако WSDL -документ предоставляет простой и последовательный способ задания разработчиком синтаксиса вызова любого web-метода. Более того, этот документ позволяет использовать инструменты автоматического генерирования прокси-классов, подобные включенным в среды Visual Studio .NET и .NET Framework. Благодаря указанным средствам использование web-службы является таким же простым, как и применение локального класса.
WSDL -документ имеет основанный на XML формат, в соответствии с которым информация подразделяется на пять групп. Первые три группы представляют собой абстрактные определения, не зависящие от особенностей платформы, сети или языка, а оставшиеся две группы включают конкретные описания.
Связь между web-службами и их клиентами осуществляется посредством сообщений в формате XML. SOAP (Simple Object Access Protocol - простой протокол доступа к объектам) представляет собой протокол сообщений для выбора web-служб. Использование слова Object в названии данного протокола является не совсем корректным, поскольку сообщения SOAP не направляются объектам. Основная идея стандарта SOAP заключается в том, что сообщения должны быть закодированы в стандартизированном XML -формате. Можно сказать, что формат SOAP идеально подходит для технологии RPC ( Remote Procedure Call - вызов удаленной процедуры), так как SOAP -сообщение содержит направляемые клиентом параметры или отсылаемую службой возвращаемую величину. Нет ничего удивительного в том, что другие программные продукты (скажем, сервер BizTalk компании Microsoft) применяют протокол SOAP для передачи иных типов информации. Аналогично, SOAP -сообщения могут использоваться не только при передаче по протоколу HTTP, но также при пересылке через сокеты, именованные каналы и даже по протоколу SMTP электронной почты.
Кроме сообщений SOAP, для обмена данными с web-службами .NET можно использовать методы GET и POST протокола HTTP. Теоретически при передаче информации методом POST вы можете по-прежнему применять формат SOAP, но в этом случае данные проще передавать в виде набора имя-значение без указания их типа.
Давайте рассмотрим преимущества применения формата SOAP.
Кодировать в XML структуры данных и наборы DataSet с использованием SOAP так же легко, как и данные простых типов (скажем, целого или строкового).
При использовании SOAP -сообщений предоставляются дополнительные инструменты, позволяющие легко добавлять, например, функции обеспечения безопасности или трассировки.
Истинная межплатформенность
Протокол SOAP лучше всего подходит для получения .NET -услуги на обычном клиенте. Имеются наборы инструментов SOAP для различных языков программирования (и даже для предыдущих версий Microsoft C++ и Visual Basic ). Чтобы обеспечить связь с web-службой посредством методов GET и POST протокола HTTP, придется, очевидно, вручную сконструировать строку запроса, а затем вручную провести синтаксический разбор ответа, что, согласитесь, является не самым элегантным решением.
Стандарт DISCO предоставляет простейший способ получения доступа к файлам манифестов, позволяющий группировать ссылки на web-службы. Поскольку основной целью web-служб является обеспечение В2В-взаимодействия, требуется такой инструмент, который давал бы возможность не только создавать полезные функции, но и использовать их совместно с другими организациями. Информация о коммуникации с единственной web-службой может быть достаточно простой, но если у вас имеется сложная комбинация web-служб, которые расположены в различных приложениях ASP .NET и предназначены для различных клиентов, намного сложнее уследить за тем, чтобы клиенты получили требуемую информацию.
Один из методов обеспечения связей с различными web-службами состоит в создании специальной HTML-страницы. Однако такой подход не стандартизирован, требует формирования базового пользовательского интерфейса и может сбить с толку потребителей, которые просматривают web-узел. Возможны другие способы обмена информацией, в частности посредством электронной почты или телефона, но такие методы неэффективны.
Технология DISCO позволяет избежать данных проблем. DISCO -файл - это не просто список web-служб и соответствующих связей, представленных в XML-формате. Такой файл может включать файлы различных web-серверов и поддерживает "динамический поиск" - автоматический поиск каталога файлов web-службы на сервере. Инструменты .NET, например Visual Studio .NET, содержат средства обработки файлов манифестов и предоставляют простой способ их просмотра, а также обеспечивают подключение группы связанных служб к клиенту.
Чтобы использовать web-службу, клиенту необходимо знать адрес web-узла соответствующей компании либо адрес URL файла манифеста. Файлы манифеста полезны тем, что объединяют множество web-служб в единственном списке, однако они не позволяют клиентам отыскивать web-службы определенного типа без указания наименования компании-разработчика.
Спецификация ), включая основных конкурентов - Sun и Microsoft. Объединив свои усилия, эти компании разработали проект спецификации Windows .NET для
использования в корпоративных сетях интранета.
В хранилище SOAP -сообщение.
Microsoft - не единственный разработчик инструментов реализации web-служб. В настоящее время существуют инструменты создания web-служб для разнообразных языков и платформ. Некоторые из них перечислены ниже.
Java.SOAP Toolkit от Microsoft позволяет вызывать web-службы из программных продуктов, созданных в предыдущих версиях Microsoft Visual Studio (и написанных на таких языках, как Visual Basic и C++ ).Perl включает набор инструментов SOAP::Lite для работы с базовыми функциями SOAP..NET MyServices (первоначальное название - Hailstorm) представляет собой ориентированный на пользователя набор web-служб, разработанных компанией Microsoft. MyServices находится на вершине структуры .NET Framework и предназначен для предоставления некоторых основных функций, к которым приложения будут получать доступ, чтобы совместно использовать пользовательскую информацию.
Службы .NET MyServices выполняют такие функции, как сопровождение информации, поддержка аутентификации, а также выдача уведомлений для отдельных пользователей. Хотя названные службы ориентированы на конечных пользователей, однако таковые не взаимодействуют с ними напрямую, как это происходит в случае обычных web-служб. К данным службам для получения базовой информации и высокоуровневых функций обращаются приложения. Большинство служб .NET MyServices являются стандартизированным интерфейсом web-служб онлайнового хранилища данных. К таким данным может относиться все что угодно, от бизнес- календаря с указанием дат встреч до финансовых отчетов.
Первоначально компания Microsoft планировала хранить все наборы служебных пользовательских данных для MyServices на своих серверах. Потенциальные партнеры, однако, скептически отнеслись к такому способу размещения информации и потребовали предоставления возможности выбора места хранения своих данных. Поэтому было принято решение о том, что MyServices будет позволять организациям самостоятельно поддерживать свои службы MyServices и собственные (возможно, связанные) хранилища данных.
В настоящее время самой известной (и наиболее важной) частью .NET MyServices является система аутентификации Passport, которая разрабатывалась для сервера Hotmail и предназначалась для проверки паролей доступа к электронной почте. Позднее Passport превратилась в полноценную web-службу и сегодня используется многими компаниями для аутентификации своих клиентов. Данная система также доступна для потребительских web-узлов через систему ASP .NET Framework и может использоваться в качестве простого средства для идентификации пользователей.
.NET Remoting - это технология распределенных компонентов, заменившая модель DCOM в среде .NET. Она остается идеальным средством во многих ситуациях, когда web-службы .NET оказываются неподходящими, в частности применяется при работе приложений, требующих совместного использования больших объемов информации либо при необходимости сокращения времени ответа. Однако в отличие от web-служб технология .NET Remoting разрабатывалась не с целью совместного использования и публикации служб (таких как DISCO -файлы и
Сегодня .NET Remoting представляет собой расширяемую технологию, которая способна поддерживать различные протоколы передачи данных, в том числе HTTP и SOAP. Таким образом, данная технология могла бы составить конкуренцию web-службам, если бы не тот факт, что .NET Remoting не поддерживает .NET -ориентированный формат сериализации.
Технология .NET Remoting может оказаться полезной лишь при необходимости создать распределенную систему, которая работает в довольно гомогенной (однородной) среде и не требует взаимодействия с множеством клиентов. Иными словами, эта технология больше подходит для внутрикорпоративных решений и в меньшей степени - для основанной на стандартах разработки, требующей совместимости с большим количеством проектов других организаций. Технология .NET Remoting используется в локальной сети компании или при работе с группой постоянных клиентов в Интернете. В отличие от web-служб .NET, для хост-компонентов .NET Remoting не требуется наличия ASP .NET или IIS.
XML-RPC - это простой, но довольно распространенный протокол, который является предшественником протокола SOAP и web-служб .NET. Протокол RPC (Remote Procedure Call - вызов удаленной процедуры) обеспечивает вызовы удаленных процедур путем отправки запросов в виде XML-документов и получение ответа в другом XML-документе. Таким же образом работает и web-служба .NET, но для связи с ней необходим протокол SOAP.
Протокол XML-RPC имеет некоторые ограничения, главным из которых является отсутствие поддержки типов данных. Технология web-служб .NET вобрала в себя лучшее качество XML-RPC, то есть тот факт, что программы могут взаимодействовать, если они обмениваются сообщениями, имеющими стандартный согласованный формат. Кроме того, при разработке web-служб .NET были учтены потребности промышленности в необходимости кросс -платформенного представления данных различных типов.
Microsoft, Sun и многие другие компании предоставляют системы обмена сообщениями, которые допускают коммуникацию типа "store-and-forward" (сохранение и отправка далее). Такая модель не подходит для ситуаций, когда требуется немедленный ответ, но применима в случае односторонней связи наподобие регистрации. Серверные программные средства обмена сообщениями, например MSMQ (Microsoft Message Queuing - организация очередей сообщений), обеспечивают богатый набор функций, включая транзакции, и оказываются скорее помощниками, чем конкурентами web-служб. Однако web-службы относятся к числу более распространенных технологий и могут рассматриваться в качестве более простой модели для реализации удаленных вызовов функций, а не только односторонних сообщений. Кроме того, web-службы поддерживают асинхронный режим работы.
Сервер .
При ближайшем рассмотрении сервер BizTalk оказывается, по сути, хостом для дополнительных высокоуровневых служб, которые разработчик может использовать для интегрирования бизнес-процессов. Например, с помощью сервера BizTalk можно создавать интерфейсы, позволяющие различным процессам взаимодействовать друг с другом даже тогда, когда для работы одного процесса требуются данные в формате, отличном от предоставляемого другим. Вы можете также конфигурировать длительные распределенные транзакции, проектировать рабочий поток документов с использованием визуальных средств проектирования, предписывать правила ведения бизнеса, а также обмениваться сообщениями в формате SOAP. Чтобы описать возможности сервера BizTalk, требуется отдельная книга, но он представляет интерес, главным образом, для разработчиков, которые проектируют программное обеспечение для В2В -взаимодействия.
Web-службы - это технология предоставления совместно используемых функций, не зависящих от устройств, сетей, операционных систем и языков программирования.
Сегодня доступ к Интернету можно получить с помощью различных устройств, обеспечивающих большое разнообразие функциональных средств. В большинстве случаев обмен информацией в Интернете осуществляется посредством запросов и ответов с использованием открытых протоколов, в частности HTTP. Обычно большая часть такой информации представлена на языке HTML, специальные теги которого позволяют организовать пользовательский интерфейс в отображаемых браузером web-страницах.
С недавних пор настольные и web-приложения стали похожи друг на друга. Интерфейсы настольных приложений, например таких, как в системе Windows ХР, теперь напоминают интерфейсы интернет-браузеров. В обычных настольных приложениях применяются функции Интернета, а Windows-приложения способны взаимодействовать с web-серверами посредством протокола HTTP. В частности, программа Microsoft Money автоматически загружает банковскую информацию; операционная система Windows уведомляет вас о появляющихся обновлениях; Visual Studio .NET позволяет проводить поиск в библиотеке MSDN, не покидая среду разработки.
Web-приложения нельзя назвать совершенными, поскольку для интеграции функциональных возможностей различных web-узлов используются достаточно "неуклюжие" методы, такие как метод поиска связей, кадров и экранов. Недостаток приложений подобного типа состоит в их "монолитности" (связанности): они существуют как пакеты "все в одном", и очень непросто отделить пользовательский интерфейс от его функциональности, обеспечить, скажем, отслеживание курсов акций или их пакетов без того, чтобы принуждать пользователя "бегать" по всему web-узлу.
С появлением web-служб и технологии .NET ситуация изменилась. Протоколы web-служб определяют структуру для предоставления функций через Интернет. Они основаны на открытых стандартах, являются взаимосвязанными, расширяемыми и используются для нынешнего поколения web-ориентированных приложений. Система .NET Framework представляет собой высокооптимизированную платформу и имеет набор инструментов для развертывания web-служб.
Web-служба (Web Service) - это приложение или блок находящегося на web-сервере выполняемого кода, функционирование которого основано на применении стандартных форматов XML. Поиск этого кода, его извлечение и получение посредством него требуемого результата выполняется в среде .NET Framework. Вызывается web-служба .NET так же просто, как и
Web-служба .NET - это не объект (во всяком случае, не в его традиционном представлении). Web-метод является, по сути, независимым, "атомарным" и не имеющим постоянного местонахождения. Web-служба больше подобна библиотеке функций в DLL и ее сложно ограничить рамками объектно-ориентированной абстракции. Это упрощение в значительной мере и обеспечивает преимущества web-служб. Поскольку web-службы не ограничены конкретной технологией (безопасности, управления или транспортировки), они могут быть использованы почти в любом разрабатываемом сценарии, что существенным образом отличает их от предыдущих технологий, таких как СОМ и CORBA.
Web-службы предоставляют способ совместного использования программных функций. Их даже можно назвать "СОМ для Web", хотя в основе работы этих систем лежит совсем другая технология.
Web-служба не является продуктом для конечного пользователя. Она представляет собой основанное на компонентах приложение, позволяя многократно использовать свою функциональность в различных средах и на клиентах разных типов. Пользователем web-службы всегда является другое приложение.
Web-службы могут использоваться для решения следующих задач:
На сегодняшний день это наиболее широко распространенные задачи, решаемые с применением web-служб. Web-службы позволяют совместно использовать информацию либо могут интегрироваться с другими службами. Например, компания, занимающаяся электронной коммерцией, может обращаться к web-службе для осуществления автоматического взаимодействия с поставщиками. В подобных случаях в качестве пользователя web-службы, скорее всего, будет выступать программное обеспечение, установленное в такой компании.
Допустим, независимый разработчик спроектировал web-службу аутентификации, предназначенную для применения в среде ASP .NET. Если вы пожелаете воспользоваться этой службой, то за соответствующую плату можете приобрести месячную подписку на нее. Однако данный процесс будет совершенно прозрачным для конечного пользователя, который решит, что указанные средства аутентификации являются частью вашего приложения. Такие готовые компоненты можно использовать в web-приложениях, а также в настольных и мобильных программах.
Компания Microsoft выдвинула инициативу создания технологии встройки, которая позволила системным администраторам осуществлять дистанционное администрирование с применением web-служб. Банк, который имеет намерение открыть вам инвестиционный счет, заинтересован в наличии web-службы для загрузки информации о транзакциях, которую можно было бы использовать без необходимости тратиться на финансовую программу наподобие Quicken. Пока конечные пользователи не получат напрямую требуемую услугу, ее доступность в Quicken может вынудить их открыть счет в другом банке, который предоставляет данную программу.
DLL для многократного использования кодаСамый простой способ многократного использования определенных функциональных возможностей в приложениях ASP .NET заключается не в создании сборки .NET, а в проектировании web-службы, к которой могли бы обращаться различные клиенты, в том числе настольные приложения,
Web-службы можно использовать, в частности, для соединения специализированной программы по работе с
Концепция, лежащая в основе функционирования web-служб, не нова. Существует множество и других сред программирования, которые базируются на принципе разделения приложений и функций между компьютерами по сети, позволяющем сделать работу их пользователей более эффективной и гибкой. Однако до сих пор ни одна из таких сред не приобрела широкой популярности, поскольку с их применением связаны две проблемы:
История программирования в значительной степени представляет собой процесс перехода от небольших изолированных сред (таких как мэйнфреймы и автономные приложения) к более широкомасштабным и многокомпонентным системам, начиная от сетевого и клиент-серверного программного обеспечения и заканчивая Интернет -приложениями и распределенными приложениями.
В начале 90-х годов прошлого века интерес разработчиков привлекали две соперничающие
Однако по мере того как распределенные сети приобретали все более широкую популярность, возникла необходимость в обеспечении возможности взаимодействия отдельных компьютеров. Разработчики могли создавать собственные решения, воспользовавшись сокетами, хотя это требовало от клиентов и серверов выполнения достаточно тяжелой работы, а для кодирования и декодирования сообщений нужны были высокоуровневые протоколы. Но не только в этом состояло неудобство для разработчиков: их программы получались громоздкими и могли содержать множество ошибок.
В середине 90-х годов компания Microsoft выпустила расширенную компонентную модель - DCOM ( Distributed СОМ ). Эта модель не являлась альтернативой или дополнением модели СОМ - в действительности она была лишь сетевым протоколом, определяющим способ взаимодействия СОМ -объектов различных компьютеров. Компания
Эти стандарты позволили приложению, запущенному на одном компьютере, использовать код, расположенный на другом компьютере. Но поскольку оба указанных стандарта являлись потомками стандартов разработки настольных приложений, они имели несколько уровней сложности, затрудняющих их применение (в частности, модель DCOM за это часто критиковали). Опытные разработчики считают, что эти протоколы сыграли положительную роль, обеспечив возможность создавать приложения, которые могут выполняться распределено на нескольких рабочих станциях, тем самым позволив подняться от разработки клиент-серверного программного обеспечения до так называемых 3-уровневых и n-уровневых приложений.
К сожалению, ни COM/DCOM, ни CORBA/ не функционировали должным образом в рамках Интернета. В частности, потому, что оба этих стандарта являются взаимно исключающими. Серверы DCOM могут взаимодействовать только с клиентами DCOM, стандарты CORBA и DCOM ограничена компьютерами, оснащенными операционной системой Microsoft Windows. Модель CORBA, подобно СОМ, является сложным стандартом, не предназначенным для работы через брандмауэры. Таким образом, помимо необходимости адаптировать модели СОМ и CORBA для использования в сетевой среде, требовалось создать простые программные средства разработки распределенных приложений в сети Web.
DCOM - это сетевой протокол, основанный на стандарте распределенной среды обработки СОМ - объекты на удаленном компьютере точно так же, как и на локальном (рис. 12.1). DCOM просто переносит локальную межпроцессную связь с помощью сетевого протокола. Вызов становится несколько более медленным, но ни клиенту, ни компоненту нет необходимости знать, что связь между ними осуществляется по сети. На рис. 12.1 показан многоуровневый протокол, позволяющий модели СОМ работать через сеть.
(рис 12.1) Архитектура COM/DCOM
К сожалению, модель COM/DCOM не подходит для работы в распределенных сетях.
Применить DCОМ в сети приводит к большим издержкам из-за возникновения помех и большого количества отложенных сообщений. Очевидно, что применять DCОМ в сети Интернет тем более не имеет смысла, поскольку по мере роста числа клиентов в сети объем сетевого трафика увеличивается и необходимость обрабатывать большое количество запросов наносит серьезный вред всей системе. Таким образом, разработчики пришли к выводу, что протокол DCOM является принципиально не масштабируемым для обслуживания большого числа клиентов. Кроме того, указанные ограничения делают невозможным использование DCOM -компонента в случае ненадежной или периодически устанавливаемой связи.
Модель CORBA является общим стандартом для создания СОМ на платформе Microsoft, - они обеспечивают взаимодействие объектов. С появлением CORBA большинство разработчиков рассчитывали на то, что распределенная среда компьютерной обработки CORBA, показаны на рис. 12.2.
По многим параметрам CORBA кажется идеальным средством для работы с распределенными объектами. Об этом свидетельствует, в частности, тот факт, что данная технология поддерживается внушительной группой разработчиков, включающей более 500 компаний-партнеров. Но все они и несут ответственность за снижение интереса к модели CORBA. Имеется множество реализаций CORBA, и все они обладают своими особенностями. Не существует коммерческих брокеров
(рис 12.2) Архитектура CORBA/IIОР
Протокол CORBA быстро теряет репутацию, становясь все более сложным и неудобным для программирования. Частично в ответ на это компания Sun создала свой собственный механизм Java, поскольку прекрасно интегрируется с ним. Однако подобное интегрирование также является и недостатком. Работа Java, ни одна из которых не поддерживается популярными языками наподобие C++. Фактически CORBA.
Несмотря на имеющиеся различия, технологии COM/DCOM и CORBA/ обладают рядом общих ограничений:
Данная особенность затрудняет использование указанных стандартов при наличии в сети брандмауэров, которые ограничивают доступ нетекстовых данных через большинство портов. Даже если брандмауэр сконфигурирован так, что подобные данные могут поступать через порт, изменение каких-либо настроек (что обычно и случается) приведет к разрыву объектной коммуникации.
С помощью СОМ и CORBA можно спроектировать компоненты, способные взаимодействовать с сотнями клиентов так же легко, как и с десятками. Однако это требует от программистов огромного опыта и дисциплины. Типичный компонент того не стоит.
Протокол СОМ тесно связан с платформой Windows. Не существует простого способа создать и разместить СОМ -компонент в другой операционной системе, такой как UNIX. Модель CORBA подобным недостатком не обладает, но ее сложно использовать в языках, отличных от Java. В конечном счете, оба этих стандарта оказываются "закрытыми", что ограничивает сферу и способы их использования.
Стандарты СОМ и CORBA включают множество встроенных средств, таких как транзакции, инструменты безопасности и шифрования, что повышает вероятность возникновения проблем, связанных, в частности, с несовместимостью и дополнительными затратами. В настоящее время протоколы web-служб не предоставляют и не специфицируют инструменты API для указанных высокоуровневых служб. Этот факт значительно упрощает их реализацию, но означает, что в случае необходимости вам придется самостоятельно разрабатывать такие средства.
Рассматривая историю развития совместного использования программного кода в сетях, мы оставили без внимания такой важный вопрос разработки, как эволюция универсального стандарта для кодирования информации. Это объясняется тем, что в то время, когда создавались технологии СОМ и CORBA, стандарта для совместного использования структурированных данных не существовало. И лишь позднее появились такие стандарты, как SGML, XML и SOAP, предназначенные непосредственно для представления типов данных.
Несмотря на все выше сказанное технологии СОМ и CORBA по-прежнему широко используются. Конечно, у них есть свои недостатки, но они отнюдь не потеряли еще своей работоспособности. В некоторых отношениях они не способны конкурировать с web-службами, но могут стать идеальным инструментом для реализации распределенных компонентов в гетерогенной сетевой среде.
Web-службы были разработаны с целью преодоления ограничений описанных выше технологий. С помощью .NET компания Microsoft надеется построить более совершенную структуру программирования для создания и предоставления web-услуг.
Web-службы .NET отличаются от существующих технологий создания распределенных приложений следующими характеристиками.
В web-службах отсутствуют какие-либо скрытые или недоступные элементы. Каждый аспект технологии, от способа поиска web-службы до ее описания и организации связи с ней, определен общедоступными стандартами. Доступность информации способствует дальнейшему расширению и развитию данной технологии.
Язык программирования, который позволяет создавать XML-документы и отправлять информацию посредством HTTP, позволяет взаимодействовать с любой web-службой. Вы можете получить web-услугу из системы, отличной от .NET. Самое приятное то, что вам никогда не придется ориентироваться на определенный "уровень совместимости" - web-службы .NET изначально встроены в открытые стандарты.
Рассматривая различные стандарты, которые используются для реализации web-служб, нельзя не отметить простоту, элегантность и легкость их применения. Это сводит к минимуму количество ошибок при разработке, но также означает, что программисты должны создавать свои собственные функции обеспечения безопасности,
Переход от двоичных стандартов, применяемых в СОМ и CORBA, к XML-тексту позволил упростить исправление ошибок и обеспечил возможность осуществлять взаимодействие с web-службами по обычным каналам HTTP, без усилий отправляя сообщения через брандмауэры. Но такое изменение привело к нескольким потенциальным неудобствам. Один из недостатков состоит в том, что сообщения web-службы требуют большего количества байтов для передачи одного и того же объема информации.
Реализация web-служб .NET осуществляется так же просто, как и активизация удаленной web-службы или вызов метода локального класса. Это достигается за счет применения инструментов, предоставляемых системой .NET Framework, которые позволяют создать полноценную web-службу, не вникая в детали работы таких стандартов, как SOAP и WSDL. Порядок действий при этом подобен приведенному ниже (обратите внимание, что этапы 1, 3, 5 и 8 выполняются вручную).
.NET -класс с атрибутами, которые идентифицируют его как web-службу с некоторыми функциями..NET автоматически создается документ WSDL, где описывается, как клиент должен взаимодействовать с web-службой..NET осуществляется автоматическая SOAP -ответ, преобразует таковой в соответствующий тип данных и возвращает его как обычный тип данных .NET.Описанный процесс схематически показан на рис.12.3.
(рис 12.3) Взаимодействие с web-службой
При работе web-служб .NET используется технология ASP .NET, являющаяся частью системы .NET Framework. Она также требует поддержки со стороны сервера Microsoft IIS (Internet Information Server). Среда Visual Studio .NET обеспечивает большое количество инструментов, которые помогают облегчить решение задач, связанных с получением и выполнением web-службы.
Для создания и использования web-службы не требуется глубоких знаний о технологии, лежащей в ее основе. Однако если вы хотите создать web-службу, реализующую лучшие свойства платформы, и избежать при этом наиболее распространенных ошибок, без понимания работы базовых технологий вам не обойтись.
Работа web-служб построена на использовании различных открытых стандартов, которые описаны в таблице.
| Технология | Назначение |
|---|---|
| WSDL | Основанный на XML формат описания web-службы, ее методов, типов данных параметров и возвращаемого значения, а также поддерживаемых методов коммуникации |
| HTTP | Коммуникационный протокол, служащий для отправки запросов web-службе через Интернет. (Кроме того, это распространенный стандарт, применяемый для передачи web-страниц web-браузеру) |
| SOAP | Основанный на XML формат кодирования информации в запросе, посылаемом web-службе, и ответном сообщении для отправки таковых через Интернет. Например, SOAP определяет способы представления величин различных типов данных |
| DISCO | Необязательная спецификация Microsoft, позволяющая клиентам находить требуемые web-службы. DISCO-файл является, по сути, несистематизированным списком связей с web-службами. В настоящее время вытесняется стандартом WS-Inspection. |
| Каталог, который позволяет клиентам находить web-службы, предоставляемые конкретной компанией. |
WSDL представляет собой стандарт, разработанный только для web-служб .NET. С целью обеспечения совместимости с другими платформами. При создании web-служб рекомендуется использовать формат SOAP, но допускается также применять методы POST и GET протокола HTTP. Спецификации DISCO и HTTP -коммуникация, и нет смысла от нее отказываться.
К числу менее распространенных стандартов, используемых при создании web-служб, относится WS-Inspection - спецификация для поиска документов, в которых перечислены группы web-служб и их местонахождение. Эта спецификация была разработана совместными усилиями компаний Microsoft и IBM и предназначалась для замены протокола DISCO.
Кроме того, имеются конкурирующие спецификации, служащие для преодоления некоторых присущих web-службам ограничений, к которым можно отнести отсутствие транзакций, аутентификации, лицензирования и шифрования. Ни одна из подобных спецификаций не достигла уровня установленного стандарта и не была включена в .NET, но, возможно, в будущем это произойдет.
Каждая web-служба предоставляет документ WSDL (Web Service Description Language - язык описания web-службы), в котором описывается все, что клиенту необходимо знать об этой службе. WSDL -документ служит тем же целям, что и файл IDL (CORBA или СОМ: он определяет интерфейс web-службы. Указанный документ, по сути, представляет собой контракт между клиентом и web-службой, где декларируется, что "если вы вызовете такой-то метод с такими-то параметрами, то в качестве возвращаемой величины получите такие-то данные".
Во многих отношениях web-службы даже проще, чем создаваемые для CORBA или СОМ компоненты. Например, в web-службах отсутствует возможность поддержки нескольких интерфейсов - каждый класс web-службы обеспечивает только один набор открытых ( public ) методов. С другой стороны, документ WSDL немного сложнее своего IDL -эквивалента, поскольку он является платформонезависимым и поддерживает коммуникационные протоколы, отличные от SOAP и HTTP. Это означает, что каждый WSDL -файл для web-службы .NET содержит значительный объем стереотипного кода, служащего для обеспечения поддержки базового уровня коммуникации (в соответствии с протоколом SOAP или методами GET и POST протокола HTTP ).
ПРИМЕЧАНИЕ
В процессе .NET -программирования нет необходимости создавать свой собственный WSDL -документ. Каждая web-служба .NET генерирует такой документ автоматически. Его можно увидеть с помощью поддерживающего XML браузера.
Некоторые разработчики утверждают, что стандарт WSDL для web-служб не нужен, поскольку сообщения SOAP являются самодостаточными и точно специфицируют типы данных любых содержащихся в них величин. Однако WSDL -документ предоставляет простой и последовательный способ задания разработчиком синтаксиса вызова любого web-метода. Более того, этот документ позволяет использовать инструменты автоматического генерирования прокси-классов, подобные включенным в среды Visual Studio .NET и .NET Framework. Благодаря указанным средствам использование web-службы является таким же простым, как и применение локального класса.
WSDL -документ имеет основанный на XML формат, в соответствии с которым информация подразделяется на пять групп. Первые три группы представляют собой абстрактные определения, не зависящие от особенностей платформы, сети или языка, а оставшиеся две группы включают конкретные описания.
Связь между web-службами и их клиентами осуществляется посредством сообщений в формате XML. SOAP (Simple Object Access Protocol - простой протокол доступа к объектам) представляет собой протокол сообщений для выбора web-служб. Использование слова Object в названии данного протокола является не совсем корректным, поскольку сообщения SOAP не направляются объектам. Основная идея стандарта SOAP заключается в том, что сообщения должны быть закодированы в стандартизированном XML -формате. Можно сказать, что формат SOAP идеально подходит для технологии RPC ( Remote Procedure Call - вызов удаленной процедуры), так как SOAP -сообщение содержит направляемые клиентом параметры или отсылаемую службой возвращаемую величину. Нет ничего удивительного в том, что другие программные продукты (скажем, сервер BizTalk компании Microsoft) применяют протокол SOAP для передачи иных типов информации. Аналогично, SOAP -сообщения могут использоваться не только при передаче по протоколу HTTP, но также при пересылке через сокеты, именованные каналы и даже по протоколу SMTP электронной почты.
Кроме сообщений SOAP, для обмена данными с web-службами .NET можно использовать методы GET и POST протокола HTTP. Теоретически при передаче информации методом POST вы можете по-прежнему применять формат SOAP, но в этом случае данные проще передавать в виде набора имя-значение без указания их типа.
Давайте рассмотрим преимущества применения формата SOAP.
Кодировать в XML структуры данных и наборы DataSet с использованием SOAP так же легко, как и данные простых типов (скажем, целого или строкового).
При использовании SOAP -сообщений предоставляются дополнительные инструменты, позволяющие легко добавлять, например, функции обеспечения безопасности или трассировки.
Истинная межплатформенность
Протокол SOAP лучше всего подходит для получения .NET -услуги на обычном клиенте. Имеются наборы инструментов SOAP для различных языков программирования (и даже для предыдущих версий Microsoft C++ и Visual Basic ). Чтобы обеспечить связь с web-службой посредством методов GET и POST протокола HTTP, придется, очевидно, вручную сконструировать строку запроса, а затем вручную провести синтаксический разбор ответа, что, согласитесь, является не самым элегантным решением.
Стандарт DISCO предоставляет простейший способ получения доступа к файлам манифестов, позволяющий группировать ссылки на web-службы. Поскольку основной целью web-служб является обеспечение В2В-взаимодействия, требуется такой инструмент, который давал бы возможность не только создавать полезные функции, но и использовать их совместно с другими организациями. Информация о коммуникации с единственной web-службой может быть достаточно простой, но если у вас имеется сложная комбинация web-служб, которые расположены в различных приложениях ASP .NET и предназначены для различных клиентов, намного сложнее уследить за тем, чтобы клиенты получили требуемую информацию.
Один из методов обеспечения связей с различными web-службами состоит в создании специальной HTML-страницы. Однако такой подход не стандартизирован, требует формирования базового пользовательского интерфейса и может сбить с толку потребителей, которые просматривают web-узел. Возможны другие способы обмена информацией, в частности посредством электронной почты или телефона, но такие методы неэффективны.
Технология DISCO позволяет избежать данных проблем. DISCO -файл - это не просто список web-служб и соответствующих связей, представленных в XML-формате. Такой файл может включать файлы различных web-серверов и поддерживает "динамический поиск" - автоматический поиск каталога файлов web-службы на сервере. Инструменты .NET, например Visual Studio .NET, содержат средства обработки файлов манифестов и предоставляют простой способ их просмотра, а также обеспечивают подключение группы связанных служб к клиенту.
Чтобы использовать web-службу, клиенту необходимо знать адрес web-узла соответствующей компании либо адрес URL файла манифеста. Файлы манифеста полезны тем, что объединяют множество web-служб в единственном списке, однако они не позволяют клиентам отыскивать web-службы определенного типа без указания наименования компании-разработчика.
Спецификация ), включая основных конкурентов - Sun и Microsoft. Объединив свои усилия, эти компании разработали проект спецификации Windows .NET для
использования в корпоративных сетях интранета.
В хранилище SOAP -сообщение.
Microsoft - не единственный разработчик инструментов реализации web-служб. В настоящее время существуют инструменты создания web-служб для разнообразных языков и платформ. Некоторые из них перечислены ниже.
Java.SOAP Toolkit от Microsoft позволяет вызывать web-службы из программных продуктов, созданных в предыдущих версиях Microsoft Visual Studio (и написанных на таких языках, как Visual Basic и C++ ).Perl включает набор инструментов SOAP::Lite для работы с базовыми функциями SOAP..NET MyServices (первоначальное название - Hailstorm) представляет собой ориентированный на пользователя набор web-служб, разработанных компанией Microsoft. MyServices находится на вершине структуры .NET Framework и предназначен для предоставления некоторых основных функций, к которым приложения будут получать доступ, чтобы совместно использовать пользовательскую информацию.
Службы .NET MyServices выполняют такие функции, как сопровождение информации, поддержка аутентификации, а также выдача уведомлений для отдельных пользователей. Хотя названные службы ориентированы на конечных пользователей, однако таковые не взаимодействуют с ними напрямую, как это происходит в случае обычных web-служб. К данным службам для получения базовой информации и высокоуровневых функций обращаются приложения. Большинство служб .NET MyServices являются стандартизированным интерфейсом web-служб онлайнового хранилища данных. К таким данным может относиться все что угодно, от бизнес- календаря с указанием дат встреч до финансовых отчетов.
Первоначально компания Microsoft планировала хранить все наборы служебных пользовательских данных для MyServices на своих серверах. Потенциальные партнеры, однако, скептически отнеслись к такому способу размещения информации и потребовали предоставления возможности выбора места хранения своих данных. Поэтому было принято решение о том, что MyServices будет позволять организациям самостоятельно поддерживать свои службы MyServices и собственные (возможно, связанные) хранилища данных.
В настоящее время самой известной (и наиболее важной) частью .NET MyServices является система аутентификации Passport, которая разрабатывалась для сервера Hotmail и предназначалась для проверки паролей доступа к электронной почте. Позднее Passport превратилась в полноценную web-службу и сегодня используется многими компаниями для аутентификации своих клиентов. Данная система также доступна для потребительских web-узлов через систему ASP .NET Framework и может использоваться в качестве простого средства для идентификации пользователей.
.NET Remoting - это технология распределенных компонентов, заменившая модель DCOM в среде .NET. Она остается идеальным средством во многих ситуациях, когда web-службы .NET оказываются неподходящими, в частности применяется при работе приложений, требующих совместного использования больших объемов информации либо при необходимости сокращения времени ответа. Однако в отличие от web-служб технология .NET Remoting разрабатывалась не с целью совместного использования и публикации служб (таких как DISCO -файлы и
Сегодня .NET Remoting представляет собой расширяемую технологию, которая способна поддерживать различные протоколы передачи данных, в том числе HTTP и SOAP. Таким образом, данная технология могла бы составить конкуренцию web-службам, если бы не тот факт, что .NET Remoting не поддерживает .NET -ориентированный формат сериализации.
Технология .NET Remoting может оказаться полезной лишь при необходимости создать распределенную систему, которая работает в довольно гомогенной (однородной) среде и не требует взаимодействия с множеством клиентов. Иными словами, эта технология больше подходит для внутрикорпоративных решений и в меньшей степени - для основанной на стандартах разработки, требующей совместимости с большим количеством проектов других организаций. Технология .NET Remoting используется в локальной сети компании или при работе с группой постоянных клиентов в Интернете. В отличие от web-служб .NET, для хост-компонентов .NET Remoting не требуется наличия ASP .NET или IIS.
XML-RPC - это простой, но довольно распространенный протокол, который является предшественником протокола SOAP и web-служб .NET. Протокол RPC (Remote Procedure Call - вызов удаленной процедуры) обеспечивает вызовы удаленных процедур путем отправки запросов в виде XML-документов и получение ответа в другом XML-документе. Таким же образом работает и web-служба .NET, но для связи с ней необходим протокол SOAP.
Протокол XML-RPC имеет некоторые ограничения, главным из которых является отсутствие поддержки типов данных. Технология web-служб .NET вобрала в себя лучшее качество XML-RPC, то есть тот факт, что программы могут взаимодействовать, если они обмениваются сообщениями, имеющими стандартный согласованный формат. Кроме того, при разработке web-служб .NET были учтены потребности промышленности в необходимости кросс -платформенного представления данных различных типов.
Microsoft, Sun и многие другие компании предоставляют системы обмена сообщениями, которые допускают коммуникацию типа "store-and-forward" (сохранение и отправка далее). Такая модель не подходит для ситуаций, когда требуется немедленный ответ, но применима в случае односторонней связи наподобие регистрации. Серверные программные средства обмена сообщениями, например MSMQ (Microsoft Message Queuing - организация очередей сообщений), обеспечивают богатый набор функций, включая транзакции, и оказываются скорее помощниками, чем конкурентами web-служб. Однако web-службы относятся к числу более распространенных технологий и могут рассматриваться в качестве более простой модели для реализации удаленных вызовов функций, а не только односторонних сообщений. Кроме того, web-службы поддерживают асинхронный режим работы.
Сервер .
При ближайшем рассмотрении сервер BizTalk оказывается, по сути, хостом для дополнительных высокоуровневых служб, которые разработчик может использовать для интегрирования бизнес-процессов. Например, с помощью сервера BizTalk можно создавать интерфейсы, позволяющие различным процессам взаимодействовать друг с другом даже тогда, когда для работы одного процесса требуются данные в формате, отличном от предоставляемого другим. Вы можете также конфигурировать длительные распределенные транзакции, проектировать рабочий поток документов с использованием визуальных средств проектирования, предписывать правила ведения бизнеса, а также обмениваться сообщениями в формате SOAP. Чтобы описать возможности сервера BizTalk, требуется отдельная книга, но он представляет интерес, главным образом, для разработчиков, которые проектируют программное обеспечение для В2В -взаимодействия.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.