|
|
|
| Главная | О компании | Новости | Обучение | Обратная связь | Форум |
ABACUS Financial ABACUS Builder ABACUS Professional
|
Объектные технологии в продуктах Oracle
Спустя примерно 30 лет после зарождения (если за отправную точку брать язык программирования Симула-67), объектные технологии стали обязательным элементом коммерческих программных продуктов, в том числе систем управления базами данных. Выряжаясь официальным языком, сейчас у объектного подхода нет альтернатив. Причин тому несколько. Во-первых, изменился характер данных, хранимых в БД. Существенно увеличился их объем, усложнились структуры данных и связи между ними. Без слов и словосочетаний "мультимедиа" и "информационно-насыщенные системы" не обходится ни один доклад. Традиционные реляционные таблицы с присущими им количественными ограничениями и недостаточно широким спектром базовых типов перестали соответствовать возросшим потребностям. Во-вторых, изменилось место СУБД в общей архитектуре приложений. СУБД стали стандартным компонентом больших распределенных систем, компонентом, который больше не может диктовать правила игры, но должен подчиняться общим требованиям. От СУБД требуется совместимость с сетевыми сервисами (такими как HTTP), тонкое разграничение доступа, расширяемость и настраиваемость. На сегодняшний день только объектный подход позволяет успешно строить и эксплуатировать информационные системы большого масштаба, поэтому СУБД должны предоставлять соответствующие базовые средства и программные интерфейсы. В-третьих, практически все компании - производители реляционных СУБД стремятся стать поставщиками готовых решений, а не отдельных компонентов, пусть и очень важных. Это заставляет обращать внимание на всю технологическую цепочку - от разработки до эксплуатации, от клиентов до серверов. И в каждом звене цепочки объектные технологии оказываются ключевым элементом. Бюллетень Jet Info уже обращался к теме включения объектных средств в серверы реляционных СУБД (см. [1]). В настоящем материале нам хотелось бы представить подход корпорации Oracle к встраиванию объектных возможностей, а также к их архитектуре и реализации. В статье [2] подробно рассматривалась архитектура современных информационных систем. Было выделено три уровня:
Связь между уровнями обеспечивает менеджер транзакций и коммуникаций. Технология Интранет наложила свой отпечаток на эту классическую схему, расположив на уровне представления универсальный клиент - Web-навигатор (возможно, пополненный прикладными аплетами) и возложив функции информационного концентратора (которые естественно объединить с функциями менеджера транзакций и коммуникаций) на Web-сервер. В результате получается схема, изображенная на Рис. 1.
Рисунок 1. Трактовка трехуровневой архитектуры в технологии Интранет. Опираясь на эту архитектуру, корпорация Oracle предлагает три ключевых элемента информационных систем:
В интерпретации Oracle трехуровневая архитектура имеет еще одну особенность. Она изначально задумана как расширяемая (см. Рис. 2). Основной единицей расширения является картридж - клиентский, прикладной или картридж данных. Предусмотрены средства для создания картриджей и интерфейсы для их состыковки с другими компонентами информационной системы. Перечисленные элементы будут подробно рассмотрены в последующих разделах.
Рисунок 2. Архитектура сетевых вычислений (Network Computing Architecture, NCA) корпорации Oracle. Современный сервер СУБД можно сравнить с большим, изрядно нагруженным кораблем. Грузы эти разной степени свежести, но для заказчиков все они важны и все должны быть доставлены в порт назначения, поскольку за них заплачены деньги, и немалые. Команда корабля способна улавливать ветер перемен, но не может быстро маневрировать, поскольку маршрут расписан на годы вперед, да и осадка такова, что волна вот-вот захлестнет палубу и смоет часть груза. Для таких популярных СУБД, как Oracle, возможны только относительно неспешные, эволюционные изменения, не нарушающие устойчивость работы сервера и построенных на его основе многочисленных приложений. Даже такая казалось бы ясная и апробированная вещь. как объектно-ориентированная технология, должна встраиваться постепенно, с продолжительными периодами тестирования и опытной эксплуатации каждой возможности. Подобные соображения следует иметь в виду, анализируя новые свойства сервера СУБД Oracle8. Поддерживаемые типы и структуры данных являются основой любой СУБД, определяя в конечном счете стиль написания, эффективность и управляемость приложений. Опыт эксплуатации Oracle7 доказал необходимость развития типов и структур данных в трех направлениях:
В настоящем разделе мы рассмотрим первые два из перечисленных пунктов. Определяемые типы и структуры являются темой Разд. Объектные типы данных. Как правило, в примерах будет использоваться PL/SQL - язык хранимых процедур Oracle8, являющийся процедурным расширением SQL. В Oracle8 представлены средства поддержки интернационализации /локализации (National Language Support, NLS). В частности, поддерживаются национальные алфавиты. Типы данных NCHAR и NVARCHAR2 предназначены для хранения цепочек национальных символов, соответственно, фиксированной и переменной длины. Национальные символы могут быть многобайтными и даже иметь переменную длину. На длину значений типов NCHAR и NVARCHAR2, хранящихся в столбцах реляционных таблиц, накладываются довольно жесткие ограничения - 2000 и 4000 байт соответственно. Если эти ограничения представляются обременительными, можно воспользоваться средствами для работы с большими объектами. "Каковы средства для работы с большими объектами?" - вот один из первых вопросов, который традиционно задают программисты, прежде чем приступить к реализации реальной системы. Имеются в виду прежде всего количественные ограничения, связанные с большими объектами. В Oracle8 такие ограничения практически сняты. Размер большого объекта может достигать 4 Гб, а сами объекты полноценно участвуют в транзакциях. С языковой точки зрения большие объекты представлены как бинарные (BLOB) и символьные (CLOB для текстов типа CHAR и NCLOB - для NCHAR, см. Разд. Поддержка национальных алфавитов). Кроме того, большие объекты могут храниться внешним по отношению к СУБД образом, в файлах операционной системы. Этот вид хранения обслуживается типом данных BFILE. С точки зрения реализации большие объекты представлены в столбцах реляционных таблиц так называемыми LOB-локаторами, содержащими, в частности, ссылку на реальное место хранения значений. Операции с большими объектами выполняются средствами программного интерфейса или пакета DBMS_LOB. При этом поддерживается случайный доступ внутри значений как на чтение, так и на запись (объекты типа BFILE доступны только на чтение). Каждая строка каждой реляционной таблицы в СУБД Oracle8 имеет уникальный идентификатор (реализованный как физический адрес в БД). Этот идентификатор имеет тип ROWID. С каждой реляционной таблицей неявно ассоциируется столбец типа ROWID и с именем ROWID, хранящий адреса строк. Столбец ROWID, доступный только на чтение, может использоваться наравне с другими столбцами таблицы в операторе SELECT и конструкции WHERE. По существу значения типа ROWID являются указателями на строки таблиц. В этом качестве они используются в индексах и объектных ссылках (см. описание типа REF в Разд. Объектные ссылки). Ссылка остается корректной при модификациях строк, но "повисает" после удаления соответствующей строки. Для работы со значениями типа ROWID служит пакет DBMS_ROWID. Предоставляемые этим пакетом функции позволяют разложить уникальный идентификатор на элементарные компоненты, а также выполнить некоторые другие вспомогательные действия. Записи трактуются в языке PL/SQL Oracle8 вполне традиционным образом - как совокупность разнотипных (быть может, структурных) компонентов. Записи являются полноправным видом значений, их можно хранить в столбцах реляционных таблиц, передавать в качестве параметров и т.п. На Листинг 1 приведен пример описания типов записей и переменной-записи. Идея этого и следующего примеров заимствована нами из [3]. Обратим внимание, что второй тип (AgendaItem) содержит поле, представляющее собой запись первого типа (TimeInterval).
Листинг 1
Листинг 2 В общем, записи введены в Oracle8 весьма последовательно, они практически свободны от реализационных ограничений. Несомненно, программисты, привыкшие к записям по универсальным языкам программирования, будут с удовольствием пользоваться ими и в PL/SQL. Коллекции в Oracle8 представляют собой одномерные массивы с подвижными верхними границами. Коллекции подразделяются на два вида:
Вложенная таблица - это, в сущности, обычная реляционная таблица с одним столбцом. Число элементов во вложенной таблице практически не ограничено; существующие элементы могут удаляться, так что таблица не обязана являться непрерывным массивом (см. Рис. 3).
Рисунок 3. Вложеная таблица как одномерный массив. Массивы переменного размера - более привычная сущность. При их описании задается максимальный размер; "дыр" в массиве быть не может. На Листинг 3 приведены примеры описаний типов - вложенной таблицы и массива переменного размера, элементами которых являются записи.
Листинг 3 Коллекции в Oracle8 живут как бы двойной жизнью - обычной для массивов и объектно-ориентированной. От массивов они унаследовали способ обращения к элементам - традиционную индексацию (см. Листинг 4). Из объектного мира пришли конструкторы для создания значений-коллекций, а также методы для работы с ними.
Листинг 4 Имя конструктора, как и положено, совпадает с именем типа коллекции. В качестве аргументов задаются значения инициализируемых элементов. Конструкторы могут использоваться как в выполняемых операторах, так и в декларациях. К коллекциям применимы следующие методы:
Вызов этих методов оформлен по-объектному (см. Листинг 5): за именем коллекции через точку следует имя метода, затем (при необходимости) - аргументы в скобках. Разработчики Oracle поступили весьма разумно, реализуя новые возможности в едином, современном стиле.
Листинг 5 Объектный тип данных - это тип, определяемый пользователем, и задающий как структуру (атрибуты), так и поведение (методы) объектов. Объектный тип в Oracle8 является аналогом класса в других объектных языках программирования. При описании объектных средств Oracle8 мы позволим себе немного пофантазировать, несколько расширив возможности языка PL/SQL. Дело в том, что в него пока не введены декларации вида:
Листинг 6 и, строго говоря, следует пользоваться операторами SQL*PLUS:
Листинг 7 но, конечно же, проблемы такого рода носят чисто технический характер и, несомненно, в следующих версиях будут устранены. Разделение интерфейса и реализации относится к числу общих мест объектного подхода. Такое разделение, позволяющее выбирать наиболее подходящую реализацию при сохранении интерфейса, проведено, например, в языке программирования ADA, оказавшем заметное влияние на PL/SQL. Описание объектного типа состоит из двух частей (см. Рис. 4). В интерфейсной декларируются атрибуты объектов и заголовки методов (процедур и функций). В теле типа приводится реализация методов.
Рисунок 4. Две части описания объектного типа данных. На Листинг 8 приведен пример описания объектного типа Person. В нем используется вспомогательный тип Address, также являющийся объектом (правда, без методов). Идея этого примера заимствована нами из [4].
Листинг 8 По сравнению с традиционными языками программирования объектные средства Oracle8 имеют ряд особенностей. Первая из них состоит в том, что конструкторы объектов определяются неявно, их аргументами являются значения атрибутов. На Листинг 9 приведен пример описания переменной типа Person и создания соответствующего значения. Подчеркнем, что конструкторы Person и Address мы не определяли. Кроме обращения к конструкторам, на Листинг 9 присутствует вызов метода age (). Видно, что он оформлен в традиционном стиле.
Листинг 9 Вторая особенность объектных средств Oracle8 проистекает из того, что мы имеем дело не с языком программирования, а с СУБД, поэтому объекты, как и значения других типов, нужно индексировать, сравнивать между собой и т.п. Отношение порядка на объектах некоторого типа можно задать двумя способами:
Чтобы выделить такие "упорядочивающие" функции среди других методов, используются спецификаторы MAP и ORDER, соответственно. Например, функция age () могла быть описана следующим образом:
Листинг 10 если, конечно, мы согласны сравнивать людей исключительно по возрасту. Попутно отметим, что специфика СУБД сказывается еще и в том, что методам труднее, чем в обычном случае, хранить в объектах информацию о состоянии и извлекать ее. Точнее, в пределах транзакции проблем не возникает, а между транзакциями объект может измениться, и это следует принимать во внимание. Наконец, третья особенность объектных средств Oracle8, носящая, очевидно, временный характер, состоит в том, что отсутствуют средства наследования, а все атрибуты и методы являются общедоступными. Пока не реализованы спецификаторы EXTENDS, PRIVATE, PROTECTED и т.п., присутствующие в традиционных объектно-ориентированных языках программирования. После того, как объектный тип описан (создан), его можно использовать наравне с другими типами данных. В частности, можно определять и создавать таблицы, в столбцах которых располагаются объекты, выполнять реляционные операции с подобными таблицами и т.п. На Листинг 11 приведен пример создания таблицы, описывающих работников. Один из столбцов этой таблицы имеет тип Person. К таблице применимы обычные реляционные операции, в которых могут участвовать компоненты объектов.
Листинг 11 Если таблица содержит единственный столбец и этот столбец имеет объектный тип, то такая таблица называется в Oracle8 объектной. Объектные таблицы являются как бы мостом между двумя мирами - реляционным и объектным, поскольку на них можно смотреть с двух точек зрения. Можно "развернуть" объектный тип в совокупность атрибутов, и тогда мы получим обычную реляционную таблицу. Но можно оперировать с объектами-строками и как с единым целым, если воспользоваться оператором VALUE (см. Листинг 12).
Листинг 12 Извлечем все атрибуты PersonSELECT *FROM persons pWHERE p.name LIKE '%Smith'; - Извлечем некоторые атрибуты Person и результаты методовSELECT p.name, p.age (), p.addrFROM persons pWHERE p.address.county = 'Russia'; - Извлечем объукты-строки целикомSELECT VALUE (p)FROM persons pWHERE p.name LIKE '%Smith'; Частным случаем объектных таблиц можно считать объектные представления. Вероятно, именно такие представления позволят постепенно преобразовать чисто реляционные данные в нечто более современное. Пример создания объектного представления приведен на Листинг 13.
Листинг 13 Для построения сложных структур данных нужны не только объекты, но и ссылки на них. В Oracle8 введен ссылочный тип данных REF, позволяющий ссылаться на объекты-строки (см. Разд. Использование объектов). На Листинг 14 приведен пример декларации ссылки, ее порождения и использования.
Листинг 14 Для перехода от указателя к указуемому объекту служит функция DEREF, также использованная на Листинг 14. При изменении объектных таблиц ссылки на их строки могут "повиснуть". В Oracle8 введен SQL-предикат
Листинг 15 выявляющий подобные ссылки. Пример использования этого предиката приведен на Листинг 16. Мы не определяли таблицу department, но смысл совершаемых действий достаточно очевиден - "обнулить" висячие ссылки. Разумеется, объектные ссылки могут являться атрибутами других объектов и храниться в столбцах реляционных таблиц, что позволяет более эффективно и, главное, более наглядно, по сравнению с внешними ключами, организовывать связи между элементами данных.
Листинг 16 Некоторые реализационные соображения Одно из главных достоинств реляционных СУБД состоит в развитом механизме оптимизации выполнения SQL-запросов. Вообще говоря, введение объектных средств вступает в конфликт с механизмами оптимизации, поскольку заранее неизвестен характер действий, выполняемых методами объектов, их относительная цена, устойчивость по отношению к распараллеливанию запросов и т.п. В Oracle8 приняты определенные меры для решения проблемы оптимизации. При описании объектного типа посредством оператора.
Листинг 17 можно описать степень "чистоты" методов, то есть сообщить компилятору, каких побочных эффектов (состоящих в обращении к базам данных) при выполнении методов не будет. В будущем предполагается предоставить открытые программные интерфейсы, помогающие строить индексы объектов и проводить глубокую оптимизацию SQL-запросов, в которых фигурируют вызовы методов. Объекты могут не только мешать оптимизации, но и помогать ей. В Oracle8 на стороне клиента организуется специальный объектный кэш, куда за один раз передается с сервера как сам запрошенный объект, так и весь граф связанных с ним объектов. В результате экономится число сетевых взаимодействий, уменьшаются задержки в работе пользователей. Для повышения возможности распараллеливания запросов Oracle8 производит блокировки на уровне отдельных объектов. Это важно, если учитывать возможность разделения объектов (то есть наличия нескольких ссылок на один объект). Более "грубые" блокировки, несомненно, существенно сказались бы на работе пользователей. Картридж данных - это совокупность определенных разработчиком типов данных (как правило, объектных) и подпрограмм (процедур и функций), привносящая в СУБД новую функциональность. Картриджи данных являются основным средством расширения для сервера Oracle8. На момент написания статьи существовали картриджи для работы с текстами (в том числе русскими), с изображениями, видеоинформацией, географическими данными и т.п. У картриджа можно выделить две стороны:
На Рис. 5 показаны основные составляющие технологической стороны.
Рисунок 5.Основные составляющие технологической стороны картриджей данных. Строго говоря, в Oracle8 нет специальных средств для создания картриджей. Базой являются объектные типы данных и их методы, по большей части реализуемые в рамках внешних библиотек. Существенную помощь в группировке взаимосвязанных элементов оказывает аппарат пакетов языка PL/SQL, аналогичный имеющемуся в языке программирования ADA. Как указывалось в Разд. Некоторые реализационные соображения, пока в Oracle8 не развиты технологические программные интерфейсы к подсистемам индексирования и обработки запросов. Трудно сказать, насколько это существенно, поскольку картриджи, хотя и интегрированы в СУБД, в значительной степени живут собственной жизнью, входящие в них методы потребляют значительные вычислительные ресурсы, так что оптимизация на уровне SQL может и не оказать заметного влияния на общий уровень эффективности. Любое расширение сервера СУБД чревато снижением надежности его работы. Чтобы минимизировать риск, Oracle8 выполняет внешние подпрограммы в рамках отдельных процессов. Это несколько замедляет передачу параметров и возврат результатов, но зато защищает сервер от ошибок сторонних разработчиков и, что очень важно, обобщается на распределенный случай. Для тех, кто хочет разрабатывать собственные картриджи, в качестве отправной точки можно порекомендовать статью [5]. Мы же рассмотрим в качестве примера картридж ConText, предназначенный для работы с текстами. Реляционные СУБД являются самым продвинутым средством для хранения и обработки структурированных данных. С другой стороны, основная часть данных практически любой организации существует в виде неструктурированных текстов. Целесообразно объединить удобство SQL-запросов и технологичность реляционных СУБД со средствами текстовой обработки, в том числе интеллектуальными. Эту задачу и решает картридж данных ConText. Отметим, что попытки организовать "самодельные" хранилища текстов, на наш взгляд, абсолютно бесперспективны. Поскольку, как мы уже отмечали, объем текстовых данных велик, проблемы эффективности, масштабируемости и управляемости встают для текстовых баз еще острее, чем для "чистых" реляционных СУБД. Без оптимизации и распараллеливания запросов, без поддержки многопроцессорных и кластерных конфигураций, без отработанных средств администрирования, короче говоря, без технологического багажа, отработанного за годы использования реляционных СУБД, системы хранения и обработки текстов не выдержат жестких требований промышленной эксплуатации. С точки зрения хранения текстов картридж ConText не предлагает ничего особенного по той простой причине, что Oracle8 и так содержит достаточный набор возможностей (см. Разд. Поддержка национальных алфавитов и Разд. Средства для работы с большими объектами). Единственной важной новинкой является хранение в столбцах таблиц универсальных локаторов ресурсов (URL) и прозрачная для пользователя выборка соответствующих документов. Набор методов, реализуемых картриджем, можно подразделить на две группы:
Первая группа методов базируется главным образом на словарных индексах, представляющих собой инвертированные списки, где для каждого слова указаны документы, его содержащие, и позиция слова в документе. Подобная структура позволяет эффективно осуществлять выборку по ключевым словам и фразам. Разумеется, ConText обладает достаточным интеллектом для разбора различных форматов текстовых документов (обычный текст, HTML-документ, файлы MS-Word, PDF и т.п.). Кроме того, определенный интеллект проявляется и при построении индексов: можно задать (общеупотребительные) слова, которые в индекс не попадут.Для удобства работы введено понятие "текстовых политик", содержащих такие параметры, как подразумеваемый естественный язык, формат документов и т.д. Разработчикам предлагается набор встроенных политик, пригодных для большинства практически важных случаев. На уровне элементарных операций ConText предлагает обычные предикаты, операторы NEAR (встречается поблизости) SOUNDEX (звучит похожим образом) SYN (искать синонимы) и т.п. Искомым словам можно придавать различный вес, задавать "порог" для числа вхождений, подсчитывать итоговый "рейтинг" документа и т.д. Пожалуй, в рамках традиционной работы со словами ConText реализует максимум возможного. На Листинг 18 приведен пример таблицы с текстовыми атрибутами и запроса на языке PL/SQL, в котором задействованы методы картриджа ConText. Даже этот простой пример, заимствованный нами из статьи [6], показывает, насколько полезно сочетать текстовую специфику с обычными средствами языка SQL.
Листинг 18 В примере обрабатываются резюме, поступившие в компанию из различных агентств по подбору персонала. Выбираются кандидаты, подавшие документы в агентство ACME Recruiting и являющиеся специалистами по Java. Аргумент 'TEXTTABLE_POLICY' метода CONTAINS обладает достаточной информацией о таблице TEXTTABLE; в частности, он "знает", в каком столбце располагается анализируемый текст. Продвинутые лингвистические средства направлены на понимание смысла текстов, точнее, на определение тем, которые в тексте рассматриваются. На базе этих средств можно составить инвертированный список тем (где для каждой темы хранится перечень соответствующих ей документов), выдать "выжимку" документа (набор абзацев, наиболее полно освещающих затрагиваемые темы) и т.д. Понятно, что реализация возможностей такого рода требует масштабной настройки на естественный язык; замечательно, что для русского языка подобная настройка уже выполнена. На примере картриджа ConText можно видеть, насколько органично на объектной основе сочетаются специфические методы, присущие определенной области знания, и реляционные механизмы. Перед нами тот случай, когда целое существенно больше арифметической суммы частей, поскольку составляющие поддерживают и усиливают друг друга. Задачи, стоящие перед ПО прикладного уровня. Программное обеспечение прикладного уровня занимает в трехуровневой архитектуре (см. Рис. 1) центральное место - и в прямом, и в переносном смыслах. На этом уровне решаются следующие важнейшие задачи:
Наконец, должны существовать удобные инструментальные средства для разработки прикладных частей информационных систем. Перечисленные требования выполнить отнюдь не просто. В принципе можно собрать набор программных продуктов (ПО промежуточного слоя, Web-сервер, сервер аутентификации и т.д.), решающих поставленные задачи, но с большой вероятностью такой набор окажется нетехнологичным. Разнородными элементами трудно управлять, зачастую каждый из них расширяется по-своему, многие плохо масштабируются. В общем, если просто слить все имеющееся под рукой в пресловутый "один флакон", ничего хорошего не получится. Недостаточно и повторять заклинания про "технологию Интранет", поскольку ее внедрение в корпоративную среду решает далеко не все проблемы. Основная идея, реализованная корпорацией Oracle в сервере приложений (Oracle Application Server, OAS), состояла в том, чтобы предложить единый программный продукт, решающий все перечисленные в Разд. Задачи, стоящие перед ПО прикладного уровня задачи. Идея эта является нетривиальной хотя бы потому, что раньше подобных продуктов никто не делал. Решение, принятое корпорацией, требовало не только смелости, но и умения выявлять тенденции развития информационных технологий, поскольку реализация столь масштабного продукта и его "промышленная обкатка" - процесс, очевидно, многолетний, в котором неизбежны локальные неудачи и перестройки. Стыковка различных элементов как внутри прикладного уровня, так и между уровнями, разумеется, должна выполняться на основе стандартов. Трудность состоит в том, чтобы из множества существующих спецификаций выбрать "минимально достаточное" подмножество, способное обслужить текущие и перспективне нужды. Двумя главными стандартами, взятыми на вооружение в OAS, стали HTTP и IIOP (Internet Inter-ORB Protocol, Интернет-протокол взаимодействия брокеров объектных запросов). Протокол HTTP решает важнейшую задачу поддержки "универсальных тонких расширяемых клиентов" - Web-навигаторов. По этому поводу написано много, мы не станем повторяться. Пожалуй, более существенной является ориентация на компонентную объектную архитектуру. Эта ориентация нашла свое выражение в поддержке архитектуры CORBA (см.[7]) и в следовании спецификациям Enterprise JavaBeans (EJB). CORBA и EJB позволяют решить несколько задач:
Поддержка распределенной объектной среды, протоколов HTTP и IIOP дает возможность на тех же принципах построить систему управления прикладными сервисами, что очень важно с технологической точки зрения. Результирующая система получается концептуально экономной, технологичной, простой в освоении и использовании. Организация взаимодействия с СУБД сейчас относится к числу рутинных задач, решаемых на основе спецификаций ODBC, JDBC, использования механизма хранимых процедур и мониторов управления распределенными транзакциями. Вполне понятно, что здесь у такой компании, как Oracle, проблем было меньше всего. В заключение раздела - одно терминологической замечание. В материалах корпорации для обозначения прикладных компонентов служит термин "картридж", хотя по сути имеются в виду компоненты в смысле JavaBeans. В дальнейшем изложении мы будем следовать корпоративным традициям, чтобы подчеркнуть тот факт, что расширяемыми являются все уровни в сетевой архитектуре Oracle (правда, механизмы расширения оказываются разными).
Рисунок 6. Основные архитектурные элементы Oracle Application Server 4.0 и связи между ними. Как уже указывалось, для связи с клиентскими системами используются протоколы HTTP и IIOP. HTTP-запросы принимает Web-сервер, который обслуживает их, если обращение производится к HTML-документам или CGI-процедурам. Прочие обращения передаются брокеру объектных запросов (ORB) или серверам картриджей. IIOP-запросы сразу принимает ORB. Предполагается, что поддержка CORBA на клиентской стороне встроена в Web-навигатор или обеспечена аплетами, полученными по сети. Агенты менеджера ресурсов обеспечивают маршрутизацию запросов от CORBA-клиентов к свободным экземплярам CORBA-объектов, возвращая объектную ссылку на такой экземпляр. Картридж в контексте OAS - это компонент прикладного уровня, обеспечивающий некую содержательную функциональность (в Разд. Элементы, входящие в состав OAS 4.0 мы рассмотрим основные картриджи, входящие в состав OAS 4.0). Сервер картриджей - это процесс операционной системы, в рамках которого функционируют экземпляры картриджей. Выбор картриджа для обслуживания пользовательского запроса осуществляется на основе анализа универсального локатора ресурсов (URL), заданного в запросе. Помимо перечисленных элементов, непосредственно предназначенных для обслуживания пользовательских запросов, в состав OAS 4.0 входит ряд инфраструктурных сервисов:
Еще один важный архитектурный элемент - взаимодействие между картриджами (Inter-Cartridge Exchange, ICX), организованное на основе протокола HTTP. Более детальное представление об архитектуре Oracle Application Server 4.0 можно получить, прочитав статью [8]. Фронтальным элементом сервера приложений Oracle является Web-сервер. В состав OAS 4.0 входит реализация Web-сервера, обеспечивающая поддержку HTML 3.2 и HTTP 1.1. При желании в OAS можно задействовать популярные продукты других компаний (разные варианты серверов Netscape, Microsoft IIS, Apache). Точнее, в OAS 4.0 имеются адаптеры для этих Web-серверов. Брокер объектных запросов, входящий в OAS 4.0, удовлетворяет спецификациям CORBA 2.0. В комплект входят и реализации объектных сервисов CORBA (эти сервисы подробно описаны в статье [7]), и, в частности, сервис транзакций OTS. Особого упоминания заслуживает брокер Web-запросов (Web-Request Broker, WBR), являющийся объектной альтернативой CGI, альтернативой гораздо более мощной и эффективной. WRB соединяет миры HTTP и CORBA и играет ключевую роль в OAS. Вместе с OAS 4.0 поставляются следующие картриджи:
В комплект поставки Oracle Application Server входит ряд продуктов третьих фирм:
Oracle Application Server 4.0 поддерживает три модели приложений:
Модель запрос/ответ типична для протокола HTTP. Для ее реализации не нужно прилагать специальных усилий. В сеансовой модели вводится структура контекста, за счет чего сохраняется связь между клиентом и экземплярами картриджей. Для поддержки транзакционной модели в корпоративную редакцию OAS 4.0 введен Java Transaction Service (JTS), реализующий сервис OTS архитектуры CORBA. Информационная безопасность не является предметом данной статьи. Тем не менее, следует отметить, что OAS 4.0 предоставляет весьма продвинутые средства безопасности:
Таким образом, Oracle Application Server 4.0 есть нечто гораздо большее, чем Web-сервер с небольшими "нашлепками". OAS 4.0 предоставляет объектную инфраструктуру и полезные стандартные компоненты, позволяющие в короткие сроки создавать и развертывать серверы приложений корпоративного масштаба, обладающие всеми необходимыми функциональными и технологическими характеристиками. Корпорация Oracle является одним из самых активных сторонников Java-технологии. Oracle поддерживает и внедряет разработки JavaSoft и других компаний, одновременно проводя собственные масштабные работы в области Java. Уже в статье [9] корпорация обнародовала Java-стратегию, которой продолжает следовать и поныне. На Рис. 7 сведены основные продукты Oracle, поддерживающие Java-технологию.Видно, что эти продукты распределены по всем уровням трехуровневой архитектуры, а также по всем фазам жизненного цикла информационных систем - от разработки до администрирования. Примечательно, что поддерживаются как "тонкие", так и "толстые" клиенты, то есть Oracle не пытается навязать своим заказчикам какую-то одну схему, он дает им возможность выбора (хотя и не скрывает собственных предпочтений).
Рисунок 7. Java в продуктах Oracle. Несколько продуктов, фигурирующих на Рис. 7, на наш взгляд, нуждаются в пояснениях. Корпорация предлагает собственную реализацию JDBC-драйверов, оптимизированную для взаимодействия с СУБД Oracle и поддерживающую то новое, что появилось в Oracle8. Разумеется, при этом сохраняется поддержка всех стандартных возможностей, а также распределенных конфигураций и (с помощью Oracle Open Gateways) "инородных" баз данных. JSQL - это и спецификация, и препроцессор, обеспечивающий встраивание SQL-операторов в Java-программы. За прошедшие годы корпорация Oracle накопила огромный опыт по встраиванию SQL практически во все популярные языки программирования (C, C++, ADA, FORTRAN, COBOL, PASCAL), поэтому JSQL, несомненно, унаследует высокое качество предыдущих разработок. Отметим, что JSQL обладает важным преимуществом по сравнению с JDBC - возможностью обращаться к схеме базы данных во время компиляции. Это позволяет проводить проверки во время компиляции (с выдачей диагностики при обнаружении ошибок) и оптимизировать SQL-запросы. На наш взгляд, корпорация Oracle весьма последовательно и активно внедряет объектные технологии и на уровне серверов СУБД, и на прикладном и клиентском уровнях. Хотелось бы обратить внимание читателей на тот факт, что в данном случае объектный подход выполняет в первую очередь инфраструктурную, системообразующую функцию, делая программные продукты Oracle технологичными, способными работать в разнородном, распределенном окружении. В то же время, превращение Oracle8 в объектно-реляционную СУБД имеет и, если так можно выразиться, утилитарную ценность, помогая пользователям более естественным образом строить базы данных и постепенно мигрировать от чисто реляционной к более содержательной модели данных. Перспективность пути, выбранного корпорацией, подтверждает сопоставление с деятельностью других передовых компаний, таких как Sun Microsystems. Развитие компонентной модели программных систем, использование Java на серверной стороне и в качестве программного обеспечения промежуточного слоя - все это общие достижения, способствующие прогрессу информационных технологий, прогрессу, выгодному всем. 1. В. Галатенко , А. Гвоздев -- Типы и структуры данных в INFORMIX® -Universal Server -- Jet Info, 1997 N 12/13.
|
|
|
|
||
