Разработка веб-служб средствами Java. Ильдар ХабибуллинРазработкаWebслужбсредствами
 Скачать 9.24 Mb.
|
|
ГЛАВА 2 Архитектура Web Services Широкое распространение Интернета началось после того, как была соз- дана "Всемирная паутина" WWW (World Wide Web, "Всемирный словарь Вебстера", если считать слово Web сокращением слова Webster). Она сде- лала получение информации из Интернета легким и приятным занятием. На каждой машине есть стандартный браузер: Mozilla, Opera, Internet Explorer, Netscape Communicator — выбирай, что нравится. Человек за- прашивает Web-страницу с любого сервера, включенного в WWW, нимало не интересуясь, на какой платформе работает Web-сервер, какой операци- онной системой он управляется, в каком порядке идут байты в его ма- шинных словах. Да и название и версия самого Web-сервера вовсе не ин- тересуют клиента. Ему достаточно набрать адрес URL, что-нибудь вроде или просто щелкнуть кнопкой мыши на гиперссылке. Браузер сам оформляет запрос по правилам протокола HTTP, устанавливает связь с сервером и передает ему запрос по сети. На машине-сервере запрос принимает Web-сервер, обычно прослушивающий порт номер 80. Сервер выполняет запрос и передает ответ в стандартном виде, по правилам протокола HTTP, не зависящим от платформы клиента и от браузера, которым пользуется клиент. Успех WWW основан на едином языке HTML, понятном любому браузеру, и на простом протоколе HTTP, легко реализуемом любым сервером. Успех языка HTML, в свою очередь, основан на том, что запись на нем ведется обычным байтовым который одинаково понимается всеми машинами. Его легко передать по сети без искажений и интерпретировать стандартным образом в браузерах. Серверы, включенные в систему WWW, готовы предоставить не только ста- тичную информацию, записываемую, в конце концов, HTML-файлами, 84 Разработка Web-служб средствами Java звуковыми файлами, файлами с изображениями и прочими файлами. Они могут предоставить свои программные средства — отдельные процедуры и целые объекты — для выполнения их удаленными клиентами, находящими- ся, может быть, по другую сторону Земли. Процедуры и объекты, которые сервер предоставляет всем нуждающимся в них клиентам, называются распределенными (distributed) процедурами и объ- ектами. С точки зрения клиента это удаленные (remote) процедуры и объек- ты. Технологии обращения к удаленным процедурам и объектам существуют давно. Более того, есть несколько различных технологий. В голову сразу приходит множество аббревиатур: RPC, DCOM, Однако их реализация ограничивается выбранной технологией: соке- тами BSD, технологией Java или Microsoft Windows. Только технология претендует на всеобщность, но это делает ее чрезвычайно громозд- кой и запутанной, потому что CORBA стремится использовать возможности всех или хотя бы наиболее распространенных платформ. Использование распределенных процедур началось на рубеже 80-х годов с создания в фирме Xerox механизма вызова удаленных процедур RPC (Remote Procedure Call). Суть RPC заключается в том, что на машину клиента вместо вызываемой процедуры пересылается небольшой про- граммный код, называемый заглушкой (stub). Заглушка внешне выглядит как вызываемая процедура, но ее код не выполняет процедуру, а преоб- разует (marshall) ее аргументы к виду, удобному для пересылки. Такое преобразование называется сборкой (marshalling). После сборки заглушка устанавливает связь с сервером по понятному для него протоколу и пере- сылает собранные аргументы на сервер. Клиент, вызвавший удаленную процедуру, взаимодействует не с ней, а с заглушкой, как с обычной ло- кальной процедурой, выполняющейся на его машине. Сервер, получив собранные аргументы процедуры, разбирает их, вызывает процедуру, передает ей параметры, дожидается результата, собирает (marshall) его и пересылает заглушке. Заглушка снова разбирает (unmarshall) результат и передает его клиенту как обычная локальная процедура. Эффективно реализовать механизм RPC совсем не просто. Значительная часть толстой книги [10] посвящена методам вызова распределенных проце- дур и методов распределенных объектов. Различные реализации RPC и дру- гих способов вызова удаленных процедур и объектов стремились ускорить работу удаленных процедур и придумывали изощренные и наиболее быст- рые алгоритмы и форматы сборки аргументов. В результате эти форматы могли применяться только в данной реализации RPC. Тем временем компьютерные сети развивались и улучшались, на предпри- ятиях стали широко применяться распределенные приложения, и понадо- билось эффективное взаимодействие распределенных объектов. Глава 2. Архитектура Web Services 85 Напомним [10], что распределенным называется приложение, отдельные компоненты которого работают на разных компьютерах и используют раз- ные сетевые средства, но взаимодействуют так, что приложение выглядит как единое целое, как будто все его компоненты расположены на одной машине. Простейшая архитектура распределенного приложения, называемая архи- тектурой клиент-сервер, предполагает, что приложение состоит из двух час- тей: серверной части, оказывающей услуги, и клиентской части, пользую- щейся услугой. В Web-приложении, построенном по архитектуре клиент- сервер, услуги оказывает Web-сервер, а клиентом служит браузер, или текстовый редактор, подключенный к Интернету, или другое клиентское приложение, связанное с Web-сервером как показано на рис. 2.1. Клиент Сервер Запрос Протокол HTTP Ответ Браузер о о / Web-сервер Рис. 2 . 1 . Архитектура клиент-сервер в WWW В архитектуре клиент-сервер очень важно правильно разделить работу меж- ду клиентом и сервером. Можно сделать клиента "тонким", только отобра- жающим результаты запроса. Это удобно для организации клиента. Его можно разместить на простейшем дешевом компьютере. Ему не нужно сложного программного обеспечения, в большинстве случаев достаточно обыкновенного браузера. Но тогда сервер становится "толстым", на него ложится большая нагрузка, ему приходится выполнять все запросы к источ- нику данных и всю обработку этих данных. Сервер не справляется с нагруз- кой, его трудно модернизировать, обновлять, неудобно наращивать его Можно, наоборот, сделать клиента "толстым", выполняющим всю обработку результатов запроса, а сервер "тонким", только рассылающим необработан- ные данные клиентам. Так организован классический обмен информацией WWW между "толстыми" браузерами и "тонкими" Web-серверами. В этом случае для клиента требуется мощный дорогостоящий компьютер. В случае смены алгоритма обработки данных или обнаружения ошибок придется об- новлять программное обеспечение на всех клиентских машинах. Для того чтобы избавиться от этих недостатков архитектуры клиент-сервер, программы, которые обрабатывают данные, выделяют в отдельный, кроме- 86 Разработка Web-служб средствами Java (middleware) слой программного обеспечения. Этот слой может работать на той же машине, что и серверный слой, работать на другой ма- шине или даже на нескольких машинах. Распределенное приложение стано- вится трехслойным. В технологии Java промежуточный слой обычно реали- зован сервером приложений (application server). Выпускается много промыш- ленных серверов приложений: BEA WebLogic, JBoss, IBM WebSphere, Sun ONE Application Server, Application Server, Sybase EAServer, Orbix E2A, Borland Enterprise Server и другие. В технологии Microsoft Corporation это сервер IIS (Internet Information Services). Очень часто промежуточный слой делится на две части. Одна часть взаимо- действует с клиентом: принимает запросы, анализирует их, формирует ответ на запрос и отправляет его клиенту. В технологии Java это Web-слой — сервлеты и страницы JSP. Другая часть промежуточного слоя получает дан- ные от серверного слоя и обрабатывает их, руководствуясь указаниями, по- лученными от Web-слоя. В технологии Java это EJB-слой — компоненты EJB. Такая схема показана на рис. 2.2. Клиент Промежуточный слой Сервер Запрос Ответ Браузер Приложение Web-слой EJB-слой Сервлет JSP S e s s i o n B e a n E n t i t y B e a n Сервер приложений Рис. 2.2. Многослойная архитектура База данных Количество слоев можно увеличивать, но важнее установить надежную и бы- струю связь между всеми компонентами распределенного приложения. Каза- лось бы, надо воспользоваться старыми проверенными средствами: RPC, DCOM, но тогда компоненты оказываются намертво привя- занными к выбранной технологии, и мы получаем тесно связанное (tightly coupled) распределенное приложение. Это хорошо, если все компоненты соз- даны для одной платформы, но такая ситуация редко встречается в Интерне- те. Гораздо чаще компоненты распределенного приложения работают на раз- ных платформах: клиентская часть разработана для MS Windows, Linux или Apple Macintosh, серверная часть — для Solaris, Linux, Free BSD, HP UX, для других UNIX или для мейнфреймов. Более того, сейчас наблюдается яв- ная тенденция создавать приложения, независимые от какой бы то ни было платформы. Вся технология Java создана в русле этой тенденции. Распределенное приложение, компоненты которого могут работать на разных платформах и заменять друг друга, называется слабо связанным (loosely Глава 2. Архитектура Web coupled) приложением. Например, браузер и Web-сервер слабо связаны друг с другом. Они не только могут работать на разных платформах, но и обмени- ваются самой разной информацией с разными Кроме того, связь между ними очень коротка, она состоит только из запроса и ответа. Фактически, общее у браузера и Web-сервера только то, что они работают по одному протоколу HTTP и то, что они должны быть на связи одновременно. Для слабо связанных приложений необязательно даже последнее условие. Они могут работать асинхронно, их компоненты могут выходить на связь в удобное для них время. Так работает электронная почта, которую можно счи- тать классическим примером слабо связанного приложения. Создатели Web Services решили, что Web-услуги будут предоставляться в рамках слабо связанных приложений. Они решили опереться только на об- щие средства, имеющиеся на всех платформах. Таким "наименьшим общим знаменателем" различных вычислительных платформ, использующих WWW, оказался язык HTML и протокол HTTP. Языка HTML явно недостаточно для описания вызовов распределенных процедур и методов распределенных объектов и тут на выручку приходит язык Действительно, он не зави- сит от платформы. Средства обработки документов XML, как мы убедились в предыдущей главе, имеются на всех платформах. Документы XML легко передаются по сети любым прикладным протоколом, поскольку это просто байтовый ASCII-текст. Таким образом, Web Services — это услуги, предоставляемые WWW с использованием той или иной реализации языка XML, протокола HTTP или других Web-протоколов. Есть множество определений этого понятия. Каждая фирма, разрабатывающая Web Services, дает свое определение Web-услуг. Мне показалось наиболее точным определение, которое дал консорциум W3C в документе "Требования к архитектуре Web Services", http://www.w3.org/TR/wsa-reqs. Его стоит привести в оригинале: "A Web service is a software application identified by a whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via internet-based protocols". Вот дословный перевод: "Web Service — это приложение, идентифицируемое строкой URI, интер- фейсы и связи которого могут определяться, описываться и отыскиваться документами XML. Оно взаимодействует напрямую с другими приложения- ми по межсетевым протоколам с помощью сообщений, записанных на язы- ке По этому определению Web Service — это не всякая услуга, оказываемая посредством Web-технологии. Пересылка файлов, даже XML-документов, к ней не относится. Обычными Web-услугами пользуются независимые при- ложения: браузеры, связанные с Web-сервером только на время оказания 88 Разработка Web-служб средствами Java услуги. В отличие от них услуги, названные Services", предоставляют- ся, как правило, в рамках распределенного приложения. Можно сказать, что обычные Web-услуги предоставляются клиенту-человеку, a Web Services — это услуги, оказываемые клиенту-программе. Как правило, Web Service применяется как компонент распределенной информационной сис- темы, разбросанной по компьютерам с разной архитектурой и разными средствами сетевой связи. При описании всякой новой технологии возникает вопрос о переводе анг- лийских терминов. Поскольку русский перевод термина "Web Service" еще не устоялся, будем в этой книге записывать и без перевода ("Web Service"), и словом "Web-служба", а каждую отдельную услугу, предостав- ляемую данной Web-службой, будем называть "Web-услугой". Итак, для удобства предоставления Web-услуг необходим эффективный протокол пересылки информации, основанный на XML. Все началось с очень простого протокола XML-RPC, оформленного как реализация языка XML. Рассмотрим его подробнее. Протокол XML-RPC Самое простое применение языка XML для сборки аргументов вызываемой удаленной процедуры, и пересылки результатов ее работы было сделано в 1999 году Дейвом Винером (Dave Winer), который вместе со своими друзья- ми создал протокол XML-RPC — реализацию XML и написал специфи- кацию XML-RPC. Она доступна по адресу http://www.xmlrpc.com/spec. В том же году был написан сервер XML-RPC, названный Frontier С тех пор написано множество клиентов и сер- веров XML-RPC на разных языках: Java, Perl, Python, C/C++, Ruby. Спецификация XML-RPC очень проста, она вводит не более двадцати эле- ментов XML. Пусть мы хотим получить прогноз погоды на завтра и обращаемся к процедуре public String location); выполняющейся на сервере метеослужбы. В процедуру заносится название местности location, она возвращает строку с прогнозом. Код процедуры нас сейчас не интересует. Собранные по протоколу XML-RPC аргументы вызова этой удаленной про- цедуры, готовые к пересылке на сервер, выглядят так: Глава 2. Архитектура Web Services 89 Корневой элемент вызова удаленной процедуры называется В него вложен элемент в теле которого записывается имя процедуры, и необязательный элемент тело которого содержит список аргументов процедуры. Тело элемента содержит строку символов, состоящую из букв арабских цифр 0—9, знаков подчеркивания, точек, двоеточий и слешей. В элемент вложены нуль или несколько элементов , опи- сывающих аргументы процедуры. Каждый элемент описывает один аргумент процедуры вложенным элементом В него вкладывается элемент, описывающий тип аргу- мента. В табл. 2.1 приведен список этих элементов. Таблица Типы аргументов Элемент Тип < s t r i n g > Строка символов ASCII . iso8 601> Дата и время в формате < s t r u c t > Структура 90 Разработка Web-служб средствами Java По умолчанию аргумент относится к типу Как видно из таблицы 2.1, аргумент процедуры может быть массивом или структурой. Аргумент-массив выглядит так: В элемент поэтому порядок их записи очень важен. Аргумент-структура оформляется в следующем виде: Структура подобна структуре языка С или записи языка Pascal. Она состоит из нескольких членов, описываемых элементами Глава 2. Архитектура Web Services 91 Собранные аргументы процедуры в виде документа XML с корневым эле- ментом пересылаются серверу по протоколу HTTP методом POST с типом содержимого Content-Type: Сервер оформляет ответ, содержащий результат выполнения процедуры, как документ XML вида В случае удачного выполнения процедуры в корневой элемент ответа вкладывается один элемент , содержащий один элемент с единственным элементом Если при выполнении процедуры возникли ошибки, то в элемент В этом случае ответ выглядит так: r> 92 Разработка Web-служб средствами Java В элемент вкладывается элемент содержащий структуру с двумя членами, имеющими фиксированные имена и Эти члены содержат целочисленный код ошибки и строковое сообщение об ошибке. Спецификация не определяет никакие коды ошибок — это остается на долю реализации протокола. Вот и все описание протокола XML-RPC. Как видите, он предельно прост, но описан неточно. Его спецификация не дает даже описания DTD опреде- ленных в ней элементов XML. При таком расплывчатом описании клиент- скую и серверную части, реализующие этот протокол, должна делать одна команда программистов, одинаково понимающих все недоговоренности спецификации. Кроме того, средств протокола XML-RPC явно недостаточно для вызова процедур со специфичными типами аргументов, с аргументами по умолча- нию. Еще менее он приспособлен для вызова методов распределенных объ- ектов. Поэтому теми же авторами в то же время был создан протокол SOAP. Протокол SOAP Протокол SOAP возник в 1998 году в фирме UserLand и корпорации Microsoft, но затем его разработка была передана в консорциум W3C, кото- рый и готовит сейчас рекомендации по его применению. Их можно посмот- реть на странице проекта http://www.w3.org/TR/SOAP/. Протокол SOAP не различает вызов процедуры и ответ на него, а просто определяет формат послания (message) в виде документа XML. Послание может содержать вызов процедуры, ответ на него, запрос на выполнение каких-то других действий или просто текст. Спецификацию SOAP не инте- ресует содержимое послания, она задает только его оформление. Корневой элемент посылаемого документа XML содержит не- обязательный заголовок |