Введение

Одна из основных целей поддержки статического SQL в DB2® - это повышение производительности системы. До появления технологии оптимизации клиента pureQuery большинство Java™ приложений (кроме использующих SQLJ) не имели возможности использовать статический SQL. Именно поэтому практически все Java-приложения, работающие с базами данных, значительно повышали нагрузку на систему за счет динамического выполнения инструкций SQL, включая формирование SQL-команд (построение планов доступа к базе данных) в процессе выполнения приложения. Существуют методы минимизации дополнительной нагрузки за счет кэширования, как на стороне сервера, так и на стороне клиента. Однако подобные сценарии имеют дополнительные ограничения, связанные с выделением и использованием свободной памяти. Вопросы кэширования выходят за рамки данной статьи. Использование статического SQL позволяет повысить производительность, так как в этом случае план выполнения SQL-запроса создается заранее, на этапе работы утилиты BIND, а не во время исполнения программы. Таким образом, исполнение статических SQL-инструкции не требует использования операторов PREPARE и DESCRIBE. Средства оптимизации клиентских приложений пакета Optim pureQuery Runtime позволяют Java-приложениям (даже тем, которые были разработаны на Java-фреймворках) перейти при работе с базами данных DB2 к статическому исполнению SQL-инструкций, используя тем самым все преимущества производительности и управляемости статического SQL. При этом подобная оптимизация не потребует от вас изменения кода Java-приложений. Если вы используете базы данных, отличные от DB2, вы можете воспользоваться другими преимуществами оптимизации клиентских приложений. Например, при работе в среде разработки Optim™ Development Studio для любого SQL-запроса вы сможете легко определить генерирующий этот запрос фрагмент Java-кода. Таким образом, вам будет гораздо проще отладить код с точки зрения составления оптимальных запросов и оценить, каким образом изменение того или иного SQL-запроса влияет на работу приложения. Вы сможете оптимизировать работу клиентского приложения, избавившись от низкопроизводительных SQL-инструкций, не меняя при этом код всего приложения. Кроме того, вы сможете внести ограничения в работу клиентского приложения, разрешив выполнять только заранее определенные и согласованные SQL-инструкции, тем самым снизив риск возможных SQL-инъекций. Более подробную информацию об использовании статического SQL вы можете найти в статье "'No excuses' database programming for Java" (раздел Ресурсы). Детальное описание функций отслеживания и замены SQL-инструкций пакета Optim Development Studio дается в статье "What's New in Optim Development Studio 2.2" (см. раздел Ресурсы).

Краткий обзор процесса оптимизации клиентских приложений

Как описано в статье "Optimize your existing JDBC applications using pureQuery" (см. раздел Ресурсы), процесс преобразования динамического SQL в статический с помощью средств оптимизации pureQuery требует выполнения определенных шагов (см. рис. 1). Если вы не используете статический SQL, этапы конфигурирования и создания пакетов не нужны.

Для использования технологии оптимизации pureQuery вам потребуется IBM Data Server Driver for JDB and SQLJ и пакет Optim pureQuery Runtime. Для целей разработки приложений эти компоненты устанавливаются на том же компьютере, где установлен пакет Optim Development Studio. На рисунке 1 такой компьютер представлен в виде прямоугольника с подписью DB2 JCC Driver and pureQuery Runtime. Четыре основных этапа оптимизации показаны на рисунке 1:

Сбор SQL-инструкций в отдельный файл (Capture)

На первом этапе процесса оптимизации необходимо выполнить приложение с исходным динамическим SQL. В процессе работы приложения инструменты pureQuery выделяют SQL-инструкции и связанные с ними данные в отдельный файл pureQueryXml. На рисунке 1 этот файл отмечен как Собранные SQL-инструкции и связанные с ними метаданные.

Конфигурирование свойств пакетов (Configure)

На этом этапе вы определяете, в какой или какие пакеты необходимо включить выделенные SQL-инструкции. Самый простой способ сделать это – воспользоваться соответствующими инструментами Optim Development Studio.

Создание пакетов с помощью BIND (Bind)

На этом этапе утилита BIND анализирует собранные SQL-инструкции и создает соответствующие пакеты или DBRM для выполнения запросов к выбранной базе данных. Этот этап необходим только для статического выполнения SQL-запросов. Для создания пакетов вы можете воспользоваться средствами Optim Development Studio или вызвать утилиту Static Binder из командной строки.

Исполнение (Execute)

На этом этапе вы можете выбрать настройки pureQuery для статического, динамического или смешанного выполнения выделенных SQL-инструкций. Для этого вы можете воспользоваться инструментами Optim Development Studio или утилитами командной строки.

В начало

Использование пакета pureQuery Runtime на сервере приложений

На рисунке 2 показана типовая топология использования pureQuery в трехуровневой среде (уровень клиента, уровень приложений и уровень баз данных). Пакет pureQuery Runtime работает на уровне приложений, т.е. там, где установлен сервер приложений, или, если вы не используете такой сервер, там, где установлены клиентские драйверы для автономных приложений. Дополнительное программное обеспечение на уровне баз данных не требуется.

Несмотря на то, что на рисунке 2 в качестве сервера баз данных показана DB2, pureQuery также можно использовать с базами данных Informix Dynamic Server и Oracle. Данная статья описывает правила настройки pureQuery для работы с WebSphere Application Server. Если вы используете другой сервер приложений, необходимо выполнить те же самые основные этапы, которые описаны в этой статье, однако конкретные шаги, связанные с настройкой среды сервера приложений, могут отличаться от приведенных здесь.

Основные этапы:

1. Установка pureQuery Runtime и IBM Data Server Driver for JDBC and SQLJ.
2. Создание JDBC-провайдера с поддержкой pureQuery.
3. Создание источника данных с поддержкой pureQuery.

Установка pureQuery Runtime и IBM Data Server Driver for JDBC and SQLJ

В таблице 1 указаны версии Java Runtime Environment (JRE), WebSphere Application Server и IBM Data Server Driver for JDBC and SQLJ JDBC, поддерживаемые различными версиями пакета pureQuery Runtime (для Linux®, UNIX®, Windows® и для z/OS®).

Подробную информацию о требованиях к программному обеспечению вы можете найти в разделе Ресурсы.

Создание JDBC-провайдера с поддержкой pureQuery

В этом разделе мы расскажем, как настроить JDBC-провайдер, используя WebSphere Application Server в качестве сервера приложений. При этом предполагается, что подключение приложения к базе данных производится с помощью драйвера IBM Data Server Driver for JDBC and SQLJ. Этот драйвер используется в качестве JDBC-провайдера на сервере WebSphere Application Server. Для использования технологии pureQuery необходимо добавить jar-файлы pureQuery (pdq.jar и pdqmgmt.jar) к путям поиска классов JDBC драйвера, используемого в качестве JDBC провайдера. На рисунке 3 показана управляющая консоль WebSphere с соответствующими настройками путей поиска классов.

Создание источника данных с поддержкой pureQuery

Теперь можно приступить к созданию источников данных с использованием JDBC-провайдера. Для этого в среде WebSphere Application Server необходимо выполнить следующие шаги:

1. В административной консоли WebSphere щелкните мышкой на вкладке Data source (в разделе Resource). В открывшемся контекстном меню выберите опцию New.
2. Укажите имена источника данных и JNDI, которые используются в приложении.
3. Выберите JDBC-провайдер, соответствующий источнику данных, и укажите параметры доступа к базе данных, включая имя базы данных, имя сервера, порт, идентификатор и пароль пользователя.
4. Чтобы указать пулу соединений сервера, что подключение к указанному источнику данных использует технологию pureQuery, присвойте значение свойству pdqProperties. Это может быть значение pdqProperties по умолчанию (executionMode dynamic).

Теперь инструментарий pureQuery установлен и доступен на сервере приложений. Приложение будет использовать созданный источник данных для подключения к базе данных. Одно Web-приложение может использовать несколько источников данных для работы с различными базами данных. Аналогично, несколько Web-приложений могут использовать один и тот же источник данных.

В начало

Обзор настроек среды pureQuery Runtime для оптимизации клиента

Процесс оптимизации клиентского приложения требует определенных настроек для преобразования динамического SQL в статический и для выделения SQL-инструкций. В данном разделе описываются различные варианты настройки свойств оптимизации клиента pureQuery для Web-приложений.

1. Вариант 1: Глобальная настройка свойств pureQuery Runtime
2. Вариант 2. Настройка свойств pureQuery Runtime для источника данных
3. Вариант 3. Настройка свойств pureQuery Runtime на уровне приложений (начиная с версии 2.2)

Каждый вариант имеет свои преимущества и ограничения. В этом разделе мы рассмотрим несколько примеров и определим, какой вариант удобнее использовать в каждом конкретном случае.

Вариант 1: Глобальная настройка свойств pureQuery Runtime

В каком случае следует использовать этот вариант?

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

Что для этого нужно сделать

Для глобальной настройки свойств добавьте файл pdq.properties в путь поиска классов CLASSPATH для драйвера вместе с jar-файлами pureQuery. При этом свойства, определенные в файле pdq.properties, будут работать для всех приложений, использующих указанный драйвер. Другими словами, возможность разделения свойств на уровне приложений и уровне источников данных поддерживаться не будет.

Что при этом необходимо иметь в виду

Чтобы перейти от динамического выполнения SQL-инструкций к статическому и активировать изменения, сделанные в файле pdq.properties, требуется перезапуск сервера приложений. Так как свойства, указанные в файле pdq.properties, применяются ко всем источникам данных, использующих указанный JDBC-провайдер, все SQL-инструкции будут собраны в один файл pureQueryXml и будут исполняться в одном и том же режиме (динамически или статически).

Вариант 2. Настройка свойств pureQuery Runtime для источника данных

В каком случае следует использовать этот вариант?

Настройка свойств pureQuery Runtime на уровне источников данных позволяет назначить различные свойства разным источникам данных. Такой вариант предпочтительно использовать в том случае, когда каждый источник данных должен быть независимым по отношению к остальным источникам. Примером может служить приложение, обращающееся к нескольким источникам данных, причем для работы с одними источниками используются динамические SQL-запросы, а для работы с другими источниками – статические SQL-запросы.

Что для этого нужно сделать

Для установки свойств pureQuery на уровне источников данных воспользуйтесь дополнительным свойством pdqProperties конкретного источника данных. Чтобы установить значение этого свойства, выберите опцию DataSources > your datasource name > Custom properties > New в административной консоли WebSphere Application Server, как показано на Рис. 4.

Что при этом необходимо иметь в виду

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

Вариант 3. Настройка свойств pureQuery Runtime на уровне приложений

Как уже было сказано выше, свойства, указанные в глобальном файле pdq.properties, применяются ко всем приложениям, использующим один и тот же драйвер, и ко всем источникам данных, с которыми работают эти приложения (так как глобальный файл pdq.properties включен в переменную CLASSPATH драйвера). Кроме того, свойства, определенные на уровне источника данных, применяются ко всем приложениям, работающим с данным источником данных. Для определения дополнительных ограничений помимо тех, которые заданы на глобальном уровне или на уровне источника данных, в версии Optim pureQuery Runtime Version 2.2 используются два новых файла свойств для Web-приложений (файлы свойств на уровне приложений).

В каком случае следует использовать этот вариант?

Определение свойств на уровне приложений имеет смысл в среде, использующей несколько приложений и несколько источников данных в конфигурации n:n.

Что для этого нужно сделать

Для настройки свойств pureQuery на уровне приложений необходимо изменить один или оба файла свойств:

pdq.appwide.properties

Этот файл задает свойства pureQuery для конкретного приложения. Все значения свойств, указанные в файле pdq.appwide.properties, будут применяться ко всем источникам данных, которые использует приложение

pdq.dataSourceName.properties

Этот файл определяет свойства приложения по отношению к конкретному источнику данных. Это означает, что свойства приложения, определенные в этом файле, будут применяться только к одному конкретному источнику данных, который использует данное приложение. Строковое значение dataSourceName соответствует дополнительному свойству dataSourceName источника данных. Вы можете задать это свойство аналогично тому, как задается свойство pdqProperties (см. рисунок 4).

Синтаксис определения конкретных значений для свойств приложения выглядит точно так же, как определение свойств в файле pdq.properties (см. листинг 1).

pdq.captureMode = ON pdq.executionMode = DYNAMIC
pdq.pureQueryXml = C:/PDQ_2.2/captureFiles/abc_pdq.xml

Чтобы задать свойства определенного приложения для работы с одним конкретным источником данных, используйте файл pdq.dataSourceName.properties.

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

Что при этом нужно иметь в виду

Если свойства приложения определяются файлами pdq.appwide.properties или pdq.dataSourceName.properties, то при изменении свойств приложения достаточно закрыть соединение, перезапуск сервера приложений не требуется.

В начало

Настройка свойств pureQuery на уровне приложения

Данный раздел содержит подробную информацию о том, каким образом свойства оптимизации клиента pureQuery уровня приложений обеспечивают гибкую настройку на уровне приложений и источников данных.

Где должны находиться файлы свойств при настройке параметров pureQuery на уровне приложения

Для того чтобы параметры настройки pureQuery, определенные в файле pdq.appwide.properties или pdq.dataSourceName.properties, использовались для оптимизации клиента, этот файл должен находиться как минимум в одной из перечисленных ниже директорий:

• В директории WEB-INF/classes для Web-приложения
• В директории WEB-INF/lib как .jar файл
• Непосредственно в той директории, где установлено приложение

Два первых варианта используются в случае, если приложение включает в себя Web-модуль. Для EJB-приложений может использоваться любой из трех указанных выше вариантов. Предположим, например, что приложение TestClintOptEAR.ear установлено на WebSphere Application Server. В этом случае приложение будет установлено по следующему пути: <WAS_INSTALL_ROOT>/profiles/AppSrv01/installedApps/myNode01Cell/ TestClintOptEAR.ear, где AppSrv01 – имя профиля, а myNode01Cell – имя узла. Предположим, что приложение содержит Web-модуль TestClintOpt.war. Тогда файлы свойств pureQuery для этого приложения могут располагаться в следующих директориях:

Вариант 1. Сохраните файлы pdq.appwide.properties и/или pdq.dataSourceName.properties в директории TestClintOptEAR.ear/TestClintOpt.war/WEB-INF/classes.

Директория WEB-INF/classes существует только для Web-модулей, так что первый вариант имеет смысл только для приложений, включающих такие модули.

Вариант 2: Создайте .jar файл (например, prop.jar), который содержит в себе один из файлов pdq.appwide.properties или pdq.dataSourceName.properties properties или оба этих файла. Сохраните созданный jar-файл в директории TestClintOptEAR.ear/TestClintOpt.war/WEB-INF/lib.

WAR-модули могут использовать .jar-файлы свойств, хранящиеся непосредственно в директории WEB-INF/lib, так что в данном случае вам не надо добавлять созданный .jar-файл к путям поиска классов. Этот вариант может применяться только для приложений, использующих Web-модули, так как только в этом случае при установке приложения создается директория WEB-INF/lib.

Вариант 3: Создайте файл prop.jar, как указано в Варианте 2, и сохраните его в EAR директории <WAS_INSTALL_ROOT>/profiles/AppSrv01/installedApps/myNode01Cell/TestClintOptEAR.ear

Добавьте указание на prop.jar к файлу MANIFEST.MF, соответствующему всем модулям приложения, которые должны использовать свойства оптимизации pureQuery из файла prop.jar. Например, модифицируйте файл MANIFEST.MF, соответствующий модулю TestClintOpt.war: <WAS_INSTALL_ROOT>/profiles/AppSrv01/installedApps/myNode01Cell/TestClintOptEAR.ear/ TestClintOpt.war/META-INF/MANIFEST.MF. По умолчанию в файле MANIFEST.MF указывается только информация о версии файла. Кроме того, вам необходимо добавить файл prop.jar к путям поиска классов. При изменении файла MANIFEST.MF новая запись должна быть сделана на новой строке. Не забудьте добавить новую строку в конец файла, как показано в листинге 2.

Manifest-Version: 1.0
Class-Path: <path>/prop.jar

Такой способ использования файлов свойств может применяться для приложений любого вида.

Если необходимо задать свойства оптимизации на уровне приложения для программ, которые содержат Web-модули и модули EJB, то предпочтительнее использовать третий вариант, так как в этом случае вам достаточно создать одну копию файла свойств. Добавьте запись, соответствующую файлу prop.jar, во все файлы MANIFEST.MF, используемые приложением. Тогда для изменения свойств оптимизации вам достаточно будет изменить один файл. Если приложение использует только Web-модули, наиболее предпочтительным с точки зрения простоты и удобства является первый вариант.

В начало

Примерный сценарий использования файлов свойств

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

В сложной Web-среде, использующей несколько приложений или несколько источников данных, для разных приложений может потребоваться использование различных настроек при обращении к различным источникам данных. Добиться правильного поведения приложения можно благодаря использованию свойств на уровне приложения. Если для приложения определены одновременно файлы pdq.appwide.properties и pdq.dataSourceName.properties, то используются значения свойств, заданные в этих двух файлах. Если одно и то же свойство определяется и в pdq.appwide.properties, и в pdq.dataSourceName.properties, то использоваться будет значение из pdq.dataSourceName.properties.

Следующий пример поясняет использование двух файлов свойств. В примере рассматриваются два приложения, использующие несколько источников данных, как показано на рисунке 5.

Приложение 1

Приложение 1 использует три источника данных, из которых DS1 и DS2 соответствуют двум различным базам данных DB2, а DS3 соответствует базе данных другого формата (Informix или любая другая СУБД, которая использует Data Server Driver for JDBC and SQLJ).

Предположим, что администратор уже собрал все SQL-запросы к источнику данных DS2 и теперь должен перейти к статическому выполнению SQL-запросов при работе с этим источником данных. Сбор SQL-запросов к источнику данных DS1 еще не закончено. Что касается источника данных DS3, хотя статическое выполнение инструкций для этого источника невозможно, администратор хочет, чтобы выполнять можно было только собранные SQL-инструкции.

Так как администратор уже готов перейти к статическому выполнению запросов к DS2, он может изменить свойства captureMode и executionMode для этого источника, указав их новые значения в файле pdq.ds2.properties. Новые значения будут заданы соответственно как captureMode OFF и executionMode STATIC. Для того чтобы полностью запретить динамическое выполнение любых инструкций, нужно присвоить значение FALSE параметру allowDynamicSQL FALSE. Определение значений параметров captureMode и executionMode для источника данных DS2 показано в листинге 3.

captureMode=OFF
executionMode=STATIC
pureQueryXml=app1_ds2.pdqxml

Поскольку сбор SQL-запросов к источнику данных DS1 еще не закончен, определение новых свойств для этого источника пока не требуется. Достаточно указать имя файла pureQueryXml, например: pureQueryXml=app1_ds1.pdqxml.

Чтобы предотвратить возможные SQL-инъекции при динамическом выполнении SQL-запросов к источнику данных DS3, администратор должен указать в файле pdq.ds3.properties значение TRUE для свойства captureMode и значение OFF для свойства capturedOnly, как показано в листинге 4:

captureMode=OFF
capturedOnly=TRUE
pureQueryXml=app1_ds3.pdqxml

Приложение 2

Это приложение использует только один источник данных - DS1. Первоначально приложение выполняется только для определения и сбора SQL-запросов. После того, как все запросы собраны, администратору нужно запустить Приложение 2 так, чтобы использовался только статический SQL. Однако администратор вовсе не желает изменять приложение и переустанавливать его. Для того чтобы оба приложения работали в требуемом режиме, необходимо использовать файл pdq.dataSourceName.properties для переопределения свойств, заданных на уровне приложений.

Чтобы при обращении к источнику данных DS1 исходное приложение использовало статический SQL, необходимо переопределить свойства captureMode и executionMode, задав их новые значения в файле pdq.ds1.properties. Листинг 5 демонстрирует настройки файла pdq.ds1.properties для Приложения 2.

captureMode=OFF
executionMode=STATIC
pureQueryXml=app2_ds1.pdqxml

На стороне DS1 вы можете установить различные свойства для разных приложений, используя соответствующий файл pdq.appwide.properties для каждого из приложений.

Окончательный вид конфигурации

Окончательный вид конфигурации использует два файла pdq.ds1.properties и два файла pdq.appwide.properties. Поскольку эти файлы находятся в разных директориях, соответствующих различным приложениям, каждый из указанных файлов применяется только к одному конкретному приложению.

В таблице 3 перечислены файлы и свойства, определенные для Приложения 1.

Файлы и свойства Приложения 2 приведены в таблице 4

При подключении к базе данных DB1 источник данных DS1 использует файл app1.ds1.pdqxml (для Приложения 1) и файл app2.ds1.pdqxml (для Приложения 2). При подключении к базе данных DB2 источник данных DS2 использует файл app1.ds2.pdqxml (для Приложения 1). При подключении к базе данных DB3 источник данных DS3 использует файл app1.ds3.pdqxml (для Приложения 1).

Схема работы такой конфигурации показана на Рисунке 6.

В начало

Заключение

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

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

Благодарности

Авторы выражают свою искреннюю признательность Кристоферу Фаррару (Christopher M Farrar), Катрин Зейденштайн (Kathryn Zeidenstein) и Патрику Титцлеру (Patrick Titzler) за участие в отборе и редактировании материалов для данной статьи.

Ресурсы

Научиться

• Оригинал статьи: Managing pureQuery client optimization in Web application environments, Part 1: Optimize applications on a single application server node (EN).
  
  
• Прочтите статью "No Excuses" Database Programming for Java (EN) для более подробного знакомства со статическим SQL и его преимуществами.
  
  
• Узнайте больше о технологии оптимизации клиента из учебного пособия Optimize your existing JDBC applications using pureQuery (EN).
  
  
• Ознакомьтесь с детальной информацией о настройках пула соединений для сбрасывания подключения, приведенной в статье Changing connection pool settings with the wsadmin tool (EN).
  
  
• Подробнее о работе со средствами администрирования WebSphere Application Server и об использовании их для написания JACL-скриптов вы можете узнать, прочитав статью Starting the wsadmin scripting client (EN).
  
  
• Системные требования для работы с pureQuery на Linux, Unix и Windows приведены на странице System requirements for pureQuery Runtime for Linux, UNIX, and Windows (EN).
  
  
• Здесь (EN) вы можете найти системные требования для работы с pureQuery Runtime версии 2.2.0.1 на Linux, Unix и Windows 2.2.0.1.
  
  
• С вопросами по поводу установки и планирования работы pureQuery обратитесь в службу поддержки IBM.
  
  
• Узнайте больше о решениях Optim на страничке семейства продуктов Optim developerWorks (EN). Вашему вниманию предлагается техническая документация, рекомендации и ответы на вопросы, образовательные статьи, информация о продуктах и версии для загрузки, а также многое другое.
  
  
• Пользовательскую документацию по настройке Web-приложений вы можете найти на страничке Integrated Data Management Information Center (EN).
  
  
• Статья Integrated Data Management: Managing data across its lifecycle (EN) (developerWorks, июнь 2009 г.) познакомит вас с задачами и возможностями интегрированного управления данными на различных этапах работы с данными.
  
  
• Демо-ролик Optim solutions for accelerating Java database access на примере гипотетической организации рассказывает о том, как компании могут использовать решения Optim для более эффективного определения проблемных мест, повышения производительности работы системы и сокращения сроков разработки приложений. (EN)
  
  
• Вы можете подробнее познакомиться с технологией оптимизации клиента, посетив страницу программы виртуальных технических брифингов IDM (EN) и зарегистрировавшись для просмотра презентаций и роликов, представленных в этом разделе 4 февраля 2010.
  
  
• Чтобы быть в курсе последних новостей, посещайте сайт технических мероприятий и Web-трансляций developerWorks.(EN)
  
  

Получить продукты и технологии

• На страничке ознакомительных и бесплатных продуктов Data Studio и Optim можно загрузить пробные версии продуктов, включая Optim Development Studio с лицензией, дающей право на использование среды Optim Development Studio и pureQuery Runtime для разработки приложений на одном компьютере в течение 30 дней. (EN)
  
  
• Используйте в вашем следующем программном проекте ознакомительные версии ПО IBM, которые можно скачать непосредственно с сайта developerWorks.
  
  

Обсудить

• Примите участие в обсуждении материала на форуме.
  
  
• Посетите блог экспертов Integrated Data Management и страничку сообщества Integrated Data Management, где вы можете найти обширный список ресурсов и продуктов для загрузки. (EN)
  
  
• Участвуйте в блогах developerWorks и станьте членом сообщества developerWorks.(EN)
  
  

Об авторах

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Краткий обзор процесса оптимизации клиентских приложений
• Использование пакета pureQuery Runtime на сервере приложений
• Обзор настроек среды pureQuery Runtime для оптимизации клиента
• Настройка свойств pureQuery на уровне приложения
• Примерный сценарий использования файлов свойств
• Заключение
• Ресурсы
• Об авторах
• Комментарии