Опубликован: 08.08.2007 | Доступ: свободный | Студентов: 1666 / 173 | Оценка: 3.86 / 3.76 | Длительность: 11:46:00
Специальности: Программист
Лекция 13:

Основные понятия Web-службы

< Лекция 12 || Лекция 13: 12345 || Лекция 14 >

Недостатки существующих стандартов

Несмотря на имеющиеся различия, технологии COM/DCOM и CORBA/IIOP обладают рядом общих ограничений:

  • Ориентирование на двоичную связь

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

  • Проблемы масштабирования

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

  • Зависимость от платформы или языка программирования

    Протокол СОМ тесно связан с платформой Windows. Не существует простого способа создать и разместить СОМ -компонент в другой операционной системе, такой как UNIX. Модель CORBA подобным недостатком не обладает, но ее сложно использовать в языках, отличных от Java. В конечном счете, оба этих стандарта оказываются "закрытыми", что ограничивает сферу и способы их использования.

  • Сложность

    Стандарты СОМ и CORBA включают множество встроенных средств, таких как транзакции, инструменты безопасности и шифрования, что повышает вероятность возникновения проблем, связанных, в частности, с несовместимостью и дополнительными затратами. В настоящее время протоколы web-служб не предоставляют и не специфицируют инструменты API для указанных высокоуровневых служб. Этот факт значительно упрощает их реализацию, но означает, что в случае необходимости вам придется самостоятельно разрабатывать такие средства.

  • Отсутствие универсального стандарта для представления данных

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

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

Достоинства web-служб .NET

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 осуществляется так же просто, как и активизация удаленной web-службы или вызов метода локального класса. Это достигается за счет применения инструментов, предоставляемых системой .NET Framework, которые позволяют создать полноценную web-службу, не вникая в детали работы таких стандартов, как SOAP и WSDL. Порядок действий при этом подобен приведенному ниже (обратите внимание, что этапы 1, 3, 5 и 8 выполняются вручную).

  1. Вы разрабатываете web-службу как .NET -класс с атрибутами, которые идентифицируют его как web-службу с некоторыми функциями.
  2. В среде .NET автоматически создается документ WSDL, где описывается, как клиент должен взаимодействовать с web-службой.
  3. Потребитель находит вашу web-службу и, решив воспользоваться ею, добавляет соответствующую web-ссылку в проект Visual Studio .NET (или запускает утилиту wsdl.exe).
  4. В среде .NET осуществляется автоматическая проверка документа WSDL и генерируется прокси-класс, который позволяет потребителю взаимодействовать с web-службой.
  5. Потребитель вызывает один из методов вашего класса web-службы. С его точки зрения этот вызов не отличается от вызова метода любого другого класса, но в действительности потребитель взаимодействует с прокси-классом, а не с web-службой.
  6. Прокси-класс преобразует, переданные параметры в сообщение SOAP и отправляет его web-службе.
  7. Вскоре прокси-класс получает SOAP -ответ, преобразует таковой в соответствующий тип данных и возвращает его как обычный тип данных .NET.
  8. Потребитель использует возвращенную ему информацию.

Описанный процесс схематически показан на рис.12.3.

Взаимодействие с web-службой

Рис. 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.
UDDI Каталог, который позволяет клиентам находить web-службы, предоставляемые конкретной компанией. UDDI является самым молодым среди стандартов web-служб

WSDL представляет собой стандарт, разработанный только для web-служб .NET. С целью обеспечения совместимости с другими платформами. При создании web-служб рекомендуется использовать формат SOAP, но допускается также применять методы POST и GET протокола HTTP. Спецификации DISCO и UDDI представляют собой необязательные расширения, которые облегчают публикацию и поиск информации о web-службах. Однако на сегодняшний день наиболее логичным способом передачи информации является HTTP -коммуникация, и нет смысла от нее отказываться.

К числу менее распространенных стандартов, используемых при создании web-служб, относится WS-Inspection - спецификация для поиска документов, в которых перечислены группы web-служб и их местонахождение. Эта спецификация была разработана совместными усилиями компаний Microsoft и IBM и предназначалась для замены протокола DISCO.

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

< Лекция 12 || Лекция 13: 12345 || Лекция 14 >