Web-службы как средство для всеобщего взаимодействия в Internet
Администраторам сетей Windows часто приходится слышать вопрос: как стратегия Microsoft .NET изменит мир? На самом деле далеко не все четко представляют себе, что такое .NET. В ряде статей мне встречались различные варианты ответов на этот вопрос, но, как правило, авторы смешивают технологию и маркетинг. Я думаю, пора оставить в стороне рекламную сторону вопроса и обратить внимание на технологию.
С точки зрения технологии особый интерес представляют новые протоколы и стандарты, объединенные под названием Web Services (Web-службы). Они являются ключевыми компонентами .NET. Web-службы должны значительно упростить работу пользователя, но в то же время они ставят перед нами новые задачи. Прежде чем углубляться в детали, рекомендую прочитать врезку «.NET как она есть».
Что же такое Web Services?
Средства массовой информации представляют Web-службы как результат очередного этапа развития Internet. Web-службы являются мощным средством, недаром многие ведущие поставщики решений для электронной коммерции (включая Microsoft, IBM, Sun Microsystems, Ariba) заявили о поддержке таких служб в своих продуктах. Благодаря обширной поддержке, Web-службы могут оказаться тем связующим элементом, который позволит объединить прикладные программы в различных сетях, интегрированных средах и операционных системах. Web Services имеют два несомненных достоинства. Во-первых, они обеспечивают более слаженное взаимодействие приложений в Internet. Во-вторых, они позволяют несовместимым платформам взаимодействовать более гладко, чем теперь.
Если посмотреть на современные приложения для Internet, можно сразу отметить множество общих элементов - несмотря на различия аппаратных и программных платформ, а также операционных систем. Большинство компаний использует для представления данных Web-сервер (Microsoft IIS, ASP). Например, при совершении покупки в Internet с помощью браузера можно просмотреть данные на HTML, созданные сервером в ответ на запрос. При этом Web-сервер обращается к базе данных (Microsoft SQL Server) непосредственно из страницы ASP или же через промежуточный сервер бизнес-логики. Бизнес-логика, формирующая алгоритм приложения сайта, реализована с помощью компонентов, разработанных на основе объектных моделей, COM или Java. Web-службы меняют эту модель, добавляя новые возможности.
Допустим, компания А создала сайт для представления прогнозов погоды в любой точке земного шара. При посещении этого сайта для получения прогноза в каком-либо городе пользователю приходится проходить через несколько форм. Теперь предположим, что я публикую на своем сайте информацию о путешествиях по всем странам мира и хочу там же представлять прогнозы погоды, предлагаемые компанией А. Сейчас я могу это сделать несколькими способами, но ни один из них нельзя назвать легким. Во-первых, я могу связать сайт компании А со своим через фрейм на моем сайте, передавая в этот фрейм запросы, сформированные посетителем моего сайта на основе предложенных вариантов. Во-вторых, я могу сформировать запрос и получить данные с сайта компании А в виде страницы HTML, затем проанализировать результат и представить эти данные на своем сайте. В-третьих, если компания А предлагает объектный компонент для получения необходимых данных, я могу использовать его для запроса соответствующих данных и представления их на своей странице. Третий способ проще остальных, но при этом для добавления новых возможностей к своему сайту мне придется каждый раз тратить время и деньги для переработки бизнес-логики и встраивания новых компонентов (схема представлена на Рисунке 1). А мне бы хотелось иметь возможность обратиться к бизнес-логике сервера компании А непосредственно из своего Web-приложения. Таким образом, мой сайт сможет представить пользователям необходимые данные без применения приведенных выше подходов к получению данных.
В этом и заключается суть Web Services, которые позволяют приложениям предлагать свои компоненты и в то же время использовать компоненты других приложений. Эта схема представлена на Рисунке 2.
SOAP
Приложения на базе Web-служб используют стандартный набор протоколов и служб для связи с другими приложениями. Приложение, реализующее Web-службу, создает удаленный объект и запрашивает удаленный метод на удаленном сервере Web-приложений, и этого можно было бы добиться с помощью Microsoft Distributed COM (DCOM), Java Remote Method Invocation (RMI) или Common Object Request Broker Architecture (CORBA) Internet Inter-ORB Protocol (IIOP). Вместо этих средств Web-службы используют протокол Simple Object Access Protocol (SOAP).
SOAP обеспечивает взаимодействие между объектами в формате XML, который не зависит от конкретной объектной технологии (COM, Java, CORBA), лежащей в основе объектов. На Рисунке 3 представлен протокол прохождения запроса SOAP, составленный в программе Network Monitor. В верхней панели содержатся HTTP-запросы приложения клиента (с отметкой LOCAL) к серверу Web-службы и ответы от него Web Services (помечен ROUTER, так как доступ к серверу осуществляется через маршрутизатор). В средней панели представлен выделенный пакет HTTP в развернутом формате. Обратите внимание на раскрытое описание HTTP-области из инспектируемого пакета. В нижней панели содержатся числовые значения рассматриваемого пакета.
Сообщение SOAP включает три основных компонента - конверт, заголовок и тело. Конверт идентифицирует закодированное сообщение в формате XML как стандартное сообщение XML. Заголовок содержит дополнительную информацию о сообщении, например сведения об аутентификации. Тело несет информацию, относящуюся к вызываемому приложением компоненту (т. е. ожидаемые параметры передаваемых и получаемых данных, а также описание типов данных для этих параметров).
Спецификация SOAP 1.2 в настоящее время находится в фазе рабочего проекта в консорциуме World Wide Web Consortium (W3C). Ведущие производители программного обеспечения, такие, как Microsoft и IBM, поддерживают в приложениях протокол SOAP 1.1 (хотя он пока не утвержден консорциумом W3C в качестве стандарта). Поэтому мое Web-приложение, написанное на C# или Visual Basic.NET (VB.NET), исполняемое на сервере .NET или на клиенте, может вызывать компоненты Java, исполняемые на IBM WebSphere Application Server - благодаря поддержке SOAP в IBM Web Services. И, естественно, я могу использовать SOAP для вызова компонентов .NET, исполняемых на сервере .NET, из приложения .NET, выполняемого на другом сервере .NET. Ранее подобная интероперабельность была невозможна.
Важной особенностью SOAP является возможность связывания с другими протоколами. Предложенная W3C спецификация SOAP описывает привязывание сообщений SOAP к протоколу HTTP. Совместимость с HTTP - второе важное преимущество SOAP как транспортного средства, служащего для взаимодействия между процессами, поскольку HTTP обычно легко передается через корпоративные межсетевые экраны. Также можно использовать HTTPS (HTTP c SSL, Secure Sockets Layer) для передачи между приложениями зашифрованных сообщений. Применение HTTP дает преимущества при организации коммуникаций между приложениями по модели запрос/ответ, которая является стандартной для удаленных вызовов Remote Procedure Call (RPC).
Однако если требуется организовать асинхронное взаимодействие объектов, HTTP использовать не стоит, поскольку объект после отправки запроса HTTP, прежде чем продолжить обработку следующих запросов, должен дождаться ответа. Производители программного обеспечения планируют задействовать в качестве транспорта для передачи сообщений SOAP другие протоколы, например SMTP (правда, пока такое связывание протоколов не закреплено стандартами).
Поиск и описание служб Web Services
В дополнение к использованию SOAP для формирования запросов при взаимодействии объектов и передачи этих запросов по сети, приложение должно иметь возможность находить нужные службы Web Services как во время выполнения, так и на этапе проектирования (разработки приложения). Кроме того, приложение должно узнавать о возможностях найденных Web-служб. Предположим, руководству некой компании, которая является владельцем портала финансовой информации, хотелось бы предоставлять клиентам изменения котировок в реальном времени. При этом нет желания или возможности разрабатывать собственную систему котировок. В данном случае можно сделать так, чтобы приложения во время работы обращались к центральному репозитарию в Internet и находили другие сайты, на которых соответствующие службы Web Services предоставляют информацию о котировках. Служба Universal Description, Discovery and Integration (UDDI - универсальное описание, обнаружение и интеграция) как раз и представляет собой такой репозитарий (более подробно о спецификации UDDI рассказано на сайте http://www.uddi.org). Реестр UDDI представляет собой каталог служб Web Services, к которому приложения могут обращаться в поисках подходящих служб Web Services. Microsoft предоставляет справочник UDDI и средства разработки (SDK) UDDI на сайте http://uddi.microsoft.com. Разработчики могут применять этот SDK для регистрации и поиска служб Web Services в справочнике Microsoft. UDDI для обнаружения служб Web Services использует в качестве транспортного средства SOAP. UDDI можно рассматривать как специализированный тип сообщений SOAP, предназначенный для поиска зарегистрированных в реестре UDDI служб Web Services.
После обращения к UDDI в поисках какой-либо службы Web Services разработчик должен иметь возможность получить описание найденной Web-службы в терминах, понятных проектируемому приложению. Для этого Microsoft, IBM и другие производители предлагают стандарт Web Services Description Language (WSDL - язык описания Web-служб). WSDL представляет собой стандарт документов XML, предназначенный для описания отдельных деталей Web-службы, включая формат принимаемых и передаваемых данных, имена и типы методов и функций, реализуемых службой, а также протоколы (скажем, HTTP), используемые при обмене.
Сопоставление стандартного документа WSDL и службы Web Services означает, что любое приложение, поддерживающее WSDL, может задействовать данную службу Web Services.
В действительности, WSDL является основным методом, который используют приложения .NET для объявления о предоставлении и применения служб Web Services.
Web Services и .NET Framework
Технологии .NET позволяют упростить задачу разработчика при создании и использовании служб Web Services. Помимо поддержки всех перечисленных выше протоколов и спецификаций - SOAP, UDDI и WSDL — специалисты Microsoft интегрировали поддержку служб Web Services в среду разработки Visual Studio (VS), а также в IIS и ASP.NET. Представленные в .NET службы Web Services имеют сходство со страницами ASP специализированного вида. Примечательно, что IIS и ASP.NET с помощью страниц с расширением .asmx могут сообщать о предоставляемых службах Web Services. Так, разработанная компанией А служба weatherservice может быть вызвана с использованием URL http://companya.com/mywebservices/ weatherservice.asmx.
Расширение .asmx означает assemblies — сборки (термин, используемый Microsoft для управляемых .NET приложений). IIS и ASP.NET «поймут», что приведенный в предыдущем абзаце адрес URL скрывает службу Web Services и что обращения по указанному адресу, вероятнее всего, представляют собой сообщения SOAP, которые система должна декодировать и доставить приложению .NET под названием weatherservice. Точно так же использующее эту службу Web Services приложение-клиент может представлять собой другой сервер .NET или приложение .NET конечного пользователя Windows, обмен сообщениями с которым осуществляется по протоколу SOAP.
Чтобы служба weatherservice могла использоваться в других приложениях, достаточно сформировать для нее файл WSDL, который сообщит заинтересованным разработчикам о наличии такой службы Web Services.
В Microsoft .NET Framework SDK содержится соответствующая утилита, wsdl.exe, которая обрабатывает файл WSDL и создает промежуточный (proxy) код для VB.NET, JScript.NET или C#, который может быть вызван из разрабатываемого приложения-клиента. Этот proxy-код сообщает, где искать службу Web Services (т. е. сообщает ее URL) и как к ней обращаться.
Средства безопасности служб Web Services
Каким же образом можно обеспечить надежность работы с конкретной службой Web Services, если на сайте содержатся не только HTML-данные? В конце концов, службы Web Services представляют собой конкретную бизнес-логику - интеллектуальную собственность компании, - реализованную как обычная страница в Internet. К сожалению, спецификация SOAP не предусматривает явно описанных механизмов аутентификации и авторизации конкретных служб Web Services. Так что задача выбора модели и обеспечения аутентификации и авторизации ложится на плечи разработчика службы Web Services. Впрочем, организовать такую модель несложно. Службы на сервере .NET выполняются как обычные страницы сервера IIS, что позволяет задействовать встроенные средства защиты. Можно задать анонимную, базовую или интегрированную аутентификацию Windows для виртуального каталога, в котором размещены службы Web Services. Предполагается, что к моменту официального выпуска .NET Microsoft обеспечит поддержку других средств аутентификации (например, цифровых сертификатов X.509).
Вне зависимости от выбранного метода аутентификации, вызывающее приложение должно иметь возможность передать необходимые свидетельства о своих полномочиях Web-серверу при обращении к службе Web Services. Эту задачу также решает утилита wsdl.exe при формировании промежуточного кода, используемого вызывающим приложением при обращении к службе Web Services. При запуске утилиты указывается URL нужной службы .asmx и необходимые для получения доступа имя пользователя и пароль. Если доступ к сайту службы Web Services осуществляется через proxy-сервер, следует также указать proxy-сервер для протокола HTTP.
Средства защиты сети
Современная корпоративная информационная инфраструктура применяет proxy-серверы и межсетевые экраны для защиты внутренней сети от вторжений из Всемирной паутины.
В этой броне можно проделать несколько дырочек, чтобы обеспечить использование сравнительно безопасных протоколов для работы браузеров (порты 80 и 443). Но тогда большинство протоколов, необходимых для построения полноценных распределенных приложений (в частности, DCOM и RMI), оказывается под запретом. На самом деле межсетевые экраны значительно затрудняют создание распределенных приложений, которые могли бы работать в корпоративном масштабе, что вынуждает разработчиков использовать для обмена между приложениями менее эффективные протоколы, такие, как HTTP.
Мы были свидетелями того, как считавшийся безобидным трафик электронной почты стал использоваться для различного рода вирусных атак - появились почтовые вирусы для Microsoft Outlook. Достоинства служб Web Services заключаются еще и в том, что теперь разработчики могут создавать надежные распределенные приложения с использованием стандартных протоколов, работе которых межсетевые экраны не мешают.
Конечно, эти новые возможности потребуют соблюдения дополнительных мер предосторожности. Большинство сетей имеет открытые порты с односторонним движением в своих межсетевых экранах: например, пользователи могут подключаться к внешним сайтам, но не наоборот. Так что разработчик использующего службы Web Services приложения может рассчитывать, что приложение будет нормально получать данные от внешних служб, при этом активный доступ из внешнего мира будет закрыт. Однако излишне доверчивые разработчики могут подключиться к сайту злоумышленника, и тот сможет пробраться во внутреннюю сеть. Необходимо обеспечить режим, при котором разработчики будут пользоваться только разрешенными службами Web Services. Следует добавить, что на уровне списков доступа маршрутизаторов и коммутаторов можно установить блокировку определенных заголовков SOAP на уровне протокола HTTP.
Мощь во благо
В заключение хочу сказать, что какой бы из подходов для управления этим новым механизмом разработки распределенных приложений вы ни выбрали, службы Web Services представляют собой исключительно мощную и гибкую модель для развития систем приложений в Internet. .NET предоставляет все необходимые технологии и инструментальные средства для достижения этих целей в среде Windows. Однако нужно всегда внимательнейшим образом следить, чтобы разработанные в конкретной организации и независимыми компаниями приложения работали как следует и не нарушали стабильное функционирование корпоративной сети.
Даррен Мар-Элиа — редактор журнала Windows & .NET Magazine. С ней можно связаться по адресу: dmarelia@winnetmag.net.
.NET как она есть
Первое, что следует помнить о Microsoft .NET, - это то, что данный термин не относится к конкретному продукту или услуге, а указывает на принадлежность к комплексу продуктов и услуг. Как правило, Microsoft использует термин .NET в отношении трех технологических областей.
.NET Framework SDK. Концептуальная основа .NET Framework SDK представляет собой набор объектно-ориентированных библиотек классов в сочетании со средой исполнения Common Language Runtime (CLR — общая среда исполнения промежуточного языка), которые в совокупности образуют ядро .NET. Базовые библиотеки классов .NET обеспечивают основной набор функций, позволяющих разработчику программного обеспечения выводить на консоль текст, выполнять поиск в каталоге AD, создавать основанные на формах приложения Windows и Web-службы - словом, выполняют функции классов JDK. Разумеется, разработчики могут расширять стандартные библиотеки классов и создавать собственные классы. CLR, в свою очередь, служит аналогом виртуальной машины Java. Приложения .NET (assemblies, сборки) компилируются в промежуточный язык (наподобие байт-кода Java). Для выполнения приложений .NET CLR производит JIT-компиляцию промежуточного языка в машинный.
Поддержка платформ .NET. Следующая составная часть технологий .NET включает в себя поддержку .NET Framework для различных операционных систем и программных пакетов производства Microsoft, в том числе Windows XP, Windows .NET Server (известный под названием Whistler), Application Center 2000, Microsoft BizTalk Server 2000, Exchange 2000 Server. Кроме того, следующий выпуск Active Server Pages (ASP) - ASP.NET будет выполнен как расширение Microsoft IIS. ASP.NET тесно связан с .NET Framework SDK и содержит расширенные версии многих из входящих в .NET Framework SDK библиотек классов для создания страниц Web для ASP. Библиотеки ASP.NET позволят разработчикам с помощью этих Web-страниц создавать консольные и графические приложения. В каких пределах каждая из перечисленных платформ будет поддерживать .NET, остается неясным. Например, все будущие версии операционных систем семейства Windows будут поставляться с предустановленными .NET Framework SDK и CLR, однако непонятно, какая еще поддержка .NET будет в них включена. Я подозреваю, что специалисты Microsoft все еще работают над этим вопросом.
.NET My Services. Третьим ключевым компонентом .NET является набор служб .NET My Services (кодовое название Hailstorm). Он представляет собой набор Web-услуг, которые должны повысить значимость модели Web-служб Microsoft для бизнеса и технологических компаний. Сюда входят службы аутентификации (Passport.NET), хранение пользовательских данных, уведомление (скажем, о резервировании билетов или назначении совещания). Запуская приложения, поддерживающие Web Services (т. е. будущие версии Microsoft Office), пользователи смогут подписаться на размещенные в Internet службы Microsoft .NET My Services, подключиться к поддерживающим эту технологию сайтам, сохранять личные данные в сети и взаимодействовать с другими приложениями и службами. Более подробно ознакомиться с продуктами, службами и услугами, входящими в .NET, можно на сайте Microsoft: www.microsoft.com/net/whatis.asp.