Главная » Java, Web, XML » Архитектура Web Services

0

Широкое распространение Интернета началось после того, как была создана "Всемирная паутина" 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-файлами, звуковыми файлами, файлами с изображениями и прочими файлами. Они могут предоставить свои программные средства — отдельные процедуры и целые объекты — для выполнения их удаленными клиентами, находящимися, может быть, по другую сторону Земли.

Процедуры и объекты, которые сервер предоставляет всем нуждающимся в них клиентам, называются распределенными (distributed) процедурами и объектами. С точки зрения клиента это удаленные (remote) . процедуры и объекты. Технологии обращения к удаленным процедурам и объектам существуют давно. Более того, есть несколько различных технологий. В голову сразу приходит множество аббревиатур: RPC, RMI, DCOM, СОМ+, CORBA, Однако их реализация ограничивается выбранной технологией: соке- тами BSD, технологией Java или Microsoft Windows. Только технология CORBA претендует на всеобщность, но это делает ее чрезвычайно громоздкой и запутанной, потому что CORBA стремится использовать возможности всех или хотя бы наиболее распространенных платформ.

Использование распределенных процедур началось на рубеже 80-х годов с создания в фирме Xerox механизма вызова удаленных процедур RPC (Remote Procedure Call). Суть RPC заключается в том, что на машину клиента вместо вызываемой процедуры пересылается небольшой программный код, называемый заглушкой (stub). Заглушка внешне выглядит как вызываемая процедура, но ее код не выполняет процедуру, а преобразует (marshall) ее аргументы к виду, удобному для пересылки. Такое преобразование называется сборкой (marshalling). После сборки заглушка устанавливает связь с сервером по понятному для него протоколу и пересылает собранные аргументы на сервер. Клиент, вызвавший удаленную процедуру, взаимодействует не с ней, а с заглушкой, как с обычной локальной процедурой, выполняющейся на его машине. Сервер, получив собранные аргументы процедуры, разбирает                                                                                  их, вызывает

процедуру, передает ей параметры, дожидается результата, собирает (marshall) его и пересылает заглушке. Заглушка снова разбирает (unmarshall) результат и передает его клиенту как обычная локальная процедура.

Эффективно реализовать механизм RPC совсем не просто. Значительная часть толстой книги [10] посвящена методам вызова распределенных процедур и методов распределенных объектов. Различные реализации RPC и других способов вызова удаленных процедур и объектов стремились ускорить работу удаленных процедур и придумывали изощренные и наиболее быстрые алгоритмы и форматы сборки аргументов. В результате эти форматы могли применяться только в данной реализации RPC.

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

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

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

Рис. 2.1. Архитектура клиент-сервер в WWW

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

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

Для того чтобы избавиться от этих недостатков архитектуры клиент-сервер, программы, которые обрабатывают данные, выделяют в отдельный, кроме- жуточный (middleware) слой программного обеспечения. Этот слой может работать на той же машине, что и серверный слой, работать на другой машине или даже на нескольких машинах. Распределенное приложение становится трехслойным. В технологии Java промежуточный слой обычно реализован сервером приложений (application server). Выпускается много промышленных серверов приложений: BEA WebLogic, JBoss, IBM WebSphere, Sun ONE Application Server, Oracle9i Application Server, Sybase EAServer, IONA Orbix E2A, Borland Enterprise Server и другие. В технологии Microsoft Corporation это сервер IIS (Internet Information Services).

Очень часто промежуточный слой делится на две части. Одна часть взаимодействует с клиентом: принимает запросы, анализирует их, формирует ответ на запрос и отправляет его клиенту. В технологии Java это Web-слой — сервлеты и страницы JSP. Другая часть промежуточного слоя получает данные от серверного слоя и обрабатывает их, руководствуясь указаниями, полученными от Web-слоя. В технологии Java это EJB-слой — компоненты EJB. Такая схема показана на рис. 2.2.

Рис. 2.2. Многослойная архитектура

Количество слоев можно увеличивать, но важнее установить надежную и быструю связь между всеми компонентами распределенного приложения. Казалось бы, надо воспользоваться старыми проверенными средствами: RPC, RMI, DCOM, CORBA, но тогда компоненты оказываются намертво привязанными к выбранной технологии, и мы получаем тесно связанное (tightly coupled) распределенное приложение. Это хорошо, если все компоненты созданы для одной платформы, но такая ситуация редко встречается в Интернете. Гораздо чаще компоненты распределенного приложения работают на разных платформах: клиентская часть разработана для MS Windows, Linux или Apple Macintosh, серверная часть — для Solaris, Linux, Free BSD, AIX, HP UX, для других UNIX или для мейнфреймов. Более того, сейчас наблюдается явная тенденция создавать приложения, независимые от какой бы то ни было платформы. Вся технология Java создана в русле этой тенденции.

Распределенное приложение, компоненты которого могут работать на разных платформах и заменять друг друга, называется слабо связанным (loosely coupled) приложением. Например, браузер и Web-сервер слабо связаны друг с другом. Они не только могут работать на разных платформах, но и обмениваются самой разной информацией с разными MIME-типами. Кроме того, связь между ними очень коротка, она состоит только из запроса и ответа. Фактически, общее у браузера и Web-сервера только то, что они работают по одному протоколу HTTP и то, что они должны быть на связи одновременно. Для слабо связанных приложений необязательно даже последнее условие. Они могут работать асинхронно, их компоненты могут выходить на связь в удобное для них время. Так работает электронная почта, которую можно считать классическим примером слабо связанного приложения.

Создатели Web Services решили, что Web-услуги будут предоставляться в рамках слабо связанных приложений. Они решили опереться только на общие средства, имеющиеся на всех платформах. Таким "наименьшим общим знаменателем" различных вычислительных платформ, использующих WWW, оказался язык HTML и протокол HTTP. Языка HTML явно недостаточно для описания вызовов распределенных процедур и методов распределенных объектов и тут на выручку приходит язык XML. Действительно, он не зависит от платформы. Средства обработки документов 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 URI, 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. Оно взаимодействует напрямую с другими приложениями по межсетевым протоколам с помощью сообщений, записанных на языке XML".

По этому определению Web Service — это не всякая услуга, оказываемая посредством Web-технологии. Пересылка файлов, даже XML-документов, к ней не относится. Обычными Web-услугами пользуются независимые приложения: браузеры, связанные с Web-сервером только на время оказания услуги. В отличие от них услуги, названные "Web Services", предоставляются, как правило, в рамках распределенного приложения. Можно сказать, что обычные Web-услуги предоставляются клиенту-человеку, a Web Services — это услуги, оказываемые клиенту-программе. Как правило, Web Service применяется как компонент распределенной информационной системы, разбросанной по компьютерам с разной архитектурой и разными средствами сетевой связи.

При описании всякой новой технологии возникает вопрос о переводе английских терминов. Поскольку русский перевод термина ‘Web Service" еще не устоялся, будем в этой книге записывать его и без перевода ("Web Service"), и словом "Web-служба", а каждую отдельную услугу, предоставляемую данной Web-службой, будем называть "Web-услугой".

Итак, для удобства предоставления Web-услуг необходим эффективный протокол пересылки информации, основанный на XML. Все началось с очень простого протокола XML-RPC, оформленного как реализация языка XML. Рассмотрим его подробнее.

Литература:

Хабибуллин И. Ш. Разработка Web-служб средствами Java. — СПб.: БХВ-Петербург, 2003. — 400 с: ил.

По теме:

  • Комментарии