1 декабря 2000 г.

JSERVER - NEW FEATURES AND ENHANCEMENTS IN ORACLE8i RELEASE 2

An Oracle White Paper, March 2000

Белая книга (препринт) Oracle, Март 2000 г.

Источник: http://technet.oracle.com/products/oracle8i/pdf/8ir2java.pdf

Выпустив Oracle8i, корпорация Oracle выполнила свои обязательства перед Интернет, включив в состав Oracle8i JServer высоко масштабируемую виртуальную машину (VM) Java. Релиз 2 Oracle8i - это новый шаг в развертывании Java-платформы класса предприятия. Релиз 2 Oracle8i включает новую функциональность и совершенствование производительности Oracle JServer для разработки и развертывания приложений на базе Java.

В этом документе характеризуется каждая из областей, которые подверглись расширению в релизе 2 Oracle8i. В начале идет обзор поддержки языка Java 2 в JServer, главным в котором являются возможности, адресованные для использования в промышленном программировании. Далее внимательно рассмотрены новые возможности и расширения, введенные для полной поддержки стандарта JDBC 2.0. После этого описано повышение производительности в JDBC и SQLJ. Вводится концепция, называемая "быстро загружаемые" классы ("Hotloaded" classes), которая помогает JServer Java VM (JVM) достичь огромного увеличения производительности и сокращения требующегося для работы объема оперативной памяти (footprint). После этого кратко излагается поддержка многобайтовых наборов символов, а также поддержку удаленной Java-отладки. За этим следует описание Java-интерфейса с опцией AQ (Advanced Queuing - расширенное управление очередями). Здесь рассмотрена поддержка объектного типа (oracle.AQ) в естественном (native) Java-интерфейсе и Java-интерфейс Message Service (JMS) к AQ. Обзор завершается коротким резюме о новых возможностях и усовершенствованиях, появившихся в релизе 2 Oracle8i.

Релиз 2 Oracle8i JServer полностью поддерживает все новые возможности языка Java 2. Платформа Java 2 вводит множество новых API, направленных на решение многих проблем как клиентской, так и серверной сторон. Большинство изменений сосредоточены в двух направлениях:

Будучи Java-платформой корпоративного уровня, JServer умножает для предприятия все преимущества новых возможностей. Однако, так как JServer не используется для выполнения проблемного кода на сервере, попытка организовать и материализовать на сервере интерфейс пользователя, усовершенствованный UI, не оказывают влияния на JServer.

Одно из наиболее значительных изменений в платформе Java 2 произошло в модели защиты данных. Эта новая модель использует модель защиты данных версии 1.1, которая основана на принципе песочницы (sandbox) и поддерживает подписание кода (code signing). В области поддержки прав доступа и стратегий (permissions and policies) новая реализация предлагает гораздо более детальное (fine-grained) управление, чем ее предшественница.

Права доступа, которые схема или роль имеет для каждого загруженного объекта, могут быть точно определены. Релиз 2 Oracle8i твердо придерживается модели защиты данных Java 2, и пользователям назначаются права доступа к классу на основании классов (class by class). Роли защиты данных Java 1 Oracle8i продолжают поддерживать в редизе 2 только для обратной совместимости. Однако рекомендуется использовать модель защиты данных Java 2 и специфицировать каждое разрешение явно, а не использовать старые роли.

Платформа Java 2 полностью решает два важных аспекта защиты данных:

Системная безопасность достигается с помощью Permission API, Security Manager и поддержки языка программирования Java. Каждому пользователю или схеме должны быть назначены надлежащие права для доступа к классам JVM и ресурсам операционной системы. Это позволяет безопасно выполнять непроверенные и частично проверенные коды (например, апплеты, каналы, сервлеты, удаленный код, а также приложения).

Защита информации достигается с помощью криптографических методов – Java Cryptography Architecture (ядро) и Java Cryptography Extension (стандартное расширение).

Когда модель защиты Java 2 применяется к JServer, который встроен в базу данных, некоторые характеристики говорят сами за себя. В следующей таблице сведены некоторые ключевые характеристики реализации защиты Java 2 в Oracle8i.

С введением в Java 2 слабых ссылок получили толчок средства "сборки мусора" и новаторские методы управления памятью поколения JServer. Слабые ссылки дают программе возможность содержать ссылки на объекты, причем это не мешает объектам подвергаться процедуре "сборки мусора" (without preventing the objects from being garbage collected). Кроме того, программы могут быть уведомлены, когда объекты становятся доступными для "сборки мусора". Эти новые функциональные возможности, требующиеся для всех реализаций, удовлетворяющих требованиям платформы Java 2, дают возможность программам кэшировать информацию в памяти и сбрасывать кэш на диск, когда памяти становится мало; формировать коллекции объектов не требуя, чтобы объекты были защищены от воздействия процедуры сборки мусора; и реализовывать действия по очистке, которые не могут быть выполнены при завершении (with finalization). Все это способствует увеличению производительности механизма "сборки мусора" JServer.

Кроме того, в Java 2 появилась опция Java Extensions Framework, которая облегчает добавление библиотек классов, расширяющих платформу Java. Несмотря на то, что JServer , не нарушая соответствия с Java 2, обеспечивает поддержку этой интегрированной среды, новая возможность не дает больших преимуществ. Причина этого состоит в том, что JServer уже поддерживает более передовой способ достижения большего, чем может дать интегрированная среда расширений, – с помощью собственных решающего устройства (resolver), загрузчика классов (classloader) и основанного на схеме разрешения классов (resolution of classes).

Наряду с полностью соответствующим стандарту ORB, с платформой Java 2 была интегрирована полная поддержка CORBA. CORBA – это промышленный стандарт распределенных вычислений уровня предприятия; таким образом эта добавка к API Java означает, что промышленные приложения, написанные на языке программирования Java, могут теперь “бесшовно” интегрироваться с существующими системами на базе CORBA. Новая добавка не влияет на ORB, включенный в Oracle8i JServer.

В JServer встроен ORB версии 3.4 компании Visigenic. Само собой разумеется, что этот встроенный в JServer ORB обеспечивает большее количество функциональных возможностей и является более мощным, чемORB Java 2. Однако при использовании этой новой добавки нужно не забывать следить за тем, чтобы при написании программ CORBA был вызван тот ORB, который необходим.

Общие добавления, обеспеченные API Java2-платформы, включают каркас метода ввода для ввода сложных иностранных наборов символов, коллекции API, которые обеспечивают стандарт для представления коллекций объектов, API идентификации версии, новый интерфейс отладчика и API ссылок, который поддерживает продвинутое кэширование и очистку объектов. К другим областям, где действуют новые усовершенствования, можно отнести JavaBeans, RMI, сериализацию (последовательное упорядочивание), аудио, производительность, поддержку JAR, JNI, отражение (reflection) и JDBC. Имеются также много уточнений различных типовых API. Будучи полномасштабной Java2-платформой, релиз 2 Oracle8i поддерживает все приведенные выше возможности, но некоторые из этих новых возможностей не имеют большого влияния на JServer, потому что они являются заделами на будущее.

В релизе 2 Oracle8i появилось много новых возможностей и расширений для драйверов JDBC. Все новые драйверы JDBC Oracle полностью совместимы с самым последним набором возможностей Java 2 и JDBC 2.0. В этом разделе рассматриваются некоторые ключевые особенности, например, расширения набора результатов (resultset), пакетные обновления, расширенные типы данных, наборы строк (rowsets), JNDI для названий баз данных, пулы подключений, кэширование подключений, распределенные транзакции, JNI и другие общие возможности.

JDBC 2.0 определяет три типа наборов результата: forward-only (только вперед), scroll-insensitive (нечувствительный к прокрутке) и scroll-sensitive (чувствительный к прокрутке). Для каждого типа набора результата приложение может выбирать один из двух различных типов параллелизма для набора результатов: только для чтения или обновляемый. До сих пор драйверы JDBC поддерживали только тип набора результатов Forward_only/Read_only. Новый выпуск драйверов JDBC Oracel8i поддерживает наборы результатов JDBC 2.0 с возможностью прокрутки. Это означает, что они поддерживают все шесть комбинаций – Forward_only/Read_only, Forward_only/Updatable, Scroll_insensitive/Read_only, Scroll_insensitive/Updatable, Scroll_sensitive/Read_only и Scroll_sensitive/Updatable.

Драйверы JDBC 2.0 реализуют прокрутку как часть самого драйвера, поддерживая кэширование в оперативной памяти на стороне клиента, чтобы сохранить все результаты запроса. Это налагает ряд ограничений. Новые драйверы позволяют пользователям обеспечивать их собственную реализацию кэша ResultSet.

Драйверы JDBC Oracle, начиная с драйверов JDBC версии 1.22, поддерживают возможности пакетного обновления. Новые драйверы JDBC поддерживают как обеспечивавшееся старыми драйверами средство пакетного обновления, так и новые средства, специфицированные в JDBC 2.0. Большинство выполнимого кода и хранимых данных остались теми же, но с небольшими различиями в поведении. Oracle использует неявный стиль пакетирования; как только оно (пакетирование) включается, пакеты накапливаются и посылаются на сервер без каких-либо других изменений в коде или действий программы. Стиль пакетирования JDBC 2.0 явный; программа должна явно добавить операторы к пакету и выполнить его. Два эти типа пакетирования не могут быть смешаны в одном подключении (сеансе связи) – результат будет непредсказуем.

Предыдущие выпуски драйверов JDBC Oracle поддерживали объектные данные, которые были согласованы с техническими требованиями JDBC 2.0. Однако, так как входящий в JDK 1.1 пакет java.sql не определял типы, которые поддерживают объектные данные – Array, Blob, Clob, Ref, SQLData и Struct – для совместимого с JDK 1.1 драйвера было невозможно точно поддерживать возможности объектных данных JDBC 2.0. Oracle разрешил эту проблему, определив пакет oracle.jdbc2, в котором содержатся типы JDBC 2.0, не определенные ранее в JDK версии 1.1.

Теперь, когда Java 2 полностью поддерживает JDBC 2.0 и определяет в пакете java.sql все типы объектных данных, новые драйверы JDBC имеют полностью подчиняющуюся правилам поддержку объектных данных. В драйверах JDBC 2.0 больше не существует пакета oracle.jdbc2. В результате этого при портировании кода из драйверов JDBC 1.22 к драйверам JDBC 2.0 может потребоваться некоторая модификация исходного текста и его рекомпиляция. Те места, где используется пакет oracle.jdbc2 или его типы данных, необходимо заменить их эквивалентами из пакета java.sql и перекомпилировать.

Oracle в настоящее время не обеспечивает никакой реализации интерфейса RowSet.

JNDI обеспечивает инфраструктуру, необходимую, чтобы отделить части продукта, специфические для производителя, от частей, “нейтральных” для него, и дать им возможность сотрудничать через службы имен и справочников (naming and directory service). Стандартные расширения JDBC 2.0 определяют интерфейс (javax.sql.DataSource) для “фабрики подключений” (Connection factory). Например, приложение использует API JNDI, чтобы определить расположение соответствующего DataSource, а затем получить подключения из этого DataSource. В идеальном случае, отдельное приложение зарегистрирует DataSource в службе имен. Тем самым будет четко отделена зависящая от производителя часть – регистрирующее приложение – от части, не зависящей от производителя – бизнес-приложения – и продемонстрирована полноценность JNDI. На все DataSources можно ссылаться в смысле JNDI

Пулы подключений – это схема, в которой множество потребителей вместо того, чтобы создавать новое подключение для каждого потребителя, совместно используют ограниченный набор подключений. Расширения стандарта JDBC 2.0 определяют инфраструктуру для поддержки пулов подключений. Спецификация пулов подключений не обеспечивает никаких дополнительных функциональных возможностей времени выполнения; она обеспечивает набор инструментальных средств, которые можно использовать для реализации кэша подключений.

Пулы подключений поддерживаются и в драйверах JDBC 1.22 и в JDBC 2.0 с помощью драйверов OCI и Thin drivers (тонких драйверов). Работающий на сервере драйвер JDBC (драйвер KPRB) не поддерживает пулов подключений, так как размещенный на сервере драйвер может иметь только одно подключение к начавшему работу сеансу, в рамках которого оно выполняется.

Кэширование подключений реализовано с использованием инфраструктуры пула подключений и полностью поддерживается драйверами JDBC релиза 2 Oracle8i. Кэш подключений Oracle, в дополнение к облегчению производителям программного обеспечения промежуточного уровня реализации их собственной схемы, предлагает две обычно используемых схемы кэширования:

Расширения стандарта JDBC 2.0 определяют API для поддержки распределенных транзакций. Этот API формируется на инфраструктуре пула подключений. Драйверы JDBC релиза 2 Oracel8i полностью поддерживают этот API за одним исключением – не поддерживается метод javax.sql.XAResource.recover (int). Поддержка распределенных транзакций обеспечивается двумя пакетами – oracle.jdbc.xa.client и oracle.jdbc.xa.server. Каждый пакет содержит три класса – OracleXAConnection, OracleXADataSource и OracleXAResource. Приложения, использующие драйверы OCI или Thin, должны использовать пакет oracle.jdbc.xa.client, а приложения, использующие драйвер сервера в составе JServer, должны использовать пакет oracle.jdbc.xa.server. Важно гарантировать, что используется нужный класс из нужного пакета, особенно, если приложение использует несколько драйверов JDBC. Как драйверы JDBC 2.0, так и драйверы JDBC 1.22 поддерживают распределенные транзакции. Поддержка распределенных транзакций, однако, не обеспечивает обратной совместимости с более ранними версиями сервера базы данных Oracle.

Естественный интерфейс Java (Java Native Interface – JNI) и естественный вызов методов (Native Method Invocation – NMI) – это механизмы для вызова из Java кода на языке C. NMI был первым механизмом, специфицированным Sun для вызова из Java кода на C, и единственным механизмом, поддерживавшимся JDK 1.0.2. С прекращением поддержки для JDK 1.0.2 во втором выпуске Oracle8i, драйверы OCI JDBC используют JNI 1.1, а не NMI. Это означает, что драйвер OCI релиза 2 Oracel8i может теперь использоваться с различными VM, отличными от VM Sun, например, VM IBM и Microsoft, которые не обеспечивают поддержку NMI.

API JDBC 2.0 обеспечивает методы для определения числа строк, которые будут предварительно выбраны (pre-fetched) из базы данных. Единственное исключение: когда любой из типов выбора столбца является потоковым, размер выборки автоматически устанавливается равным единице. Предыдущие выпуски драйверов JDBC Oracle обеспечивали подобный механизм предварительной выборки, используя другие методы. Для достижения того же самого результата может использоваться любой из методов. Однако эти два метода не могут быть смешаны в одном объекте Statement, PreparedStatement, CallableStatement или ResultSet.

Была добавлена поддержка символьных потоков, что означает, что символьные данные может быть выбраны и посланы в базу данных как поток интернационализированных символов Уникода (Unicode). Кроме того, были добавлены методы, позволяющие с полной точностью возвращать значения класса java.math.BigDecimal. И, наконец, в то время как поддерживаются API, принимающие календарные аргументы, их поведение будет подобно поведению API без календарных аргументов. Причина в том, что данные типа sql в базе данных не содержат информации о часовом поясе или регионе. Методы будут использовать календарные аргументы, когда база данных обеспечит поддержку часового пояса и региона.

Драйверы JDBC, предоставляемые как часть релиза 2 Oracle8i, будут обеспечивать полную поддержку JDK 1.2 и JDBC 2.0. Версия JDK 1.1.X будет по-прежнему поддерживаться драйверами OCI и тонкими драйверами JDBC, в то время как поддержка JDK 1.0.2 будет прекращена.

Сопровождение для драйверов JDBC, полученных в составе предшествующих выпусков, будет доступно до тех пор, пока будет продолжаться поддержка этих выпусков.

В релизе 2 Oracle8i за счет снижения накладных расходов для сеанса и каждого вызова, а также благодаря оптимизации выполнения JDBC и SQLJ на сервере увеличена производительность SQLJ и JDBC.

Для драйверов Oracle был сделан широкий набор усовершенствований, что привело к увеличению производительности и более эффективному использованию памяти. Были упрощены и оптимизированы все структуры данных, связи (binds), определения и преобразования типов данных. Была экстенсивно улучшена производительность объектов LOB и BFILE, а сами объекты точно отрегулированы (fine-tuned). Также были минимизированы переключения контекста и передача данных между Java и C для драйвера OCI. За счет эффективного использования кэширования, рабочей памяти и памяти запроса, повторного использования ресурсов (recyclable resources) и “ленивого” распределения памяти было достигнуто более эффективное использование ресурсов памяти.

Был сделан целый ряд расширений и усовершенствований к различным аспектам SQLJ. Усовершенствования могут быть отнесены к трем главным категориям: язык, транслятор и производительность.

В рассматриваемом новом выпуске SQLJ поддерживает типы JDBC 2.0 java.sql.Struct/Ref/Array/Blob/Clob и Jpublisher, генерируемые классами оболочки (wrappers) JDBC 2.0 Java, реализующими интерфейс java.sql. SQLData. Далее, теперь SQLJ разрешает образование подклассов итераторов (iterators). И, наконец, была улучшена поддержка SQLJ-анализатора для языка Java. В этом выпуске в трансляторе в ограниченной форме появились функциональные возможности make, аналогичные javac. Кроме того, инструментарий класса SQLJ теперь поддерживает отладчик jdb.

В релизе 2 все усовершенствования производительности, которые раньше были доступны через JDBC-драйверы Oracle, полностью поддерживаются SQLJ. Теперь SQLJ во время выполнения поддерживает кэширование операторов, кэшируя несколько последних SQL-операторов, которые выполнялись в данном подключении JDBC. SQLJ также поддерживает пакетирование SQL-операций. И, наконец, можно активизировать оптимизацию параметров переменной длины и столбцов набора результатов, устанавливая некоторые новые флажки.

Динамическая загрузка классов является главной особенностью языка Java. По мере того, как Java-код начинает выполняться, необходимые классы динамически загружаются во время выполнения. Как только класс загружен любым сеансом, JServer организует совместное использование Java-классов всеми сеансами пользователей, так что влияние динамической загрузки классов на производительность становится относительно малым после того, как класс был загружен в одном сеансе JServer. Объекты, содержащиеся в статических переменных класса, являются частными (private) по отношению к сеансу. Таким образом, потребитель может изменять состояние объекта в одном запросе, изменяя что-то содержащееся в статической переменной класса. Это состояние будет частным по отношению к пользовательскому сеансу и будет поддерживаться между вызовами. Многие основные Java-классы широко используют статические переменные, чтобы хранить в них неизменяемые данные, используемые только для чтения. В релизе 1 Oracle8i эти статические переменные всегда инициализировались при загрузке класса, а объекты, содержащиеся в них, были частными по отношению к сеансу пользователя. При каждом сеансе, в котором используется такой класс, вызывались для выполнения "инициализаторы класса" ("class initializers"), создавая Java-объекты для заполнения статических переменных. Память для хранения в этих статических переменных Java-объектов была частной относительно сеанса, так что, даже если они были бы идентичными для каждого класса в каждом сеансе, они копировались бы каждый раз. Недостаток языковой поддержки специфицирования констант в Java делает невозможным вывести, исходя непосредственно из Java-кода, какие статические переменные могли бы рассматриваться как совместно используемые данные только для чтения.

В релизе 2 Oracel8i JServer вводится концепция быстро загружаемых ("hotloaded") классов. Во время создания базы данных предварительно инициализируются различные основные классы, где инициализируются статические переменные, про которые известно, что они будут постоянными. Когда Вы используете один из этих классов в вашей программе, загрузчик класса загружает предварительно инициализированную форму. Во многих случаях, требующееся для инициализации статических переменных время само по себе весьма значительно, но теперь с введением быстро загружаемых классов это время полностью устраняется. Кроме того, объекты в этих конкретных статических переменных совместно используются всеми сеансами. Поэтому быстро загружаемые классы увеличивают производительность, устраняя инициализацию класса, и уменьшают размер оперативной памяти, требующейся каждому пользователю для сеанса, увеличивая количество совместно используемых сеансами данных. Быстро загружаемые классы "бесплатно", не требуя вмешательства потребителя, обеспечивают увеличенное значение производительности и масштабируемости.

RDBMS Oracle имеет один из самых богатых наборов поддержки многоязычных символов. Драйверы JDBC Oracle поддерживают Уникод и имеют API для выполнения любых необходимых преобразований, тем самым, обеспечивая разработчикам возможность создавать глобальные приложения с полной NLS-поддержкой. До появления релиза 2 серверные JDBC-драйверы и JServer имели возможность поддерживать только английский язык и наборы символов Latin-1. С появлением релиза 2 JServer поддерживает полный спектр наборов символов (NLS), обеспеченных базой данных.

В одноуровневой среде пользователь отлаживает Java-приложение, выполняющееся на его локальной системе. В этом случае, отладчик, скажем, jdb компании Sun Microsystems, связывается с локально выполняемой JVM через протокол, который дает возможность отладчику отображать информацию о состоянии Java-программы. Однако, в случае JServer, Java-программа выполняется дистанционно – на сервере. Сервер может размещаться на той же самой (физически) машине, но обычно он размещается на отдельной машине. Отладчик не может отлаживать удаленное (выполняющееся на сервере) Java -приложение, если он сам выполняется на локальном JDK. Релиз 2 Oracle8i предлагает метод для отладки Java-приложений, находящихся в удаленной базе данных. В JVM JServer включена реализация протокола Java-отладки sun.tools.debug.Agent. Класс DebugProxy представляет удаленное Java-приложение как локальное. Таким образом, стандартный отладчик, который поддерживает протокол sun.tools.debug.Agent может подключиться к JVM JServer и отлаживать приложение, как будто оно выполняется локально. Прокси (proxy) пересылает запросы на сервер и возвращает результаты в отладчик. Модель безопасности Java 2 требует, чтобы пользователь имел разрешение на отладку, и чтобы у него была возможность выполнить программу-агент отладки. Поддержка удаленной отладки JServer доступна из многих Java-отладчиков. JDeveloper – это одна из интегрированных сред разработки, обеспечивающая интерфейс пользователя, в котором используются отладочные средства JServer.

AQ (механизм "расширенного управления очередями") Oracle предлагает два контекста разработки: естественный AQ и Java Messaging Service (JMS). К естественному AQ можно обращаться средствами трех различных сред программирования:

К службе обработки сообщений Java (Java Messaging Service – JMS), с другой стороны, можно обращаться, используя пакет Java oracle.jms. Эта реализация общедоступного стандарта расширяет определенные компанией Sun интерфейсы JMS так, чтобы разработчики, работающие в контексте JMS, имели те же самые средства, что и работающие с естественным AQ.

oracle.AQ – это API AQ Java для организации очередей сообщений. API AQ Java поддерживает как административные, так и операционные возможности AQ Oracle. Теперь программы на Java для приложений, использующих передачу сообщений, в которых используется oracle.AQ, могут больше не использовать интерфейсы PL/SQL.

Advanced Queues могут сохранять либо неструктурированные (необработанные) сообщения, либо структурированные (Oracle Objects) сообщения. В Oracle8i пакет oracle.AQ поддерживал только доступ к запросам с нагрузкой (payload) RAW. В релизе 2 Oracle8i пакет oracle.AQ был расширен для поддержки запросов с полезными нагрузками типа Oracle Object. Это означает, что Oracle Advanced Queues (расширенные очереди Oracle) могут сохранять структурированные (Oracle Objects) сообщения, делать к ним запросы и проецировать их. В результате наличия содержания со строгим контролем типов, то есть, содержания, чей формат определен внешней системой типов, становятся допустимыми много мощных возможностей. К таким возможностям относятся:

Java Message Service (JMS) – это промышленный стандарт для обработки сообщений в масштабе предприятия. Advanced Queuing (AQ) – это интегрированная с базой данных система организации очередей сообщений Oracle. AQ не только обеспечивает все функциональные возможности традиционных систем обработки сообщений масштаба предприятия, но и является законченной системой управления сообщениями. В появившейся в релизе 2 Oracle8i возможности Advanced Queuing реализована спецификация API JMS. Более того, в ней этот API расширен, причем возможности расширения JMS использованы для усиления дополнительных возможностей, являющихся уникальными для Oracle AQ. Этот расширенный API известен как API Oracle Java Messaging Service (OJMS). OJMS является надмножеством JMS.

Стандартные интерфейсы JMS доступны в пакете javax.jms; реализация JMS корпорации Oracle находится в пакете oracle.jms.

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

Посредством возможностей расширяемости OJMS предлагает дополнительный набор реквизитов сообщения, который предоставляет провайдеру конкретные реквизиты для обеспечения большего контроля пользователя над сообщениями. Реквизит интервала задержки позволяет пользователям датировать сообщения более поздним числом, то есть, отправлять сообщения “в обращение” в более поздние даты. Используя эту возможность вместе со стандартной поддержкой даты истечения срока, пользователи могут определить окно выполнения (window of execution). Реквизит обработки особых ситуаций позволяет потребителям определять очередь исключений. Можно сделать так, чтобы, например, просроченные сообщения, – то есть сообщения, которые не могли быть обработаны в пределах указанного интервала времени или указанного количества попыток, были автоматически перемещены в специфицированную очередь исключений. Тогда они могут быть исследованы, чтобы определить причину возникновения исключительной ситуации.

В дополнение к стандартным типам сообщений JMS, OJMS поддерживает тип ADTMESSAGES, которые хранятся в базе данных как SQL99 Objects. Подписка на эти сообщения может быть определена как по их содержанию, так и по их реквизитам. Далее, к ним можно делать запрос в то время, как они находятся в очередях. Наконец, так как поддержка Oracle Object включает технологию расширяемости, полезной нагрузкой сообщения(message payload) может стать любой тип данных.

Опция Transacted Sessions дает пользователям возможность в одной атомарной транзакции выполнять действия как JMS, так и SQL. Она является уникальной особенностью Oracle и существенно увеличивает производительность и операционную простоту транзакционных систем передачи сообщений.

В реализации JMS корпорации Oracle имеется API для создания администрируемых объектов, фабрики подключений (connection factory), очередей и тем и управления ими. Во-первых, интерфейс сеанса был расширен для поддержки административных функций, наподобие создания таблиц очередей, очередей и тем и модификации их реквизитов. Во-вторых, интерфейс пункта назначения был расширен для администрирования поддержки очередей и тем и разрешения распространения сообщений между адресатами информации. И, наконец, пользователям могут быть предоставлены привилегии для посылки и приема сообщений для конкретной очереди или темы.

Следующие возможности JMS в релизе 2 Oracel8i в настоящее время не поддерживаются:

В настоящем документе предлагается общий обзор новых возможностей и уточнений, появившихся в релизе 2 Oracle8i JServer. выше описывалось, как JServer обеспечивает полномасштабную Java2-платформу, усиливая новые возможности Java 2 – безопасность, архитектуру и изменения в API, которые расширяют JVM, поддержку CORBA и различные другие общие расширения. Далее было сказано о разнообразных новых возможностях JDBC-драйверов. JDBC-драйверы корпорации Oracle – тонкий драйвер, драйверы OCI и сервера – поддерживают JDBC 2.0 и обеспечивают много новых расширений, наподобие пула подключений и распределенных транзакций. Затем обсуждались усовершенствования производительности JDBC-драйверов и некоторые расширения SQLJ. В SQLJ укреплена языковая поддержка, введены расширения в трансляторе и усовершенствования производительности. Была представлена новая концепция, получившая название "быстро загружаемые" ("Hotloaded") классы, которые помогают JServer VM Java (JVM) добиваться огромного прироста производительности и сокращения требующего объема оперативной памяти (footprint). Затем последовало обсуждение поддержки многобайтных наборов символов и удаленной Java-отладки. И, наконец, в предлагаемом документе описана JMS-поддержка для Advanced Queuing (AQ) с использованием стандартных API JMS и поддержка объектных типов для AQ с использованием API Java AQ.

Из всего сказанного очевидно следует, что JServer Oracle обеспечивает разработчиков приложений целым рядом важных преимуществ, включая 100 % соответствие стандартам Java, лучшие в отрасли производительность и масштабируемость и не имеющие себе равных надежность, готовность, защиту данных и управляемость. Подводя итоги, можно сказать, что в этом новом выпуске корпорация Oracle сделала важный шаг на пути предоставления Java-платформы уровня предприятия.