Тема номера: Web-сервисы

Куасси Менсах

База данных и Web-сервисы
(WEB services enable Your Database,
by Kuassi Mensah)

Если ты не идешь к Лагардеру, то Лагардер придет к тебе.
("Si tu ne vas pas à Lagardère, Lagardère ira à toi!")
Александр Дюма,
“Ле Босси” ("Le Bossu")

Источник: журнал Web-Services Journal ( www.sys-con.com/webservices), no.3, 2004,
http://www.sys-con.com/webservices/archives/0304/mensah, а также
http://www.sys-con.com/webservices/articleprint.cfm?id=515

Превратите вашу базу данных в поставщика и потребителя Web-сервисов.

На караул! Что общего имеют Web-сервисы с фехтовальщиками? Перефразируя высказывание персонажа Александра Дюма, можно сказать: "Если вы не идете к Web-сервисам, Web-сервисы придут к вам". Ведь Web-сервисы проникают на каждый уровень корпоративных вычислений – от пакетированных приложений электронной коммерции (например, ERP и CRM) к промежуточному уровню (например, J2EE и .NET) и до инфраструктуры базы данных.

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

Быстрое распространение в базах данных структурированных и неструктурированных данных и логики данных, постоянно растущее значение XML как формата обмена данными, фактическое принятие HTTP как повсеместно используемого транспортного механизма – в контексте гетерогенных сред – пробудило интерес к Web-сервисам для баз данных. Например, во многих приложениях имеется значительное количество бизнес-логики (типа PL/SQL-пакетов), которая выполняется внутри базы данных. Web-сервисы базы данных позволяют организациям усилить использование подобных ранее сделанных инвестиций.

Web-сервисы базы данных работают в двух направлениях. База данных может выступать в роли провайдера сервисов (услуг). В этом случае вызовы идут из внешнего мира в базу данных, что позволяет приложениям-клиентам обращаться к базе данных через механизмы Web-сервисов. Однако база данных может выступать и в роли потребителя сервисов, и тогда вызовы идут из базы данных во внешний мир, что позволяет SQL-запросу или модулю приложения использовать в сеансе с базой данных внешний Web-сервис. В этой статье делается попытка рассмотреть преимущества и выгоды от превращения вашей базы данных в действующее лицо на сцене Web-сервисов.

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

База данных как провайдер сервисов

Мотивация

Почему вы намереваетесь представить операции данных в виде набора Web-сервисов? Что будет, если бы вы смогли представить имеющиеся хранимые процедуры как Web-сервисы? Когда вы должны рассматривать Web-сервисы базы данных, а когда рассматривать Web-сервисы промежуточного уровня (J2EE, .NET)?

Многие организации считают предоставление имеющихся у них данных и логики данных, выполняющейся в базе данных, Web-сервисами (как для внутренней, так и для внешней аудитории). Взгляните на широко известные Web-сервисы компаний Amazon (www.amazon.com/webservices) или Google (www.google.com/apis/index.html). Они позволяют приложениям-клиентам обнаруживать свои каталоги и поисковые серверы, используя стандартные протоколы Web-сервисов (WSDL, SOAP). Вообще говоря, при рассмотрении обстоятельств, в которых должны быть развернуты Web-сервисы базы данных, должны быть соблюдены правила разделения приложения между промежуточным уровнем и базой данных. Бизнес-логика, связанная с Web-сервисами, наиболее естественно смотрится на промежуточном уровне, а логика данных – на уровне базе данных. Это разделение интересов уменьшает сложность приложения; увеличивает его защищенность, возможности повторного использования и эффективность доступа к данным, а также ограничивает воздействие, оказываемое на приложение изменениями в схеме.

Рассмотрим в качестве примера хранимые процедуры. Хранимые процедуры являются основной моделью программирования базы данных, позволяющей выполнить четкое разделение ориентированной на данные логики, которая выполняется в базе данных, и бизнес-логики, которая выполняется на промежуточном уровне. Представление хранимых процедур как Web-сервисов – это более рентабельный, более безопасный, более понятный и более эффективный выбор, чем предъявление компоненты промежуточного уровня.

Архитектура: инфраструктура провайдера сервисов и механизм обращения к сервисам

Как часть своих всеобъемлющих предложений Web-сервисов, все главные производители баз данных, включая Oracle, IBM и Microsoft, теперь предлагают доступ к своим базам данных через механизмы Web-сервисов (SOAP, WSDL, UDDI). В настоящее время все они усиливают использование имеющегося промежуточного уровня инфраструктуры Web-сервисов. Пример приведен на рисунке 1.

База данных DB2 компании IBM также использует для обработки кодирования/декодирования SOAP промежуточный уровень, но для определения операций базы данных, которые должны быть представлены как Web-сервисы, использует подход на основе файла. База данных Microsoft SQL Server использует набор инструментария SQL Server 2000 Web Service Toolkit. При этом требуется многошаговый процесс, состоящий из определения операций базы данных, которые будут представлены как Web-сервисы, конфигурирования виртуального имени SOAP и определения папки IIS, связывающей виртуальное имя SQLXML с подпапкой IIS.

API базы данных для реализации Web-сервисов базы данных

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

• Запросы SQL и операторы языка DML: здесь пределом служит только небо. SQL предлагает удивительные возможности для поиска, обновления и сохранения любых данных, которые могут иметься в вашей базе данных, включая реляционные, текстовые, пространственные, мультимедиа данные и XML-данные. Но давайте не упустим главного: Web-сервисы – это вовсе не новый или модный способ представления SQL-операторов вашей базе данных и не замена шлюзам. Вопрос о реализации крупномодульных сервисов, использующих SQL-операторы, вы должны рассматривать только в тех случаях, когда их преимущества перевешивают накладные расходы SOAP. Web-сервисы базы данных на основе SQL работают с приложениями-клиентами и упрощенными SOAP-приспособлениями, чтобы, к примеру, сделать запрос к каталогу или найти карту местности, исходя из известного почтового индекса (ZIP-кода).
• API XML: интеграция XML с реляционными базами данных делает возможным хранение, индексацию и поиск слабоструктурированных и неструктурированных данных. В зависимости от уровня интеграции, XML-документы могут быть сохранены или естественным образом, или через XML-представления над реляционными структурами. Web-сервисы базы данных для XML позволят приложениям-клиентам (например, настольным инструментальным средствам), отыскивать XML-документы, локально делать в них изменения, а затем синхронизировать их обратно с базой данных на сервере. К тому же, такой подход скрывает от потребителя сервисов сложность API XML и не дает поводов для беспокойства по поводу хранения и индексации данных.
• Хранимые процедуры и определяемые пользователем функции: Хранимые процедуры являются основной моделью программирования базы данных, позволяющей четко разделять логику, ориентирующуюся на данные, которая выполняется в базе данных, и бизнес-логику, которая выполняется на промежуточном уровне. Хранимые процедуры могут быть запрограммированы на языке конкретной базы данных, например, на PL/SQL или на переносимом и независимом от базы данных языке типа Java. Часть 1 стандарта ANSI SQLJ определяет возможность вызывать статические методы Java из SQL как процедуры или функции. Красота Web-сервисов состоит в том, что вы можете усилить использование сделанных вами инвестиций в хранимые процедуры и представить их как Web-сервисы, не имея необходимости волноваться о языке, на котором реализованы хранимые процедуры.
• API обмена сообщениями и организации очередей базы данных: API Web-сервисов может использоваться для представления операций AQ: постановка/исключение сообщений в очередь и регистрация уведомлений; сбор и распространение операций по изменению базы данных и предоставление доступа к операциям администрирования очередей.

Поговорим о проблемах Web-сервисов

Как Web-сервисы базы данных решают общие проблемы Web-сервисов, скажем, проблемы отображения типов данных, обеспечения безопасности, транзакций и способности к взаимодействию?

• Отображения типов данных: Создание XML-документов из типов базы данных требует наличия некоторых метаданных. О простых SQL-типах позаботились, создав для них универсальную или предопределенную XML Schema. Сложные типы базы данных (вроде Resultset, JDBC WebRowset, ADO Datasets) и другие проприетарные (составляющие чью-то собственность) иерархические формы данных будут отображаться через особую XML Schema. Появление в JDBC и .NET выталкивающего синтаксического анализатора (Pull parser) и программы записи выходных данных XML (XML writer) улучшит и упростит создание документов XML и их синтаксический анализ.
• Обеспечение безопасности: Так как бизнес-данные являются самым ценным корпоративным активом, управление безопасностью данных представляется критичным требованием. Для Web-сервисов базы данных это требование можно разрешить, усиливая инфраструктуру безопасности Web-сервисов, а также механизмы безопасности базы данных, типа контроля над фактическими пользователями базы данных или над схемой в исполнительном периоде и ограничения разрешенных операций при реализации сервисов.
• Транзакции: Так как стандарты для проведения транзакций, как Web-сервисов к базе данных, к промежуточному уровню и пакетированным приложениям продолжают развиваться, операторы языка DML (модификация, вставка и удаление), представленные как Web-сервисы, будут автоматически фиксироваться (commit) без какого-либо распространения контекста транзакции через вызовы, а в операторах модификации будет использоваться оптимистическая блокировка.
• Способность к взаимодействию: Web-сервисы базы данных могут использовать как средство для достижения цели характеристики способности к взаимодействию для промежуточного уровня. Например, выполняющиеся в базе данных Oracle9i Web-сервисы, используют сервер приложений Oracle9i, чтобы извлечь выгоду из встроенной способности к взаимодействию, основанной на способности к взаимодействию Web-сервисов (WS-I) и действиях SOAPBuilder.

База данных как потребитель сервисов

Мотивация – сценарий

Реляционные базы данных распространяют свои возможности хранения, индексации и поиска на слабоструктурированные и неструктурированные данные, в дополнение к предоставлению объединенных данных, например из гетерогенных и внешних источников, включая Web-сервисы. Возможность вызывать Web-сервисы позволяет базам данных отслеживать, агрегировать, освежать (обновлять) и делать запросы к динамическим данным, а также к данным, произведенным по требованию, типа курсов акций, курсов обмена валют, процентных ставок, таблиц налогов IRS (внутренней налоговой службы США), научных данных и информации о погоде. Например, можно спланировать задание базы данных, которое будет выполняться с предварительно заданной частотой, и вызывать внешние Web-сервисы, возвращающие инвентаризационную информацию от несколько поставщиков и обновляющие локальную базу данных по инвентаризации. Другим примером является Web Crawler (Червяк - жаргонное название механизма поиска в WWW – словарь Lingvo): можно запланировать работу (job) базы данных, которая сопоставляет информацию о продукте и ценах на него из множества источников.

Архитектура: инфраструктура потребителя сервисов

Для потребления данных от внешних Web-сервисов требуются следующие шаги:

• построение сообщения SOAP, базирующегося на конечной точке Web-сервиса;
• посылка сообщения SOAP по HTTP к конечной точке Web-сервиса;
• получение ответа SOAP;
• извлечение результирующих данных из тела сообщения SOAP и
• обработка ошибок и исключительных ситуаций.

К числу архитектурных проблем, о которых вы должны знать, относятся:

• Инфраструктура, не готовая к работе с SOAP: Этот основной подход, используемый некоторыми продавцами баз данных, требует, чтобы определяемые пользователем функции с точки зрения программы строили SOAP-подобный XML-текст (оболочка SOAP является главным образом статической), и посылали его по HTTP, а затем подвергали синтаксическому анализу и расчленяли ответ SOAP. Такой подход может оказаться приемлемым, если вы наперед знаете все о Web-сервисе и его формате, и если вы желаете читать и интерпретировать спецификацию сервиса WSDL самостоятельно. Это требует некоторых навыков программирования, но может быстро стать трудоёмким и громоздким делом.
• Инфраструктура, готовая к работе с SOAP: Более гибкая альтернатива должна использовать имеющийся стек клиента SOAP, который понимает WSDL. Например, база данных Oracle позволяет загружать Java-библиотеки, типа клиента Apache SOAP или JAX-RPC компании Sun, позволяя вам динамически взаимодействовать с Web-сервисом или использовать предварительно сгенерированный код прокси-клиента. Для обновления стека SOAP достаточно просто загрузить более новую версию.
• Статические вызовы: Для вызова Web-сервисов может быть получен предварительно сгенерированный прокси-клиент, который будет использоваться базой данных. Прокси-клиент упрощает вызовы Web-сервиса, поскольку он точно знает, где расположен этот сервис, и не ищет его в системном реестре UDDI, а также выполняет всю работу по созданию запроса SOAP, и упорядочению и разупорядочению параметров. Как только вы создали экземпляр прокси, вы можете вызывать с него требующиеся операции Web-сервиса.
• Динамические вызовы: Статический вызов является самым общеупотребительным стилем вызова. Однако, он требует загрузки предварительно сгенерированного прокси. Динамический вызов обеспечивает возможность динамически создавать запросы SOAP и обращаться к сервису без прокси-клиента.

SQL по SOAP

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

• Потребление внешних Web-сервисов – вызовы функций: Сеанс базы данных вызывает Web-сервис с помощью определяемого пользователем вызова функции или непосредственно в составе оператора SQL или представления, или через переменную (см. рисунок 2).

X := getTemp(zipcode) SELECT city_name, getTemp(zipcode) FROM ... WHERE ...

CREATE VIEW city_temp AS SELECT city_name, getTemp(zipcode) FROM ...

• Виртуальные таблицы – интеллектуальный анализ динамических данных: Что произойдет, если из Web-сервиса будет возвращено несколько значений? А что получится, если вы захотите отследить и реализовать диапазон значений, возвращенных рядом вызовов функции из Web-сервиса, как таблицу SQL или структуру представления? Как могут использоваться в реальной жизни виртуальные таблицы? Рассмотрите следующие два сценария:
  • Сценарий 1: Вычисление агрегированных значений: Внедряется приложение для агрегирования некоторых значений температуры по некоторому множеству городов. Приложение может быть реализовано как процедура запоминания (хранения), которая запрашивает текущие температуры в выбранных городах, вызывая для этого общедоступный Web-сервис Temperature (температура), используя в качестве аргумента почтовые индексы выбранных городов. К результирующему набору данных могут быть применены агрегатные функции типа максимального, минимального и среднего значений.
  • Сценарий 2: Подборка данных: Разрабатывается приложение, которое через предварительно определенные интервалы времени собирает значения температуры для заданного множества городов и сохраняет эту информацию в локальной базе данных. Это приложение может быть реализовано как пакетное задание для базы данных, которое вызывает Web-сервис Temperature, используя почтовые индексы всех городов, и сохраняет получаемые в результате данные в локальной таблице базы данных.

Архитектура, поддерживающая оба этих сценария, показана на рисунке 3.

Web-сервисы базы данных: что дальше?

Web-сервисы привлекли к себе существенное внимание, в связи с чем наблюдается большая заинтересованность отрасли предоставляемыми ими возможностями. И хотя большая часть этого внимания сосредоточена на Web-сервисах промежуточного уровня, недавно появился растущий интерес к Web-сервисам базы данных, так как организации всерьез задумались над судьбой ранее сделанных ими инвестиций в данные и хранимые процедуры. Так чего же можно ожидать в будущем? Вероятно, мы увидим более сильную интеграцию с инструментальными средствами и инфраструктурами, поддержку более сложных типов данных и конвергенцию с технологиями Grid. Инструментальные средства вместе с находящимися в стадии становления стандартами Web-сервисов начнут поддерживать Web-сервисы базы данных в плане слаженности и гармоничного сочетания их действий. Также мы сможем увидеть связывание SOAP с другими протоколами, кроме HTTP (например, с FTP и специализированными протоколами обмена сообщениями).

Поскольку широко используются сложные и иерархические типы данных, вы можете также ожидать появления способности к взаимодействию продуктов различных производителей для иерархических форм данных, типа JDBC WebRowset и ADO Datasets, чтобы позволить обмен данными между потребителями и производителями Web-сервисов, не требуя информации из XML Schema Definition. Можно также ожидать конвергенции между Web-сервисами базы данных и ориентированными на данные сервисами данных Grid для описания и публикации сервисов, вызова сервисов, подписки на события и уведомления.

Заключение

Web-сервисы базы данных используют имеющуюся у вас серверную инфраструктуру, позволяя использовать вашу базу данных и как провайдера сервисов, и как их потребителя. Я показал, как мы в Oracle позволяем вам превратить базу данных в провайдера Web-сервисов, тем самым, давая вам возможность разделить данные и метаданные между корпоративными интранет и обратиться к операциям базы данных, например, триггерам, через запросы SOAP. Я также объяснил, как можно превратить вашу базу данных в потребителя Web-сервисов для обращения к динамическим данным. Наконец, я дал краткий обзор будущих возможностей Web-сервисов базы данных.

Риунок 1.

Риунок 2.

Риунок 3.

Об авторе

Куасси Менсах является руководителем группы продуктов в составе группы продуктов Java для серверных технологий Oracle. Он опубликовал несколько статей в ведущих журналах для разработчиков и часто выступает с докладами на различных конференциях.

Адрес электронной почты: info@sys-con.com